How to Build a Real Browser Game with Claude Opus 5.5 (Full Guide)

You do not need a game engine, an art budget, or years of experience to ship a real browser game anymore. With Claude Opus 5.5 and a few free tools, one person can take an empty folder to a polished, playable game in an afternoon — and we built one to prove it: Orbit Switch, a one-button arcade game where you flip which of two stars pulls your comet. You can play it here.

This is the complete, honest pipeline. It works whether you are a developer or just curious, because the hard parts are not the code — they are the decisions. We will cover the one idea that makes this possible, how to pick a game, the exact prompt to copy and paste, how to film a trailer from the game itself, how to make it addictive, how to add a leaderboard, how to ship it to phones, and — the part most guides skip — how people actually make money from it.

The one idea that makes this work

Here is the thing to understand before anything else: Opus 5.5 does not draw a game — it writes the code for one, and a browser runs that code. The model takes text and images in and puts text out, so every "AI game" is really a program it wrote. For a 2D game that is a single HTML file with a drawing canvas; for 3D it is three.js loaded locally so the game works offline.

That is good news for you in two ways. First, the output is code you can read, change, and own — a tweak is an edit and a reload, not a re-roll of a black box. Second, Opus 5.5 can look at images, which means it can inspect the frames it rendered and fix what looks wrong (more on that below). Anthropic's own launch noted that when several models each built a game from a single prompt, Opus 5.5 scored highest on graphics and polish — making a clean, playable program is a real strength of it.

The one technical habit that ties everything together is determinism: the game is written so the same inputs always produce the same result. That single choice is what lets you film a perfect trailer, verify scores on a server, and keep the difficulty identical on every device. We will ask for it in the prompt.

Step 1: Pick a game you can explain in one rule

The hardest part is not building — it is choosing something a stranger understands in the two muted seconds they will give a video. So start from a single rule and hang everything else off it. Orbit Switch's rule is literally tap to flip which of two stars pulls your comet. Thread the gates, grab the stardust — the whole game is that one sentence.

Good one-rule ideas for a first build: a stack that tips when it gets uneven, a city that floods when you build too low, a ship that sinks if you load one side, a garden that dies without shade. The test is social: say the rule to a friend in one sentence. If they get it instantly, you have a game. If they ask "and then what?", tighten the rule before writing a line of code.

Step 2: Set up the stack (ten minutes)

You need four free things, and nothing else — no engine, no asset store, no build step:

• Claude Code running Opus 5.5 — an agent with a terminal, so it can write files, run them, and look at the frames.
• A renderer — plain HTML + canvas for 2D (what Orbit Switch uses), or three.js copied locally for 3D.
• A headless browser — Playwright + Chromium, so the agent and the trailer pipeline can screenshot frames.
• ffmpeg — to turn frames into video.

mkdir my-game && cd my-game && npm init -y
npm i -D playwright && npx playwright install chromium
# ffmpeg: brew install ffmpeg (macOS) | apt install ffmpeg (Linux)
claude --model claude-opus-5-5
# set effort: medium for small fixes, xhigh for a new game, max for a flagship piece

Step 3: The prompt — copy, paste, fill in the blanks

The single biggest lever on your first build is a long, structured prompt. Treat it like a short design document, not a wish. Here is the full prompt to copy — replace the bracketed parts with your game:

Build a small but genuinely polished browser game in this folder, entry point index.html.
Working title: [NAME]. One rule: [YOUR ONE SENTENCE].

LOOK
- A real indie game, not a tech demo. Clean and confident, one accent color.
- Every frame should look like a screenshot from a released game. No corner labels,
  no everything-fades-in, no generic particle spam.

TECH
- Plain HTML and a single canvas (or three.js from a local file for 3D). No external assets;
  draw everything in code. Must run in headless Chromium: modest geometry, no heavy effects.
- Works with mouse AND touch AND keyboard. Target a vertical phone screen first.

THE GAME (the loop in five bullets)
- The rule: [RESTATE THE ONE RULE AS A MECHANIC].
- Input: [tap or click or a single key].
- Fail state: [what ends a run, keep runs a few minutes long].
- Scoring: [points for progress, bonus for a collectible].
- Ramp: it gets harder over time (faster, tighter, heavier).

DETERMINISM (important)
- Advance the simulation on a fixed timestep (1/60s with an accumulator).
- Use a seeded random generator, never Math.random, never Date or performance inside the sim.
- The same inputs must always produce the same game.

CAPTURE CONTRACT (so we can film it)
- With ?capture in the URL, do not run a requestAnimationFrame loop. Instead expose
  window.render(t) that steps the real simulation to time t deterministically, then draws.
- A scripted cursor plays a 45-second session through the same input a human uses.

QUALITY BAR
- After writing the files, render a dozen frames, open them, and critique them as a harsh
  playtester (reads at phone size, the rule is obvious, motion quality, anything broken).
  Fix the three worst problems, then show me.

Do not open a browser or run anything until the files are written. Write the files first.

That last line matters: the model writes more complete, coherent code when told to finish the files than when it starts testing halfway. And the "critique the frames" instruction is the secret weapon we come back to in Step 5.

Step 4: Why determinism pays off three times

We asked for a fixed timestep and seeded randomness in the prompt for a reason. That one decision gives you three things for free: a flawless trailer (you can step the game and screenshot every frame with zero drops), verifiable scores (a server can replay the same inputs and confirm a score is real), and consistent difficulty (the game plays the same on a 60Hz and a 144Hz screen). Orbit Switch seeds its obstacle layout from a tiny generator, which is exactly why everyone can get the same "daily" course.

Step 5: Record the trailer from the game itself

The muted vertical clip is how your game gets discovered, and screen-recording a game drops frames. Because the simulation is deterministic, you instead step it and screenshot each frame, then encode with ffmpeg for a perfectly smooth result:

# drive window.render(t) across every frame with Playwright, pipe PNGs into ffmpeg
for i in range(30 * 45):                 # 45 seconds at 30 fps
    page.evaluate("t => window.render(t)", i / 30)
    ffmpeg_stdin.write(page.screenshot(type="png"))
# ffmpeg ... -c:v libx264 -crf 16 -pix_fmt yuv420p out/trailer.mp4

Two traps worth knowing: headless browsers can briefly lose the WebGL context and emit white frames (check for it and reload), and the encoder needs even width and height (an odd size silently fails).

Step 6: Playtest with frames, not vibes

This is the step that separates a polished game from a janky one, and it uses Opus 5.5's best trick: it reads images. After each pass, render a dozen keyframes and have the model look at them and score them before you watch any long render. Most real game bugs are visual — a gauge that moves when the camera moves, a label covering a banner, physics that tips when nothing should have moved it — and a test suite never catches those. You only see them in the frames. Iterate three or more rounds until it looks right; iteration is the method, not a failure.

Step 7: Turn a sandbox into "one more run"

A pleasant sandbox hooks nobody. What turns it into something people replay is, counterintuitively, taking choices away and adding pressure: pieces arrive one at a time, difficulty ramps, and a clear fail state keeps runs short. Then give players a reason to come back — above all a shared daily: one seed per day, the same layout for everyone, a fresh score to chase. That daily loop is the engine behind Wordle, and because the game is deterministic it is a one-line change.

Step 8: A tiny, cheat-resistant leaderboard

A real leaderboard is small: a couple of serverless functions plus a free database (Vercel + a free Upstash Redis tier, or your existing database). The whole skill is not trusting the client: check the server-measured time, cap the maximum score per action, allow one submission per run, and — because the game is deterministic — optionally re-run the submitted inputs on the server to confirm the score. Test it the way a cheater would: resend a finished run, post an impossible score, submit one that is too fast. If all three are rejected, your board is honest.

Step 9: Ship it to phones, cheapest step first

In order of cost: a PWA (a manifest, a service worker that never caches your API, and an install prompt — free, works offline, and this is the whole ship for most games); then Google Play by wrapping the same folder with Capacitor (a one-time ~$25 registration); then the App Store ($99/yr, and Apple rejects "just a website," so add native touches like haptics first). Orbit Switch is a PWA — it installs from the browser and plays offline.

Getting paid, honestly

Here is the part the hype skips. Shipping a game in an afternoon is real. Getting paid is a separate business you build on top — not a button the model presses. Most afternoon games earn nothing; what they earn first is attention, and attention is not revenue. Two realistic routes:

• Your own game. Cosmetic packs, player-chosen rewarded ads (watch one to get a save), a paid level pack with the first chapter free. The cozy audience hates energy timers and pay-to-win, so the ceiling is modest unless the game genuinely retains players. The nearer-term "income" is often indirect — a build-in-public post every day is attention, which on some platforms pays out on views. Treat that as marketing, not salary.
• Sell the pipeline (the faster money). The one-rule, 30-second, one-file, touch game you just learned to build is exactly the format of a playable ad — and businesses pay for those, plus branded mini-games for launches and trailers rendered from a real game for studios that have a game but no video. The move that works: build one sample for a product you like, record its trailer, and send it with "made this playable for your launch — want the source?" A buyer can play it on their phone in five seconds, which beats any pitch.

So go in clear-eyed: the build is genuinely achievable and genuinely fun; the money is a business you build with the skill, most reliably by selling the pipeline to people who already have budgets.

Try it, then build your own

The fastest way to understand all of this is to play the finished example and then build your own. Play Orbit Switch → (one button; grab the stardust), and when you want the whole pipeline step by step — the design-doc prompt, a deterministic engine, the trailer pipeline, a cheat-proof leaderboard, and the ship-to-phones path, with a real game as the worked example — take the hands-on course: Ship a Browser Game with Opus 5.5 (Module 1 is free).