Text to Game AI: The Prompt Shape That Produces Something Playable

Short answer: a prompt that produces something playable is not a description of a game. It is a nine-line spec, written in a fixed order, where four of the nine lines exist only to stop the generator from deciding something for you. Here it is, ready to paste:

ARCHETYPE: <dodge | collect | shoot | jump | sort | survive>
VERB: <the one action the player repeats>
WORLD: <fixed screen | N screens wide | endless scroll>, <portrait | landscape>
CAMERA: <locked | follow with clamp | follow with lead>
FAIL: <one hit | three hits | timer | resource drains>
WIN: <survive N seconds | reach N points | clear N waves | none, score only>
FEEL: player <X> screen-widths/sec; first threat at <Y>s; then every <Z>s, floor <F>s; hitbox <P>% of sprite
LOOK: <shapes | sprites>, <one line of palette or art direction>
DO NOT: <five things the generator must not add>

Nine lines, roughly 110 words. It outperforms a paragraph ten times its length, because length is not what the pipeline reads — slot coverage is. A 400-word paragraph about a lonely astronaut will fill two slots. These nine lines fill the ones that decide whether the result is a game or a demo.

If you have already read [what a one-sentence brief leaves out](/ai-game-generator-from-text), this page is the other half: how to write the brief so there is less left out.

The clause budget

Every clause in a brief competes with every other clause. Generators resolve a fixed number of decisions per pass and approximate the rest, which produces a pattern that repeats across tools: the brief gets read from the top, the first several lines land precisely, and the tail gets flattened into adjectives.

The practical rule: one line per decision, and never more than nine. If you find yourself writing a tenth, you are not adding a decision — you are usually adding a restatement of one you already made, which costs a slot and buys nothing. The two most common redundant lines are a second sentence about mood (the first one already fixed the palette) and a second sentence about difficulty (the cadence line already sets it).

Nine is not a magic number, and it is not a limit imposed by any particular product. It is the count at which the four load-bearing slots plus the five supporting ones fit without the tail collapsing. Fewer than six and you leave camera or fail open. More than twelve and you start losing the lines you care about most, because they sit above the flood, not below it.

The four slots that decide playable versus demo

Four of the nine lines are not description at all. They are guardrails, and each one blocks a default that arrives whether you asked for it or not.

Take these in order, because they constrain each other. Camera only matters if the world is wider than the screen, so a locked camera plus a fixed screen is consistent and a locked camera plus a three-screen world is a contradiction the generator will resolve by ignoring one of them. Fail sets run length. Run length sets the cadence in FEEL — a 30-second run with a 2-second opening threat interval is a game with fifteen decisions in it, which is not a game, it is a coin flip.

WIN is the slot people skip most often, and it is the one that most changes how the build reads. A game with no win condition is not unfinished; it is a different genre, the endless one, and endless games need a score curve to substitute for an ending. If you did not specify a curve, you got the default one, which is a number that goes up by tens.

Feel numbers, written in units that travel

This is where most briefs fail quietly. People write "fast player" or "difficult but fair", both of which are unmeasurable, so the generator substitutes its own numbers and the brief has effectively said nothing about feel.

Write the numbers in relative units, never in pixels. A speed of 300 pixels per second is brisk on a 400-pixel-wide phone and glacial on a 1400-pixel monitor, so a pixel value makes your brief non-portable and guarantees the build feels different on a laptop than on a phone. Screen widths per second is the same measurement with the viewport divided out, and it survives resizing, export, and a switch of tool.

Starting values that hold up, by archetype:

These are starting points, not measurements, and they are chosen for one property: they are the ranges in which a player who has never seen the game can still react to what is on screen. Push player speed below 0.35 screen-widths per second and the build reads as sluggish no matter what the art looks like. Push the first threat below one second and it reads as unfair, because the player is still locating their own character. The hitbox share matters more than any other number for perceived fairness, and it is the one almost nobody writes down: a hitbox at 100 percent of the sprite makes a clean-looking near-miss register as a hit, and players describe that as "the collision is broken" rather than "the hitbox is too big".

Two rules for the FEEL line. State one speed and one cadence, not a curve. A brief that says "difficulty ramps smoothly" gets a step function, because smooth is not a value. A brief that says "every 1.1 seconds, shrinking to a floor of 0.4" gets a slope, because the numbers are there to interpolate between. Put the floor in. Without a floor, any shrinking interval reaches zero and the game becomes impossible at a time you did not choose; the floor is the difference between a difficulty curve and a wall.

The DO NOT line

Five prohibitions, and they are the cheapest characters in the brief. Each one blocks a default that would otherwise occupy a slot you wanted.

The reason a prohibition works better than a correction is mechanical: a correction costs a generation, a prohibition costs four words. Say the negative in the first brief and you never spend the round.

Keep the list to five. A DO NOT line with twelve items reads as a wall of negatives and the tail gets dropped exactly like any other overlong brief — and the items at the end are usually the ones you cared about.

The same game, written two ways

Take one idea: a game where you dodge falling rocks in a cave. Here is the version most people type, and the version that produces something playable.

The nine-line brief:

ARCHETYPE: dodge
VERB: move to avoid falling rocks
WORLD: fixed screen, portrait
CAMERA: locked, no scroll
FAIL: one hit ends the run
WIN: survive 60 seconds
FEEL: player 0.7 screen-widths/sec; first rock at 1.5s; then every 1.1s, floor 0.4s; hitbox 60% of sprite
LOOK: flat shapes, three-colour palette, dark ground, light rocks
DO NOT: lives counter, score steps, letterbox, upgrades, tutorial text

Same idea. The difference is not that one is longer. It is that six of the seven things a player would notice are pinned, and the seventh (the art) is pinned loosely on purpose.

When the tool only takes one sentence

Some inputs cap you at a couple hundred characters. Compress, but compress in priority order — dropping the wrong line is worse than dropping three lines.

The compressed form of the example above, at about 270 characters:

Fixed-screen portrait dodge game; drag anywhere to steer at 0.7 screen-widths per second; one hit ends the run; survive 60 seconds; rocks fall from the top, first at 1.5s then every 1.1s to a floor of 0.4s; flat shapes, dark palette; no lives, no upgrades.

Semicolons, not full stops. A full stop invites the generator to treat the next clause as a new topic; a semicolon keeps it inside the same spec.

When the tool rewrites your prompt

Many tools show a "refined" or "enhanced" version of what you typed before generating. Read it. This is the highest-value thirty seconds in the whole workflow, because the rewrite is where your clauses get silently dropped, and the build you are about to judge is generated from the rewrite, not from your text.

Check four things, in this order: is the archetype still the one you named, is the fail condition still single-hit, is the camera still specified, and is at least one number still present. If any of the four is missing from the rewrite, re-add that line and generate again. Do not generate first and diagnose later — you will spend the round diagnosing a build that was never given your brief.

The same check applies to any tool that asks you to pick from a menu of "styles" after you type. A style selector is a presentation slot, and it can overwrite the LOOK line. It cannot overwrite FEEL, so if your build feels wrong after choosing a style, the style is not the cause.

The repair clause

When a build misses one slot, the fix is a clause, not an edit. The syntax matters more than the wording:

Keep everything else exactly as it is. Change only FAIL: from three hits to one hit.

Two parts, both load-bearing. "Keep everything else exactly as it is" stops the pipeline from re-rolling the decisions you already won; without it, a repair can return a different archetype and you lose four slots to fix one. "Change only X: from A to B" names the slot, the old value, and the new value, which is the only form that cannot be read as a mood adjustment.

For numeric repairs, name the neighbour you are protecting:

Change only player speed: 0.7 to 0.55 screen-widths per second. Do not change spawn cadence.

Without the second sentence, changing speed usually re-tunes the cadence with it, because the two were tuned as a pair. You then have two changes, one of which you did not ask for, and no way to tell which one caused the improvement.

The two-minute acceptance test

Generate, then check four things before you play for fun. Each takes about thirty seconds, and each maps to one slot.

1. Camera. Walk into all four edges. If every edge clamps and there is visibly nothing beyond it, the world frame clause did not land — the camera defaulted.
2. Fail. Take one hit on purpose. If the run continues, you have lives, and the run length in your head is wrong.
3. Win. Look for a timer, a counter, or a wave number. If the only number on screen is a score, the WIN line was absorbed.
4. Feel. Count the seconds until the first threat appears. Under one second means the opening was overridden by the scaffold's own cadence, regardless of what you wrote.

Any failure here is a brief problem, not a code problem. That distinction is the whole point of the test: it tells you whether to rewrite a line or open an editor, and those two activities have very different costs.

What this template cannot do

Four honest limits, because a template that claims to solve everything gets abandoned after the first miss.

It cannot invent an archetype the tool does not have. If your verb has no scaffold behind it, no phrasing saves the build — the generator will map your idea onto the nearest archetype it owns, and you will get a dodge game with a story. Change the verb, not the wording. [Judging whether an idea is buildable at all](/game-made-by-ai) is a separate decision, and it happens before this template is useful.

It cannot blend two genres. A brief naming two archetypes gets one of them as mechanics and the other as paint. Pick the one that carries the loop and describe the other in LOOK.

It cannot hold art consistent across generations. Every regeneration re-rolls presentation, so a consistent style is a workflow problem, not a prompt problem.

It cannot add content. The brief sets the loop, the numbers, and the boundaries. How many levels, enemies, or variations exist is a different axis, and no clause in these nine lines touches it.

The one rule that survives all four limits: write the brief for the decisions you cannot afford to have made for you, and accept every other default on purpose. Nine lines, in this order, is the smallest brief that covers those decisions — and the largest one that still gets read in full.