A quick guide on how to win a Game Jam
Have you ever considered joining any coding marathon like a Game Jam, but were too afraid to do it? Or did you join one and it didn’t go as you planned? If your answer to any of those question was ‘Yes’ – don’t worry. It happened to most (if not all) of us. Here is a quick guide on how to organise your work and team to make a successful project during 48 hours. Although this guide is based on experience from Game Jam events, basic concept and rules are applicable to any coding marathon.
The Greatest Enemy: Time
Usually every coding marathon has a strict time constraint. The participants of Game Jams have about 48 hours from the start of the event to upload final executable files. So it is crucial to make every hour count. Here are some basic things that you can do before the event to save some time during it:
- Form a team. It may look like a minor problem, or even contradictory to event spirit, but it’s quite useful. If you build a team beforehand, you will know its members’ strengths and weaknesses ahead and will not waste your precious time on finding out who’s good at what during the event.
- Prepare equipment. Make sure everyone has what they need to work e.g. PCs, laptops, graphics tablets etc. Of course you should also prepare all the software you are going to need: IDE, game engine, graphics program/s, audio mixers and so on. There is no point in wasting few hours because someone for example didn’t have system variable set correctly.
- Configure environment. Create GIT, SVN, TFS or any repository you are going to need. Create an empty project and push it to the repository. Have every member of the team download it and run locally to make sure everything is well connected and configured.
These are the things that you can do for almost every project/coding marathon before the event starts.
How to divide your time
This is an example of how you can divide your time efficiently during the entire event:
- 10% planning application/game/features,
- 20% creating basic working version,
- 20% adding features,
- 20% testing, debugging and final polishing,
- 5% preparing presentation,
- 25% resting, sleeping and eating.
Of course this will vary depending on your team capabilities and specifics of the project, but the general rule is not to neglect design, tests and not to code while when making a timetable. This will allow you to create a working solution, add additional features and develop a stable and relatively bug-free game. And here is the anti-pattern you’d better not follow:
- 2% planning,
- 90% creating a working version,
- 8% adding features.
It is most likely going to fail due to one simple fact – if it turns out you need 20% more time than you originally intended to build a working version of your application you will not manage to meet the deadline.
Good and bad ideas
There are multiple principles that people stick to during coding marathons, but my favourite are:
Basically they encourage people to do things as simple as possible without adding anything that you aren’t 100% sure that will be used later. Here are some other things that you should do during events like a Game Jam:
- Use Lean Start-up methodology, especially focus on creating MVP. This will allow you to minimise waste in your project and bring the best results in a given time limit.
- Focus on a single Idea. You usually will not have enough time to implement multiple core mechanics. This doesn’t include adding features, after you have built simple but working MVP.
- Get rid of any potential risk early. By risk I mean any technological or non-technological issue that you are not 100% sure how to do or how much time it will take. For example, if you are not sure how to implement a core mechanism other things will depend on – it should be the first thing you finish in the project.
- Prepare the final build several hours before the deadline. Then test it. If any major issue comes up – fix it, build your project again and retest it. Don’t start building your project 15 minutes before the deadline. There is always a chance of failure and you will not have your working solution when deadline comes.
- Practise presentation skills. Many people say that: “good product will speak for itself”, but consider this: best products have excellent marketing. Coincidence? I don’t think so…
And there are several things you should not do:
- Use unknown software. It may seem like a good idea to try out new software during a coding marathon, but if you get stuck with a problem you may lose several hours instead of several minutes trying to fix it.
- Try to stay awake for 48h. It sounds really cool, but after 6-8 hours your performance will decrease and after 12-16 you will start to make simple mistakes (that you wouldn’t normally do) which will take you significant time to fix.
- Try to make too many features. Make a few really cool features that will be really polished. Otherwise you may end up with multiple features but none of them will actually work.
- Overlook details. I don’t mean minor details but clearly visible ones. If it takes you a minute to fix them – do it. Getting rid of minor bugs usually greatly improves user experience.
- Hide your idea. If you have a good idea for a game/application – share it with other participants of the event. Don’t worry – no one is going to steal it. Instead, you may get some valuable feedback that will allow you to perfect your solution.
Goal
Everyone has a different goal when going to a Game Jam and the above rules will not apply to everyone. But that is ok. If you go to a Game Jam and you have fun – you are doing it right, because that is what the event is all about.
So I assume you have won last jam? 🙂