Game jams

Why this matters

A game jamAn event where people make a game in a fixed, short time, usually around a theme announced at the start. is an event where people make a game in a fixed, short time, usually around a theme announced at the start. Ludum Dare (48-hour solo and 72-hour team formats), Global Game Jam (a weekend, often at local sites) and the hundreds of online jams listed on itch.io are the best-known. For an aspiring designer, jams are the fastest way to build a portfolio of finished games, practise scoping, and meet collaborators. Many studios read jam entries when hiring, because a small finished game shows more than a large unfinished one.

The real skill is scope

Almost every failed jam game fails the same way: too big. The idea is fine; the plan assumes everything will work first time. Experienced jammers design for about a third of the time they have, because the rest disappears into bugs, art, sound, menus, building and uploading.

Start from one sentence:

"You are a lighthouse keeper who rotates the beam to guide boats past rocks."

That sentence is the core mechanicThe one main action the game is built around; features that do not improve it wait.. If a feature does not make that mechanic more interesting, it waits.

A 48-hour plan

Sleep is in the plan on purpose. Tired developers write bugs that cost more time than they save.

Must, should, could

Write every feature on a list and sort it:

• MustA feature without which there is no game, such as movement, the core mechanic, losing and restarting.: without it there is no game (move, the core mechanic, lose, restart).
• Should: makes it much better (three levels, sound, a score).
• CouldA feature that is nice if time allows and is the first to be cut.: nice if time allows (leaderboard, story intro, extra enemy type).

Build all the musts before any should. When you fall behind (you will), cut from the bottom. A story intro is never worth a broken core loop.

Worked example: cutting a plan

Theme: "Deeper and deeper". First idea: a submarine game with an upgrade shop, five biomes, a boss and a crafting system. Applying the rules:

• Core sentence: "Steer a falling submarine between hazards as it speeds up."
• Must: steering, hazards, speed increasing with depth, collision, depth score, restart.
• Should: two hazard types, sound, a high score in memory.
• Could: one upgrade between runs, a second biome palette.
• Cut entirely: crafting, boss, shop with many items.

The cut version reuses the AABB collision, game loop and state machine you already wrote and is realistic for one person in 48 hours.

Working in a team

• Agree on the engine and version before the jam starts.
• Use version control from the first hour; decide who owns which files or scenes to avoid merge conflicts.
• Artists and musicians need specifications early: sizes, palette, file formats, how many animations.
• Hold a five-minute check-in every few hours: what is done, what is blocked, what is being cut.

Rules and etiquette

Each jam has rules about what you may use (pre-made assets, existing code, AI-generated content) and when the theme may be used. Read them on the official page before you start; they differ between events. Credit every asset you did not make, with its licence. Rate and comment on other entries: jam communities run on feedback, and playing others' games is one of the best ways to learn.

Common mistakes

• Starting with menus and art instead of the core mechanic.
• No fail state or restart, so testers play once and stop.
• Testing only in the editor and discovering the web build is broken at hour 47.
• Adding features after the freeze.
• Skipping sleep and food.

Quick recap

• Pick an idea whose core can be playable in about four hours.
• Plan for a third of the time; freeze features well before the end.
• Sort features into must, should and could, and cut from the bottom.
• Build and upload early, and test the uploaded version.
• Read the jam rules and credit every asset.

Try it

Open the Do tab to scope your own 48-hour jam game on paper.