Building a playable and presentable game in one week is no joke. In October we attended Epic Game’s biggest game jam to date, the Epic MegaJam. We would like to share our experience on how we accomplished it through scheduling, prioritizing features, coming up with the minimum viable product, and incremental playtesting. You’ll find that it applies to all forms of game development and not just to game jams. To see where it took us, here’s a gameplay trailer of our submission, Mind the Traps.
In the end you’ll find the download links for the winners of the MegaJam. I highly recommend playing their games for your learning.
Half of our team had school or a day job, so scheduling was key to get us started and to ensure we would finish the game on time. We listed out the phases of development, assigned what needs to be accomplished in each phase, and allocated the number of hours to be spent in each phase.
1. Choose an awards category (30 minutes)
Choosing an award to aim for helped create the framework for our game’s design. We wanted to make a game that we would enjoy making and potentially sell, so given our quirky personalities and love for multiplayer party games it made the most sense that we target the Addiction (most fun) award.
2. Brainstorm ideas (3 hours)
Games in the Addiction category generally focus on gameplay, as opposed to visuals, music or interpretation of theme. We came up with at least 10 different ideas and went with a voting system to filter the number of ideas from 10 to 3 to 1.
The selected concept was a “dungeon crawler, multiplayer party game. Players have no weapons and bump into each other into the darkness to figure out the path ahead.”
- One week isn’t enough time to learn new technical skills, so brainstorm ideas that are feasible.
- The more ideas you come up with, the more creative you get, the better the game you can make.
- Think simple. Throwing around complex ideas has the tendency to impede discussion with your teammates. Let’s say the game jam’s theme is impossible puzzles, so you bring up an idea for a “first person shooter in an M.C. Escher-esque world fighting rainbow-barfing unicorns.” It’s natural for the listener to think that’s ridiculous and reject it right off the bat because it’s so loaded. What if instead you said: “a first person game in an M.C. Escher-esque world?” This concept is interesting but vague enough to give your teammates something to work with. That’s how you stimulate discussion and get the creative juices flowing.
3. Plan out the minimum viable product (3 hours)
The minimum viable product is the minimally playable version of your game with only the most important features implemented. The rest of the features that enhance your game are listed in order of priority to be implemented later. This is a risk averse approach to building your game that ensures you have a playable game that fits your vision and is ready by the deadline.
Imagine that making your game is like an RPG: each additional feature you want to add is a new boss you have to defeat. If you come across a difficult boss that wrecks you, do you want to restart all the way back to the beginning of the game and lose all your progress? Of course not! You want to respawn at the previous checkpoint where you killed the last boss and keep all the items and upgrades you made.
The same goes for you and your game’s development. That’s why the MVP is so important to plan out this early on. The list of prioritized features is a set of predetermined checkpoints that ensures you’ll always have a playable game, no matter where you crash during its development.
Other benefits to this approach are:
- You have something playable/functional very early.
- Customers/followers are aware your game is working.
- From this point forward you only have to work on features that make the game better.
- You can incrementally playtest and debug.
- You always have a working version no matter where your game crashes.
We broke down our game concept into a list of features arranged by “fun” factor and how critical it is to the gameplay. We included additional features that weren’t important but would enhance the game if we had time to implement them. The prioritized list of features were:
- Basic character movement for single player
- Multiplayer on a local PC
- Multiplayer interactions (push, bump)
- Gems (incentive for players to fight each other)
Because player-to-player interactions is key to the fun-ness of our game, we concluded that the minimally playable version of our game must have the first three features—basic character movement, multiplayer on a PC, and multiplayer interactions.
4. Prototype (1 day)
We immediately prototyped the MVP with placeholder assets and playtested it with friends and family. We were told the controls felt solid, the gameplay was fun, and the player’s goal was immediately clear. This was a sign that we were on the right track, so we finalized the mechanics and cleaned up the code in preparation for making levels.
Since gems and traps were easy to implement, we included those as well.
It’s sometimes easy for playtesters to quickly judge a prototype the wrong way because it’s not visually appealing or because it’s not that fun. We had to remind them to focus and provide feedback on gameplay only.
5. Create levels and incrementally playtest (3 days)
We used an incremental build model, meaning we playtested and debugged each level as it was made. This proactive, versus reactive, approach was extremely beneficial because the incremental feedback allowed the level designer to create progressively better levels without spending too much time fixing the older levels. It also allowed the coder to take care of each bug as they popped up before it became too much to handle.
Our playtesting focused specifically on gameplay because we were targeting the Addiction award. We made sure each level was fun, challenging, not frustrating and able to be completed in a reasonable amount of time. The judges were going to look at over 170 game submissions in a week, so we expected their playtime to be around 30 minutes per game.
For level creation, we continued to use placeholder assets for everything (cubes for walls, cubes for characters, spheres for enemies, fire particles in the starter content, etc.).
Don’t get hung up on small details. Our level designer was a perfectionist and would make sure each wall and platform were placed perfectly next to each other—no gaps allowed! It added up to a good amount of time wasted. In the end it’s better to have a complete game with imperfections than to have an incomplete game.
6. Add custom assets (1 day)
Fortunately, we had an artist and musician on board who were already making assets halfway through the week. But because gameplay was a higher priority, we didn’t start incorporating the assets until level creation and playtesting were complete.
7. Buffer time (1 day)
Last but not least, you have to allocate buffer time for a rainy day. Time and time again, history has shown that a game almost never finishes on time, so we took this into account and planned for an entire day of debugging assuming the worst-case scenario happens. How much buffer time you need depends on the scope of your game, skillsets, technical limitations and personal responsibilities.
If no last-minute issues pop up during this time, great! Utilize this free time to add the extra features that will make your game even better.
Although we didn’t win, the game jam provided such a huge learning experience that taught us how to operate efficiently and with minimal risk. The process of scheduling, prioritizing features, planning out the minimum viable product (MVP), and incrementally playtesting is applicable to game development in general and not just in game jams. We hope you learned something new from our experience.
Listed below are the winners of the MegaJam. Judging is subjective and can vary between game jams; nonetheless, these were really well made games and are worth downloading for your learning. You can check out the other contestants’ games on the Epic MegaJam forum.
- Addiction Award (most fun): Midnight Mall Race by Sleepless Meatbags V2.0
- Philosophy Award (best interpretation of theme): Omnitron by Handkor
- Eye Candy Award (best visuals): Guardians by Blazing Badger. You can also check out their detailed post on how they made the game.
- Allegorithmic’s Pick: (R)evolution Jumpers by Digital Hussars, Sir Isaac Fruiton by Impromptu Pub Giants, Guardians by Blazing Badger
I received approval from Epic Games to share these games.