-= kpworld.xyz =-

KP's Declassified Game Jam Survival Guide


So you're new to game jams, possibly Ludum Dare or one of the many itch.io events. Maybe you're still hesitant to join a jam, or you're a veteran looking to step up your game(s). Here's some of my tips to get you through the competition.

Preparing for the jam

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 beverage of choice, mine personally being Monster Energy® Zero Ultra™. I find it's best to not make any sudden changes to your sleep schedule before the start of the jam, 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 bored. Others may find it easier to concentrate while listening to white noise, rain, etc. as well.

The development environment

I'd say 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.

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.

"But I'm not confident"

Who cares? Game jams are one of the best ways to improve. They give you a sense of what true crunch is like without diving into the industry and when you're forced to make something in the span of a few days, weeks, etc. you pick up a few things you otherwise wouldn't have.

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 dev cycle.

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.

Use MS Paint as a level editor

Here's a trick I've been using 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.

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.

Forget encapsulation

You aren't designing an API, you're writing a game, and you don't have a lot of time to do so.

Avoid shotgun debugging

It's probably tempting and we're all guilty of doing it at some point, but when you're already tired and can't think straight it's only going to get in the way of your development. This goes back to the topic of development environments, you want to make sure you have a nice set of debugging tools by your side and most importantly, understand how to use them effectively.

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.

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.

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.


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.

Acknowledge your ambition

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 just be like that sometimes. It really do.

If something looks even slightly cool, Tweet it

This is how you get followers as well as others outside the jam community to play your game.

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.

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.

Have fun and don't panic

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 a perfect game, you start to pick up on its flaws. The game doesn't really fit the theme, you can't finish it in time, etc...

Usually when this happens, participants will keep chugging along even if they damn well know they aren't gonna be happy with the finished game. This is a horrible idea. To me you should prioritize the integrity of your game design over being able to say "Yeah, I made something in 48 hours". But if you feel hopeless, always remember that there's nothing wrong with dropping out of the jam to make a game you'll actually be happy with.

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.