Why your first AI-generated game is bad, and what to do about it

The first one always goes the same way. You describe a game. Something gets built. It launches. There is a character, a ground plane, some enemies, a score. Nothing crashes.

You play it for ninety seconds and a feeling arrives that is hard to name at first. It is not that anything is broken. It is that nothing is happening. You move, you press the button, the enemy dies, the number goes up, and you have no reason to do it again.

Almost everybody's first reaction is to assume something went wrong technically, or that the tool is not good enough yet, or that the model needs to be smarter. Occasionally that is true. Overwhelmingly it is not. The thing you got is an accurate build of what you asked for, and what you asked for was a category rather than an experience.

This is worth saying plainly because the alternative wastes weeks. You can spend those weeks trying different tools and different phrasings and get the same boring game every time, because the problem was never in the generation.

"A 2D platformer where you collect coins." "A survival game on an island." "A roguelike dungeon crawler." Every one of those is a description of a category of games, not of a game.

Ask for a category and you get the average of that category, because the average is the only thing the description specifies. The jump height is the average jump height. The enemy walks back and forth because that is what enemies in that description do. The coin does nothing except increment. Nothing is wrong; everything is the median.

The median of a genre is exactly what nobody wants to play. What makes a platformer worth playing is never that it has platforms. It is a specific relationship between jump arc, momentum, and level geometry that someone tuned for months. Celeste is not "a platformer with a dash". It is a dash with a specific length, a specific freeze frame, a specific rule about when it comes back, and levels built entirely around those choices.

None of that is inferable from the genre name, so none of it is in what you get. The generation did its job. The description contained no game.

The corollary is uncomfortable and useful: the interesting part of your game is the part you have not thought of yet. Until you make a decision that is specific to your game and not implied by its genre, no tool of any kind can produce anything other than the average.

A model can tell you what games in a genre usually do. It cannot tell you whether the jump in your game feels good, because feeling good is not a property of the code. It is a property of the experience of a person holding the controls, and the model is not holding the controls.

This is the load-bearing limitation and it does not go away with a better model. Ask any AI system whether your combat is satisfying and you will get a fluent, plausible, entirely invented answer. It will describe the combat you described to it. It has no access to the thing you actually want to know.

Which means the taste in the project has to come from you, and it has to come from playing. Not from reading the code, not from watching a video of it, not from reasoning about whether the design sounds good. From playing it, repeatedly, and noticing what you feel.

People underrate how much this is a skill in itself. Noticing that you are bored is easy. Noticing exactly when you became bored, and what you were doing in the four seconds before, is the actual work, and it is the work that produces a specific instruction instead of a vague dissatisfaction.

The instinct when a generated game is disappointing is to reach for a bigger, smarter model. It almost never helps, because the missing input is not intelligence about games in general. It is information about your game specifically, and the only source of that is you playing it.

The second structural mistake is scope in the first request. Inventory, crafting, day and night, three enemy types, a quest system, save and load, a menu.

You will get all of it, at the shallowest possible depth, because the effort got divided by nine. And now you have a large thing where every part is mediocre, and no part is finished enough to tell you whether it is worth having. Worse, changing anything means considering eight other systems that touch it.

The pattern that works is the opposite and it feels absurdly small. Build one verb. Make it good. The whole first session should produce a character who moves and one thing they do, and then you should spend far longer than feels reasonable making that one thing feel right.

Concretely: is there a wind-up before the swing, and how long? Does the character stop moving when they swing? Does the screen shake, and by how much, and for how many frames? Is there a hit pause? Does the enemy get knocked back, and does the player? What happens when you press the button again halfway through?

Those are eight questions about one action and each has a wrong answer you can feel immediately. Answering them is what turns a mechanic into a game. And you cannot even ask them if you built nine systems on day one, because there is not enough of any one of them to have an opinion about.

The third reason first attempts are dull is that they contain no friction. Enemies that do not threaten. Resources that are never scarce. Choices where every option is fine. Failure that costs nothing.

This happens by default because a plain description does not specify tension. You said there were enemies. You did not say the player should be afraid of them, and afraid is a design outcome that comes from specific numbers: how much damage, how fast they close the distance, how many at once, how long healing takes, what dying costs.

A useful diagnostic: at any given moment in your game, can the player lose something? If not, nothing they do matters, and no amount of content will make it matter. Games without any risk of loss are not automatically bad, but they need a different engine driving them, usually curiosity or expression, and that has to be built deliberately too.

Test it directly. Play for two minutes deliberately badly. Stand still, ignore the enemies, spend nothing, take the worst option every time. If you are more or less fine, you have found the problem, and it is a much more actionable problem than "the game is boring".

Then there is the way it looks, which is usually a set of things that do not belong to each other: a semi-realistic character, a cartoon enemy, a photographic ground texture, default engine UI in a font nobody chose.

Each piece was produced by a separate request, and nothing carried a style decision between them. The result reads as cheap even when every individual asset is competent, because coherence is a property of the set and the set was never considered.

The fix is cheaper than it looks and does not require you to make art. Pick a small palette, five or six colours, and force everything into it. Pick one font and use it everywhere. Pick one light direction. Delete the assets that do not fit rather than trying to reconcile them.

A game made entirely of flat coloured shapes in an agreed palette looks intentional. A game made of mismatched high-quality assets looks like a folder. Intentional beats expensive every single time, and intentional is a decision rather than a budget.

First, play it for ten minutes with a notepad, and write down the timestamp every time you feel anything: bored, confused, frustrated, briefly pleased. Do not fix anything while you are playing. You are collecting evidence, and stopping to fix things destroys the run.

Second, look at the list and find the earliest bad moment. Not the worst one, the earliest. Everything after it is contaminated, because you were already disengaged. Fix that one thing.

Third, express the fix as a specific change rather than a quality complaint. "Combat is boring" is not actionable by you or anyone else. "The enemy takes four hits and should take two, and it should flash white and stop moving for a moment when hit" is a change you can make and immediately evaluate.

Fourth, play again. The whole ten minutes, from the start. This is the step everyone skips and it is the one that compounds, because most changes fix the thing you aimed at and break something adjacent, and you will not find that by testing the change in isolation.

Fifth, after about the third round, cut something. There is always a system in there that is not earning its place, and removing it will make the game noticeably better in a way that adding never does. Ico is the usual example of design by subtraction, and the principle survives at any scale: the thing you remove stops competing for attention with the thing you actually care about.

Sixth, and only when the loop is genuinely enjoyable for two minutes, add content. Not before. Content built on a loop that does not work just produces more of a thing nobody wants to do.

The single most valuable thing you can do costs half an hour: sit someone down, hand them the controls, and say nothing at all.

Saying nothing is the hard part. You will want to explain the controls, mention that the art is placeholder, warn them the second level is unfinished. Every one of those sentences destroys the data you came for, because the player who ships with your game does not come with you attached.

Watch their hands and their face rather than listening to their words. People are polite and will tell you it is nice. They will also, without noticing, press the wrong button four times, miss the exit, walk straight past the thing you spent two days on, and go quiet at the exact moment the game loses them. That silence is the most useful information you will get all month.

Take what they do seriously and what they suggest lightly. Players are excellent at identifying where something is wrong and unreliable at prescribing the fix, because the fix requires knowing what the game is for, and only you know that.

What has actually changed is the cost of trying something. An idea that used to take a week to test now takes an hour, and that is a real change in kind, not just in speed. It means you can afford to be wrong far more often, and being wrong quickly and often is how design has always worked. Most professional design is the process of discarding, and the constraint was always that discarding was expensive.

What has not changed at all is the part where somebody plays the thing and decides whether it is any good. That was always the whole job. It was never the typing.

So your first game being bad is not a signal that the approach does not work, and it is not a signal about your ability. It is the completely normal first iteration that every game has ever had, arriving faster than it used to. The people whose first prototypes were also bad simply took three weeks to find out instead of an afternoon.

The failure that actually matters is a different one: describing a game, receiving something mediocre, and concluding the tool is not ready, rather than that this is iteration one of thirty. The ones who end up with something good are the ones who play the boring version, write down where it lost them, change one thing, and play it again. That has never been automatable, and it is not the part worth automating.