Keep world identity, ownership, and recovery in one record
- Step 1: Create or select the world, write down its name, seed, owner, version, and world modifiers, and decide whether the host or dedicated server is authoritative.
- Step 2: Before the first boss, update, reset, migration, or mod test, close the game and create a dated backup of the world and related save data.
- Step 3: After creating or restoring the world, test loading, inventory, settings, player join, and portal access separately, then record the confirmed restore path.
World management becomes safer when identity and recovery are treated as one operating record. The record should tell every player which save is authoritative, who can change it, and how to restore the previous state.
- Write the world name, seed, owner, host, version, modifiers, and backup path before the first major gate.
- Test loading, inventory, settings, joining, and portal access as separate checks after a restore.
- Keep the previous backup and working join path until every intended player has confirmed the new state.
World state register
| State | Record | Acceptance check |
|---|---|---|
| World | Name, seed, modifiers, version, and save path | The intended world loads with the expected settings |
| Ownership | Host, administrator, password, and working join route | A second player can join, build, leave, and reconnect |
| Recovery | Dated backup, previous setting, and restore owner | The copy loads before the active world is changed |
Confirm the result in game
The backup identifies the world, seed, owner, settings, version, and restore path.
If joining or applying the setting fails
- Restore the copied world instead of editing the only active save.
- Ask the server owner to confirm which state is authoritative.
- Recheck world modifiers after a reset or provider migration.