save-slot

save-system autosave slots gaming migration
by @iberry420gaming
Design a crash-safe game save system with versioned schema, slots, autosave, and migration. Use when the user wants save/load, save slots, autosave, save corruption, or migrating old saves after a patch. Gaming only, engine-neutral.
SKILL PACKAGE

Directory layout for Grok — SKILL.md plus scripts, references, and assets. 5 file(s).

Select a file

Edit in place, then Save (full package security scan). Use fullscreen for a larger workspace.

SYNCED SUMMARY (from SKILL.md)
# Save Slot

Saves are documents, not the live world. Version them. Write them atomically. Load through a pipeline.

Inspired by gamedev-skills/awesome-gamedev-agent-skills save-systems (Apache-2.0). Original Grok remake. Engine-neutral. Not a Godot tutor. Complements room-flow (space), juice-pass (feel), and branch-talk (talk flags).

Read `references/save-rules.md` before you design. Fill the three templates.

## When to use
- Save / load, save slots, continue, checkpoint
- Autosave, crash recovery, "my save vanished"
- Schema change after a patch; migrate old files
- Corruption or "trust the disk" questions

## When NOT to use
- Teach Godot FileAccess or engine APIs (use godot-teacher)
- Level blockout (use room-flow), hit juice (use juice-pass), dialogue graphs (use branch-talk)
- Cracked save editors, online cheat tools, or account theft
- Treating a client file as the server of record in multiplayer

## Inputs
- Genre slice (story campaign, roguelike run, sim, etc.)
- What must persist (progress, inventory, flags, settings)
- Slot count they want (manual + autosave + last-good)
- Current schema version if any (default: start at 1)
- Online vs local only

## Procedure
1. List persistable facts as plain data. Never serialize live engine objects, node paths, or pointers.
2. Stamp `schema_version` as an integer from day one. Never ship version 0 with "we will add it later".
3. Prefer JSON on disk first so you can open a file and read it. Binary or compression later, after the document is stable.
4. Write atomically: write temp, flush, rename over the slot. Keep a last-good `.bak` of the previous successful slot.
5. Load pipeline, in order: read bytes, parse, read version, migrate one step at a time, validate, reconstruct gameplay objects from IDs.
6. Autosave only on safe boundaries (room exit, rest bench, menu, quest complete). Dedicated autosave slot. Never overwrite a named manual slot. Throttle (time and/or event cap).
7. Fill `templates/schema.md`, `templates/slot-plan.md`, and `templates/verify.md`.
8. Keep any sample notes engine-neutral. No vendor FileAccess dumps.

## Output format
- Schema card (fields, types, version)
- Slot plan (manual / auto / bak, when each writes)
- Verify list: save, quit, relaunch, inspect; plus load an older version
- Optional tiny original sample only if they asked for code shape

## Safety
- No malware, cracked engines, cracked save editors, or account theft.
- No CSAM or sexual content involving minors in save payloads or game ideas.
- Do not write tools that forge online saves or steal credentials.
- Multiplayer: client saves are cosmetic or cache. Server owns truth.

## Stop conditions
- Schema + slots + verify delivered, or refused for scope / safety
Version History
Comments (0)
No comments yet. Be the first!
Sign in to leave a comment.