VeerMultiplayer Game

Veer is a light-cycle game in the browser. Up to six people (or bots) race around an arena leaving walls behind them, and the last one still riding wins. You can queue for a match, make a private room with a four-letter code, or just watch.

It has not been played across a real WAN. Many rooms running at once under load was not tested, and neither were touch controls on a physical phone. It runs and the checks pass, but it is not a hammered game server.

This one started on the Codex list in the split file. On the last day I asked Claude Code to build everything left, so it took Codex rows from the bottom up, and #91 was one of them. It was a fresh build in one focused session, about half an hour of wall clock.

I set the constraints: write the WebSocket layer by hand, keep the server authoritative and deterministic, add prediction, Elo matchmaking and bots, and use no dependencies at all. Claude Code wrote the server, the client and the test suite in small files. That was on purpose. The API connection kept dropping long responses mid-stream, so everything got grown in small edits.

The server speaks RFC 6455 directly on node:http: handshake, frame codec, ping and pong, close codes, a 16 KB frame cap and a rate limit. It runs a 20 Hz simulation and sends each client a delta snapshot. The client predicts its own cycle and smooths everyone else. One set of pure modules in core/ runs in both the browser and Node, so the code that ships is the code that gets tested. Claude also wrote a raw WebSocket client on the same codec and used it to drive headless Chrome over the DevTools protocol, so it could actually steer a cycle in real time and screenshot the player view.

• Prediction only lines up if the server consumes exactly one input per tick. With constant lag the test shows zero mispredictions. With jitter, every correction traced back to a tick where the server's input queue was empty.
• Commands sent during the countdown have to replay as turns, not moves, or the local cycle jumps ahead at "GO".
• Append-only state is great for compression. Sending only the new trail cells since the last ack cut a tick from about 4 to 6 KB down to about 200 bytes.
• The spec has sharp edges. Close code 1005 is fine locally but illegal on the wire, and a 64-bit length with the top bit set has to be rejected before reading anything.
• Headless Chrome's virtual time fakes the page clock but not the server's, so the overlay showed RTTs near a second. Real-time capture showed the honest number, 1 to 10 ms locally.

Veer is one of the most reused builds in the repo. Project #63 (Realtime Chat) imports five of its files directly: the WebSocket server, the frame codec, the parser, the SHA-1 handshake and the rate limiter. I wrote the hard part once and the chat app stood on it.

I would move snapshots to a compact binary format, since the codec already supports binary frames. I would also add server-side lag compensation for head-on collisions.