The honest state of ai game making in 2026

Almost every strong impression of ai game making comes from a clip: forty seconds, one prompt, something appears and moves. Clips are not lies. They are a genuine record of the best case, captured on the run where it worked.

The problem is that a game is not a best case. A game is four hundred hours where most of the work is small, specific, and unglamorous, and the tooling has to hold up on the boring days as well as the demo day. A survey worth reading is about the boring days.

So this is a category survey with the marketing removed. It sorts the field into three piles: what genuinely works now, what does not, and what has an appearance of progress without much underneath. No forecasts stated as facts. No adoption figures, because the honest ones are hard to check and the checkable ones are usually somebody's press release.

Everything below is about capability, not about any particular tool. Capability moves slowly and is easy to test yourself. Product claims move quickly and are not.

One more ground rule. Where a claim below could be checked by you in an hour, it is worth more than a claim that could not, so the article leans on the ones you can reproduce. Open a tool, ask for the same sprite twice, and look at the two results side by side. That takes four minutes and settles more argument than any amount of reading.

If one thing has changed materially in two years, it is a model writing gameplay code inside an existing project. Not pseudocode in a chat window. Actual script files that compile, sit in the right folder, and get called by something.

It is good at the plumbing. Input handling, state machines, save and load, timers, inventory bookkeeping, signal wiring between objects, spawning, the fiddly maths in a camera follow, the third refactor of a damage function. That work is mostly pattern, and patterns are what these systems are built out of.

It is also good at a specific thing that is easy to undervalue: reading a codebase it did not write and answering a question about it. Where does the player's speed get set. What already listens for this event. Why does the enemy stop at the ledge. For someone who does not write code, that is the difference between a project that feels like a locked box and one that feels navigable.

What it is bad at is knowing what the game should be. Ask for a jump and you get a jump, competently. Ask for a jump that feels like a specific game you love and you get a plausible guess, then a second plausible guess, and the loop only closes when a person plays it and says shorter, heavier, faster off the ground.

The practical consequence is about how you brief it. Vague requests get generic implementations, because generic is the safest answer to an underspecified question. Specific requests about behaviour, numbers, and what should happen at the edges get much closer to what you meant, and the specificity has to come from someone who has decided what the game is.

The most useful real gain in the last two years is not a finished anything. It is the speed of getting an ugly, playable, roughly correct version of a space in front of you.

Generated 3D in 2026 makes one model with a texture from a description. The topology is dense and irregular, the UVs are machine-made, there are no levels of detail, and rigging or retopology is still a person's job. Read that list as a verdict on hero assets and it is damning. Read it as a verdict on a grey-box prop that exists so you can judge the size of a doorway, and it is irrelevant.

That is the honest position of generated geometry: excellent for blocking out a scene, poor for anything the camera lingers on. A market square with forty rough stalls in it teaches you about sightlines, walking distance, and whether the space is boring, and it teaches you that on the first afternoon rather than the third week.

The trap is the moment the blockout starts looking passable. Passable geometry has a way of surviving into production because replacing it feels like going backwards. Decide early which objects are scaffolding, and be willing to throw the scaffolding away.

There is a second, quieter benefit. A rough scene is something to react to, and reacting is easier than inventing. Standing in a badly proportioned corridor tells you what the right proportion is far more reliably than staring at an empty grid and trying to imagine it.

Text to image is quick and genuinely useful, and it fails in ways that are completely predictable once you have listed them.

Two calls with the same description do not match. Exact pixel dimensions are unreliable. There is no clean alpha edge unless somebody cuts it. A set of items does not share a palette. There is no sprite sheet coherence, no rig, and no guarantee that frame two of a walk cycle resembles frame one. None of that is a bug being fixed next quarter; it follows from how the output is produced.

So the honest framing is that generated art is a strong placeholder and a weak final asset. As a placeholder it is close to ideal, because a placeholder's whole job is to stop you guessing what the screen will feel like, and it does that in seconds for the price of nothing.

As a final asset it fails at consistency, and consistency is most of what art direction means. A game where every item was individually beautiful and none of them agreed with each other looks worse than a game drawn in one flat style by one person in an afternoon.

There is a route through this that works, which is to use generation for the layout and the idea of an asset, then have a person unify the set: one palette, one line weight, one light direction. That is much less work than drawing from nothing, and it is the step people skip when they expect the output to be finished.

Generated sound effects work at a specific size: a few seconds, one at a time, made from a description. Impacts, footsteps, interface blips, a door, a pickup chime. For a prototype that has been silent for a week, that is a real improvement in five minutes.

What it is not is an audio system. There is no layered mix, no adaptive behaviour that follows the player's state, no set of variations that sit together as a family, no ducking, no reverb sense of the room. Those are engine and mixing problems, and they stay yours.

Music generation is not part of this workflow at all, and it is worth being blunt about that rather than letting the word "audio" carry an implication it has not earned.

The practical value is the same as with art. A prototype with rough sound gets judged more accurately than a silent one, because so much of whether an action feels good lives in the response. Rough sound gets you to a fair verdict. It does not get you to a soundtrack.

One caution about volume. Because clips are cheap, it is easy to end up with sixty of them and no idea which are actually in the build. Name them as you go and delete the ones you rejected, or the folder becomes its own small tax on every future decision.

The most valuable shift is not any single output. It is that the gap between "I wonder if" and "I can see it" got much shorter, and it got shorter across several things at once: code, rough art, a blocked-out space, a placeholder noise.

That matters because most game design is a search problem. You do not reason your way to a good jump arc. You try eleven and keep one. Anything that raises the number of attempts you can afford raises the quality of what you keep, and it does so without making anyone smarter.

It also changes what is worth prototyping. Ideas that were previously not worth the two days it took to test them are now worth the twenty minutes. Some of those turn out to be the good ones, and they were previously invisible because nobody would sink two days into a hunch.

The risk on the other side is real. Cheap attempts make it easy to keep generating instead of deciding, and a folder of forty variations is not progress. Speed is only a gain if something gets chosen.

A useful discipline is to decide the question before you start generating. If you know you are testing whether the dash should cancel the attack, you will recognise the answer when you see it. If you are generating to see what comes out, you will keep going for a long time and finish the day with nothing decided.

Every failure mode above points the same direction. These systems produce a good first draft of an isolated piece and struggle with anything that has to agree with everything else.

A final 2D asset has to sit in a palette, hold a silhouette at the size it is actually displayed, and match its own animation frames. A final 3D asset needs clean topology, sane UVs, levels of detail, and a rig that an animator can use. A final audio bed needs to respond to what the player is doing. None of those are one-shot outputs; they are outputs plus a person integrating them.

Long-form coherence is the same problem stretched over time. A model will happily write you fifty quest descriptions. Somewhere around the twelfth, the same village has two names, a character who died is giving out work, and the tone has drifted from wry to earnest without anyone deciding it should. Individually each one reads fine. As a body of content they do not hold.

The workaround is not a better prompt. It is structure: a small authored source of truth about the world that everything generated has to be checked against, and a person who does the checking. That is genuine work, and pretending otherwise is where most disappointment starts.

The same applies to systems rather than text. Ten enemy behaviours produced independently will not form a roster, because a roster is defined by how its members differ from each other. Coherence is a property of the set, and these systems produce members.

This is the flat ceiling of the whole category, and it is not moving. A model can tell you that your design resembles other designs. It cannot tell you whether your game is fun, because fun is a fact about a person playing, and the model is not playing.

Ask one whether your combat feels good and you will get a fluent, well-organised answer assembled out of things people have written about combat. It will sound like feedback. It is not feedback, because nothing was experienced. The dangerous part is that it is confident enough to substitute for the playtest you did not run.

You are the instrument here. You do not have to write the code to judge the result, and nobody needs to protect you from the verdict. You play it, you notice that the second room is boring, and that noticing is the single most valuable input in the whole process.

Treat the loop accordingly. Generate to get something playable, play it yourself, decide what is wrong in plain words, and send that back as the next instruction. The judgment stays with you not as a limitation but because it is the only place it can live.

It also means playtesting other people has lost none of its value. Your judgment is reliable about whether something is wrong and much less reliable about whether a stranger will understand it, and no amount of generated content changes that arithmetic.

Three things get reported as progress and are mostly presentation.

The first is fluency. Outputs are better written, better lit, better composed, and better at looking like the thing they are imitating. That is real, but it is improvement in the first draft, not in the integration, and the integration is where the hours went in the first place. A more beautiful asset with the same alpha edge problem costs the same to fix.

The second is the one-prompt game. A description goes in, something playable comes out, and it is genuinely impressive for as long as you do not try to change it. The test is not whether it produced something. The test is what happens on the fourth change request, when your alteration has to survive contact with everything already there.

The third is the vocabulary. Words like agent, pipeline, and end-to-end have expanded to cover workflows that still contain all the same manual steps, just described at a higher altitude. When you read a claim, translate it downward: which specific file does this produce, and who fixes it when it is wrong.

None of these three are scams. They are ordinary product enthusiasm, and the outputs behind them are genuinely better than they were. The distortion is in the implied conclusion, which is that the remaining work is small. It is not small, and knowing that in advance is the difference between a project that survives contact with reality and one that stalls out in month two.

Put generation where it is strong. Use it to get to a playable state fast, to write the plumbing, to fill a scene with objects whose job is to be the right size, and to make noise where there was silence. Every one of those is a placeholder with a job.

Keep authorship where it is scarce. The rules of your world, the tone, the thing the game is actually about, the decision about what the player does with their hands for the first ninety seconds. Those are decisions, not outputs, and no volume of generated material substitutes for having made them.

Play constantly and early. The whole gain from faster iteration is spent the moment you stop looking at the result, because then you are just accumulating material that nobody has checked. A build you have played is worth more than a folder you have not opened.

And keep a clear line in your head between draft and final. Almost everything the category is good at is drafting. Drafting fast is worth a great deal. It is simply not the same claim as finishing, and the gap between those two words is where nearly all the disappointment in this field is manufactured.