How to actually finish a game in one month

A 48-hour jam fails because there is not enough time. That failure is honest and everybody sees it coming, which is why weekend jams produce so many finished tiny games — the clock does your scoping for you.

A month fails the opposite way. A month is just long enough to start building infrastructure. So you build an inventory system. Then a save system, because the inventory needs persisting. Then a dialogue parser, because you have a character now. Then a level format, because hard-coding rooms feels amateurish. Each decision is individually defensible. None of them is a game.

Then it is the 26th, you have a genuinely impressive engine, and there is nothing in it that a stranger can play.

Here is the test, and you can run it today. Open your project and try to play it for ten seconds. Not "run it" — play it. If you cannot, you are building a system, and every additional day spent there makes the eventual assembly harder, not easier.

This is the most useful and most ignored thing on the Slow Cook page. Each of the five challenges carries a line labelled "To count". That is not flavour text. It is a specification, and it is short enough to hold in your head.

Treat it as a pass/fail checklist and the scoping problem mostly solves itself. Here is each one, next to the smallest honest thing that satisfies it, and the thing most likely to eat your month if you let it:

Notice what the fourth column has in common: every single item is a tool for making the game rather than the game. That is the trap in one sentence.

Deadlines are only useful if you subtract from them. Working back from 31 August:

Days 1–2 · One page, then stop planning

Write down four things and nothing else: one sentence describing what the player does; the win condition; the lose condition; and a list of every noun in the game (every enemy, item, screen, mechanic). If that noun list runs past about eight entries, cut until it does not. You are not being pessimistic, you are being arithmetic — every noun is art, code, tuning and bugs.

Days 3–7 · The ugly loop

By 7 August you want something you can open in a browser that goes title screen → play → win or lose → back to the title screen. Coloured rectangles. No art. No sound. No menus. One level, one enemy, one of everything.

This week is doing something specific for you: it converts your idea from a plan into a thing with known problems. Everything after this is filling it in, which is work you can estimate. Nothing before it is.

If the loop is not closed by the end of week one, do not extend week one. Cut the concept instead. There are still three weeks, which is plenty for a smaller idea and not nearly enough for a bigger one.

Days 8–20 · Content, which is the actual work

Ten rooms, twenty levels and three bosses are all content, and content is slower than people expect because each unit has to be made, then played, then fixed. A level that took twenty minutes to lay out routinely takes another forty to become fun.

Build it in the order a player meets it, and play from the beginning every few days. You will discover that level 4 teaches something level 2 already needed, and that is much cheaper to learn on day 12 than day 29.

Day 21 · Feature freeze

Write the date down somewhere you will see it. After 21 August, no new mechanics, no new systems, no new nouns. Only content, tuning, fixing and polish. Ideas that arrive after the freeze go in a file called next-game.txt, which is a genuinely nice place for them to live.

Almost every project that misses a deadline missed it because of something added in the final week.

Days 22–27 · Polish that a player would actually notice

In order: the first thirty seconds (can a stranger tell what to do?), then difficulty, then sound, then everything else. Add a loading indicator if your game loads anything at all. A player who can see a progress bar will wait; a player looking at a black rectangle assumes it is broken and closes the tab — we took one of our own games apart after making exactly that mistake.

Day 28 · Build and host it

Not on the 31st. Export the web build, upload it to itch.io, Netlify or GitHub Pages, and open the public link. This is where projects discover that the build works locally but not from a subdirectory, that a file path was capitalised differently, or that the export forgot an asset folder.

Day 29 · Play the hosted link on a device you did not build on

A phone, a friend's laptop, a different browser. Half an hour here reliably finds more real problems than the previous week of development: audio that never starts because browsers block it before a click, text sized for your monitor, controls that assume a keyboard nobody has on a phone.

Then submit. Submitting on the 29th costs you nothing and buys you two days of margin.

Days 30–31 · Buffer

For the thing that goes wrong. Something will.

Programmers build tools. It is a good instinct and it is the wrong one at this scale.

A rough working threshold: if a thing appears fewer than about thirty times, make it by hand. Ten rooms do not justify a room editor — laying out ten rooms by hand takes an afternoon, while an editor takes a week and then needs its own bugs fixed. Twenty levels sit right at the line, which is why the honest answer there is a data format but not an editor:

const LEVELS = [
  [ "########",
    "#..o...#",
    "#..##..#",
    "#@...x.#",
    "########" ],
  // ...nineteen more, edited as text
];

That is fifteen minutes of parsing code and it will carry twenty levels comfortably. An editor with drag-and-drop, undo and a save format is days of work whose only user is you.

The same logic applies everywhere. Three bosses do not need a boss-behaviour scripting language; they need three functions. Five upgrades do not need a modifier system; they need five if statements you are allowed to be embarrassed by. Nobody plays your architecture.

Browser games have a few extra pass/fail conditions that desktop builds do not, and they are exactly the ones that get discovered on the last day. Before you call it finished:

• It opens from a link. No install, no download, no login, no build step for the player.
• A stranger can start playing without being told anything. If it needs an explanation, the explanation has to be inside the game.
• It can be finished or lost, and restarted without reloading the page. This one is skipped constantly and it is the difference between a demo and a game.
• It does not sit on a blank screen while loading. Check the total size that has to arrive before the first frame. If it is tens of megabytes, fix that before anything else.
• Audio does not try to play before the first click. Browsers block it, and some engines then behave oddly, which reads to the player as broken.
• It works on a phone, or it says on screen that it needs a keyboard. Either is fine. Silence is not.
• Free assets are credited on a screen inside the game. Slow Cook's rules require your own work and credited free assets — and a credits screen takes ten minutes.
• The link keeps working. Host it somewhere durable rather than a temporary tunnel or a preview URL that expires.

You will fall behind. Deciding the order in advance means you cut calmly on day 20 instead of panicking on day 30. From first to last:

1. The second mechanic. Always. One mechanic explored properly beats two half-explored ones, and it is also what four of the five challenges are literally asking for.
2. Story, dialogue and cutscenes. Expensive to write, expensive to display, invisible in a screenshot.
3. Original music. Use credited free audio. Nobody has ever declined to play a game over this.
4. Menus, options and settings screens. A title screen with one button is a complete title screen.
5. Original art. Consistent placeholder art beats half-finished good art every time, because inconsistency reads as unfinished while simplicity reads as a style.
6. Difficulty modes. Pick one difficulty and tune it well.

Never cut these three: the ending screen, the restart, and the first thirty seconds. They are what turn a pile of working parts into something a person can experience from start to finish — which is the entire thing being asked for.

Worth being straight about, because "enter the jam" pitches often are not.

Slow Cook is free to enter and open to everyone. Selected games get a feature on the SlowDen homepage plus a shoutout across SlowDen's social accounts. That is the whole reward list. There is no cash prize, no guaranteed traffic, no guaranteed downloads or revenue, and being selected is never guaranteed. Every entry is read by a person.

You submit a link to your game hosted wherever you like — itch.io, Netlify, GitHub Pages — and it has to run in a browser and be your own work. You can look at all five prompts and pick whichever one you like, and you do not have to enter a challenge at all: a finished browser game made at any time, for any reason, can go through the general submission form and gets the same review by a person.

And the honest reason to do it is not the shoutout. It is that a deadline with someone waiting at the end of it finishes games that would otherwise sit in a folder. That is worth more than the feature.

So you can check this rather than take our word for it:

• The five challenges, their "To count" requirements, the rules and the reward wording were all read from the live SlowDen Slow Cook page on 1 August 2026, and are quoted from it.
• The closing date of 31 August 2026 is the one printed on that page. Rounds change — if you are reading this later, check the Slow Cook page for the current round rather than trusting this date.
• The calendar, the cut list and the thirty-times rule are editorial judgement, not measurements. They are offered as a starting structure to adapt, not as findings.
• itch.io, Netlify and GitHub Pages are third-party services named for accuracy only. SlowDen has no affiliation with them.

The single highest-value hour of this entire month is the first one, because it is the hour in which you decide how big the game is. Pick a prompt, write the four lines, and go and make one rectangle move.

See the five challenges Submit your game How submitting works

Also useful: where to publish a browser game for free in 2026 if you have not picked a host yet, and why browser games load to a black screen before you hand anyone a link.