The same world, grown on another computer
For most of its life The Long Watch could only prove its central promise in one place: the same seed grows the same world, checked on one laptop against one exact copy of the engine. In late July the project spread onto three computers across two operating systems, and we ran that proof everywhere at once. The world came out identical. Almost nothing else did.
One desk’s worth of proof
Reproducibility is the house rule here, and every random choice the simulation makes runs through one seeded stream so that the same seed grows the same world anywhere. Anywhere was the untested word. Until this month we could only ever demonstrate it in one place, on one machine, against one exact copy of the engine.
A good deal leaned on that. We keep a set of pinned fingerprints: compact summaries of a whole simulated world after a fixed run from a fixed seed, compared byte for byte so any drift trips a check on the day it happens. We keep per-scene frame-rate floors. Both had been treated as facts about the game, and both had been measured on the same desk.
The promise at the far end of all that is a player-facing one. A world’s short shareable code is an address: hand it to somebody else and they should settle the same world you did. Some design decisions are deliberately locked once the game is out, precisely because changing them would break that address. A promise of that shape deserves better evidence than one computer agreeing with itself.
Getting the game to start somewhere else
A second computer came online first, and what it found immediately was that a fresh copy of the project could not build itself into a playable game at all. The packaging settings had been an empty placeholder for the project’s whole life, because the one machine that ever did the packaging carried them outside the repository. They are tracked now.
The heavy engine packaging templates travelled machine to machine over the local network instead of being downloaded again, on a piece of reasoning we liked: if the engine binary is required to be identical everywhere, then its templates are identical by construction, so copying the proven set beats fetching a fresh one that merely ought to match. Only about a third of that bundle was the preset we actually needed.
Then a third machine joined, a headless box running a different operating system, and it went wrong in a more instructive way. Its first run reported hundreds of broken tests. All of them were a single plumbing failure wearing hundreds of masks: the test runner launched each piece of work through a command that exists only on the original operating system, so every child process came back instantly finished and empty, and the harness dutifully wrote down each empty result as a failure.
Rendering hid something worse. The machine has a real graphics chip, but with only one of the two device nodes it needs exposed, the engine fell back to rendering in software and reported no error whatsoever. Same crowded-objects probe: 51.6 frames per second on the chip against 0.2 on the fallback, roughly two hundred and fifty times slower, presented as a clean run. We had already learned that some proofs mean nothing outside a real graphics window; this was that lesson with the failure mode inverted, so a run there now refuses to start rather than substituting something false and saying nothing, in the same spirit as probes built to skip rather than fake a green.
The same world, grown twice
With all three able to run the whole set of checks, we froze the code at one point in its history, recorded its state either side of the run so that any change landing partway through would void the result, and re-ran the fingerprints on all three at the same time.
Every scenario agreed, byte for byte, across both operating systems. That includes the one scenario we keep deliberately failing as a guard against a check that has stopped checking: even its wrong answer was the same wrong answer everywhere. The scene-level witness counts matched too, down to how many plants a batch places inside the sampled bounds, which retired a caveat we had been carrying about whether those numbers were portable.
The result was stronger than we had any right to expect. We had assumed byte identity would require an identical engine binary — a claim first asserted back when a whole simulation moved onto the graphics card — and what we had in hand were two different platform builds of the same version.
The same world, grown on another computer, came out identical.
We declined to promote that into a general claim. One frozen build, one set of scenarios, one afternoon. It says the fingerprints reproduce across these platforms at this point in the history, which is a long way up from one desk and still short of a guarantee.
What does not travel
The frame-rate floors went the other way entirely. Each windowed test scene asserts a minimum somewhere between twenty-two and thirty-three frames per second, and the moment those scenes ran on three different graphics chips, the numbers stopped reading as properties of the game. On the slower boxes, real scenes breached floors with no defect behind them. On a faster card the same floor would have sat harmlessly beneath a genuine regression and waved it through. Our confidence in those floors was already thin, since the meter reading them could not count past about sixty.
So the floors are machine-scoped now. One machine is the speed authority. Another can declare itself off the gate, which demotes a breach from a failure to a warning and changes nothing else about the run, and that verdict is written into the run record itself, so a green result from a machine that was not gating can never be mistaken later for a clearance. Gating stays on by default: an unconfigured or unrecognised machine enforces the floors, so a forgotten setup step costs a loud false alarm rather than a set of checks that quietly stopped checking.
All of which required the project to know which computer it was running on, which it never had. Asking the operating system was useless, since two of the three share one. Each machine now has a name in a registry, one command sets a machine up, and an unknown machine gets refused rather than guessed at. The names turned out to matter less than the cross-checks they make possible: a settings file copied wholesale from one machine to another, an authority machine with its own checks switched off, a machine claiming to be one of its siblings.
The run whose ground moved
The most expensive lesson of the stretch was neither of those. A fifty-three minute run was thrown away because two code updates landed while it was still going. The run finished. It reported four entirely plausible failures where the true count was one. A measurement whose ground shifts underneath it fails convincingly rather than loudly, and you spend the rest of the afternoon chasing three things that were never wrong.
Days later the new split earned its keep. A run came back with its frame-rate verdicts voided, because the laptop that produced them had been on battery, and a laptop on battery is a different machine. Its fingerprint results stood, untouched by any of that. One run, two kinds of evidence, and only one of them had to go in the bin.
The portability notes we wrote along the way then took a dose of the same medicine. Several of the re-check commands recorded in them were wrong, including one that was structurally incapable of seeing the exact leftover it had been written to find, and one figure was withdrawn outright rather than replaced with a second number nobody could re-derive.
Three machines, then. The world they grow is one world. The frame rate is three different answers, and three is the correct number.
