save-systems

Save systems

A save file is a serialized snapshot of game state that survives restarts. The hard parts aren't writing bytes — they're choosing what to save, writing it so a crash mid-save can't corrupt it, and reading old saves after you ship a patch. Get those three right and the rest is plumbing.

When to use

• Use to persist progress: player stats, inventory, world flags, settings, positions — across sessions and game updates.
• Use to design save slots, quicksave/autosave, and crash-safe writes.
• Use when old save files break after a content/code change (versioning & migration).

When not to use: for Roblox cloud persistence specifics, use roblox-datastores. For the data model the save serializes (resources/SOs), use godot-resources / unity-scriptableobjects. For Godot's FileAccess/ ResourceSaver and user:// paths, defer to the Godot engine skill while applying the patterns here.

Core workflow

1. Decide what state is authoritative. Save the data (hp, position, seed, unlocked flags), not engine objects or scene nodes. You will reconstruct objects from data on load — never serialize live node references.
2. Define a versioned schema. Every save embeds a version integer. This is the single most important field for a game you intend to patch.
3. Pick a format. JSON/text for readability and debuggability; a binary format for size/speed or mild tamper-resistance. Start with JSON.
4. Write atomically. Serialize to a temp file, flush, then rename over the real file. A crash leaves either the old save or the new one — never a half-written one.
5. Load defensively. Read version → migrate up to current → validate → instantiate. Keep a backup of the last good save and fall back on parse error.
6. Autosave on safe boundaries (level change, checkpoint), throttled, and to a separate slot so it can't clobber a manual save.
7. Verify: save, fully quit, relaunch, load — and confirm by inspection that state matches. Test loading a save from the previous version.