The game jam checklist and troubleshooting tips
It's been awhile but I am thinking about game jams again. I have been part of over 10 game jams (I think I lost count, but it's around that number). This weekend made me feel more up to it seeing Ludum Dare 36 kick off. It's always been a bit intimidating to participate in that particular game jam, as the community feels a bit too technical, and for some reason that (imaginary) bar is set a bit higher than other jams. The amount of cool games that come from the event is probably what made me stop each time in awe and struck me as a jam to be amazing at. This is all in my head of course, as the game jam experience is what you make them out to be as a participant. I'll probably see if I can do an LD entry in October. The October jam only has one objective which lasts the month: publish the game and make at least $1. I think I would like to try that as my initiation into Ludum Dare, unless I miraculously do something tiny for LD36.
Anyways, I wanted to share the game jam checklist with troubleshooting tips that I recently re-updated, which I would copy into the post below. I also have it as a downloadable PDF file to keep or print out.
Game Jam Checklist
These are suggestions and may help as a sanity check before and during a jam.
A. Materials before the jam
|1. Program installations (Game Creation tools, IDEs, Audio, Graphics).|
|2. Extensions, USB drives/storage, headphones, adapters, cables, fans.|
|3. Tablets, microphones, extra equipment like controllers or other inputs.|
|4. Mobile devices, tablets or consoles as necessary.|
|5. A (web) camera or mobile phone for photo & video documentation.|
B. Logistics on Friday
|1. Form a team and pick someone who is project-responsible.|
|2. Find a place for your team, sort out (wireless) internet access.|
|3. Plus points if you sort out whiteboard access, team schedule and roles.|
|4. Know where to find support and where to find food and supplies.|
|5. Prepare or make it easier to submit (e.g. a project page on itch.io).|
C. Game Idea on Friday
|1. Brainstorm/ideate on game ideas. Look over the brief and any supplements.|
|2. Rapidly prototype ideas through paper, whiteboard or digitally.|
|3. Evaluate your ideas and find ways to vote on them.|
|4. Keep the idea simple, you can make it complex later. Or way, way later.|
|5. Always have a backup plan. Have a good sleep schedule.|
D. Game Prototyping on Saturday
|1. You should be well on your way with game creation.|
|2. Check that people are well fed and drinking enough water (or choice of drink).|
|3. If people have not slept Friday night, a nap or a walk may be good.|
|4. Update the project page with title, description, names and roles.|
|5. Take photos of your playtesting/progress and start forming your documentation.|
|6. Game jams sometimes have some kind of activity/talk during the afternoon.|
E. Deliverable on Sunday
|1. Create a zip file for the source, resources and print&play files as needed.|
|2. Create an executable for public play for digital games.|
|3. Update the project page with all the necessary details to get the game running.|
|4. Upload screenshots/action shots on the project page.|
|5. Upload source files and executable to the project page.|
|6. (Optional) A gameplay video which is also uploaded (e.g. to YouTube/Vimeo).|
|7. Submit before the deadline at (what usually is) 15:00!|
F. Last few things on Sunday (for local game jams)
|1. Clear and clean up your area and work space. Leave things as you found it.|
|2. Set up your game in the demo space. Usually there’s a space dedicated.|
|3. One team member should host the demo, but make time so everyone gets to check out everyone else’s games at the game show.|
Practical troubleshooting tips
A quick reference of things to look out for during the course of the game jam.
A. Division of different tasks
(not to be confused as roles; everyone may contribute)
- Coding/programming/version control
- Artwork/assets including character design
- Game Mechanics
- Level/map Design
- Music/sound and audio
- Quality Assurance/feedback and user testing
B. When stuck or struggling
- Check if there are other priorities, the details may be minor and disregarded.
- Reassess if making it technically work is worth it, and how much time it will take.
- Attempt to divide the problem into smaller ones, and among team members.
- Look for external feedback and accept critique to change the design.
- Look for creative alternatives or easier solutions and playtest them.
- Take a short break and revisit the issue later. Napping, sleeping or eating may help.
C. Recommended habits
- A shared folder to collaborate together on. Google Drive works fine, for example.
- A form of version control (e.g. GitHub, Bitbucket, Mercurial, script, or manually copying).
- Put up a schedule where everyone can easily see it. Preferably on a whiteboard.
- Shared working area, and a quiet (maybe dark) isolated area for sleep.
- Save early and often, playtest early and often. Take breaks early and often.
- Build-test-repeat and be sure to always have something playable.
- Rotate working hours so the work process and flow is more natural (e.g. when one coder sleeps another can take their place to avoid the need to merge code).
- Rotate hours for assets and graphics only to keep sanity and sleep deprivation at bay.
- Keep a positive vibe and remember the time dedicated to this is for fun.
D. Quick overview checklist
- (Philosophical) What defines a game?
- Do the core mechanics work?
- Does it relate to or challenge the theme?
- Is this a game of quality?
- Is the gameplay fun?
- Does it have good game flow, challenge and feel?
- Is the game compelling or intriguing?
- Has there been at least three different playtest sessions?
- How long does gameplay last?
- Is it understandable, and can players get it?
- Does the game have music or audio?
- Have you added juice?
E. Game specifics
- (Recommended) A minimum resolution of 1024x768
- Player controls, mechanics and gameplay work
- Game challenge and game flow are balanced
- Menus for starting and ending the game, and a help screen if needed
- If the game ends, you should be able to easily start/retry the game
- Audio (especially music) add to the game and it’s presentation
- External user testing or feedback needs to be conducted
- The deliverable exists (optimally a zipped file for ease of download):
- A readme with a short description, credits/contacts, help to get started and links to any dependencies
- Executables and libraries
- Source files
- Screenshots (3 are optimal)
- (Optional) Presentation, Gameplay Video, Gamelog, Design document and other documentation
That's all of it. Remember you can get the full content of the checklist and tips as a PDF file as well to keep and print. I think this is a good thing to have handy as it gives you important information at-a-glance and calms the nerves a little if you are in need of some organization or direction.