A save that can’t be half-written
A world in The Long Watch is a single rolling save — one copy, no backup, overwritten as you play, because a world is a place you keep rather than a slot you store (that conviction, and why there’s no second chance, has its own home). What that single copy does is turn the most boring-sounding line in the whole codebase — write the world to disk — into the single most dangerous moment in the game.
If the machine dies in the middle of that write, from a crash, a cut of power, or a lid closed at exactly the wrong instant, a naive write-over-the-file could leave the one and only save half-finished. And a half-written world is a destroyed one.
So when we sat down to round out the per-world management — renaming, deleting, the everyday housekeeping — we put one fix above every convenience on the list and held it there: make the save impossible to catch half-finished. Everything else could wait. This couldn’t.
Never write over the live file
The fix is an old, dependable technique, and its first rule is simply: never write over the save that’s currently good. The early version did exactly the dangerous thing — it opened the real file and wrote the new state straight into it. Almost always fine. But “almost always” is the whole problem when there’s no second copy to fall back on.
So we changed how every save lands. The game now writes the new world out to a separate side file first — off to the side, complete and entire, every byte on disk — while the real save sits untouched the whole time. Only once that side file is fully written does the game swap it into the real save’s place, in a single step the operating system either performs completely or not at all. There is no moment where the real save is part old and part new. It is either the world you had, or the world you just saved — and never a blend of the two.
That single-step swap is the load-bearing part, and it’s worth being precise about why it’s safe. The swap doesn’t re-save anything; it relocates the bytes that are already finished on disk into the save’s place. So the saved world is identical to exactly what was written to the side file — the swap can’t subtly alter it, because it isn’t writing a world at all, it’s moving a finished one. An all-or-nothing move of an already-complete file is about the strongest guarantee the disk underneath us offers, and we lean the world’s only copy on it.
Two ways it can fail, and what survives each
The reason this holds up under a crash is that there are really only two windows where things can go wrong, and the world survives both.
The first is while the side file is being written. If a crash, a power loss, or a full disk strikes here, the real save was never opened — it’s still sitting there, whole and untouched, exactly as you last left it. The half-finished side file is so much wasted effort, and nothing more. You keep the world you had.
The second is the swap itself. If the machine dies during the swap, the operating system’s guarantee is that the move either completed or it didn’t: you’re left with either the new, fully-written world or the previous good one — never a mangled overlap of the two. So in every case there is a whole, openable world on the other side of the failure. The only thing you can lose is the work of one interrupted save, never the world itself.
The goal was never “saving rarely fails.” It was that when it fails, it fails into a world that still opens.
The leftover that has to disappear on its own
A crash mid-write doesn’t just have to be survivable — it has to be invisible. If a power loss leaves a half-finished side file stranded on disk, the player should never see it, never be offered it, never be able to open it. A world that didn’t finish writing isn’t a world.
So the screen that lists your worlds deliberately ignores any leftover side file. It scans for real, finished saves and skips the unfinished one entirely — it never appears in the list and can never be loaded. The only thing the game will ever open is a save that finished writing. The effect is that the system self-heals: a crash can strand a temporary file, and the next time you look at your worlds, it’s simply not there as far as the game is concerned. Nothing broken to clean up, nothing alarming to explain.
The mistake the file extension taught us
Getting that exclusion right took a mid-build correction, and it’s a good small lesson in trusting the layer underneath you a little less. The engine we build on decides how to write a file from its name — specifically from the extension on the end. Our first instinct was to give the side file a name that marked it as temporary and incomplete. But mark it too aggressively and the engine no longer recognizes it as the kind of file it knows how to write at all.
So the side file had to thread a needle: named so the engine still happily writes a proper world into it, yet still carrying a marker the world-list scan knows to skip. Two readers of the same name, each needing a different thing from it. We’d reasoned about our own code carefully and missed that a tool beneath us was reading the filename too, with its own rules. The fix was small once we saw it; seeing it was the work.
One hardened write, and everything rides it
The quiet payoff of doing this once, in one place, is that every path that saves a world inherits the protection for free. A normal save rides it. So does the bit of housekeeping that runs when you rename a world. So does the routine that quietly upgrades an older world to the current save format the first time you open it — that migration is just another write, and because it flows through the same hardened path, an old world being carried forward is exactly as crash-safe as a brand-new one. (The story of how an old save climbs to the current format is its own one.) There’s no second, less-careful save routine lurking somewhere that forgets to be safe, because there’s only one save routine, and it’s the safe one.
To keep ourselves honest, the automated checks don’t just trust that this works — they exercise it. They create a world, save it, reload it from disk, and confirm that every field comes back identical to what went in. Saving and loading a world each take about a millisecond in our testing, comfortably inside the budgets we set for them, so all of this safety costs nothing a player would ever feel. The protection is invisible, which is exactly the point: you should never once have to think about whether your world survived being saved.
The same care, made human
There’s a mirror to all this on the other side of the screen. Because a world is permanent and singular, letting one go is treated with the same weight as protecting it — a deliberate, confirmed moment rather than a click you can fat-finger, worded in the cozy-but-serious register the rest of the game speaks in. That’s a feel decision more than an engineering one, and it has its own home alongside the shelf of worlds it belongs to. What ties the two together is a single conviction that runs from the disk all the way up to the dialog box.
This world matters. So we don’t lose it by accident — not to a crash, and not to a stray click.
By the end of this stretch, the full set of things you can do with a world — make one, see them listed, open one, rename one, let one go — was complete, and every one of those paths writes through the same all-or-nothing swap. The promise of the game is that you can tend one place for a long, long time. The least we could do was make sure the act of saving that place could never be the thing that took it from you.
