Claude Opus 5.5 can take a game from an empty folder to a live portal in 9 days
It writes the code, draws the art, records its own trailer and passes the portal's QA
In this article, I show you how, step by step https://x.com/i/article/2112472576832258048
How to Build and Ship Your Own Browser Game with Claude Opus 5.5 (Full Course)
From an empty folder to a game strangers play on CrazyGames: one rule, a one-page doc, short Opus passes, a build that saves through the portal's SDK, and the numbers that tell you what to fix next.
Most people who try to make a game with AI type "make me a game", get a demo that looks fine for ten seconds, and quit. They don't know which rule to start from. They don't know how to brief the model so it finishes. And nobody tells them what happens after it runs on localhost.
I built Skyhold this way. Houses arrive under balloons, you drop each one onto a floating island, and every house tips it. Opus 5.5 wrote every line: 22 passes, about $164. Nine days after an empty folder it passed CrazyGames' SDK check 7 of 7 on the first try and went live in front of their players.
This course is the whole route, at a scale you can finish in a few evenings.
01. The rule - one idea a stranger gets in 2 seconds
Every game that works on a portal can be explained before the first tap. Mine is: the island has a centre of mass.
That one sentence decides everything downstream. Houses have weight. Weight tips the island. Past 15° the edge starts to slide into the clouds. Lose five homes and the island flips. You never have to explain a menu, because the rule is the tutorial.
Before you open Claude Code, write your rule in one line. If you need "and" twice, it's two games.
02. The doc - one page before any code
Don't ask Opus for a game. Give it a game doc: the rule, the loop, how you win, how you lose, the camera, the controls on desktop and phone, and what "done for today" means.
Prompt 1. The day-one brief
My first pass took 46 minutes and came back with a playable island. Ugly in places, but playable, and that's the only goal of day one.
03. The passes - one system per Opus run
The biggest mistake is one giant prompt for the whole game. Run each feature as its own pass and give each pass one finish line.
Every brief has the same five parts:
- Read these files first (and skip the big library files).
- Do exactly this one thing.
- Keep these things working exactly as they are.
- Done means [something I can check by playing].
- Do not open a browser. No runtime errors.
The "keep" line is the one people skip. Without it, every pass quietly rewrites something you already accepted. The JSON output gives you the real cost of each run, so you always know what a feature cost you. My most expensive pass was $12.94 (the arcade loop). The cheapest was $1.01.
04. The stack - no engine, no image files
three.js for the world. Everything else drawn in code: low-poly houses, balloons, clouds, the UI, even the two mascots. One pass gave the game Moss and Puff for $5.14 in 14 minutes, as SVG in a single module.
No image files means no asset pipeline, no licences to check, and a build that ends up tiny. Mine is 1.5 MB in total.
05. The trailer - let the game record itself
Add a ?capture mode: a fixed-size canvas, a deterministic window.render(t), and a scripted demo that plays the real game. Then record it frame by frame with a headless browser.
Every video I've posted about the game came from the game's own engine. No screen recorder, no editor. When the game changes, you re-record the trailer in minutes, and it always matches what players will see.
06. The funnel - measure the first minute before you add features
Four days in I had a game with five story islands, a daily island and a leaderboard. Then I looked at the numbers: 51 visitors, 13 opened the game, 6 started a run, 0 finished one.
Nobody needed a fifth island. They needed the first minute to work.
Prompt 2. Fix the funnel
After that pass the first island became "keep 6 homes standing", which takes most people under 30 seconds to win. 62 islands got saved in the next four days.
07. The host - cheap, and boring on purpose
A browser game is static files plus a few small endpoints. Mine runs as one Node process on Lizard: 20 MB of RAM, 0.03% of one CPU, about 19 cents a month. Put it on your own domain from day one so every post links to the same address.
08. The portal build - one adapter, one zip per portal
Portals each want their own SDK: loading start and stop, gameplay start and stop, ads between runs, and mute. Put all of them behind one small adapter, so the game calls platform.gameplayStart() and never knows which portal it's on.
Then a build script makes one folder and one zip per portal, with index.html in the root, relative paths, and no calls to your own server.
Prompt 3. Portal mode
09. The QA gate - what CrazyGames actually checks
CrazyGames runs your build in a test page and lights up each SDK call it sees. Basic Launch needs:
- Initial download under 50 MB
- First gameplay start (play a round in their test window, or it stays red)
- No external ads and no external login
- Runs on all their domains, on desktop and on phones
- Progress saved through their SDK Data Module, not plain localStorage
That last one is the only thing I had to add. One pass, $1.01: read every save from the SDK on boot, then mirror every later write into it. Upload the unzipped files, not the zip.
10. The launch - four portals, four different tests
- itch.io: live in 10 minutes, no review. Embed at 960×720 and turn on "mobile friendly".
- Newgrounds: live at once, then 3 days of player votes. Good scores keep it, bad ones get it removed.
- CrazyGames: SDK QA, then a Basic Launch in their "New" carousel for a few weeks. Good numbers unlock the full launch and ad revenue.
- Poki: an application with a playable link first. They invite you to upload only if they like it.
Every portal wants a 16:9 cover, often portrait and square too, and a 15–20 second gameplay clip. That's where the ?capture mode pays for itself.
11. The numbers - what decides if it lives
Once you're live, the build cost stops mattering. Four numbers decide what happens next: how many people see the cover, how many click it, how long they play, and whether they come back the next day.
My first CrazyGames day: 141 impressions, 1.4% clicked, about 3 minutes of play, 0 crashes, 2.3 s to load. The click rate was in the bottom 20%, so the first fix was the cover, not the game: bigger mascots, an island that's clearly tipping.
Fix the number that's worst, one pass at a time.
The split
- Opus 5.5: every line of code, the art, the mascots, the music.
- three.js: the 3D world.
- A headless browser: the trailers.
- The portals: the players and the honest feedback.
- Me: playtest, read the numbers, say what feels off.
Six mistakes that waste a weekend
1. One prompt for the whole game. You get a demo that falls apart on the second feature.
1. No "keep" list. Every pass quietly breaks something you already liked.
1. Building the fifth island before the first minute works.
1. A sign-in screen before the first round ends. In my numbers it turned 9 players into 0 sign-ins.
1. Saving to localStorage on a portal that requires its SDK. That's an instant QA fail.
1. Judging the game by its cost. $164 is nothing. The retention number is the whole story.
The rule that saved the project: fix the first minute before you build the fifth island.
Play the result: skyhold.lol
Follow me @0xbobaaa