Ask Claude Fable for a game and you get a game. Not a mockup, not pseudocode. A single HTML file with the JavaScript sitting inside it, which you save, double click, and play in a browser. Models from Anthropic and elsewhere crossed this line fairly quietly, and a lot of people still file it under party trick. It is not one. The mechanics run, the input handling works, the score goes up when it should. So the interesting question has moved on. Not whether a model can produce a game, but whether the game is any good, which is much harder to answer than it sounds.
So let me propose one measure and use it for the rest of the piece. Call it the second-session test. A game passes if someone who has already finished a round opens it again the next day, unprompted, because they want to. Everything else the industry counts, session length, completion rate, star ratings, is downstream of that single behaviour. The test is brutal because polish cannot fake it.
Blackjack is the cleanest illustration I know of. The rules fit on an index card and have not meaningfully changed in generations. Hit, stand, split, double, dealer draws to a fixed number. Shuffle, a crypto casino and online gaming platform where deposits and withdrawals settle on-chain in coins and stablecoins, keeps its blackjack online category page as a plain listing of these tables, and what strikes you is how little the game varies from one table to the next. There is no mechanical secret in there. Nothing a competent developer could not rebuild in an afternoon.
And yet people sit at blackjack tables for hours, and come back. Basic strategy is public. It is printed on laminated cards, and if you follow it the house edge sits at roughly half a per cent. Knowing the mathematically correct move does not remove the tension of making it, because the decision still belongs to you and the next card still does not. That is the whole engine. Blackjack proves that mechanical simplicity is not the constraint on whether a game earns a second session. The rules are trivially copyable. The reason anyone returns lives somewhere else entirely, and that is exactly the place where generated games run into trouble.
What the models are genuinely good at
The rules layer. A model will write you a clean state machine, a win condition, a scoring loop, collision handling and a restart button, and it will do it in about a minute. The rules layer used to eat a weekend for anyone building a small browser game on the side. It now costs a prompt and a re-prompt. Correctness here is high, and where it fails it fails visibly, which makes it cheap to fix.
Where the seams actually show
Feel. Pacing. The difficulty curve. Whether the enemies arrive at a rhythm that feels intentional or just arrive. Whether the jump lands a frame early or a frame late, which sounds like nothing and is the difference between a control that feels tight and one that feels like porridge. None of this is expressible as a rule, which is why a system built on rules cannot reason its way to it. The model has no way to know if the thing it just wrote is fun, because fun is not a property of the code. It is a property of what happens in a player's hands.
The first thirty seconds do most of the work
Players decide fast. Half a minute in, most people have already formed a verdict they will not revise. A generated game usually clears that bar, because a working loop and a rising number are enough to hold attention briefly. What it rarely does is give you a reason to want the next thirty seconds.
Running the second-session test on generated games
So apply it. Take ten small games produced from prompts, hand them to people who did not write them, and check who reopens one tomorrow. My honest expectation is that almost none pass the second-session test, and not because they are broken. They pass every functional check. They fail because nothing in the generation process is aiming at return behaviour. Nobody tuned the difficulty against a real player, nobody cut the dead ten seconds at the start, nobody noticed that the reward arrives just slightly too late to feel earned. Those are the blackjack qualities, the tension of a decision, and they are precisely what does not come out of a prompt.
We learned this once already
Procedural generation has been in games for decades, and it taught the same lesson. You can generate an effectively infinite amount of valid content. Valid is not the same as wanted. Players ran out of interest long before the generator ran out of caves. Generating something correct and generating something anyone cares about are separate problems, and only one of them has been solved.
The right comparison is other AI tools, not other games
AI photo culling tools do not decide which photo is beautiful. They throw out the blinks and the misfocused frames and hand a photographer a shortlist, and the taste call stays human. Game generation currently has the same shape. The model clears the mechanical work at speed, and someone with judgment still has to sit with the result and ask what is missing.
Nobody has actually measured this
Worth being blunt. There is no published benchmark, review or study measuring the quality of the games produced by any specific Claude model, and I am not aware of one for any competing model either. Anyone quoting you a score is inventing it. What exists is a real capability and an unfilled evaluation gap. Pretending otherwise would be worse than admitting it.
So are they good?
Good at rules, weak at feel. That is the honest answer. If you want a working prototype by lunchtime, this is the best tool that has ever existed for it. If you want something that passes the second-session test, you still have to earn that yourself, one difficulty tweak at a time.
One footnote, since blackjack carried the argument. Casino games run on RNG and the house edge is built into the rules, so no strategy or system removes it. Treat it as entertainment, 18+ only.
