Spieler kehren für die nächste Episode mit gewählten Routen, freigeschalteten Szenen und investierter Zeit zurück. Behandeln Sie die Kompatibilität von Spielständen als eine Funktion, die Sie bei jeder Veröffentlichung pflegen. Das Umbenennen von Zustandselementen, das Entfernen von Szenen oder Änderungen an serialisierten Objekten können alte Spielstände unbrauchbar machen, selbst wenn ein neuer Spieldurchlauf korrekt funktioniert.
Die Speichersysteme der Engines unterscheiden sich. Ziehen Sie die Referenz für Ihre genaue Engine-Version heran und dokumentieren Sie die beteiligten Versionen. Nutzen Sie diesen Leitfaden, um Ihr Kompatibilitätsversprechen festzulegen und zu testen; gehen Sie nicht davon aus, dass ein universelles Migrationsskript jedes Engine-Update kompatibel machen kann.
Den Kompatibilitätsvertrag festlegen
Entscheiden Sie, welche veröffentlichten Versionen der nächste Build unterstützen wird, bevor Sie den Zustand ändern, den er speichert. Legen Sie ausdrückliche Regeln für gewöhnliche Spielstände, dauerhaft gespeicherte Freischaltungen, Einstellungen und exportierte Browser-Spielstände fest; diese Kategorien können unterschiedlich behandelt werden müssen. Informieren Sie Spieler im Voraus, wenn ein Neubeginn erforderlich sein könnte.
Bewahren Sie eine Release-Kennung auf und, wenn Sie das Speicherformat kontrollieren, eine Schemaversion. Trennen Sie den Fortschritt in den Inhalten von Darstellungseinstellungen und abgeleiteten Daten. Dokumentieren Sie vor der Änderung eines persistenten Feldes seine Bedeutung und seinen Standardwert.
Stabile Kennungen bevorzugen
Geben Sie Routen und Szenen stabile Kennungen, die Überarbeitungen und Übersetzungen überstehen. Behalten Sie diese Kennungen so lange unverändert bei, wie Sie Kompatibilität versprechen. Muss sich eine Kennung ändern, planen Sie eine Migration oder kennzeichnen Sie klar die Grenze, ab der ältere Spielstände nicht mehr unterstützt werden.
Wenn Sie ein eigenes Speicherformat verwalten, speichern Sie einfache Daten, dokumentieren Sie das Schema und validieren Sie eingehende Daten, bevor Sie sie verwenden. Engine-eigene Spielstände können anderen Serialisierungsregeln folgen. Beachten Sie die Empfehlungen der Engine, bevor Sie eine zuverlässige Speicherfunktion durch einen selbst geschriebenen Serialisierer ersetzen.
Eine Migration vor Zustandsänderungen planen
Schreiben Sie den Migrationsplan, bevor Sie ein Feld ändern: das alte Feld, das neue Feld, die Umwandlungsregel und die Ausweichlösung für fehlende oder unerwartete Daten. Gestalten Sie Migrationen deterministisch und wiederholbar, soweit das Format es erlaubt. Ein fehlendes, nicht damit zusammenhängendes Feld darf niemals Fortschritt gewähren.
Befolgen Sie bei Ren'Py die Hinweise zum Speichern und Rollback sowie die Kompatibilitätshinweise für Ihre Versionen. Prüfen Sie bei SugarCube die genaue Formatversion und die Speicher-APIs. Implementieren und testen Sie für einen eigenen Zustand in Godot das Schema, das Sie selbst verwalten. Eine Regel, die in einem System funktioniert, lässt sich möglicherweise nicht auf ein anderes übertragen.
Eine repräsentative Spielstandsammlung pflegen
Erstellen Sie eine Spielstandsammlung, die den Anfang, Stellen unmittelbar vor wichtigen Entscheidungen, jede Hauptroute und den Abschnitt vor dem Ende abdeckt. Nehmen Sie unterschiedliche Freischaltungen, Einstellungen und ältere Versionen auf, die Sie noch unterstützen. Verwenden Sie anonymisierte Entwicklungszustände und vermeiden Sie es, Spielerdaten zu sammeln, die Sie nicht benötigen.
Testen Sie mit Kopien und lassen Sie die Originale unverändert. Dokumentieren Sie, aus welchem Release jeder Spielstand stammt und welchen Zustand Sie nach dem Laden erwarten. Laden ohne Ausnahmefehler ist nur die erste Prüfung: Ein Spielstand kann einen Spieler trotzdem auf die falsche Route führen, eine Belohnung verdoppeln oder eine Einstellung verlieren.
Ein tatsächliches Update testen
Testen Sie den fertig gepackten Build über den Update-Pfad, den die Spieler tatsächlich nutzen werden: Installieren Sie ihn oder stellen Sie ihn je nach Bedarf über einen Server bereit. Laden Sie einen alten Spielstand, spielen Sie eine aussagekräftige Szene weiter, speichern Sie erneut und laden Sie den Spielstand wieder. Prüfen Sie persistenten Fortschritt und Einstellungen getrennt.
Prüfen Sie bei Browser-Builds die Origin, das Speicherverhalten und den Hosting-Kontext bei Einbettung. Eine Änderung der URL oder des Speicherkontexts kann den Zugriff auf vorhandene Daten beeinflussen, selbst wenn die Spiellogik unverändert bleibt. Wenn Sie Export und Import anbieten, überprüfen Sie diesen Wiederherstellungsweg und erläutern Sie seine Grenzen.
Klare Informationen zur Wiederherstellung veröffentlichen
Veröffentlichen Sie den unterstützten Update-Pfad, die Sicherungsmethode und bekannte Kompatibilitätsgrenzen dort, wo Spieler sie finden können. Lassen Sie das Formular für Fehlerberichte nützliche Versionsangaben abfragen. Wenn ein Release eine Kategorie von Spielständen nicht sicher erhalten kann, erläutern Sie diese Grenze, bevor ein Spieler seine letzte funktionierende Kopie überschreibt.
Archivieren Sie den getesteten Build, die Schemanotizen und die Spielstandsmatrix zusammen mit jedem Release. Halten Sie Migrationsentscheidungen mit den Revisionen des Quellcodes verknüpft. Regelmäßige Kompatibilitätsprüfungen erleichtern die Pflege und geben Ihnen die Möglichkeit, Fehler vor den Spielern zu entdecken.
Wichtige Entscheidungen
- Benennen Sie die unterstützten Releases und legen Sie Regeln für jede Spielstandskategorie fest.
- Behalten Sie stabile IDs bei und dokumentieren Sie die Bedeutung und den Standardwert jedes Feldes.
- Prüfen Sie nach der Migration den Fortschritt, speichern Sie dann und laden Sie erneut.
- Schützen Sie die ursprünglichen Spielstände und erklären Sie Spielern, wie sie sie wiederherstellen können.
Dateien zum Leitfaden
Testmatrix ↓Externe Modell-Communitys und Veröffentlichungsseiten können explizite Inhalte enthalten. Links zu den Quellen öffnen sich in einem neuen Tab; dieser Leitfaden lädt deren Vorschauen nicht.
Quellen und weiterführende Lektüre +
- Ren'Py-Referenz zum Speichern und Rollback ↗
- Inkompatible Änderungen in Ren'Py ↗
- Spiele speichern mit Godot ↗
- SugarCube-Referenz ↗
Zuletzt geprüft 5. Oktober 2026.