How to Make a Game With AI

Don't ask for a game. Ask for one job, run it, test it, then open a fresh chat for the next job. That loop — scoped task, clean session, playable check, fix only that job — is the difference between a build you can hand to someone and a folder of half-working prototypes. Engine choice, model choice and asset pipeline are variables you tune inside the loop; none of them replaces it.

One shortcut, stated plainly because it answers a different question: if all you want is to find out whether a sentence can become a game, you don't need an engine. sentencetogame.com takes one sentence and returns a playable browser game in one of four genres — platformer, shooter, collector, maze escape — under one of six themes: castle, space, ocean, forest, neon city, haunted. It is free, and there is no sign-up. It does not do story, RPG systems, 3D or multiplayer. That is the full extent of it, and it settles the first question in about a minute; everything below is for the second question.

A concrete starting stack: an engine with an agent bridge (Unreal Engine 5.8 added an experimental MCP plugin on June 23, 2026; Unity relies on community MCP servers), a coding model driving that bridge, and a separate image model for concept art and HUD references. Block the level with primitives first. Then hand over one job at a time: character controller, HUD, save system, one enemy type, one menu. Every job ends the same way — you play the build.

What everyone who has actually shipped this agrees on

Three claims survived every workflow I compared.

AI is a tool, not a magic wand. Builders who finished something all describe the same posture: use the model where it saves hours, do the rest by hand. One 3D platformer assembled over a long weekend used generated assets for rocks, buildings and props, then spent an entire day in Blender snapping parts together by hand because the model could not judge what looked right in context.

Code is the strong suit; vision is the weak one. Character controllers come out fast and clean. Placement, composition and lighting do not. One builder tried to have the model place lanterns and lights around a scene and gave up: the model cannot reliably see the scene well enough to decide where a light belongs, so manual placement was faster than prompting.

One job per session beats one giant prompt. A model carrying nine other tasks in its context reads more and makes more mistakes, and it burns more tokens doing it. Fresh chat per job, test at the end, and if the test fails, send that one job back — not the whole game.

Where the advice contradicts itself

This is the part worth reading twice, because the contradictions are where the real decisions live.

"Never ask for the whole game" versus "I asked for the whole game and it worked." One builder's rule is explicit: do not request a full game in a single prompt. Another ran the opposite experiment and got levels, main menu, save system, progression, pause menu, music, sound effects and enemies in a single 22-minute-50-second run. Both are true. The single-prompt build ran; it just wasn't a game yet. Its levels were random platform scatter, one wall-jump section had no way in, and every enemy looked unrelated to the world. A one-prompt game is a skeleton you can walk around in, not a game you can ship.

Which model is best depends on the job, and the claims cancel out. One account says Claude-class models are stronger at logic but weaker at visual style. Another says a different frontier model was better at vision — then adds that the improvement was insignificant for anything as spatial as light placement. A third routes four different models by role: one for hard calls, one for mechanics, one for Blender work, one for aesthetics. The two frontier models in play — Claude Opus 5.5 (September 22, 2026) and GPT-6 (October 7, 2026) — traded wins by task, not by benchmark. Nobody wins everywhere, and routing matters more than the leaderboard.

"AI can't do art" sits next to a HUD that matched its reference exactly. A HUD generated as a reference image and handed to a coding model was implemented in 44 minutes and looked like the reference — no generic substitute. Yet the same project's menus, music and sound effects came out flat, and a separate test found that realistic meshes fail while simple box-and-roof shapes work fine because lighting carries them. Art is not one task. Reference-driven UI is nearly solved; original art direction is not.

Cost estimates diverge by an order of magnitude. One build ran on a $20 monthly subscription while the same work, priced at API rates, would have been just under $400. Another paid $10 a month for an image model while a free alternative covered most of the same ground with a capped number of fast generations. Subscription pricing hides the real consumption, and the gap between the two numbers is the gap between "hobby" and "budget line."

Timelines are not comparable. A 3D platformer took a 70-hour weekend. A character controller plus the rest of a 2D platformer took 1 hour 28 minutes of model time — but two weeks of iteration still produced bad levels. Time tracks scope and taste, not model speed.

Details only one or two builders mention

These are the bits that decide whether a build survives week two.

• A 49-minute coffee break can make a model look 60% slower than it is. One reported task took 2 hours 18 minutes; 49 minutes 16 seconds of that was the model waiting for project-access approval while the builder was away. The real work was 17 minutes 23 seconds.
• The cheapest collider is one vertex. Build a single plane, extrude one vertex around the map perimeter, raise it slightly so the player cannot jump it. Falling into water kills and restarts; walking outside the map becomes impossible without a single mesh collider.
• Temporary colliders need a removal hook. A bridge that lowers after a lever pull also has to delete the collider that was blocking the gap — otherwise the shortcut stays sealed after the animation plays.
• Tell the model the axis, not the outcome. "Make the door open" invites a screenshot-and-guess loop. "The door slides along the X axis" gets a correct blueprint in one pass and spends fewer tokens.
• Footprints are paint, not objects. One build paints every step into a single fixed-size image instead of spawning decals; a thousand tracks cost the same as one, and wind erases them by writing into the same texture.
• Terrain queries are local, not global. A snow system samples 110,000 height points 60 times a second, but only across a 120-metre window that slides with the character — the height keeps changing because boots compress snow and wind builds drifts.
• Batch your asset generations. Generating several rocks or barrels in one pass saves credits and produces near-identical quality; verifying each asset afterwards can still eat a full day.
• Logical meshes beat pretty meshes. Meshes built from separable parts let you delete or extend a single brick in edit mode; a fused mesh forces a re-prompt.
• Set polygon budget to auto. Left manual, poly count quietly changes how a generated asset reads in engine.
• Pixel art needs a plotting library, not an image model. Image models fake pixels. Routing the pixel placement through a Python imaging library produced true pixel art, then a second frame for the walk cycle.
• Music and SFX have known cheap paths. A software synthesizer plus a general-purpose soundfont covers music; a free SFX pack covers impacts. Neither sounds bespoke, but both ship.
• Indoor spaces can be faked with geometry removal. Stepping inside a house removes the roof and front wall; walking behind a tree fades the whole object. No occlusion system required.
• Usage limits are the real clock. A five-hour rolling cap plus a weekly cap meant roughly 20 minutes of medium-setting work before a lockout; a cheaper sibling model stretched the same budget at the cost of speed.

A workflow that survives contact with a real project

1. Pick the bridge, not the brand. Unreal Engine 5.8's experimental MCP plugin (June 23, 2026) or a Unity MCP server. The bridge is what lets a coding model read and edit the project; without it you are copy-pasting code.
2. Blockout first, with placeholders. Flat ground, boxes for buildings, a capsule for the character. Get the scale right before any asset generation, because every later asset inherits that scale.
3. Character controller as job one. Expect a working controller in roughly one to three hours of model time. Fix collision boxes early: a capsule collider makes the character float at ledges and snag on corners.
4. One job, one chat, one test. HUD, save system, enemy AI, menu — each in its own session, each ending with a playtest.
5. Generate assets in batches, then assemble by hand. Image model for concepts, 3D model for meshes, Blender for assembly and decimation. A main character at around 8,000 polygons is a reasonable target.
6. Reference-driven UI. Generate a HUD or menu as an image, drop it in the project as a reference, then ask for implementation. This is the most reliable visual win in the whole pipeline. A video model (Seedance 2.0, February 12, 2026) accepts a still as input, so the same image becomes a menu background in one image-to-video call.
7. Colliders and boundaries last, after the layout stops moving.
8. Watch the usage meter, not the clock. Time estimates are distorted by approval waits and lockouts.

The part nobody has solved

Level design. A model can build a functional level; it struggles to build one that teaches, surprises or paces. Told to put a collectible at the top of a hill, it built a hill blocking the path to the collectible. Told to avoid a straight corridor, it produced a zigzag that was still a corridor. Told to make challenges optional, it made a fork with no reason to take either branch.

The workaround that showed the most promise was boring: ask the model for a design document first, approve or reject it, then ask for implementation. The gap between "it runs" and "it's fun" is still yours to close — and that gap is where the next few weekends will go.

Two ways out

They are not ranked. If you want a game you can keep, extend and ship, the loop at the top is the path: engine, bridge, one job per session, a playtest at the end of every job. None of the AI tooling takes the engine out of that path — it takes out some of the typing, and the level design, the taste and the last 10% stay where they were.

If what you want is to see the thing running today, a one-sentence generator returns a playable page in about a minute, inside limits it states up front: four genres, six themes, no story, no 3D, no multiplayer. One path answers "can this become a game." The other answers "can I finish this game." Most people need the first answer before they are willing to pay for the second.