09 — Save-Schema

Type: grilling Status: open Blocked by: 07

Question

Was steht in einem Speicherstand, und wie überlebt er geänderte Mods?

Entschieden ist: TOML, Mod-Liste im Header, fehlender Mod bedeutet Warnung und Verwerfen statt Abbruch. Zu klären:

Was genau wird gespeichert? Held mit Stats und Effekten, Inventar, Ausrüstung, aktuelle Etage, Etagen-Layout (oder Seed?), erkundete Räume, Gegnerzustand, Questfortschritt, Gold.
Etage: gesamtes Layout speichern oder nur den Generator-Seed? Seed ist kompakt, bricht aber, sobald der Generator oder ein Prefab-Mod sich ändert.
Versionierung: Was steht im Header — Spielversion, Save-Schema-Version, Liste aus Mod-ID und Version?
Migration: Was passiert bei älterem Schema? Migrieren, ablehnen, oder Best-Effort-Laden?
Verwerfen im Detail: Wenn ein Item fehlt, wird der Slot leer — was, wenn die Klasse des Helden fehlt?
Wie viele Speicherstände, Autosave, und speichert man mitten im Kampf?

Ergebnis: Save-Schema als kommentiertes TOML-Beispiel plus Regeln für fehlende Mods.

03: Der Mod-Header nutzt manifest.id und version. Da depends keine Versionsbereiche trägt, ist version das einzige Signal, dass ein Mod sich geändert hat — und dieses Ticket ist sein einziger Leser in 1.0. Fällt der Header, fällt das Feld.
07: Serialisiert wird der Game-Baum. Alle Verweise sind ohnehin String-IDs, es gibt also nichts zurückzuübersetzen. ItemInstance schreibt sich als { id, affixes } — Affixe sind Registry-Einträge, keine eingebetteten Modifikatoren, der Save bleibt damit eine ID-Liste. Es gibt eine Etage, keine besuchten Vorgänger. Creature.options (Rasse, Klasse) muss mit, sonst hat der Held nach dem Laden keine Herkunft mehr — womit die Frage „was, wenn die Klasse fehlt?" oben scharf wird.