Game jam scoping: plan a 48 or 72 hour game you can finish

Most game jam entries that never get submitted did not fail at the end. They failed in the first two hours, when someone wrote "procedural dungeon with crafting and a boss" on a sticky note and nobody laughed. Scoping is the one jam skill that pays off every single time, and it is mostly a matter of being honest about how few hours you really have. This piece is my checklist for planning a 48 or 72 hour game you will finish, with an hour-by-hour plan, a cutting order, a polish order and a calm way to submit.

Count the hours you actually have

A 48 hour jam is not 48 hours of work. You will sleep, eat, stare at a wall, and lose at least one evening to a bug that turns out to be a typo in a file path. Before you think about the game, do the sums.

Here is a realistic budget for a solo developer in a 48 hour jam that starts on a Friday evening:

Twenty hours. That is your game. For a 72 hour jam the same exercise usually lands somewhere near 32 to 36 hours of making, not 72. Write your own number on a card and keep it next to the keyboard. Every feature you consider gets measured against that card, not against the clock on the jam page.

If you are in a team, the hours do not simply add up. Three people give you more art and more code, but also more coordination, more merge conflicts and more "wait, which build is the real one". Plan as if a team of three has the output of two and a half people, and you will be pleasantly surprised rather than crushed.

Pick one verb

The best scoping tool I know is a single sentence: "The player _____ ." Fill the blank with one verb. Jump. Push. Swap. Throw. Hide. Steer. Your entire game is that verb, explored a few ways.

Themes tempt you towards stories and systems. Resist. If the theme is "roots", the scoped version is not a farming simulator with seasons. It might be "the player grows a root downwards and steers around rocks to reach water". One verb (steer), one goal (reach water), one obstacle type (rocks). Everything else is a bonus you earn later.

A useful check: can you explain the game to a friend in the time it takes the kettle to boil? If you need to describe a menu, you have too much.

Write the core loop and the cut list

Once you have the verb, write two lists on paper.

The first is the core loop: the smallest set of things that makes the game playable from start to finish. For the root game:

• A root tip that moves down and can be steered left and right.
• Rocks that stop the root.
• Water at the bottom that ends the level.
• A restart key.

That is it. No title screen, no sound, no second level. If those four things work, you have a game.

The second list is the cut list, written in the order you will cut from it. You write it now, while you are calm, because at 3 a.m. on Sunday you will not make good decisions. For the root game it might look like this:

1. Leaderboard (cut first, it needs a server)
2. Story text between levels
3. A second obstacle type that moves
4. Particle effects when the root hits water
5. Three hand-made levels instead of one
6. Music

Notice that the list runs from most expensive and least important to cheapest and most important. When you fall behind, you cross off from the top without arguing with yourself.

An hour-by-hour plan for 48 hours

Plans like this are not schedules you must obey. They are checkpoints. If you hit a checkpoint late, you cut from the list, you do not stay up later.

Two rows matter more than the others. Uploading a test build in the first evening sounds paranoid, but it is how you discover that your web build needs a different folder layout, or that the jam site wants a zip with the HTML at the root. If you are shipping to the browser, the notes in running a Rust game in the browser will save you a panic on Sunday.

The other row is the last one. The plan aims to submit four hours before the deadline. Jam sites slow down near the end because everyone uploads at once, and that buffer is what lets you smile through it.

Stretching it to 72 hours

The 72 hour version is not "the 48 hour plan with more features". Use the extra day for three things, in this order:

1. More tuning time for the verb. Playtesting with one or two people on day two is the best use of extra hours.
2. A proper art and audio pass, rather than placeholder shapes that never got replaced.
3. Content: more levels, a second mechanic that builds on the verb.

Keep the core loop deadline the same as the 48 hour plan, or even earlier. A playable grey-box game by the end of day one is the single best predictor of a finished jam entry that I have seen in my own jams.

What to cut, and how to tell it is time

You will fall behind. Everyone does. The skill is noticing it early. Some signals:

• You missed a checkpoint by more than two hours.
• You have been on the same bug for over an hour.
• You are building a system ("an inventory framework") instead of a feature ("the player can hold one key").
• You opened a tutorial for a technique you have never used.

When one of those happens, stop, get up, drink some water, and cross off the top line of the cut list. Then cut one more thing than feels necessary. It always feels like too much in the moment, and it is always the right amount by the end.

Some things you should almost never cut, because they cost little and players notice their absence: a restart key, a clear goal shown on screen, a way to quit, and some kind of end screen. A game that just stops when you win feels broken even if it is not.

Engine choice matters here too. A jam is a bad weekend to learn a new engine's scene system from scratch. Use the tool you already know. If you are choosing between two Rust options for future jams, the trade-offs in macroquad vs Bevy are worth reading on a quiet evening, not on Friday night.

The polish order

Polish is where a jam game goes from "works" to "people actually rate it". It is also where hours vanish. Polish in this order, because each step makes more difference per hour than the one after it:

1. Feel of the verb: Acceleration, a tiny bit of coyote time on jumps, input that responds instantly. This is the whole game.
2. A readable screen: Can a new player tell what is the player, what kills you and where to go? Strong contrast between those three things.
3. Sound on actions: One sound for the verb, one for success, one for failure. Three sounds transform a game.
4. Screen feedback: A small shake on impact, a flash when you get hit, a short pause on a big moment.
5. Art detail: Better sprites, animation frames, backgrounds.
6. Music: A loop under the whole thing.

Art is fifth, which surprises artists. A beautiful game that feels sluggish gets worse ratings than an ugly one that feels tight. If you do have time for art, keep it small: a limited palette and a low resolution are faster to draw and hide a lot. The basics in how to make pixel art are a good fit for jam pace.

Submitting without panic

Submission is its own small project, and it deserves its own slot in the plan. The checklist I tape to my monitor:

• Final build made from a clean state, not "the one that worked on my machine".
• Build tested on a second machine or a second browser.
• File named clearly, with the game name and platform.
• Jam page text: one line describing the verb, the controls, and which theme you chose and why.
• Three or four screenshots that show the game being played, not the title screen.
• A short note of known bugs, so players are not surprised.
• Credits for any sounds, fonts or music you used, with their licences.
• Submit, then open the page logged out and check the game runs from there.

The controls line matters more than people think. Raters play dozens of games in a row. If they cannot find out that the action key is X within ten seconds, they leave.

Questions people ask

Should I start coding before the theme is announced?

Set up an empty project that builds and runs, with input and a window, and check the jam rules on what you may prepare. Most jams allow reusable base code and your own libraries. Do not build game content in advance, it defeats the point and you will want to change it anyway.

What if my idea is not fun once it is playable?

That is why the grey-box checkpoint is early. If the verb is not fun by the end of the first full day, tweak one variable at a time (speed, gravity, size of the play area) for an hour. If it is still flat, simplify further rather than adding features to rescue it.

Is it fine to submit something unfinished?

Yes. A small thing that runs from start to end beats a big thing that crashes. If you are short of time, cut a level and ship the rest. Nobody rates the game you planned.

How much sleep should I really get?

Enough that you can still read your own code on the last day. Six or seven hours a night is usually faster overall than staying up, because the bugs you write when tired cost more than the hours you saved.

One exercise before your next jam

Pick a jam theme from any old list and give yourself fifteen minutes. Write the one-verb sentence, the core loop in four lines, and a six-item cut list ordered from most expensive to cheapest. Do not make the game. Just do the planning, three times, with three different themes. By the third one you will notice how much faster you cut, and that speed is exactly what you need when the real timer starts.