Saves that never break: a ladder a world can always climb
The Long Watch is a game about tending one place for a long time. That promise has a quiet engineering consequence most players will never see: a saved world is somewhere you’ve spent evenings, and there is only ever one copy of it — a single rolling save, no hidden backup.
So when the game grows — when it learns to grow plants, to enrich soil, to stand a dying tree as a snag — the world you saved before any of that existed can’t be allowed to fall off the edge. This is the story of how we made an old save unbreakable: a ladder that only ever goes up, and that any world can always climb.
The first save was deliberately small
The first version of a saved world held almost nothing, on purpose. It carried the world’s seed, the elapsed in-play time, an empty slot reserved for a log of what you’d done, and the state of the season. That was the whole contract: save the world, close the game, reopen — the world is exactly where it was. Nothing more, because at the start there was nothing more to remember — no plant had grown, no ground had been enriched, no creature had lived or died.
One rule shaped even that small file. Time only advances while you’re actively tending a world; a closed game doesn’t age in your absence. So a save isn’t a clock left running — it’s a place paused mid-evening, and reopening sets you back down exactly where you stood. That rule mattered later more than we expected, because it meant an old save was never stale in the sense of having drifted on without you. It was simply a world from an earlier, smaller version of the game, waiting to be understood by a larger one.
Then life arrived, one layer at a time
What broke the small file’s calm was the simulation getting deeper. Each new kind of life changed what a world had to remember, and so changed the shape of what we wrote to disk.
First the plants. The earliest meadow needed somewhere in the file to live, so the save shape grew to carry it. Then the soil began to remember being fed — fertility that builds where things have died and decomposed into the ground — so the shape grew again to store that enrichment. Then a second, longer-lived tree arrived (the oak), with a full death cycle of its own: the standing snag, the fallen log, the litter it sheds as it returns to earth. All of that became real on disk, and the shape grew once more.
The pattern is the point. Every time the world learned to hold a new kind of life, the saved-world format had to learn to hold it too. The file was upgraded again and again — not once, not twice, but each time the living world got richer. Left unmanaged, that’s exactly the kind of churn that quietly orphans old saves: the file you wrote last month no longer matches the file the game expects to read this month.
A ladder, not a cliff
The load-bearing decision is what happens to a world saved by an older version of the game. The wrong answer — the common answer — is to refuse it, or to load it halfway and corrupt it. We chose neither. When the game opens a world, it recognizes which shape that world was saved in, and if it’s an older one, it walks the world forward one step at a time, up the ladder, until it matches the version that’s running. Then it plays it.
Each upgrade in the format added exactly one rung. A world saved before plants existed climbs the plant rung, then the enriched-soil rung, then the oak-death-cycle rung, and arrives at the top fully current — without the player ever knowing a migration happened. There is no point at which an old world hits a wall and is turned away. As long as a rung exists for every step between where a world was saved and where the game now stands, the climb always completes.
An old save isn’t a file the game has outgrown. It’s a world standing on a lower rung — and the ladder reaches all the way down to it.
Pre-feature fidelity: arriving without what didn’t exist yet
The honest question about walking a world forward is: what do you fill in for the things that didn’t exist when it was saved? Our answer is to add nothing that wasn’t there. A world saved before any plant grew arrives in the current game with no plants and an empty, unenriched soil — not because we lost that data, but because there was never any to lose. It catches up quietly to the present shape while staying truthful about its own past.
That’s the difference between an upgrade and a rewrite. We never reach back and invent a forest the player never planted, or pretend the ground was rich when nothing had ever died in it. The world’s real history is preserved — a partly-grown plant comes back at exactly its saved stage, not reset to a sprout — and only genuinely new fields, the ones that describe features the old world never met, fill in with sensible defaults. A pre-plant world is a pre-plant world. It just becomes one a current game can read.
Two more properties keep the climb safe. The upgrade happens in place and is idempotent — running it on an already-current world changes nothing, so there’s no harm in checking twice. And the ladder only goes one way. The single thing the game refuses is a world saved by a build newer than the one trying to open it, because there’s no safe way to walk a world backward and discard what a future version knew. A future world is declined cleanly rather than loaded and mangled. Everything older is welcome; only the future is turned away.
Changing the file’s shape on purpose
A format that grows this often is a format that can drift by accident, and an accidental change to how a world is stored is precisely the kind of bug that doesn’t show up until someone’s month-old world won’t open. So we treated every change to the file’s shape as a deliberate act, never an incidental one.
Each time we changed the shape, the change was checked against a recorded baseline of what the shape was supposed to be — so that any drift we didn’t intend would show up loudly, rather than slipping out to players. And no migration ever shipped alone: a new rung always landed together with an automated check that loads the oldest format, walks it all the way up to current, confirms the upgraded world is whole, and confirms a future-version world is still refused. (We’ve written separately about how easily a check like that can pass while proving nothing — the test that proved nothing — which is why this one has to actually load an old world, not just assert that it could.)
One structural choice kept all of this clean as it grew: the logic that walks an old world forward got its own dedicated home, separate from the logic that opens a world in the first place. Opening a world and upgrading an old one are different jobs, and keeping them apart meant the ladder could grow rungs without tangling the part that simply reads a current world off disk.
Why a save format carries the whole promise
It would be easy to read all of this as plumbing — versioned files, migration steps, the unglamorous business of reading bytes that someone wrote a month ago. But it sits underneath the one thing the game asks you to do: keep a place for a long time. None of that matters if a world you tended last spring stops opening the day the game learns something new.
This is the half of the durability story about a world surviving the game’s growth. The other half — a world surviving a crash mid-save, written beside the old one and only swapped in once it’s whole — has its own place in the story. Together they make the same promise from two sides: the world will keep opening no matter how rough the moment you saved it in, and no matter how much the world, or the game, has grown since.
Tend a world once, and it stays openable. The ladder only ever goes up — so an old world is never left behind, only carried forward.
