AI Game Generator From Text: One Sentence In, What Comes Out
Short answer: one sentence fills roughly six of the eighteen slots a playable game needs. The generator fills the other twelve — not randomly, but in a fixed order, using conventional defaults borrowed from the genre it decided you were asking for. What comes out is therefore not your sentence rendered. It is your sentence plus a dozen silent decisions, and the silent ones carry most of the feel.
That is why the same sentence produces a different game in two different tools, and why the difference is never in the part you wrote. It is always in the part nobody wrote.
| What a one-sentence brief can carry | What it costs to carry it | Typical slot count |
|---|---|---|
| The verb — what the player does | One word, free | 1 |
| The failure condition | One clause | 1 |
| The win or end condition | One clause, often merged with failure | 1 |
| The control surface | One clause | 1 |
| The subject matter — what the shapes represent | A few words | 1 |
| The camera relationship | One clause, usually omitted | 1 |
| Numbers: speed, spawn rate, difficulty ramp | Rarely stated, never fully | 0 of 6 |
| Collision shape and forgiveness | Never stated | 0 of 2 |
| Frame and viewport behaviour | Never stated | 0 of 2 |
| Restart and state reset | Never stated | 0 of 2 |
| Presentation model: sprites, shapes, DOM | Never stated | 0 of 2 |
| Audio | Never stated | 0 of 1 |
Six in, twelve assumed. Everything in the lower half of that table was decided for you, and none of it was announced.
The sentence is a filter, not a specification
The mental model most people bring is compression: I describe the game, the tool decompresses it. Under that model, a vague sentence yields a vague game and a precise sentence yields a precise game, and the only skill involved is precision.
The actual model is closer to a filter over a genre scaffold. The generator first picks a scaffold — dodge, collect, shoot, jump, sort, survive — and that scaffold arrives pre-populated with numbers, an input map, a camera, and a fail state. Your sentence then adjusts the parts it can reach. Whatever it cannot reach stays exactly as the scaffold shipped.
Two consequences follow, and neither is intuitive:
A precise sentence does not make a precise game. It makes a scaffold with more of its surface repainted. You can describe the art direction for three sentences and still get three lives and a top-edge spawner, because art direction is a slot the scaffold exposes and life count is a slot it does not.
The genre word does more work than any adjective. If your sentence contains "dodge", the numbers arrive already tuned for dodging — spawn interval, player speed, hitbox size, all consistent with each other. If it contains "collect", a different set arrives. Adjectives about mood or style reach the presentation layer and stop there. This is the single most useful thing to know about text-to-game input: the noun phrase selects the numbers, the adjectives select the paint.
The fill order
Every text-to-game pipeline resolves slots in some order, and the order is what makes the output predictable. It is also why a slot you left empty early is more expensive than one you left empty late.
| Position | Slot being resolved | Why it constrains everything after it |
|---|---|---|
| 1 | Genre scaffold | Selects the entire default number set |
| 2 | World frame — fixed screen or scrolling world | Decides whether a camera exists at all |
| 3 | Camera behaviour — none, follow, clamp | Only meaningful if position 2 opened a world |
| 4 | Failure state — lives, timer, single hit, none | Sets the length of a run, which sets pacing |
| 5 | Input map | Constrained by the control surface your sentence named |
| 6 | Numeric tuning — speed, spawn rate, ramp | Tuned against positions 1 and 4 |
| 7 | Presentation — shapes, sprites, DOM, audio | The only layer adjectives reach reliably |
Read the table downward and the rule appears: each position narrows the ones below it. A decision at position 4 about run length is already half-made by position 1, because the scaffold came with a fail state attached. By the time the pipeline reaches position 7, almost nothing is still open — which is exactly why "make it look like a neon arcade" changes so much less than people expect, and why it changes the thing people notice first.
The practical version of the rule: your leverage decreases as you move down the table, and your visibility increases. The slots that matter most are the ones you can least see.
Nine defaults, and the fingerprint each one leaves
These are the defaults that most often arrive uninvited. Each has an observable fingerprint, so you can confirm it in your own build in under a minute instead of guessing.
| # | Silent default | The fingerprint you will see | Smallest edit that moves it |
|---|---|---|---|
| 1 | Keyboard-only input, arrows or WASD | Nothing responds to a drag or a tap | "dragging anywhere on screen steers" |
| 2 | Three lives, one collision costs one | The HUD shows three marks you did not ask for | "one collision ends the run" |
| 3 | Score rises in fixed steps per pickup | The number jumps by tens, never by ones | "score equals seconds survived" |
| 4 | Difficulty steps up at fixed score thresholds | The game is calm, then abruptly not | "speed constant for the whole run" |
| 5 | A fixed internal resolution, scaled to fit | Letterboxing, or a blurry upscale on a phone | "full viewport, portrait, no letterbox" |
| 6 | Camera locked to the screen | The world ends where the window ends | "world three screens wide, camera follows with clamp" |
| 7 | Restart reloads the whole page | The best score vanishes on retry | "restart keeps the best score for the session" |
| 8 | Obstacles spawn on a timer from one edge | Everything arrives from the same direction, evenly spaced | "spawn from any edge, weighted away from the player" |
| 9 | No audio at all, or one placeholder blip | Silence, or the same tone for every event | "no audio" — say it, so nothing is added later |
Default 6 is the one that quietly decides whether your idea is even the same idea. A game described as "explore a cave" and delivered with a locked camera is not an exploration game; it is a single-screen game with cave art. The sentence was satisfied, the intent was not.
Default 4 is the one that most often reads as a bug. A step-function difficulty ramp feels like the game breaking rather than getting harder, because the player experiences a discontinuity rather than a slope. If your build seems fine for forty seconds and then unfair, check this before you check anything else.
Default 8 is the one that most often reads as "boring" without anyone being able to say why. Even spacing from one direction is the cheapest spawner to write and the least interesting to play, because it makes the player's position irrelevant. You will not find this by reading your sentence. You will find it by standing still for a minute and noticing that nothing about where you stand changes what happens.
Where two tools diverge on the identical sentence
Take one sentence, feed it to two generators, and compare. The differences cluster in five places, in this order of size.
1. Scaffold choice. If your sentence contains two verbs, or one verb that maps to two archetypes, the tools may pick differently — one reads "avoid the falling blocks" as a dodge game, the other as a survival game with a timer. This is the largest divergence and it happens before any of your words are applied.
2. World frame. Fixed screen versus scrolling world. Same sentence, and one build has a camera and the other does not.
3. Failure semantics. Lives versus a single hit versus a clock. Two builds of the same sentence can have run lengths that differ by an order of magnitude, and neither is wrong.
4. Numeric tuning. Even with the same scaffold and the same fail state, the constants differ. Player speed, spawn interval, and the ramp curve are the three that decide how the first thirty seconds feel.
5. Input and viewport. Keyboard versus touch, letterboxed versus fluid. Most visible, least consequential.
The rule that predicts all five: divergence is proportional to how early the first empty slot sits in the fill order, and how much freedom that slot has. Leave the scaffold ambiguous and the two builds are different games. Specify the scaffold and the fail state, and the two builds become recognisably the same game with different tuning. You cannot close the gap at position 7 by adding adjectives; you close it at position 1 by naming the archetype.
This is also why published tool-versus-tool comparisons are worth less than they look. They typically run one sentence per tool and then score the results, which measures the scaffold lottery, not the tools. A comparison that means anything has to fix positions 1 through 5 in the brief and let only positions 6 and 7 float. If a comparison does not tell you what it held constant, it is a story about one sentence, not about the products.
The read-back protocol
You do not need a second tool to find out what was assumed. Six probes, ten minutes, run against your own build. Each one produces a line in the ledger.
Probe 1 — freeze. Pause the game, or open a menu, then keep pressing movement keys. If the world keeps moving behind the pause, the loop is one clock. If everything stops, it is two. This tells you whether timers and animation share a source, which decides how hard every later change will be.
Probe 2 — wrong key. Press every key on the keyboard, one at a time, and write down what each does. The keys that do nothing are the slots that were never specified. A build where only four keys respond is a build with a four-slot input map, and the rest of the design assumed those four were enough.
Probe 3 — edge. Walk into every boundary of the play area. Clamp, wrap, kill, or scroll — four different answers, and the one you get tells you whether a world exists behind the frame. If all four edges clamp, position 2 in the fill order was never opened.
Probe 4 — stand still. Do nothing for sixty seconds. Note what happens and when. Timers, spawn cadence, and any fail state that is not collision-driven all announce themselves here. If the screen stays empty until you move, the spawner is player-triggered and the pacing is yours, not the generator's.
Probe 5 — die twice. Die, restart, and play the same way again. If the second run is identical to the first, the generator seeded it. If not, note whether the restart cleared everything: score, position, timers, and any state that survived the first run. A restart that leaves one timer running is a bug you will otherwise discover in week two.
Probe 6 — one number. Find the single constant that most affects difficulty — usually player speed or spawn interval — and change it by thirty percent in each direction. If the game still works at plus and minus thirty, the tuning was designed. If it collapses at either end, the tuning was defaulted and the value you found was load-bearing by accident.
The order matters: probes 1 to 3 tell you what was specified, probes 4 to 6 tell you what was assumed.
Confirming that an override actually landed
Adding a clause is not the same as changing the game. A clause can be absorbed, misread, or applied and then undone by the next slot down the fill order. Three checks, each takes about two minutes, and all three are needed before you believe the change is real.
Check 1 — the fingerprint changed. Every default in the table above has a fingerprint. If you asked for single-hit failure, the HUD must lose its three marks. If it still shows three, the clause was read as flavour text. Never accept "it feels harder" as evidence; look for the specific thing that had to disappear.
Check 2 — the neighbour did not break. Overrides are applied to a scaffold, and scaffolds keep their internal consistency. Move the fail state from three lives to one hit and the spawn interval, which was tuned for three mistakes, is now tuned for one — the game becomes unfair in a way you will blame on the wrong thing. After any load-bearing override, re-run probe 6 on the two numbers nearest it in the fill order. If either now collapses at plus or minus thirty percent, the override landed but the tuning did not follow it.
Check 3 — it survives one more generation. Regenerate from the amended sentence once, without editing anything by hand. If the override is gone in the new build, it was not in the sentence in a form the pipeline could resolve — it was in your head, or in a phrase that mapped to a slot the scaffold does not expose. The version that survives a clean regeneration is the version you actually own; everything else is a manual edit you will have to make again.
The pattern across all three: an override is confirmed by absence, not by presence. You are looking for the thing that should no longer be there. Presence is easy to fake — a HUD label, a menu entry, a line of on-screen text — and absence is not.
The ledger
Fill one row per default you found. Ten minutes, once per build, and it replaces every "why does this feel off" conversation you would otherwise have with yourself.
BUILD: ______________________ SENTENCE: ______________________________
WHAT MY SENTENCE FIXED
verb ............................... ______
fail condition ..................... ______
control surface ................... ______
subject matter .................... ______
camera (if stated) ................ ______
WHAT WAS ASSUMED (probe that found it)
scaffold .......................... ______ (P1)
world frame ....................... ______ (P3)
camera ............................ ______ (P3)
fail state ........................ ______ (P5)
input map ......................... ______ (P2)
spawn behaviour ................... ______ (P4)
difficulty ramp ................... ______ (P6)
viewport behaviour ................ ______ (resize)
restart completeness .............. ______ (P5)
LOAD-BEARING? for each assumed row:
if I changed this one value, is it still the same game? yes / no
if no -> it must appear in the sentence, not in the editor
VERDICT
assumed rows that are load-bearing .... ______
assumed rows that are cosmetic ....... ______The test in the middle is the whole method. A default is load-bearing if changing it changes which game this is. Camera, world frame, fail state, and spawn behaviour usually are. Score step size and audio usually are not. Load-bearing defaults are the ones that must move from the assumed column into the sentence, because they are design decisions that were made without you and are expensive to retrofit later.
Cosmetic ones should be left alone. Every default you override is a sentence clause you paid for, and clauses compete: a brief that specifies nine things gets each of them approximated, while a brief that specifies three gets those three respected. Spend the clauses on the load-bearing rows and accept the rest.
The one rule: the sentence is not the bottleneck. The defaults are. You cannot see them in the output until you probe for them, and you cannot fix the ones that matter by editing the result — only by naming them before the next generation, or by accepting them on purpose.
If you are still deciding how to shape the sentence itself rather than how to read what came back, that is a different problem, and the shape of the brief is where it gets solved. This page is the other half: what to do with the twelve slots you did not write.