Escape With Your Friends
A deliberately stupid co-op game for Steam: four friends stranded on an island punch, taser, carry and run each other over on the way to buying a boat, rebuilding a plane and getting out. Networked over Steam with no servers. I run it like a small studio where the programmers are coding agents — I set the scope, write the issues, playtest, and decide what is fun; they write the C#, and every system has to pass a headless test before it counts as done.
- Unity 6
- C#
- FishNet
- Steamworks
- URP
- Blender
- Claude Code
- GitHub Actions
The game
You wake up on a beach with three friends. To get off the island you need money, then a boat, then a second and much nastier island, then the parts of a crashed plane, then the one friend who got left behind. In between there is hunting, fishing, crafting, hostile natives, a buggy, and a casino the castaways built out of driftwood, with roulette, blackjack and slot machines that run on chips you cannot spend anywhere else.
None of that is the point. The point is that the physics are bad on purpose and your friends are a hazard: you can punch them, stun them, pick them up, throw them off a cliff and then pay to revive them in a machine that looks exactly as dumb as it sounds. The references are How to Fish and Content Warning, not anything serious.
Who does what
I did not type the C# in this project, and I am not going to pretend otherwise. Claude Code writes the code, the editor scripts that generate the content, the test harnesses and the architecture notes. What the agent cannot do is play the game, decide whether something is funny, or judge whether it looks right — so that is my job, along with deciding what gets built and in which order.
In practice that means a tracked tree of 185 issues under fourteen milestones, a written working agreement any new agent session reads before its first change, and a rule that an issue whose acceptance is a human verdict stops and waits for me rather than inventing a number and calling it green. For a while two agent accounts worked in parallel, which needed its own protocol: separate working trees, separate build folders, separate port ranges, and one shared file that only one of them may touch at a time.
Why Unity, and why not Unreal
Unreal was the obvious pick and lost on one property. Its Blueprints and asset files are binary, which makes an agent working from a terminal blind to half the project. Unity stores scenes, prefabs and data assets as text, so every change is a diff someone can read.
The project leans into that. Nobody hand-edits a scene: every piece of content — the island, the shop's inventory, the weapons, the casino — comes from an editor script run in batch mode, so it can be regenerated and reviewed. A new weapon or fish is a text file, not a session in the editor.
The host decides everything
There are no servers. One player hosts over Steam's relay and the others connect through a lobby, so nobody forwards ports and nothing costs money per month. The catch is that the host is the only thing that can be trusted: damage, money, inventory, AI and every random roll are decided there, and clients only own their own movement.
The roulette wheel is the cleanest example of what that costs. The host rolls the number and sends the result — not a seed, not a wheel speed — so no client message can reach the outcome. The first test of it passed and was only half a test, because it ran on the host, and a host never receives its own broadcast. Run as two real processes, it failed straight away: the host said 10 and the client's wheel stopped on 0, because the spin duration lived only on the server and the client was still animating the old one. The fix was one extra field in the message. It would not have been found without the second process.
Testing a game with no screen
Every non-trivial system ships with a headless harness: the game is built, launched in batch mode with a test flag, plays the scenario out and prints how many checks passed. There are around seventy of them. Some run a host and a client as two processes, because networking bugs live in the gap between them.
Two things that harnesses taught me about harnesses:
- A green run can be measuring the wrong player
- — the natives' test failed four checks identically every time. It was not the AI: the suite was run with a second player connected, and a native hunts whoever is nearest. The fix was a check that names the problem — which body, how far away — instead of four confusing failures downstream.
- Batch mode exits 0 on a failed build
- — so every build is followed by grepping the log for compiler errors. A test run on yesterday's binary passes beautifully.
- A bot that plays the first island
- in a real window, through the same input code a keyboard uses, screenshotting each step. Its first walk found that the shop drew sixteen rows of a twenty-four-item shelf, hiding the boat part the whole island is saving for, and that a full wipe left the run stuck forever.
- What is not tested
- — a headless build has no UI canvas, so no menu or HUD can be harness-tested. Those bugs are found by reading and by playing, and the docs say so.
Measured on the laptop it has to run on
The target is a game that runs on almost any PC, so the minimum spec is an integrated Radeon 760M, not an afterthought. A scripted camera route stops at fixed spots across both islands, holds each one for five seconds with the frame cap off, and appends the timings to a log in the repository, tier by tier, on both the integrated and a dedicated GPU.
That log changed decisions. The first run showed the RTX 4060 barely faster than the integrated chip on low settings — the CPU was the floor on every tier — and that the cost of the high tier was draw calls at long range, which is where the optimisation pass started. Any change that makes the medium tier slower on the 760M by more than a millisecond has to say why in its pull request.
Where it stands
Milestones zero to seven are closed: the networked core, the first island, survival, the economy and combat, vehicles, the casino, the second island and the ending. Since then there have been two rounds of my own playtesting and the fixes they produced, a cutscene system, a bigger casino, and the placeholder models replaced with ones modelled in Blender.
What is left is the art pass, the four-player playtest, and Steam itself. The playtest was set as a gate from the first week: if four people in an empty arena are not laughing within twenty minutes, the core is wrong and no amount of island will fix it. It is the one check no harness can run. The upload script, store copy and release checklist are written; the app id, the fee and the store page need a person and a card. The CI build is wired but skips — green, with a notice — until there is a Unity licence secret, because a workflow that fails red on every push until someone does paperwork gets muted, and a muted check is worse than none.