Claude Opus 5.5 crosses the inflection point for vibe coding games

From "looks like a game" to "is fun"

Simon Willison, creator of Datasette and one of the most widely read chroniclers of the coding-agent scene, published on October 28, 2026 an account that he himself calls an inflection point: for the first time, he says, language models have started producing games that are genuinely fun to play, not just visually convincing.

Willison had used that label before, in November 2025, when Opus 4.5 and GPT-5.1 made coding agents reliable enough to become a daily tool for programmers. This time he applies the same term to an area that's much harder to automate: game design, the art of building a gameplay loop that challenges the player at the right pace.

I think we've reached a new inflection point in October 2026, and this time it's for vibe coding computer games.

Simon Willison, developer and author of the personal blog simonwillison.net

He's clear about what changed: creating something that looks like a game (graphics, a menu, a basic mechanic) had already been possible for a while, in the author's own earlier experiments. The problem was arriving at a game that made you want to keep playing. Willison says he didn't expect Claude Opus 5.5 to solve that, until he asked it to "make this a lot more fun" and the result actually improved.

Four games, four levels of effort

Willison lists four projects built over the past few weeks, all in HTML and JavaScript running directly in the browser, with nothing to install. He ranks them by the effort invested, which never exceeded four hours of his own work (not counting the time the model spent processing on its own):

• Tree Appreciator: a "spot the differences" game between two procedurally generated trees, made in a single response from Claude's regular chat (no need for Claude Code), using three.js;
• Emberwick: a top-down RPG with a medieval village, NPCs, dungeons, and a sleeping troll in a cave, which grew prompt by prompt into a 15-minute campaign with a magic system and plot twists;
• Battle Drones: a multiplayer RTS in the style of Command & Conquer, with robot armies fighting over territory;
• Quarter Sun Cove (also called Pumpkin Farmer): a farming simulator about growing giant pumpkins, inspired by the annual festival in Willison's own town, Half Moon Bay.

The common thread between them is the kind of prompt used. For Tree Appreciator, Willison only wrote Build a three js game called "Tree appreciator" - it shows you two algorithmically generated trees and the game mechanics is about appreciating the differences between them. Think hard about how to make sure it is both fun and beautiful and got the finished game, including a "herbarium" of collected trees, on the first try.

Battle Drones: from clunky prototype to open-source RTS

The most developed project is Battle Drones, which Willison had already written about in another post. The first versions were made in July 2026 with Claude Fable 5 and resulted in a playable but unexciting 2D Command & Conquer. The turning point came when he started using Opus 5.5 and gave the same short instruction: Make it a LOT more fun, followed by Port this game to three.js to move the game to 3D.

Today Battle Drones has multiplayer for 2 to 4 players via a WebSockets relay that was also vibe coded, medals, replays, seven maps, a random map generator, and rule variants called "mutators." There's even a mode where different models play against each other: the game advances five seconds, pauses, and each model interprets the new state before deciding its next command.

Willison released the Battle Drones code under the Apache 2.0 license the week before the post. Days later, developer Gabriel Turpin released a fork called Panache, reimagining the same game in a French Belle Époque steampunk setting, with its own 3D models, music, and animated intro. It's the kind of reuse that only makes sense when the cost of generating art, music, and code drops to nearly zero.

Opus 5.5 understands fun, GPT-6 Astra doesn't yet

Willison didn't run a controlled study, but he notes a perceptible difference between models. He ran the same sequence of Emberwick prompts on GPT-6 Pro and describes the result as visually attractive but much less fun to play than the version made with Opus 5.5. His assessment is that OpenAI's GPT-6 Astra "can build a game" but doesn't yet have the same sense of what makes a game work, something he expects to change by the end of 2026.

This matters because it's a different kind of gap than what traditional code benchmarks measure. It's not about generating syntactically correct three.js: both models can do that. It's about design judgment, a layer that until now seemed to require human intuition and that, according to the account, only one of the tested models demonstrates having.

What changes for prototypers: stack and workflow

For anyone who wants to reproduce the experiment, the recipe Willison describes is straightforward and worth noting as a roadmap, not a guarantee:

1. Start with the regular chat (ChatGPT or Claude.ai), without opening a full coding agent, with a prompt like Build a mobile-friendly three.js game where...;
2. Use libraries the models already know well, such as three.js for 3D and Phaser for 2D;
3. Host the result as a static site, on GitHub Pages or Cloudflare Pages, since it's plain HTML and JavaScript;
4. Once the prototype moves past the proof-of-concept stage, migrate to a full agent like Codex or Claude Code to iterate in more depth;
5. If the game is still dull, literally ask it to Make it a LOT more fun.

None of the four games was made in one shot, except Tree Appreciator. Emberwick, in particular, required a lot of playtesting and fixing of gameplay bugs, like a character not being in the right place to complete a mission because another story event had already moved them away from there. That's the opposite of "vibe coding without looking at the code": it's iteration guided by repeatedly playing the game itself.

The limits: AI assets and the gaming community's reaction

Willison directly acknowledges that these games bring together everything part of the gaming community already rejects: AI-generated art, AI-generated music, AI-generated text, and AI-generated code, all at once. He cites as an example an IGN report on complaints about "slop" (AI-generated junk) in Steam Next Fest games, run by Valve, as a sign that this reaction is already real and growing even before the wave of vibe-coded full games.

His position is pragmatic: he says he respects those who reject this kind of content, but doesn't share the rejection. He's also honest about the moral limits he imposes on himself in the hobby: he doesn't intend to enter any of these games in game jams or traditional competitions, feeling he wouldn't have "earned the right" to compete there. He expects new categories to emerge, specific to games built this way.

Now imagine what could be achieved by anyone who takes this seriously, invests significant creative time, applies better taste in game design, and then playtests and iterates on the result until it's as good as they can make it.

Simon Willison, developer and author of the personal blog simonwillison.net

When it's not worth it

The account itself gives hints of where the method stumbles. More ambitious projects, like Emberwick, don't come out finished on the first try: they require real playtesting cycles, not just magic prompts. Willison's creative input into each game was minimal, almost always a single sentence, which is great for rapid prototyping but is exactly the opposite of what's expected from a project with a strong authorial identity.

There's also a concrete technical risk: Willison reports that an attempt at audio-based multiplayer gave his wife, Natalie, a real headache, a reminder that "low risk" isn't the same as "no risk at all" when the result runs in someone's browser. For anyone in Brazil who wants to try the same path, the advantage is clear: low barrier to entry, a familiar stack (three.js, Phaser, static hosting), and no dependency on a heavy engine. The downside is that, as with all vibe coding, the responsibility for testing before publishing remains human.