save-systemslisted

# Save Systems ## Purpose Losing a player's progress is the defect with the least forgiveness in games. There is no workaround, no "restart and try again", and a player who loses hours of progress usually does not come back. Two decisions cause most of that loss, and both are made early and cheaply: **no version field in the save format**, and **overwriting the only copy while writing**. This skill covers those and the rest of the persistence design. ## When to use - Building persistence for the first time in a project. - Changing what is saved, or the shape of what is saved. - Saves written by a previous version fail to load after an update. - Players report lost or reset progress. - Deciding whether something belongs in the save at all. - Preparing a release — loading a previous version's save is a release gate. ## When NOT to use - Server-authoritative persistence on a specific platform, where the platform's storage semantics dominate. Use `roblox-datastore-persistence` or the equivalent, which requires this skill for the general design. - Configuration and settings, which are simpler and rarely need migration. - Networked state synchronisation. Use `multiplayer-networking`. ## Required context | Fact | Why it matters | Where to find it | |---|---|---| | What must survive a restart | Defines the save's scope | The design, not the code | | Whether saves are local or server-side | Server-side means concurrency and trust concerns | Architecture | | Whether the ga