36 lines
1.8 KiB
Markdown
36 lines
1.8 KiB
Markdown
# 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.
|
|
|
|
## Vorgaben aus anderen Tickets
|
|
|
|
- **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.
|