KP's Declassified Game Jam Survival Guide

Here's a list of things I wish I had known when I first started entering game jams.

1. Be prepared

It's always best to go on a small shopping trip before the jam begins. It's a good idea to buy some (relatively healthy) food as well as your favorite beverage(s). I find it's best to not make any sudden changes to your sleep schedule before the start of the jam as well, though in some cases this might be unavoidable.

Put together a nice music playlist, ideally one that's long and has enough variety that you don't get tired of it. Others may find it easier to concentrate while listening to white noise, rain, etc. too.

2. Know your tools

You should have a consistent development environment weeks before the jam starts. Familiarize yourself with whatever editors, IDEs, libraries/frameworks/engines you're going to use ASAP. For more experienced jammers this is trivial, but starting out it's best to just stick to your guns and write code that does stuff immediately.

3. Don't listen to engine snobs

At the end of the day you should make your game with whatever suits your workflow the best. Nobody is really going to care if you use Unity, GameMaker, Godot, UE4, etc. as long as you make a good game. Obviously your game will have some "Unity-isms" or "Unreal-isms" that make it stand out, but stuff like that is kinda expected for jam entries.

Likewise, you should also ignore those telling you not to use your own tech. As long as you know what you're doing and you're confident in your ability to work fast, that's all that matters.

4. Write code that gets stuff done

Going back to my third point, one of your biggest priorities when making a jam game should be writing code that does stuff. Don't worry about clean abstractions or making the source as pretty as possible, focus on the game instead.

Nobody is gonna care that you hacked something together with std::vector instead of writing a robust ECS. What people are going to notice is your "robust" ECS falling apart because you tried to cram something that requires extensive testing into a 48 hour development cycle.

5. Regularly test your WebGL builds

This applies to any engine. There's always something that can break and with more and more people preferring web builds over their desktop counterparts, you have to meticulously test these.

6. Use MS Paint as a level editor

Here's a trick I've used for years. Instead of going through the painstaking process of writing a TMX parser, learning to use Tiled, etc. you can create your maps in MS Paint and treat every pixel as a tile. This gives you 4 bytes of data to work with per cell, which is usually more than enough for small 2D games.

If you're extra nerd-y like me, you can also just roll your own map editor :^)

7. Test with vertical sync disabled

This ensures your game loop timing is accurate and makes any accidental fuzz between game logic and rendering more noticeable. Many drivers will force V-SYNC off unless otherwise specified, so forgetting this will cause your game to potentially be unplayable for others.

8. Make your errors loud and clear

You don't wanna be that guy going "uhhh try running it from the command line", throw up some message boxes whenever, say, a single resource fails to load. Don't check for everything, but if a single image for instance can't be loaded that's probably an indicator the user forgot to extract the zip, misplaced the executable, etc.

9. Don't write your own platform independence layer

You could say this contradicts my third point but this is one of those things where there's hardly any benefit to doing it on your own, and I can't say it's exactly "fun" either. I suggest using SDL2, but many others exist as well.

10. Make everything a template

If there's anything that can be reduced to some kind of template, make one. I've done this before to speed up the process of writing boilerplate code, creating spritesheets, etc.

Notice that none of this involves making a full-blown engine. In game jams, it's more beneficial to just write code snippets you can reuse across projects, not a massive engine where everything has to be "baked in" in my opinion. Wrote some code to implement platformer physics? Keep it, abstract it a little bit, and next time you enter a jam, you can save yourself half an hour of work.

11. Don't force yourself to stay up

Despite the notion of game jams being an intense crunch experience involving no sleep and many energy drinks, you should still approach smaller jams (i.e. Ludum Dare) like you're making a game in two days, not 48 hours. Staying up for the hell of it when you know you aren't performing at your best is only going to delay your development process.

12. Acknowledge your ambitions and limitations

Most jam games are ultimately 50% of what the developer had in mind. Don't be discouraged when most of your ideas lead to nothing, it's really more about the fun of making something than the end result.

13. If something looks even slightly cool, Tweet it

This is how you get new followers, as well as get existing ones (maybe even some others outside the jam community) to play your game.

14. Consider livestreaming your development

Livestreaming your development is a good way to keep yourself focused and engaged with the community. When people are watching and you're trying to maintain viewership, it motivates you to keep going. It does for me at least. I guess interacting with the chat can be a distraction, but streaming forces me to keep programming instead of drifting off to Twitter or some other distraction.

15. Join community IRC channels and Discord servers

Another good source of motivation is the plethora of community chatrooms, post screencaps of your progress and get to know the other participants. I can vouch for the Ludum Dare IRC community, lots of excellent people there.

16. Have fun, don't panic, and plan things out!

Game jams can be very taxing on a person. In jam communities there's this joke about the dreaded "mid-jam crisis", it's happened to all of us at some point. You become attached to your project and after putting all your eggs in the basket to make the perfect game, you start to pick up on its worst flaws. It isn't fun, it doesn't really fit the theme, you can't finish it in time, etc...

If you're dead set on making the deadline, you can prevent this "mid-jam crisis" by spending more time fleshing out your ideas before writing a single line of code. Forcing yourself to take breaks can also go a long way.

Remember that you can always make a post-jam version if you're unhappy with how the 48-/72-hour product came out.

The important thing is to enjoy yourself!!!1234

Last updated November 7th, 2019 at 07:15 PM CST