How to Build a Multiplayer Browser Game With an AI Coding Agent

You can build a multiplayer browser game with an AI coding agent in a weekend, and it will probably work for exactly one player. The hard part is not the code. The hard part is deciding where the truth lives before you let an agent write a single line. This guide covers the stack, the traps and a prompt that bunpav's own approach supports, drawn from how we run the games on bunpav's play page.

It is dated October 16, 2026, and it reflects what is in our own repository, not a lab benchmark. Where we cannot confirm a claim, we say so.

TL;DR: what you need to know first

Why "just ask the agent" fails for multiplayer

A single-player browser game is a loop: read input, update state, draw. An agent writes that loop well, and bunpav has covered how far that goes when a model builds a whole Three.js shooter with no art assets.

Multiplayer adds a second computer, and now the same game exists in two places. Which copy is right when they disagree? If you do not answer that question in the prompt, the agent answers it for you, usually by letting each browser run its own game and syncing positions over a socket. That feels fine on localhost. On a real network with two laptops it produces rubber-banding, duplicate pickups and one player who can teleport.

So the first job is yours. Write down the rule: one program decides what happened, and everyone else watches.

Which stack should you pick?

For a small game, keep the stack boring. Every extra moving part is something an agent has to wire up and you have to debug.

A WebSocket server that does one thing

bunpav's game server is a thin Bun WebSocket adapter. The comment at the top of the file in apps/game-server describes it as a thin adapter around the room logic, and the entry file is 144 lines. It exposes a /health route, a read-only /rooms route for a public room list, and a /ws route that upgrades to a socket. Everything else is delegated to a shared room hub.

That split is the lesson. The socket layer moves bytes. The room logic lives in a separate package that does not know about sockets at all. When you brief an agent, ask for the same separation, because it lets you test the rules without opening a network connection.

Authoritative state on the server

In an authoritative design, clients send what they want to do, and the server computes what happens. bunpav's boat race document puts it plainly: clients send intent only. Numeric inputs are finite-checked and clamped, updates are bounded, stale input expires after 300 ms, and actions enforce cooldowns. Snapshots carry the current boats, pickups and traps, so a player who reconnects gets the real state back.

You can copy that checklist almost word for word into a prompt. Finite-check every number. Clamp it. Expire old input. Put a cooldown on every action. These are the rules an agent forgets when it is optimizing for "it runs."

A fixed simulation tick

Our server steps every room at a fixed 60 Hz tick. The loop accumulates elapsed time, caps a single catch-up burst at 250 milliseconds, and runs as many fixed steps as it owes. A fixed step means physics behaves the same on a fast server and a slow one.

Agents often write update(dt) with whatever frame time arrives. That works until a lag spike hands your physics a half-second step and a player tunnels through a wall. Ask for a fixed step and a cap on catch-up work.

Three.js on the client

The client should be dumb. It reads keys or touch, sends intent, receives snapshots, and draws. bunpav's browser games use Three.js for rendering, and the boat race scene computes its water displacement with the same height function the server uses, so what you see agrees with what the server decided.

Three.js is a good default because an agent knows it well and because the output runs in any modern browser with no download. If you want to know what the browser can do beyond that, see our explainer on how browser games now run PS2 titles with WebAssembly and WebGPU.

What you can skip at first

You do not need WebRTC for gameplay, a database, accounts or a matchmaking service. We did add WebRTC for optional push-to-talk voice, and that is a separate system with its own relay needs. Our voice document notes that reliable connections across restrictive networks require a TURN relay, and that is a real cost you can postpone. Start with text chat or none.

What does a good prompt look like?

Vague prompts get vague architecture. The prompt below is an example we wrote for this article; it is not a transcript of a session we ran, and we have not benchmarked it.

Build a two-to-eight player browser game called Bump Arena.

Architecture (do not change):
- One Bun server with a WebSocket route at /ws and a /health route.
- Game rules live in a separate module with no socket code. The
  server owns all state. Clients send intent only: {move: [x, z], dash: bool}.
- Fixed 60 Hz simulation step. Cap catch-up work at 250 ms.
- Validate every message: finite numbers, clamped ranges, max payload
  256 KB, per-player rate limit, action cooldowns, stale input expires
  after 300 ms.
- Rooms of up to 8 players. Reconnect restores the same seat.
- Server sends full snapshots; drop a snapshot if the socket is backed up.

Client:
- Three.js scene, keyboard and touch controls, no external assets.
- Draw only what the latest snapshot says. Never move a player locally
  except for cosmetic smoothing.
- Dispose geometry, materials, textures and listeners on unmount.

Deliver in this order: the rules module and a script that plays a
full match with bots, then the server, then the client. Stop after
each step so I can run it.

Three details earn their place. The architecture block is fenced off with "do not change," so the agent cannot quietly swap it for peer-to-peer. The delivery order forces rules first, with a bot match you can run, which catches logic bugs before any graphics exist. And the cleanup line asks for disposal, which agents omit unless told.

What are the pitfalls?

Every item here is either in our docs as a rule we enforce or a pattern we have seen in generated code.

1. Trusting the client

The most common failure. The agent lets the client send its position because that is the shortest path to a demo. Fix it in the prompt and review the message handler yourself. Search for any field the client sends that the server uses without clamping.

2. No limits on size or rate

Our server sets a maximum payload of 256 KB per message, a one-megabyte backpressure limit that closes a connection that falls too far behind, and a 60-second idle timeout. It also skips full snapshots for a slow connection once more than 128 KB is buffered, because the next tick replaces them anyway, while still delivering roster and action messages. An agent will not think of any of that unprompted. Ask for it.

3. Rooms that never end

Idle matches leak memory and confuse players. The boat race ends after the first finisher opens a 22-second window, and idle races have a hard timeout. If everyone is idle, no winner is invented. Specify an ending for every state: finished, abandoned, all-idle.

4. Memory and GPU leaks

Three.js does not free geometry, materials and textures when you drop a reference. Our design notes list disposing geometry, materials, textures, audio, animation frames and listeners on unmount as an explicit requirement. Agents write the setup half of a scene carefully and forget the teardown half.

5. Testing with one player

Our repository has a script that runs real online lifecycle checks with two actual WebSocket clients per game. Our September 26, 2026 production audit records that it passed for all 29 public games, with 340 assertions. Those numbers come from our own internal audit and we have not had them independently reviewed. The point is the method: a bot match for rules, and two real sockets for transport.

6. Believing a green test means a fun game

Our own quality review is blunt about this: passing compilation, multiplayer simulations and layout checks is necessary, but does not make an underdeveloped game good. Several of our games scored low in the first internal pass despite passing tests, and we rated them honestly. An agent can ship working code that is dull. You still have to play it.

7. Skipping mobile and pause

Pointer lock, touch controls, hidden tabs and focus loss break input in ways a desktop test misses. Our voice document lists key release, pointer cancellation, lost pointer capture and hidden tabs as cases that must mute immediately. For games, ask for held inputs to be cancelled when focus or pause changes.

How do you work with the agent day to day?

Treat the agent like a fast junior developer who never asks a question. A few habits help.

Give it one small deliverable at a time and require a runnable check at the end of each. "Write the rules module and a bot-match script" is a good unit. "Make the whole game" is not.

Keep a short design file in the repo that the agent reads first. We keep per-game documents in docs/ that list controls, rules, implementation layout and the exact validation commands. When a new session starts, the document gives the agent the shape of the system without you repeating it.

Review the diff for the security-shaped code, even if you skim the art. Message handlers, ticket checks and anything that touches identity deserve a human read. Our server verifies HMAC-signed tickets with a shared secret and refuses to start in production without one.

Ask for the check script before the fix. When a bug appears, have the agent write a failing check first, then fix it. That keeps regressions from coming back.

Finally, run it with a friend. Nothing replaces two humans yelling at each other over a bug.

How much does it cost?

We will not invent a number, because it depends on your model, plan and how many rounds you need. Here is what we can say honestly.

There are three cost buckets. The first is agent usage, which scales with how much code it reads and writes per turn. A clean architecture and a design file keep that down, because the agent does not rediscover the project each time. The second is hosting: a small Bun process can serve many rooms, since the simulation is cheap per room, but we have not published a capacity benchmark and you should load-test your own game. The third is your attention, which is usually the biggest.

For reference, one of our internal planning documents estimates the cost of an AI game edit on a top-tier model at roughly 10,000 input and 8,000 output tokens per turn, and prices that at about a quarter per edit. That is a planning estimate from July 2026, not a measured bill, and model prices change. Check current pricing before you budget.

Voice is where costs can jump. A TURN relay needs bandwidth and configuration that no code change provisions for you, so leave it out of version one.

What should you do this week?

1. Write the rule on a sticky note: the server owns the truth, clients send intent.
2. Draft a one-page design file with players, controls, win condition and the validation commands.
3. Prompt the agent for the rules module and a bot-match script first, and run it.
4. Add the server, then a bare Three.js client with cubes for players.
5. Open two browser windows and play against yourself, then a friend on a different network.
6. Add limits: payload size, rate, cooldowns, stale input expiry.
7. Only then add art, sound and polish.

If you want ideas for what to build, look at the genre that fits this approach best. Friendslop games are short, silly, physics-heavy and forgiving, which suits a small authoritative server and a rough art style. For how teams actually use such games, see our guide on online team-building games for remote teams.

What about generating assets with AI?

You can skip art entirely at first. Cubes and capsules are enough to prove the game is fun. When you want more, an AI pipeline can generate and rig 3D models, and we walked through one in our piece on a game jam 3D asset pipeline. Keep generated assets out of the critical path, because a missing model should never stop a match from starting.

Also be aware of the wider platform picture. Roblox now lets people describe a mobile game and build it, which we covered in Roblox's AI mobile game creation. That route is easier but locks you into one platform, while a browser game you host yourself is yours.

Other game news today

Enshrouded 1.0 launched on PS5. The survival game reached version 1.0 on October 15, 2026, according to our own coverage (bunpav report).

A Nigerian browser game passed a million players. Our October coverage of Lagos Life describes the milestone and why browser distribution mattered (bunpav report).

Steam set a new concurrent-user record. We reported the 43.5 million figure for October 2026 (bunpav report).

Related reading

• Friendslop browser games for team socials
• Top 10 friendslop games of 2026
• Claude of Duty: an AI-built Three.js FPS
• How browser games run PS2 with WebAssembly and WebGPU
• Online team-building games for remote teams
• Game jam 3D asset pipeline with AI
• Roblox AI mobile game creation
• Three.js documentation
• Bun WebSocket documentation

Facts about bunpav's own server and games reflect our repository as of October 16, 2026 and may change. The sample prompt is illustrative and untested as written.