Four hours before the deadline, unfinished jam games all look the same: a character that moves beautifully, three enemy types, a half-built menu, no win condition, and a designer frantically gluing them together. The game is 85% built and 0% playable. Nobody will ever see it.
Finishing a jam is not a matter of working faster. It is a scoping problem you solve on the first evening, before you write a line of code. Here is a method that works for a 48-hour weekend, whether you are doing Ludum Dare solo, Global Game Jam with four strangers, or a two-day sprint inside a university course.
Start from the submission, not the idea
Write your submission requirements down first. For a typical jam that means a playable build on the target platform, a title, a description, two or three screenshots, and a controls list — maybe 90 minutes of work that has nothing to do with your game, and it always gets discovered at hour 44.
So reserve it. Block the last three hours as non-development time and treat the deadline as three hours earlier than it is. Everything below assumes a 48-hour jam with a feature freeze at hour 40 and upload at hour 42.
The one-mechanic rule
Pick a single interaction the player performs and build everything around it. Not a genre, not a theme — one verb with one consequence.
- "You throw your shield; it ricochets; you have to catch it."
- "You rewind the last three seconds, but only your own position."
- "You can only move when the music hits a beat."
The test for a jam-sized mechanic: you can explain it in one sentence, and a player understands it within five seconds, without text. If your pitch needs the word "and" twice, you have two games and will finish neither.
Everything else exists to make that verb interesting. Enemies are not a feature; they are a reason the verb matters. A level is not content; it is a situation that asks a question about the verb.
Budget content in units you can count
Vague scope — "a few levels", "some enemies" — is how jams die. Convert the plan into countable units in the first hour, then halve every number.
| Jam length | Mechanics | Levels / rooms | Enemy or obstacle types | Art assets | Audio |
|---|---|---|---|---|---|
| 48 hours, solo | 1 | 5–8 small | 2 | ~15 sprites/meshes | 6 SFX, 1 loop |
| 48 hours, team of 3 | 1 core + 1 modifier | 10–12 | 3 | ~35 | 10 SFX, 2 loops |
| 7 days, solo | 1 core + 1 modifier | 12–20 | 3 | ~50 | 12 SFX, 2 loops |
These are deliberately conservative. A five-room game with a clean difficulty ramp beats a twenty-room game where rooms 6 to 20 are untested. If you finish early, spend the surplus on polish and extra rooms — the two cheapest things to add late.
Author levels in the cheapest format that works. Hand-placed tiles in a text file, a Tiled map, or a spreadsheet of room definitions will all outrun a custom editor you build during the jam. Never build tools during a 48-hour jam unless the tool is the game.
An hour-by-hour shape for the weekend
Jams usually start Friday evening. Times below are hours elapsed, not clock time, so adjust to your start.
Hours 0–3 — Decide and commit. Write six one-sentence pitches, score each on can I build the verb in four hours and will a stranger understand it without a tutorial, and pick one. Put the pitch, the content budget and an explicit cut list somewhere the whole team can see. Dump the five rejected pitches into an idea log — in GameDesignerX or anywhere else — because unused jam ideas are the cheapest source of future prototypes you will ever have.
Hours 3–8 — Verb in a grey box. No art, no menus, no audio. A capsule or a coloured square that performs the verb, in a test room, with a restart key. Stop and play it. If the verb is not fun with cubes, art will not save it, and this is the last moment it is cheap to swap the idea.
Hours 8–14 — Sleep. A design decision, not a weakness. Teams that skip the first night lose hours 30 to 40 to bad judgement — exactly the hours where cutting and balancing decisions matter most.
Hours 14–24 — The playable loop. Start state, fail state, win state, restart. Even if the win state is a text line that says "you win". A game with a crude loop is submittable; a gorgeous fragment is not. Lock this and you have crossed the line between "a project" and "a game".
Hours 24–32 — Content and difficulty ramp. Build the rooms or waves from your budget, in order of difficulty. Introduce one new wrinkle at a time: the verb alone, the verb under time pressure, the verb with an obstacle, the verb with both.
Hours 32–38 — Outside eyes, then cut. Get two people who have not seen the game to play it while you say nothing. You will find that one room is incomprehensible and one control is undiscoverable; fix exactly those two things and ignore the rest of your wish list.
Hours 38–40 — Feature freeze. New code only to fix crashes and blockers. Add the controls screen, the title, the mute key, and the quit button.
Hours 40–42 — Build and upload. Export, download your own upload to a clean folder, and run it there.
Hours 42–48 — Buffer. Screenshots, description, a short page, and the one bug you discovered in your own upload.
The cut list you write on day one
Write these down in advance as explicitly out of scope, so that cutting them later is not a loss but a plan:
- Main menu beyond a title and a start key
- Settings, key rebinding, resolution options
- Save/load
- Tutorial text or cutscenes
- A second mechanic
- Boss fights
- Narrative beyond one screen of framing
- Controller support, unless your engine gives it free
- Procedural generation
- Custom editors and import pipelines
Two exceptions worth keeping: a restart key (players will need it constantly) and a mute key (it is thirty seconds of work and jam judges play with speakers on).
The pre-submission checklist
Run this at hour 40, on a machine that is not the dev machine if you can manage it:
- Fresh download of your own build runs on a clean folder, no missing DLLs or assets
- Controls are stated on the first screen and on the jam page
- Restart and quit both work
- No debug keys that break the game and no placeholder profanity in strings
- Audio starts at a sane volume and can be muted
- The game can be won and lost, and both states are legible
- Fullscreen and windowed both display correctly at 1920×1080
- Web builds tested in a second browser
- Page has title, one-line hook, two screenshots, credits with asset licences
- Build number or date visible somewhere in-game, so playtest feedback can be matched to a version
After the jam: salvage deliberately
Most jam games should stay jam games. The value is the two or three things you learned, and those evaporate within a week unless you write them down. The day after, spend thirty minutes recording: which mechanic surprised you, which hour you lost and why, what you would cut earlier next time, and whether the verb has twenty hours in it or twenty minutes.
If one does look worth continuing, treat it as a new project rather than a continuation. Re-pitch it cold, give it a real content budget, and keep the jam build as evidence rather than as a foundation — jam code is written to survive 48 hours, not 18 months. Carry the jam's decision and risk notes into preproduction, and months later you will still be able to answer "why did we drop the grappling hook?"
The jam skill that transfers to shipping real games is not speed. It is the willingness to decide, on day one, what the game is not.