AI game development prompts: what 33 games taught us

The prompt-chain guides that circulate for Unity, Unreal and Three.js run to fourteen steps, and they are right to. If you are pointing a coding agent at an empty directory, most of the work is not the game: it is the project architecture, the asset pipeline, the media compression rules, the analytics taxonomy, the test harness and the deployment process. Each needs its own prompt, in its own order, because the later ones read decisions the earlier ones wrote down.

A generative studio owns that half of the list, which leaves a shorter one where every remaining step is a judgement only you can make. To find out what those steps actually are, we read back every message sent to the studio while building the games in the gallery: 236 prompts across 33 games, 2D and 3D, from a gladiator autochess to a coffee shop in hell. The median game took five prompts after the brief. The most stubborn took twenty-five, and reading back why is how several of the steps below stopped being steps at all.

Here is the order that worked, and the prompt to use at each step.

What is an AI game development workflow?

An AI game development workflow is an ordered set of prompts, one per decision, run against a project that keeps its own state between them. The ordering is the point. A prompt that asks for art before the art direction exists gets an average of everything the model has ever seen; the same prompt after a fixed palette and a named era gets a set that matches. Nothing here is a trick of phrasing. It is that each step leaves a decision behind for the next one to inherit.

Two shapes of this exist and are often confused. In the engine-side chain, you paste prompts into an assistant that edits files in a repository you are responsible for. In a studio, you talk to an agent that already has the engine, the asset pipelines, a browser to test in and somewhere to publish, and you never see a directory unless you ask for one. The prompts below come from the second shape, and most of them transfer to the first with more setup around them.

Which steps disappear when the studio owns the pipeline?

Roughly half. Not because they stop mattering, but because they stop being yours to specify: they are the same for every game, so they live in the machine rather than in your prompt.

The pattern in the right-hand column is worth naming: every step that disappeared was mechanical, and every step that survived is a taste judgement. That is the real division of labour in generative game development, and no amount of better prompting moves the line.

Phase one: get to a playable build

1. Write the brief

Across 33 games, two shapes of opening prompt both worked, and they work for different reasons.

The reference anchor is one or two sentences that name a game everyone knows and then break it: "Tony Hawk's Pro Skater, but you skate on historical battlefields through time. Start with Gettysburg." That is the entire first prompt that produced Time Skater. It works because the familiar half carries the camera, the controls, the scoring and the session length for free, so every word you have left can go on the half that is new.

The structured brief is a paragraph that names five things in order: the one mechanic, the camera, the controls, the art direction, and the scope. It works because it leaves nothing important to a default. This is the shape to use when your game has no obvious ancestor:

A cozy 3D delivery game about a cat carrying the post across a village of floating rooftops. The one mechanic: every delivery you complete lowers a bridge somewhere else in the village, so the route opens up as you work and the order you choose decides whether you can finish before dark.

Isometric camera that follows the cat with a gentle lag. Gamepad and keyboard for movement plus one jump button, touch stick for phones. A run lasts about twenty minutes.

Art direction: deep violet twilight, warm lantern windows, tilted rooftops and floating islands, soft edges and no hard shadows. Stylised and handmade rather than realistic.

Both shapes share what they leave out. Neither says "fun", "polished" or "AAA". Every phrase is checkable: someone could look at the build and tell you whether the camera lags, whether the shadows are soft, whether a run is twenty minutes. The test for your own brief is whether a person could build a wrong version of your game while technically following it. There is a longer treatment of this in how to prompt a game into existence.

2. Play it before you ask for anything

The strongest instinct when a first build lands is to queue up five changes from the screenshot. Resist it for ninety seconds, because the most common defect in the whole sample is invisible in a still image: in 10 of 33 games, the second or third prompt was some version of "I cannot get there". A bridge that stops short of the island. A ceiling too low to make the platform. A final jump the character cannot clear. A dirt patch on the car that the brush will not reach.

Generated levels look correct and are frequently not traversable, and nothing except playing them finds it. Ninety seconds with your hands on the controls is worth more than any amount of studying the screenshot.

3. Fix the feel before the content

Feel is jump arc, acceleration, hit pause, camera lag, input buffering, the delay between pressing a thing and seeing a thing. Content is levels, enemies, modes and menus. Content built on a core verb that feels wrong gets rebuilt when you fix the verb, so fix the verb first, while almost nothing is standing on it.

Describe the symptom, not the fix. The most effective change requests in the whole sample were imprecise about implementation and precise about experience, like this one from Monster Karts:

Do not make bumping into the barriers or another player stop the kart so hard. Let them slide off instead.

"Set friction to 0.82" presumes an implementation you have not read, and if your diagnosis was wrong it produces a game that is differently wrong. Say what you felt and let the agent find the cause.

4. Lock the art direction while there are ten assets, not four hundred

This is the highest-leverage prompt in the sequence and the one most often skipped, because a first build's art usually looks fine in isolation. Coherence is what breaks later, and it breaks retroactively: every asset made before the direction was fixed has to be redone against it.

Give a period, a medium and a limitation rather than adjectives. A constraint is checkable and an adjective is not. "Black and white, characters and cars inspired by old monster movies, soundtrack to match" decided every asset in Monster Karts before any of them existed. "A 90s FMV thriller in the Night Trap style" did the same job for Night Switch 9000, down to the grain on the camera feeds.

Fix the visual direction for the whole game before generating anything else. Black and white only, no colour anywhere, heavy film grain, high contrast, vignetted corners, hand-lettered title cards in a silent-film face. Write the palette down as literal values and hold every future asset to it. The HUD and menus follow the same rules as the world art, so nothing looks like a website sitting on top of a game.

5. Ask for the first minute

Say what happens in the first sixty seconds: what the player sees, what they try, what goes wrong. This is what separates a game from a sandbox, and it is the step that makes a generated game feel authored rather than assembled. It is also cheap insurance against the most annoying class of early bug, the one where a player is told to press "strike" and the game never says which button strike is.

Build the opening sixty seconds deliberately. The first race starts on the easiest track with two opponents who drive politely, and the first corner is wide enough that a bad drift still makes it. Teach the drift by making the second corner impossible without it. Name every control on screen the first time it is needed, one concept at a time, and no text tutorial anywhere.

Phase two: finish it and put it somewhere

6. Playtest with someone who has never seen it

You cannot playtest your own game after the fourth run through, because you now know where everything is. Send the link to one person, watch without narrating, and write down where they hesitated. Those hesitations are your next three prompts, ranked by evidence rather than by whichever annoyance is freshest in your mind.

Three people played it. All three span out at the same hairpin on track two and none of them knew why. Two never found the boost in a whole race. One did not realise the pickups could be thrown backwards. Diagnose those three, fix the causes, and change nothing else.

7. Ask for the performance pass on the weakest device you expect

Do this after the game is content-complete and before the polish pass, because the polish pass will spend every frame you free up. Name an actual device rather than "mobile": a three-year-old mid-range Android phone is a specific budget, and "runs well on mobile" is not.

Profile the build and hold sixty frames a second on a three-year-old mid-range Android phone: startup time, frame pacing, memory, and what the first load actually downloads before anything is playable. Keep the desktop experience unchanged and retest it afterwards so the mobile work does not quietly cost anything there.

8. Run the polish pass last

Lighting, materials, particles, screen shake, transitions, the small sounds that acknowledge an input. This is the step that most changes how a game reads in a screenshot and least changes whether it is worth playing, which is exactly why it goes at the end. Run it on a game that is already good and it makes the game look as good as it is.

Final presentation pass, no mechanical changes. Lighting and materials, impact and particle feedback, screen transitions, menu polish, and a sound for every action that currently has none. Show me the same three moments before and after so I can judge whether it actually improved.

9. Publish it, then take the project with you

The build publishes to your arcade as a link that opens on anything with a browser, which is the entire distribution story for a game you want a friend to play in the next ten minutes. If the game is going further than that, two things follow.

Download the project. It is an ordinary Godot 4 project with ordinary files, it opens in the engine on your own machine, and a game you cannot export is a game you are renting. And where a store asks about generated content, answer it: Steam surfaces an AI content disclosure on your store page, and itch.io has a disclosure field that tags the project. Over-disclosure carries no penalty. Non-disclosure risks delisting.

What a generated asset actually is

Everything above is about what you say. This is what comes back. These are three of the real assets from Monster Karts, exactly as the game ships them, running here in your browser. Drag any of them:

Each of these left the generator between 3 and 4 MB and ships at under 600 KB: meshes quantised, textures recompressed and capped, pivots and forward axis reconciled with the engine, import settings written. A driver, a rival and a pickup crate, all generated against one sentence about black and white silent film.

None of that middle part is prompt work. It is the same pipeline work the fourteen-step guides spend half their steps setting up, and it is why this list is shorter than theirs: the harness reconciles, compresses and checks on every build, so the conversation stays on the parts that are actually yours. Early games are how a harness learns what to check.

Four prompt habits worth stealing

• Paste the console error verbatim. A wall of SCRIPT ERROR: Parse Error from the browser console is a better prompt than any description of a black screen, and it is the fastest route from a broken build to a working one.
• Bring an image instead of an adjective. The prompts that fixed art fastest attached a file: a reference photo of the object, a screenshot with the problem circled, a still of the layout that was wanted. One image ends an argument that three paragraphs cannot.
• Say what not to touch. "Everything else is almost perfect as is" costs six words and prevents the class of regression where a fix arrives alongside four changes you did not want.
• Keep batches small when a run is fragile. Bundling six requests into one message is efficient when it works. When the run fails halfway, you lose all six and end up sending the same paragraph three times, which is exactly what the longest game in the sample did.

What do you do when a change makes it worse?

Say that, immediately, in one message, before asking for anything else. Compound prompts are what turn a small regression into a lost afternoon: if you follow "the karts are too twitchy now" with three unrelated requests, the next diff is impossible to read and you will not know which half of it to undo. One symptom, one prompt, one thing to judge. It is the same discipline as committing working changes before moving on, and it is the habit that most separates people who iterate quickly from people who end up rebuilding.

The whole workflow in one place

1. Write the brief: a reference anchor, or one mechanic, one camera, one control scheme, one art direction, one scope.
2. Play the draft for ninety seconds before asking for anything, and check you can get everywhere.
3. Fix the feel of the core verb before adding content.
4. Lock the art direction as a palette, an era and a limitation.
5. Specify the first sixty seconds, including where each control is taught.
6. Playtest with someone who has never seen it, and prompt from what they did.
7. Run the performance pass against a named weak device.
8. Run the presentation pass last.
9. Publish, download the project, and disclose generated content where asked.

Nine steps, a median of five prompts of iteration, and one game. The order matters more than the wording of any single prompt, and the four at the top that are purely about taste are the ones nobody can run for you.