Summary
You and three others drive into a disaster to film it. A television station buys the footage, and it pays for what is dramatic rather than what is safe. Getting the shot and getting out are opposing goals, and the game is built so that every form of safety costs you income.
In development, built solo.
The problem
The design rests on a single rule: safety costs money. If a player can be safe and well paid at the same time, the game has no tension left. That rule has to be enforced by systems rather than stated in a tutorial, which means every mechanic added to the game has to be checked against it.
Technically it is a four-player networked physics game with per-client video capture, running a disaster simulation that has to look identical to everyone while being cheap enough to hold frame rate.
What I built
All of it. Networking and authority model, the disaster simulation, the scoring system, video capture, proximity voice, the round structure, NPC crowds, and the tooling and test harnesses used to verify it.
Two decisions carry most of the weight. Destruction is evaluated analytically from a seed rather than physically simulated, so every client computes the same result without anything being sent over the wire. And video capture is local to each player and records the main render target directly, so the recording costs nothing in bandwidth and does not require rendering the scene a second time.
Technical detail
Unity 6 with Netcode for GameObjects in a client-host model. The host owns physics, scoring and damage; player movement is client-authoritative; ragdolls replicate as discrete events rather than streamed poses.
Scoring is host-authoritative pure geometry derived from a rewind buffer of each player’s replicated aim pose, so what the game scores is what the camera was actually pointed at when the event happened, not where the player is now. That buffer has to exist from the start of the project or framing is silently wrong under any latency at all.
Verification runs three gates on every change: a compile check, a play-mode smoke test that boots the game and drives the real loop asserting runtime invariants at each transition, and a rendered screenshot for anything visual. That regime exists because an earlier one did not have it – a suite of a hundred and forty tests, all green, all asserting things about code, none of which could see that the game had stopped working.