Scoping an AI game jam so you finish
A jam is a scoping problem, and a cheap prototype does not make your scope bigger. It buys you more goes at a small game, and the goes are what make it feel good.
Jump to a section
A jam is decided by scope, and AI moves the scoping maths in the direction that hurts. Work that used to cost six hours now costs twenty minutes, so the obvious move is to attempt four times the game. Do not. Attempt the same small game, four times over.
A model does not make a bigger game fit inside a weekend. It makes a small game fit four times over, with a playtest after each one. Those playtests are where a jam entry stops being a demo and starts being a game.
What the saved hours are actually for#
Writing the code was never the slow part of a jam. The slow part is the loop: build a thing, play it, notice it feels wrong, change one number, play it again. A weekend holds a fixed number of trips round that loop, and every trip costs attention rather than typing.
This is why breadth is such a trap under a deadline. Four half tuned systems each feel slightly wrong, and wrongness compounds. One system played twenty times feels deliberate, and a player can tell the difference in about ten seconds.
The first hour decides the jam#
Pick a mechanic you can describe in one sentence. Build the ugliest version of it that runs. Then play it, before you decide anything else at all.
A grey rectangle dodging grey squares tells you what the finished thing will feel like, and it tells you now rather than on Sunday. If it is dull as a grey box, it will be dull with particles, a palette and a soundtrack. That is the whole reason to do it first.
Build a grey box prototype of ONE mechanic as a single .html file. No
frameworks, no images, no sound, no menu, no title screen.
THE MECHANIC: <write your one sentence here. A verb, and a way to lose.>
UGLY ON PURPOSE: every object is a rectangle or a circle in one flat
colour on a dark background. Default font for text. Spend no effort at
all on how it looks.
PLAYABLE AT ONCE: the game starts when the page opens. There is a score,
there is a way to lose, and pressing R restarts it without reloading.
That is the entire feature list. Do not add anything else.
CONTROLS: arrow keys or WASD on a desktop, and the same control by
tapping or dragging on a phone.
TUNING: collect every number that changes how the game feels into one
CONFIG object at the top of the file. Speed, spawn rate, gravity, hitbox
size, time limit. Put a short comment on each one saying what happens
when I raise it. I want to change these without reading the rest.
TIMING: work out how many seconds have passed since the previous frame
and move everything by that amount, never by a fixed step per frame.
Never let that number go above 0.05, so a tab left in the background
does not teleport anything on the way back.
TOUCH: put canvas { touch-action: none; } in the stylesheet, or dragging
scrolls the page instead of playing the game.
Return the complete file. I am going to play this for fifteen minutes
and then decide whether to keep the idea.Twenty minutes is the budget for the whole thing, playing included. Then keep it, or go back to the sentence and write a different one. You can still afford that at hour one, and you cannot at hour thirty.
The tunable config is the part people leave out, and it is the part that pays for itself. Half of a jam is reaching into a file and changing a jump height. If every number is buried in the middle of a function, each change becomes a small negotiation with the model.
The honest division of labour#
Over a weekend a model earns its keep on the boring half of the game, and almost nowhere else. Knowing which half is which stops you asking it for the one thing it cannot give you.
| The job | Who does it | Why |
|---|---|---|
| Menu, score, restart, settings | The model, in one pass | Solved problems. You gain nothing by typing them out. |
| Keeping a best score between visits | The model | Ten lines you would otherwise forget until Sunday. |
| Placeholder shapes and beeps | The model | Good enough to submit with, and done in a minute. |
| The bug found at hour 44 | The model | A second reader, at the hour you stopped being one. |
| Whether the jump feels good | You | It cannot play the game. Playing is the only way to know. |
| What gets cut on Sunday | You | Cutting is a taste decision made against a clock. |
The split is not about how hard the job is. It is about whether playing the game is the only way to answer the question.
The weakness is worth naming exactly, because it is easy to talk yourself out of it. A model will write a jump and set the numbers to whatever you ask. It will have no view on whether the arc is satisfying. That view is the thing a jam entry lives or dies on, and it only comes from you playing.
A useful test during a jam: if your next question could be answered by reading the code, hand it over. If it can only be answered by playing, stop typing and play.
Twenty readings of the theme#
Most jams announce a theme as the clock starts. Your first idea for it is usually the first idea a lot of other people are having, because it is the reading the word puts in front of everybody. A model is genuinely useful here, in one narrow way.
Ask for twenty readings of the theme and you will have them in a minute. Most will be obvious. One or two will be a reading you would not have reached on your own, usually because they take the word in a sense you had quietly ruled out. Use the list to get past your first idea, not to choose one.
Twenty game ideas comes back as twenty genres, which is no use to anybody at hour one. Twenty readings of the word comes back as twenty meanings. You still pick the mechanic yourself, which is the part you are better at than it is.
How big the idea should be is a separate question with its own answer, and the guide on sizing ideas works through it. The jam version of that answer is short. Pick the one you could finish by Saturday lunchtime, so that Sunday is entirely polish.
Pick a constraint and keep it#
A self imposed constraint is the most reliable scoping tool there is, and it has nothing to do with AI. The constraint answers a hundred small questions in advance, so you stop paying for them one at a time at two in the morning.
- One button. Every action the player has is the same input. It forces the design to be about timing, which is the easiest thing to make feel good and the fastest thing to tune.
- One screen. No scrolling and no levels. That removes the camera, the level format, and the bug where the player walks off the edge into nothing.
- No text. No tutorial to write, no font to pick, and no wording to argue with yourself about. The game has to teach itself, which is a better game anyway.
- One colour and black. Art direction becomes a single decision you make once. Nothing else in the weekend is allowed to be about colour.
Constraints also make an entry easier to remember, which counts for a lot when somebody is working through a long list of them. A game that does one odd thing completely sticks. A game that does five ordinary things adequately does not.
Time-box the fixing loop#
A jam has a hard deadline, so debugging has to be rationed like everything else. The failure mode is familiar to anybody who has done this. The bug looks nearly solved, you paste the error back, something changes, and it looks nearly solved again. Four hours go that way.
Three goes at a bug, then it gets cut or worked around. Never a fourth. If the enemies break on diagonal walls, delete the diagonal walls. Nobody playing your entry knows what you had planned, and the planned version is worth nothing at the deadline.
Count attempts rather than minutes. Minutes slip past without being noticed, and an attempt is a thing you can see yourself making. Decide the rule before the jam starts and write it somewhere visible, because at hour 40 you will not invent it on your own.
- Attempt one: describe the behaviour, not the error. The player falls through the floor when they land on a moving platform. That sentence is worth more than the stack trace.
- Attempt two: fresh conversation, whole current file. Most of these loops are a model patching a version of the code it no longer has in front of it.
- Attempt three: remove the thing that contains it. Cut the moving platforms. The level still works, and you have bought back the rest of the evening.
The hours a stubborn bug eats come straight out of polish, which is the part that was going to make the entry good. That is the real cost, and it is invisible while it is happening.
Leave real time for submitting#
Entries die at this step in every jam, and they die for dull reasons. The build works locally and not once uploaded. The page has no image and does not say what the controls are. The file is still going up when the clock runs out.
Block out the last stretch for this and treat the block as untouchable. Nothing new goes in during it. Anything unfinished when it starts was never going to be finished.
Whatever is in the file is the game now. Say it out loud, because the urge to add one more thing is strongest at exactly this point.
Not your local copy. A fresh tab, the real link, and a full run from the start screen through to losing.
A lot of people who try it will be on one. A game that needs a keyboard is fine, but the page should say so rather than the game looking broken.
Their machine, their browser, and no instructions from you. Watch where they hesitate. Anything confusing in the first ten seconds is still a line of text you can add.
The controls, what the player is trying to do, and one image. Somebody choosing whether to play has that and nothing else to go on.
Testing on somebody else's machine is the step most people skip and the one that catches the real faults. A missing file. A path that only exists on your disk. A saved score that works because your own browser already held the key.
Finished is a short word for a hard thing, and it is worth seeing what finished looks like at this size. Every game below has a page on Agent Games carrying the prompt behind it, so you can read the sentence somebody started from. The made-with pages group them by the model that wrote them.
🏁Games people finished here
Opus 5.5newSonnet 5.5newSonnet 5.5new
GPT-6.1 SolnewGPT-6new
Xiaomi MiMo V2.6…newGPT-6 AstraFable 5.1GPT-6 AstramultiFable 5.1Opus 5GPT-6 AstraCommon questions#
Can you use AI in a game jam?
Read the rules of the jam you have entered, because they differ and some ask you to declare it on the entry page. Where it is allowed, say so plainly and move on. The interesting question is not whether to use it but what to spend the saved time on.
How much game can you make in 48 hours with AI?
One mechanic, properly tuned, with a score, a fail state and a restart. That is a complete entry. AI raises this less than people expect, because the limit was never typing speed. It was how many times you could play the thing and adjust it.
What should I do in the first hour of a game jam?
Pick a mechanic you can say in one sentence, build the ugliest playable version of it, and play that for five minutes. If it is not interesting as grey boxes, pick a different one. Dropping an idea is cheap at hour one and ruinous at hour thirty.
Should I use a game engine or one HTML file for a jam?
One file in the browser if you want people to play it in a single click, which matters when somebody is working through a long list of entries. An engine if you already know it well. A jam weekend is the worst possible time to learn one.
The model keeps breaking my fix. What do I do?
Start a fresh conversation and paste the whole current file into it. Most of these loops happen because the model is editing a version of the code it only half remembers. If the third attempt also fails, remove the feature instead of trying a fourth.
What do I do with the game after the jam ends?
Keep the tuning and throw away the deadline. A jam build is a prototype that strangers actually played, which is rare and useful. Put it somewhere people can still find it, then read what they say and fix the two things everybody tripped on.
Where to go next#
Build a grey box this week, with any mechanic at all, just to have done it once. The first hour of a jam goes very differently when the ugly playable version is a thing your hands already know how to produce.
How to make a game with AI is the same process without a clock on it. The prompt guide has repair prompts for the faults that turn up under time pressure, which is most of them.
When the deadline has gone, publish the entry somewhere that outlives the jam page. It gets a page of its own recording the model and the prompt behind it, and a leaderboard for whoever plays it next.
Built something? Put it on Agent Games.
Publishing takes a file and a minute. Your game gets its own page listing the model, the prompt and the token count, and anyone can play it without signing up.
Read next