What an AI Game Maker Actually Does — and Where It Stops

An AI game maker takes a paragraph of plain English and hands back something you can open in a browser tab and play. You describe the camera, the weapon, the weather, the mood. Something comes back. Then you fix it.

That fixing is not a footnote. It is the job. Every person who has shipped a playable game this way describes the same shape: the first build arrives absurdly fast, and it is wrong in ways only a human can see.

The floor, stated honestly

Prompt in, playable build out. That part works, including for people who have never opened an editor. Almost none of it, however, is generated out of nothing. What ships sits on ordinary machinery: a 2D engine whose logic is an event sheet — conditions on the left, actions on the right — with drop-in behaviors for platforming, bullets and eight-direction movement; a scriptable 3D editor wired to the model over a protocol connection, so it can write Python, run it, look at a viewport screenshot and run it again; a mesh generator that turns a concept image into a rigged character inside a polygon budget you choose. Roughly $16 a month buys the no-code engine. The model decides what to write. The engine still runs it.

So the useful question is not "can it make a game." It is how far past the first build you can get, and what gives out when you try.

The four things nobody disputes

The first output is a draft. No one describes shipping generation one.

Iteration is conversation, not a fresh prompt. "The enemies are too fat, they jam on the stairs" goes back through the same thread, and the change lands.

Feel is your problem. A model can make harder blocks absorb more bullets per gun. It cannot tell whether that feels right. One builder burned weeks of manual work on a single section for exactly that reason: the code was correct and the experience was wrong.

You are standing on other people's work. Downloaded assets, a bear from a library under Creative Commons attribution, open-source engines, years of community reverse-engineering. Generation is the last mile, not the road.

Where the accounts flatly contradict each other

This is the part worth reading, because most advice picks one side and presents it as settled.

One prompt or twenty. One creator typed an extremely detailed brief — villain, weapon list, weather, camera, a soundtrack reference — and had a playable 3D wave-survival game in twenty to thirty minutes. Another states the opposite as a hard rule: never ask for the whole game in one prompt. One job, one fresh session, and every job ends with a test. When the test fails, one job goes back, not the game. The reason given is mechanical — a session carrying nine other jobs reads more, mistakes more, and spends more. The longest project in the same review ran different sessions per task and different effort levels depending on how hard the task was, specifically to hold the spend down.

Twenty minutes or eleven weeks. Both are real and both were measured on shipped builds: a first version in under a day; a first version in twenty minutes; two weeks for a fishing game built by one person; almost three months for a sailing-and-fishing game that feels finished; three days for a racing prototype. The spread is not about model quality. It tracks how much of the game is feel, and feel is the part that does not compress. Terrain, physics and menu states collapse nicely into generation. The question "does this feel good" does not collapse at all.

Generated 3D or none at all. The fishing developer used no 3D generator and no image generator whatsoever. Everything came out of a scriptable 3D editor driven by the model, and it looks better for it. Meanwhile another builder reports that roughly nine in ten of the 3D models in his game come from a generator and calls it the obvious choice for anyone working in 3D. Both shipped. Both are telling the truth about their own game, which is the real lesson: the answer depends on whether you can already judge a mesh.

Realistic meshes. "Do not ask for realistic meshes. It will not deliver. Simple shapes it does well." That is one builder, whose house is boxes and a roof, and who lets lighting carry the rest. Another says generated meshes and generated textures now carry most of his scenes. The reconciliation is unglamorous and it holds: simple geometry under good light beats ambitious geometry under bad light, and that will stay true until the tooling moves again.

The details almost nobody writes down

Do not cache the ground. One builder asks the terrain roughly 110,000 height questions sixty times a second, and deliberately asks about only a 120-meter window that slides along with the character. The obvious optimisation — compute the heights once and keep them — is wrong here, because a boot presses the snow down and the wind builds a drift back up. The height is not a constant. It is a stream.

Paint tracks into one image, and let everything read it. Every step draws into a single fixed-size texture. The snow reads it, the wind erases it, and the enemies ride into the same image. That is the whole trick: a thousand tracks cost what one track costs. Spawn a footprint object per step and the cost grows with every step you take.

Never touch the mesh. When the roof comes out wrong, do not grab vertices. Fix one line of the generated script and run it again. The model is not producing a model. It is producing a recipe, and the recipe is the thing you edit.

Cheat the interior. Inside the house is not a second location. Step through the door and the roof and front wall come off; anything between the camera and the player fades on a raycast. Two cheap tricks instead of a second level.

Ship the editor. After the first version of a 2.5D pixel game, the next thing the team built was a level editor, so other people could place trees and write maps. That is usually the moment a generated game stops being a demo.

Two ceilings nobody prices in. No-code lowers the floor and it lowers the ceiling. Every layer between what you build and what the machine runs costs translation time, and visual logic gets translated on the fly while doing more generic work than the exact thing you needed. When the graph gets large it turns into spaghetti that is miserable to debug. Collaboration suffers too — text diffs merge, visual graphs do not — and more than one builder has said the plan is to learn a code-first engine purely so other people can work on the same project.

The legal floor, if you are merging games you did not make. You still need to own the originals; the mashup ships no assets and reads them off your disk. Owning a copy does not license you to redistribute anything out of it. A fan reverse-engineering project for two classic open-world games took a DMCA takedown in February 2021, was sued that September, and was settled and dismissed in April 2023. The projects never came back. And install with care: only run a mashup you can verify is the real one.

What to actually do

Pick the smallest complete game you can describe in one paragraph. Write that paragraph with an unreasonable amount of detail — camera, failure state, weather, sound.

Get the first build. Play it before you change anything.

Then stop asking for "the game." Ask for one job. Give it a fresh session. End it with a test, and when the test fails send that one job back rather than the whole thing.

Fix feel by hand, and budget weeks for it rather than minutes. Keep your palette frozen, your geometry simple, your tricks cheap. If you plan to build on someone else's game, read the licence before you write the prompt.