Schema-Migration von Spielständen und wiederherstellbare Schreibvorgänge

Ein Spielstand ist eine langlebige Schnittstelle

Eine Speicherdatei kann den Code, der sie erzeugt hat, überdauern. Wer ein Feld umbenennt, Einheiten ändert oder eine Inventarstruktur aufteilt, ändert diese Schnittstelle, selbst wenn das Parsen weiterhin gelingt. Die Persistenz sollte auf einem dokumentierten Datenmodell, einer Schema-Version und einem Wiederherstellungspfad beruhen, statt beliebige Live-Objekte zu serialisieren.

Format bedeutet nicht Kompatibilität

Die Godot-Anleitung zum Speichern zeigt die explizite Serialisierung des Spielzustands und die Einschränkungen der JSON-Typen. [1] Protocol Buffers dokumentiert Kompatibilitätsregeln, darunter den Erhalt der Identität von Feldnummern und das Reservieren entfernter Nummern. [2] Ein Serialisierungsformat hilft dabei, Daten darzustellen; spielspezifische Bedeutung, Standardwerte, Migrationen und unterstützte Versionsbereiche müssen weiterhin im Design festgelegt werden.

Praxisbeispiel

Ein beispielhafter Spielstand der Version 1 enthält coins: 125. Version 2 ersetzt dieses Feld durch wallet: {gold: 125}. Version 3 ergänzt difficulty; normal wird nur beim Migrieren eines älteren Spielstands eingesetzt, dem dieses Feld fehlt.

Die Transformationen 1 → 2 und 2 → 3 werden auf den dekodierten Daten implementiert. Nach dem ersten Schritt ist zu prüfen, dass die Währung weiterhin 125 beträgt; nach dem zweiten Schritt sind der Standardwert zu prüfen und der gesamte unabhängige Fortschritt zu erhalten. Die gespeicherte Version wird erst hochgesetzt, nachdem die jeweilige Transformation erfolgreich war. Ein Spielstand der Version 3 darf nicht allein deshalb eine zusätzliche Gutschrift erhalten, weil er erneut geladen wird.

Ist ein Spielstand der Version 5 neuer, als der Loader unterstützt, ist er unverändert aufzubewahren und die Inkompatibilität zu melden. Würde seine Bedeutung erraten und er mit Version 3 überschrieben, würde aus einem vorübergehenden Kompatibilitätsproblem ein Datenverlust.

Ablauf von Migration und Wiederherstellung

Für jedes unterstützte historische Schema sind unveränderliche Fixtures vorzuhalten, einschliesslich fehlender optionaler Felder und Grenzwerte. Vor dem Ersetzen der laufenden Spielwelt sind Datentypen, Wertebereiche, stabile Objektkennungen, benötigte Assets und Querverweise zu validieren. Wo praktikabel, wird der wiederhergestellte Zustand zunächst isoliert aufgebaut und erst nach der Validierung aktiviert.

Schema-Migration und Inhaltsabbildung (Content Remapping) sind getrennt zu behandeln: Für einen aus dem Spiel entfernten Gegenstand braucht es eine dokumentierte Ersatz- oder Entschädigungsregel, nicht bloss ein umbenanntes Feld. Fehlermeldungen sollen handlungsleitend sein, und der bisherige brauchbare Spielstand bleibt erhalten, bis der Ersatz verifiziert ist.

Festschreiben und Fehlergrenzen

Bei SQLite-basierten Spielständen werden Daten und Schema-Version in einer einzigen Transaktion festgeschrieben; die Dokumentation zum atomaren Commit erläutert sowohl den Mechanismus als auch die Annahmen über den Speicher. [3] Bei Dateispeicherung wird ein vollständiger Ersatz zunächst bereitgestellt und anschliessend mit den von der Plattform unterstützten Operationen für atomares Ersetzen und Dauerhaftigkeit eingesetzt. Ein Rename allein ist keine allgemeingültige Garantie gegen Stromausfall.

Getestet werden sollten unterbrochene Schreibvorgänge, voller Speicher, beschädigte Eingaben und fehlgeschlagene Migrationen. Eine Prüfsumme kann zufällige Beschädigung erkennen, belegt aber keine gültige Spielsemantik. Auswahl und Wiederherstellung von Backups sind explizit zu definieren, und Erfolg darf erst gemeldet werden, wenn die gewählte Persistenzoperation erfolgreich abgeschlossen ist.

Quellen

[1] Saving games — Godot Engine documentation.

[2] Proto3 language guide — Protocol Buffers documentation.

[3] Atomic commit — SQLite developers.