Crashout: A Multiplayer Racing Game Built for Live Events

Most multiplayer games assume a captive, technical audience: an app already installed, a stable connection, players who know the controls. None of that holds at a corporate party, a brand activation, or a night out with friends. The onboarding has to work for a guest who has never seen the game before, on whatever phone they happen to be holding, over whatever wifi the venue provides.

On top of that, one host has to be able to run the event end to end — start a race, reset it, start the next one — from a tablet, without ever walking up to the TV. And every screen in the room, from the big display to each player's phone, has to agree on exactly what's happening at every moment, or the whole thing falls apart in front of a live crowd.

We settled on the simplest possible onboarding: a QR code on the big screen, a browser tab on the player's own phone, no app, no account. Scan, type a name, pick a car, start driving. That single decision shaped almost everything else about the product.

The other core decision was to make the server the single source of truth for the entire game. No client — not the big screen, not a player's phone, not the host's controller — is ever allowed to decide what happened in the race. They only render what the server tells them. That's what makes it possible for a room full of strangers' phones, over unpredictable wifi, to all agree on the same race.

The backend is a Go server built on the standard library's HTTP router and a lightweight WebSocket library, with no web framework in between. Every event gets its own room, and every room owns its own simulation goroutine and inbox channel — rooms never share state or lock against each other, which keeps a game with dozens of simultaneous events simple to reason about.

The simulation runs at a 60Hz tick internally, but only broadcasts a snapshot to clients 20 times a second, with the client interpolating between snapshots for smooth motion. That ratio isn't arbitrary — we originally ran the tick and snapshot rates at a 30/20 split, which produced an irregular 33/33/67 millisecond broadcast pattern and showed up as visible stutter on the big screen. Moving to a 60/20 split, an exact multiple, gives a perfectly uniform 50 millisecond cadence and fixed it. It's a good example of the kind of detail that only shows up once you're watching a race play out on an actual TV.

Three surfaces connect to that same server: the big screen renders the race and lobby QR code on canvas, the joystick page turns a player's phone into steering and a horn button, and the controller gives the host start, reset, and settings. A fourth mode, a single-device demo race, reuses the exact same protocol — it just opens two WebSocket connections from one phone instead of inventing a new client role.

All of that runs across two providers. The frontend is on Vercel — every one of the three surfaces is just a route in the same Next.js app, reaching the backend over absolute WebSocket and REST origins baked in at build time. The backend is deliberately unglamorous: a single EC2 instance in us-east-2, provisioned by Terraform. No containers, no orchestrator, no load balancer.

Caddy sits in front of it, terminating TLS for every WebSocket connection with certificates it provisions and renews itself from Let's Encrypt — the backend's internal ports are never publicly reachable. Anything that has to outlive a process lives in PostgreSQL on a separate box, reached over SSL, with migrations running at boot. Deploys are the only thing GitHub Actions does: lint, typecheck, tests, and build all run locally before a push ever happens.

Because Crashout runs at live events, a deploy can never be allowed to interrupt a race in progress. We run production behind blue/green deploy slots on the same box, and a shutdown signal tells the old slot to drain — finish whatever races are running, refuse new ones — for up to three hours rather than dropping connections immediately. Clients pin their reconnects to the slot they started on, and a resume token lets a player whose phone drops mid-race rejoin the exact car they were driving.

Beyond the core race loop, the product grew into a full event-operations tool:

Crashout has been in continuous, active development for about five and a half months, and we've built it to the standard of production software, not a party-game prototype: