# World Persistence, Quests, Migrations, Updates, Release Cycles, Development Streams

- Problem with world persistence
- Worldgen is chaotic
- Persistence is semantic: simply transferring IDs is not sufficient
- Characters are inherently tied to the world they exist in: no separation is possible! We can't detach a quest-giver from the world they exist in

## Solutions

### Accept the chaos, thin persistence

- Persist 'thin' world data for each commit hash (i.e: a dumb strategy like serializing stuff en-masse), then destroy it if the commit hash changes

- Only specific things like player quests need persisting (thin world persistence): we can rely on deterministic worldgen for everything else!

- Relatively easy to implement, guaranteed lack of breakage (we promise nothing, commit change wipes everything)

- Not great on a rapid release cycle, frequent clearing of all data, no migration means that players don't get a chance to form relationships in the world

## Snapshot the world

- Migrate everything on every build

- Basically how we do existing persistence (inventories & pets) but with an insanely complex schema that somehow encapsulates all aspects of the world, world history, NPC & civ relationships, quests, etc.

- Completely impractical in practice: any non-trivial change requires migration. Starting the game after a month would imply applying thousands of migrations, each potentially updating hundreds of thousands of things in the world

- Very difficult to manage with a collaborative project. *Perhaps* viable for an individual project where one person controls the universe (see Dwarf Fortress, although it doesn't do this well: breakage is very common), but not for us

## Flexible world snapshot combined with thin persistence

- Snapshot the world in detail on save, but also preserve a less detailed version that is used for the basis for migration between releases

- Implies a long release cycle because we'd only be writing a proper migration system for each release, relying on the commit hash remaining consistent between releases

- Advantages of both methods: we can do thin persistence for unchanged commit hash & specific details, but do a major migration for each release

- Make no promises about persisting specific details during release migrations (quests, unimportant entities, etc.) allow for migration changes by making time pass: simulate ~10 years in-game: the broad strokes of the world stay the same (same civs, same diplomacies, perhaps even some entities are the same) but irreversible change has occurred and the player is okay with it because we got them to click a big 'migrate world' button and watch an animation of time passing (could even have a 'you awake from a long slumber' dialogue in-game). Players can accept some things being different because they're expecting change

- Gives us the chance to apply fixups to the world: sprinkle in new features developed over the last release cycle (new creatures, civ behaviours, etc.) without apparent inconsistency

- Requires us to migrate less stuff and means we can go with a less complex schema. We can omit trivial details and afford to semi-break certain things. Time has passed, so obviously things are going to be different!

- Simulating a period of history 'smooths over the bumps': the world gets a chance to settle into a new equilibrium meaning that we can fuck things up a bit during auto-migration and nobody will care too much.

- Migrating a world becomes a 'social event': a thing that players get excited for rather than a reason for them to be disappointed about breakage. A negative (migration is hard) almost turns into a positive (a chance to freshen your world up and experience new things in a place you're familiar with)