What a game jam is
A game jam is an event where participants make a game within a fixed time limit, often a weekend, sometimes a week or longer. Most are organized around a theme announced at the start. Participants work alone or in small groups, submit what they have when time runs out, and usually play and comment on one another’s entries.
Jams are not a business. They are closer to a sketching session. The point is to practice, experiment and finish something, which is exactly why they suit people at the beginning of their game-making.
Common formats
Formats vary widely, but a few patterns are common.
- Short solo jams. One person, one weekend. These are the most intense and the most forgiving, because expectations are low and everyone is in the same position.
- Team jams. Groups of two to five people split design, code, art and sound. They add coordination work, so a team needs a plan for who owns what.
- Long jams. Lasting a week or a month, these allow more polish and reward people who prefer a steadier pace.
- Themed or constrained jams. Some add rules beyond the theme, such as limiting the palette, the number of buttons or the file size. Constraints can be liberating because they narrow the choices.
Each event publishes its own rules about what you may use, such as pre-existing code, engines or asset packs. Read them before you begin so your entry is eligible.
How themes work
A theme is usually a word or short phrase, such as “gravity” or “small steps,” revealed at the start. It exists to give everyone a creative prompt, not a strict brief. Interpretations are encouraged to be loose: some people follow the theme literally, others use it in the story, others in the mechanic.
A helpful approach is to list several interpretations quickly, pick one that suggests a clear action for the player, and discard the rest. A theme that points to a verb, such as pushing, stacking or dodging, is easier to build around than one that suggests only a mood.
Preparing before the start
You cannot design the game in advance, but you can prepare.
- Set up your tools and test them, including your editor, image program and audio tools, so the first hour is not spent on installation.
- Decide how you will back up your work. Keeping the project in version control costs very little and protects against the disaster of a corrupted file at hour thirty.
- Plan your schedule, including sleep. Tired developers make more mistakes and often finish less than rested ones.
A sensible schedule
Time limits make scope the central skill. A rough pattern many people find helpful for a weekend looks like this.
- First few hours: choose the idea, define the one action that will carry the game, and write down what is out.
- Next stretch: build a rough playable version as early as possible. Anything that is not playable cannot be judged.
- Middle: add the features that make the central action more interesting, one at a time.
- Final stretch: stop adding. Fix bugs, add a title and instructions, and make sure the game can be started and finished by someone who has never seen it.
The last point is easy to forget. Many jam entries are fun for their makers but impossible for others to start. A short on-screen instruction and a clear ending can matter as much as any feature.
Cutting is constant work. If a feature is not in a playable state by the halfway point, it is often better to cut it than to rush it.
Common pitfalls
- Starting too big. The most common problem. Pick something you could comfortably finish in half the time.
- Art before play. Beautiful assets for an unplayable game are wasted effort. Use simple shapes first.
- No submission buffer. Upload problems happen. Leave time at the end, and stick with tools you already know rather than trying a new engine mid-event.
What to take away
The real value of a jam comes afterward. A few ways to get the most from one:
Finish and share. A finished, imperfect game teaches more than an unfinished ambitious one. Publish it and read the comments, remembering that comments from other participants are informal and vary in quality.
Write a short review. Note what you completed, what you cut and why, and what surprised you. This is a small version of a project postmortem, and it works well at jam scale because the memory is fresh.
Keep the best idea. Some jam prototypes contain a promising core. If one does, you can test it with a few players before deciding whether it deserves a larger project. Treat it as a starting point, not a finished design.
Do not overcorrect. The pace of a jam is deliberately extreme. It is not a model for normal development, and working through the night is not something a long project can sustain. Use the lessons about scope and focus, and leave the all-nighters behind.
Outcomes such as ratings or rankings are uncertain and depend on many things, including how many people see your entry. A better measure of success is whether you finished a game and learned something while making it.