My Game Jam Philosophy

I wanted to share my philosophy about how I make game jam entries in hopes that others will find it useful, but please remember that the only criteria is that you make something that you are happy with.

1) Players want to get to the "good stuff" as soon as possible and will ignore instructions

Players can be very impatient, and game jam players are especially so. Players will mash whatever buttons let them get to the "good part" as soon as possible, even if they're ill-equipped for it. A lot of entries think they can solve this with enough exposition in the description of the game (the only place some entries put their controls), but I strive to never have to get to that point. Introduce mechanics one at a time and guide the player through each step. It can feel like you are holding the player's hand, but given the limited nature of game jams, most people will only play your game once. They can either experience exactly what you want them to, or something that probably isn't as good.

2) Put your controls on screen when they are introduced

Some games have only a few controls, others have several that are introduced over time. In either case it's to your advantage to show them on screen when first needed. If your game engine can render text, use that. It doesn't have to be pretty. Once you know the player has figured it out, you can hide the controls. If you're making a top down game, put them where your character spawns, so when they move around the controls naturally scroll off screen. If you have a new section to your game, or a new mechanic, tell the player what the new controls are (and preferably, immediately demonstrate how the new mechanic works).

If your game uses mouse input, communicate this by having a main menu or modal that requires the player to click it to proceed. Make whatever they need to click obviously clickable. Make it look like a button and (if you have time) have it highlight on mouse hover.

3) You are a terrible tester and so is your team

If you're a programmer on your team, you know how to beat the computer, because you wrote its code. Even if you're not a programmer, you know the genre of the game, and can infer a lot about how to play it. Your best asset is someone who knows absolutely nothing about your game. Once your game is near completion, find a friend, relative, or anyone you can borrow for 5 minutes and have them play your game while you watch them. You can tell them that it's a game jam entry, and what the theme is (since that's context a lot of your players are coming in with), but that's it. If they get stuck, don't immediately tell them how to proceed, observe how they try to proceed. Don't insist that they read your instructions. If they don't read your instructions, a normal player probably won't either. Take note of what went wrong and fix it.

4) Finish your game early

One of the biggest shock factors for first-time game jammers is just how little time you have. It doesn't matter if the jam is 2 days, a week, or a month, you will over estimate your time. Lots of people suggest combating this by limiting your scope, and that's a good start, but my approach is a little different: I try to "finish" my game as soon as possible. The game isn't actually finished, but I try to get my game in a state where it is "submission ready." It's in a state where, if I had a sudden emergency, I could submit it as-is and be happy with it. It's not the game that I wanted to make, but it's good enough. If I have time, which I usually do, I make it even better. The sooner you get to this point, the better. If you're struggling to get there, then start cutting features.

5) If your game has an ending, communicate how to get there

Lots of game jam entries go on forever, gradually increasing in difficulty (and there's nothing wrong with that!). But, if your game does have an ending, it can be frustrating to receive feedback from players who clearly didn't reach it. Tell them how to get there. Add some sort of counter, progress bar, whatever makes it obvious that there's an end. Otherwise, lots of people will assume, "Oh well, this is it I guess, next game." The quality of feedback (and ratings!) you get will be substantially better if players feel that they got the complete experience.

6) Code quality is not important

On this point, some might disagree, but if you're spending a lot of time writing "good" code then that's time you're not spending moving the game design forward. It may be that you're entering game jams to improve at programming, and if that's the case, don't let me try to stop you. However, any good engineer will tell you that code that works now is better than code that never works at all. You're not writing flight critical code and there is a tremendous amount of leniency for bugs and jank in game jam entries. It's part of their charm.