How to Make a Video Game With AI Without Ending Up With a Prototype

Short answer: a prototype is not an early version of your game. It is a build that has never been asked a shipping question. Nine questions stand between "it runs in a browser tab" and "a store will accept it," and a generated build answers zero of them by default — not because the generator is bad, but because nothing in the prompt-to-playable pipeline ever asks. Seven of those nine are chores you can clear in one afternoon. Two are decisions, and if you get them wrong you cannot fix them later by adding features.

So the order is inverted from what almost everyone does: answer the nine questions first, then write the prompt. The gate that costs one clause before you generate costs four weeks of re-tuning after.

The tab you tested in is a forgiving host. It forgives input, orientation, install, version, licence, age, and persistence. Every one of those is something a store checks and a tab silently ignores — which is why your build can pass a test that was never administered.

Why the workflow parks at a prototype

The mechanism is not mysterious. A generator optimises for the shortest path to something that runs. Every step in that path is a step toward "it runs." Nothing in the path is a step toward "it can be shipped," because shipping is not part of the objective function. A prototype is the fixed point of that workflow. You did not fail to leave the stage; the stage is where the workflow terminates.

This matters because the usual advice — "add more features until it feels like a real game" — moves you along the wrong axis. Feature count is not what separates the two states. Consider two builds:

Build B is smaller in every content dimension and finished in the only dimension that counts. This is the single most useful reframe available: finish is a property of the gates you closed, not the volume you added. Which is also why the honest advice to most people making a game with AI is to cut content, not add it.

The nine gates

Read this as a checklist, not a lecture. The cost column is ordinal and deliberately not measured in hours: 1 means the fix lives in one form or one file; 5 means the fix changes numbers that everything else was tuned against.

Two of these are decisions. Seven are chores. The chores are cheap and the decisions are permanent, and almost everyone does them in the wrong order — chores last, decisions never.

A note on accuracy before you rely on any of this: platform rules move. What follows reflects the state of the two major stores in October 2026. Check the source pages the week you submit, because the gate is real even when a specific number has shifted.

Gate 1: target platform

A store build has an OS floor. Google Play requires new apps and updates to target Android 16 (API level 36) as of 31 August 2026; Apple requires a minimum deployment target in the project settings. If your output is a single HTML file with no build artefact, you have not failed this gate — you have skipped the entire category, which is a legitimate answer covered in the fork below. But you cannot answer it late by accident: a web build and a store build diverge at the point where the rendering layer has to become native, and that divergence is not a wrapper.

Gate 2: input model

This is the first of the two decisions, and it is the one that quietly ruins the most projects.

Generated builds are desktop-shaped. The pointer is precise, the target is small, hover exists, right-click exists, and the window can be any size. On a phone, none of that is true. A thumb covers roughly a centimetre of glass, there is no hover state, there is no right button, and the bottom third of the screen is where the hand already is.

Retrofitting input is not a patch. Changing the input model changes the hitbox sizes, which changes the difficulty curve, which changes the level layout, which changes the tuning of every number in the build — and all of those numbers were originally set against the old input. That is why it scores 5: the fix touches everything downstream of it.

The test takes ninety seconds and requires no tools. Hold the phone in one hand, play with your thumb, at half brightness, and count two things: mis-taps, and mechanics that require a hover state or a second button. If the count of either is above zero, you do not have a mobile game. You have a desktop game with a small window.

The decision rule that follows is blunt and saves months: if the core verb cannot be expressed with one thumb, change the verb or accept that this is a web game. Do not plan to "add touch controls later." Touch controls are not a control scheme, they are a redesign of what the player is doing.

Gate 3: viewport and safe area

Cheap, and skipped constantly. A fixed canvas with a desktop aspect ratio will letterbox on a phone, put the HUD under the notch, or clip the bottom row of the playfield behind a gesture bar. The fix is a layout decision — anchor the HUD to safe-area insets, decide whether the world crops or scales — and it belongs in the brief, because a generator that never hears about it will centre a 16:9 canvas and call it responsive.

Gate 4: session shape

On the web, the user closes the tab and expects to start over. On a device, the operating system kills your app whenever it wants: a phone call, a low-memory sweep, a swipe away. Those are different contracts, and a generated build honours neither explicitly — it assumes the page stays alive, which is true in a tab and false on a phone.

Two consequences you can check in ten minutes. First, background the build for ten minutes and return: if the run is gone, or the timer kept counting while the app was suspended, the session model is wrong. Second, look at the length of a run. A store game is played in the gaps of a day, which means a run has to end cleanly at a moment the player did not choose. A run that only ends when you die is a web-game shape.

Gate 5: persistence across versions

Progress that survives a reload is not the same as progress that survives an update. The second one is a schema question: the next build you ship will read saves written by the previous one, and if a field moved or a type changed, those saves either break or silently reset. This gate is a chore rather than a decision, but it is a chore with a deadline, because the moment you have real users you can no longer break their saves to fix your own convenience.

The mechanism — where saves land, why they corrupt, how to version the envelope — is its own problem and is covered in full on the save and progress page at /ai-generated-video-game. What belongs here is only the gate: decide the save point before the first prompt, because a game that saves at arbitrary moments needs a different state shape than one that saves at level boundaries.

Gate 6: age rating

The cheapest gate on the list and the most often discovered last. Both stores require a rating questionnaire, and the answers are declarations you are accountable for, not marketing copy. Apple's system now runs 4+, 9+, 13+, 16+, 18+ and requires the updated questionnaire; Google Play uses the IARC questionnaire and derives regional ratings from it.

The AI-specific wrinkle: a game whose content is generated may contain material you did not author and have not seen. If the build can produce text, images, or names at runtime, your honest answer to "does this contain user-generated content" is yes, and that answer changes the rating band and, on Apple's side, pulls the app into the content-moderation rules.

Gate 7: AI content safeguards

This is the gate that exists only because the game was made with AI, and it is the one the three biggest AI game makers never mention.

Google Play's AI-generated content policy requires apps that generate content using AI to include in-app user reporting or flagging that lets users report offensive content without leaving the app, and to use those reports to inform filtering. Apple does not have a separate AI chapter; instead, guideline 1.2 treats AI content creation apps alongside user-generated content platforms, requiring a filtering method, a reporting mechanism, the ability to block abusive users, and published contact information.

The practical shape of this gate for a game: if nothing in your build is generated at runtime, you are mostly out of scope and the gate costs you a paragraph in the review notes. If anything is generated at runtime — names, levels, dialogue, art — you need a report path inside the app and a moderation story you can describe in two sentences. That is a 3: real work, but bounded work.

Gate 8: data disclosure

Play's Data safety form and Apple's App privacy details both ask what you collect and where it goes. Most AI-made games collect almost nothing, which is a genuine competitive advantage and should be declared rather than assumed. The failure mode is not over-collection; it is an undeclared analytics snippet or a font loaded from a third party that quietly ships an IP address. List every network call the build makes before you open the form, not after.

Gate 9: distinctiveness

The second irreversible decision, and the one nobody warns you about.

Apple's guideline 4.2 says, in the company's own words, that "if your app is not particularly useful, unique, or 'app-like,' it doesn't belong on the App Store." Guideline 4.3 says not to submit apps "indistinguishable from what's already widely available." And 4.2.6 adds a clause that lands directly on this category: apps created using commercialised templates or app-generation services are rejected unless submitted directly by the content provider.

Read that last one carefully, because it is easy to over-read. It targets template and app-generation services, not every project that used AI. But the practical question it forces is unavoidable: if a thousand people can type the same sentence into the same public tool and get the same game, what exactly is the reviewer being asked to approve? Your build is not rejected for being AI-made. It is rejected for being the default output, and default output is reproducible by anyone.

This is the only gate that gets more expensive as you add features. Every generic system you bolt on — a shop, a leaderboard, a particle effect — is another surface that matches everyone else's build. The thing that closes this gate is small and specific: one rule that is yours, one constraint nobody else imposed, one dataset or mechanic that could only come from you. A game where the player cannot jump but the level is built around that absence is more distinct than a game with twelve generic levels.

The test is one sentence, written before you build: what would make a reviewer say this is not the default output? If you cannot write that sentence before the first prompt, you will not be able to write it after the twentieth. Features do not produce that sentence. Decisions do.

The one-sentence shipping brief

Here is the artefact that closes gates 2, 3, 4, and 5 before a single line is generated. It is one sentence, not a specification, because a six-clause sentence still selects one genre scaffold while a page of requirements gets approximated clause by clause.

Build a [genre] for [one-thumb phone / desktop browser]
where the player [single verb] and [one constraint that makes it not the default],
in runs of [length], saving at [save point],
in [orientation], and nothing that requires [excluded input].

Six slots, one sentence, and each slot exists to close a specific gate:

A filled example, so the shape is concrete:

Build a one-screen arcade game for one-thumb phone
where the player nudges a drifting block and cannot stop it,
in runs of 45 seconds, saving at the end of each run,
in portrait, and nothing that requires dragging or a second button.

Note what is absent: no art direction, no theme, no story, no feature list. Those are the clauses that get approximated anyway. Spend the sentence on the gates.

The 90-minute gate audit

Do this once per project, before the first prompt, and again before you submit.

0–10 minutes: write the brief. Fill the six slots. If you cannot fill the constraint slot, stop here — you have a distinctiveness problem, not a build problem, and no amount of generating will solve it.

10–35 minutes: the two decisions. Gates 2 and 9. Run the thumb test on your current build or on the closest thing you have. Write the one-sentence difference. Both outcomes are binary, and both are cheap now and impossible later.

35–65 minutes: the two code-shaped chores. Gates 4 and 5. Background the build for ten minutes. Decide the save point. Decide what happens to a run the OS interrupts.

65–85 minutes: the three form-shaped chores. Gates 6, 7, 8. Draft the age rating answers, decide whether anything generates at runtime, list the network calls.

85–90 minutes: write the verdict. One line, one of three: store, web, or do not ship. Then act on it.

The audit's output is not a to-do list. It is a destination.

The fork: when the store is the wrong destination

Here is the judgment the entire AI game maker category avoids, because every one of those products is selling store-shaped output: most games made with AI should not go to a store, and shipping them on the web is a finished product, not a compromise.

Six of the nine gates do not exist on the web. There is no install target, no orientation contract, no rating questionnaire, no data safety form, no distinctiveness review, and no platform policy on generated content. What survives is input (still real, because thumbs exist everywhere), session shape (simpler, because a tab closing is a legitimate ending), and persistence (simpler, because you control the version).

Four questions decide it. Answer honestly, and if all four are no, a store is a cost with no return:

1. Does this need to be found by people who are not already looking for it? Store search is discovery; a URL is not.
2. Does it need to work offline, in a place with no signal?
3. Does it need to live on a home screen, opened dozens of times a day?
4. Does it need to take money through the platform's billing system?

If the answer to all four is no — and for a 45-second arcade game made in an afternoon, it usually is — then the store adds nine gates, a review cycle, a developer account, and a testing period, in exchange for a worse version of the thing you already have. On Play, a new personal developer account also has to run a closed test with at least 12 testers enrolled continuously for 14 days before it can even request production access. That is not a formality; it is three weeks of calendar time before your first real user.

And the word "prototype" is assigned by destination, not by quality. A tight, finished, one-thumb web game is a finished game. A twelve-level build that cannot survive a phone call is a prototype no matter which store it is aimed at.

Repairing a gate after you have already built

If the audit comes back red and the build exists, repair in this order — cheapest first, because the cheap ones buy you information about whether the expensive ones are worth doing.

Two rows at the bottom are the whole point of doing this early. Gates 8 through 3 are paperwork and plumbing. Gate 2 is a re-tune that cascades. Gate 9 is a new project wearing the old one's name.

The twelve-item pre-submit check

Twenty minutes, in this order, before you upload anything.

1. Build artefact exists and installs on a clean device.
2. First launch reaches gameplay with no login and no crash.
3. The core loop works one-thumbed, portrait and landscape as declared.
4. A run ends cleanly when interrupted, and resumes without losing progress.
5. A save written by this build loads in this build.
6. The HUD clears the notch and the gesture bar.
7. No placeholder text, no lorem ipsum, no broken image, no dead button.
8. Every screen reachable; no path ends in a blank view.
9. Age rating questionnaire answered, and the answer matches the content.
10. Runtime generation declared, with an in-app report path if any exists.
11. Data disclosure lists every network call the build actually makes.
12. One sentence written that explains why this is not the default output.

Item 12 is the one that fails most often, and it is the one no amount of testing will fix.

What this page does not answer

It does not tell you how many rounds a build takes to converge, or what it costs — that is the cost page at /ai-generated-game. It does not tell you how a sentence gets expanded into a game — that is the fill-order page at /ai-game-generator-from-text. It does not tell you how to fix logic that is already broken — that is /why-ai-generated-game-feels-broken. And it does not tell you whether your idea is worth building at all — that is /game-made-by-ai.

What it does tell you is the part that decides whether the thing you made this afternoon counts as a game: nine questions, two of which must be answered before you type the first prompt, and a fork that may send you somewhere other than a store.

The rule to take away: the cheapest gate is the one you answer before the first prompt, because at that point it costs one clause. Every gate you answer late is paid for in re-tuning, not in typing.