Claude Opus 5.5 games: how to vibe-code one, with the real prompts behind 4 builds

You can build a browser game with Claude Opus 5.5 from a single prompt in the regular Claude chat, and the result is often fun to play. The prompt that works is short: ask for a mobile-friendly three.js game, describe the core idea in one sentence, and if the result is dull, send "Make it a LOT more fun". Once the game outgrows a proof of concept, move it into Claude Code and iterate there.

That's the method Simon Willison used for four games he published in October 2026, and it's the reason he called October 2026 the inflection point for vibe game development. All four games are playable, and he published the prompts and most of the transcripts.

This post is the how-to version of those builds: the five steps they have in common, every prompt copied word for word from his posts, how long each build took, and what still goes wrong. If you want a gallery of Opus 5.5 visual work instead, our Claude Opus 5.5 motion graphics collection has 3D, physics and game clips from X with the creators' own prompts.

Can Claude Opus 5.5 really build a game that's fun?

Yes, according to the clearest public test so far. Models could already produce something that looked like a game. Willison's own Battle Drones write-up says his earlier versions "wasn't any fun to play" and that he believed coding agents "can build a thing that looks like a game but can't actually make something that's genuinely compelling to play".

That changed when he upgraded the project to Opus 5.5 and asked for more fun. In his October 28 post he lists three areas where Opus 5.5 improved for game work:

• 3D modeling. Every unit and building in Battle Drones is a three.js model written in TypeScript code, no image files. You can browse them on the Battle Drones model page.
• Music. The Battle Drones soundtrack is generated in code, changes per map and gets more intense as fighting starts.
• Game design, the part he didn't expect. After "Make it a LOT more fun", Claude ran over a thousand simulated playtest sessions and rebalanced units based on the results.

Key takeaway: older models could already write game code. What changed with Opus 5.5 is that a vague instruction about fun now produces real changes to pacing, balance and comeback mechanics.

One caveat: this is one experienced developer's hands-on view, not a benchmark. Willison says so himself ("I haven't done an exhaustive study"), and his comparison with GPT-6 Astra is labeled as an impression. We cover that below.

The 4 real builds at a glance

All four games are HTML and JavaScript, run entirely in the browser and are hosted as static pages. Effort runs from one prompt to nearly two days of agent time.

Willison says none of the four took more than four hours of his own time, plus many more hours of Claude Code running on its own.

How do you vibe-code a game with Claude Opus 5.5? The 5-step loop

These steps are what the four builds have in common. The prompts are his; the order is ours.

Step 1: Start in chat with a one-line game idea and three.js

You don't need Claude Code to start. Tree Appreciator and Emberwick were both built in the normal claude.ai chat. Willison's suggested opener:

Build a mobile-friendly three.js game where...

Naming three.js matters. He writes that "telling models to use three.js works really well": Claude has no image model of its own, but it builds full-color 3D scenes in code. For 2D, Claude chose the Phaser framework on its own for the early Battle Drones versions.

Here is the full Tree Appreciator prompt. It produced the finished game in one shot:

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.

Notice what it contains: a name, one mechanic in one sentence, and a quality bar ("both fun and beautiful"). No feature list, no art direction.

Step 2: Grow it in small, concrete rounds

Emberwick started as an engine demo, not a game. The opening prompt, sent as two messages:

Build a demo game engine three.js which is a top down (but at an angle) RPG - the player gets to move through the world with one or two companions. Create a fantasy village setting that demonstrates walking around outside and then shows how when the player enters a building the wall between the player and the camera goes transparent so the user can see what is happening

Add some NPCs and plenty of furniture and different types of building some with an upstairs - be creative, make it look great

That gave a working first version. The next round was three short, specific asks:

Make it not so flat - the buildings are great but the landscape itself is completely flat at the moment, fix that

Add basements to two of the buildings with a tunnel system joining them below the village

Add the start of a rocky mountain on one side of the village containing a cave with a sleeping troll

Each one names a single visible change. That keeps every round easy to check on screen before you ask for the next one.

Step 3: Ask for the game, then ask for more fun

Once the world worked, Willison asked for the actual game:

Now turn this into an actual game - quadruple the size of the playable area, introduce fun game mechanics, add a plot that isn't too cliche, some twists, a magic system, make it really good

The result has a plot, quests and an experimental level editor. He says his creative input was roughly "it's a fantasy village and there's a troll asleep in a cave".

The fun prompt came from Battle Drones. At v3 the game looked good but bored him. He sent this from his phone:

This game isn't fun enough yet. Make it a LOT more fun.

It ran in Ultracode mode, where Claude Code runs a workflow that orchestrates many subagents. Started in the evening, it returned a playable v4 late the next morning, with opening choices, call-down powers, comeback mechanics, two new modes and progression. Claude's own release notes report that in 1,200 AI-vs-AI test matches, games still undecided after 25 minutes fell from 14% to 0.9%. You can play v4 to judge it yourself.

For Quarter Sun Cove he used a softer version of the same idea:

surprise and delight the user frequently

That line produced raccoons, an elephant seal running the weigh-off and superstitions that sometimes come true.

Step 4: Move to Claude Code, and make it design before it builds

Willison's rule: "Switch to Codex or Claude Code once your project passes the proof-of-concept phase." A chat transcript gets unwieldy once a game has many files, versions and playtest fixes. Claude Code keeps the project in a repo with commits you can roll back.

Two patterns from the bigger builds are worth copying. Battle Drones started with Claude asking questions instead of coding (this was Claude Fable 5, in July):

We are going to build a mobile friendly RTS game - command and conquer style - called Battle Drones, in which two armies of drones (both flying and ground-based) battle for territory and resources

Let's start with a MVP design, ask me some questions

And for a new map in v8, he asked Claude to critique the design before writing any code. The full prompt, unedited:

Design a new map. Goal is to make different strategic incentives that encourage use of Infantry and Condors and aerial vehicles.

To do this the map will have limited harvester resources but several more uplinks - but uplinks will be on islands that are inaccessible by land vehicles or infantry. These uplinks can also not be claimed using air vehicles. The ONLY way to get them is to fly infantry there in a Condor.

Armies always start with a Condor and a single squad. If an army has no Condor a new one will be provided for free, flying in from the edge closest to their HQ and landing there. That free condor will come with a single free squad on board.

The two HQs should be entirely separated by water, but still accessible by vehicles thanks to two bridges across the map in different places

I want to encourage a battle over uplinks.

The map should be the times the size of other maps - still square

First research and then critique this design. Only build after we have agreed on any modifications

You get to design a new biome for this

"First research and then critique this design. Only build after we have agreed" is the line to reuse. It turns a long build into a short design review first, which is cheaper to change. Quarter Sun Cove followed the same idea: a brainstorm session in Claude Code produced a spec file, and only then did Opus 5.5 start building.

Step 5: Playtest, then fix what breaks

Tree Appreciator needed no follow-up. Emberwick needed "quite a bit" of playtesting, mostly story logic: a character wasn't where a quest needed them because another story event had moved them. Expect that class of bug in anything with state that spans the whole game.

Battle Drones hit a subtler one. Replays went out of sync because Chrome and Safari return slightly different results for Math.sin() and Math.cos(), so Claude replaced them with custom deterministic versions. If you plan replays or multiplayer, ask for a deterministic simulation early.

The 3D step: from 2D sprites to three.js models

The most visible jump in Battle Drones came from one prompt:

Port this game to three.js with 3D models for all of the buildings and vehicles and landscapes

It was another overnight run, and the v5 result replaced the generated sprites with 3D models built in code. Before that, at v3, he had Claude generate art through an image API:

Massively improve this game. Make the graphics and gameplay better (keep it mobile friendly). Render new graphics using the latest OpenAI GPT image API (lookup details) with the API key in the environment variable. Add new unit types and balance the gameplay better. Also add new buildings and better, more varied terrain.

Battle Drones is Apache 2.0 licensed, and that made a remix possible within a day: Gabriel Turpin released Panache, a French Belle Époque version with new 3D models, music and an animated intro, the day after Willison published his write-up.

Is Claude Opus 5.5 better than GPT-6 for games?

On Willison's evidence so far, Opus 5.5 has the better sense of fun, but he calls it an impression, not a study. His words: GPT-6 Astra "can absolutely build a game, but its sense of fun doesn't match that of Opus 5.5", and he expects OpenAI to catch up by the end of the year.

You can check two side-by-side tests yourself:

• One prompt on two models: "Build a mobile-friendly three.js game where a mouse has to hide from a cat", built by Claude Opus 5.5 Extra and by GPT-6 Extra High.
• A full RPG from the same prompt sequence: the Emberwick prompts run through GPT-6 Pro became Lantern Hollow. He says it looks great but doesn't play nearly as well.

He also notes GPT-6 Astra is strong at 3D modeling, so the gap he describes is about game design, not graphics. If you're choosing a model for a team rather than a weekend game, our Claude Opus 5.5 model page has the specs and pricing.

What still goes wrong

Where it works

• Small, self-contained browser games with one clear mechanic
• Projects where a bug costs nothing (Willison's point: games are "super low stakes")
• Static hosting: GitHub Pages or Cloudflare Pages, no backend
• People with no game-dev background; he describes himself as knowing "almost nothing about game development"

Where it doesn't (yet)

• Long stories: quest logic breaks when one event moves a character another quest depends on
• Network features: his audio-based multiplayer gave his wife a headache; the game later got online multiplayer through a WebSockets relay
• Clear mechanics on the first try: he says Quarter Sun Cove's planting-for-weekend-crowds loop is "actually quite complicated" and not yet convincing
• Public reception: players are pushing back on AI-made games, as in IGN's report on Steam Next Fest. Willison says he won't enter his games in game jams

Watch out: "no looking at the code" is fine for a personal game. It is not fine for anything that handles user data, payments or accounts. The moment a vibe-coded game needs logins or a leaderboard, review the server side like any other production code.

More Opus 5.5 game builds worth studying

If you want more examples, these two from our motion graphics collection are game builds with source links:

• Jurly's No Man's Sky-inspired browser prototype, built with Opus 5.5 and three.js. The creator says it took one prompt and about 40 minutes, including flight from a planet's surface into space with no loading screens.
• KanaWorks_AI's pixel-art rabbit archer, made in a single HTML file with Canvas 2D and an eight-state animation machine. That card includes the creator's full prompt, which is a good template for sprite-style characters.

Why this matters past games

The loop above (one-line idea, small concrete rounds, "make it better" asks, design review before big changes, playtest) is the same loop that works for internal tools and product prototypes. Games just make it obvious, because you can feel whether the result is good within a minute of playing.

Teams that want to use it on real work usually hit the same walls: when to move from chat to Claude Code, how to set up a repo so the agent can run for hours safely, and how to review what it built. That's what our Claude Code training for teams covers. If you'd rather hand over the prototype itself, see how we run an AI product build from idea to working app. To set up Claude Code on your own machine first, start with how to set up Claude Code.

FAQ

Can Claude Opus 5.5 make a full game from one prompt?

Yes, for small games. Simon Willison's Tree Appreciator came out of a single prompt in the regular Claude chat with no follow-up. Bigger games like his Emberwick RPG took a prototype, several expansion prompts and playtest fixes.

Do I need Claude Code to build a game with Claude?

No, you can start in the normal claude.ai chat. Willison built two of his four games there. Move to Claude Code once the game passes the proof-of-concept stage, so the project lives in a repo with commits you can roll back.

What prompt should I use to start a game with Claude?

Start with "Build a mobile-friendly three.js game where..." and describe the core mechanic in one sentence. If the result plays flat, send "Make it a LOT more fun". Both prompts come from Willison's published builds.

Why use three.js for a Claude-built game?

Claude has no image model of its own, but it can build full 3D scenes and models in three.js code. Willison found that asking for three.js "works really well", and every unit in his Battle Drones game is a 3D model written in code.

How long does it take to vibe-code a game with Opus 5.5?

From minutes to days of agent time. Willison says none of his four games took more than four hours of his own work, but Battle Drones went through 12 major versions and Quarter Sun Cove used nearly two days of Opus 5.5 running on its own.

Is Claude Opus 5.5 better than GPT-6 at making games?

In Willison's hands-on view, yes for now: he says GPT-6 Astra can build a game but its sense of fun doesn't match Opus 5.5. That's his impression, not a benchmark, and he expects OpenAI to close the gap by the end of 2026.

Can my team use the same approach for product prototypes?

Yes, the loop of short concrete prompts, design review before big changes and hands-on testing works for internal tools and MVPs too. Our Claude Code training teaches teams to run it safely on real codebases.

---

Sources: Simon Willison, The October inflection point for vibe game development (Oct 28, 2026), Simon Willison, Battle Drones: a vibe coded RTS with audio-based multiplayer (Oct 20, 2026), Simon Willison on Panache (Oct 21, 2026), Battle Drones source code, Panache source code, IGN on AI games at Steam Next Fest