Server und Cloud-Save
Lokaler Spielstand, Geräteidentität und Nakama-Spiegelung – mit Grenzen für Gerätewechsel, Konflikte und automatische Wiederherstellung.
Dein Spielstand wird zuerst lokal gespeichert. Eine vorbereitete Nakama-Anbindung kann einen gespeicherten Stand auf den Server spiegeln. Der vorhandene Cloud-Code ist jedoch kein vollständiger Gerätewechsel- oder Wiederherstellungsablauf.
Online-Funktionen: standardmäßig nicht aktiv
BackendFlags aktiviert das Backend nur bei PHONEMON_MULTIPLAYER=1 oder true beziehungsweise einem Testoverride. Ohne Aktivierung verwendet die Laufzeit lokale Dienste und deaktivierten Cloud-Sync. Diese Dokumentation bestätigt weder einen erreichbaren Produktionsserver noch ein veröffentlichtes Login-Menü.
Was wird wo gespeichert?
| Bestandteil | Lokaler Betrieb | Aktiviertes Nakama-Backend |
|---|---|---|
| Spielstand | Lokale Datei ist maßgeblich | Lokale Datei bleibt maßgeblich; Spiegelung ist zusätzlich möglich |
| Geräteidentität | Separate phonemon-account.json | Lokale ID dient als Geräteanmeldedaten für Nakama |
| Gildenaktionen | Lokaler Dienst beziehungsweise Fallback | RPC-Aufrufe mit serverseitiger Regelprüfung |
| Cloud-Save | Deaktivierter Dienst | Upload und Remote-Leseadapter vorhanden |
| Automatische Remote-Wiederherstellung | Kein Cloud-Ablauf | Im Spiegeladapter nicht implementiert |
| Konfliktzusammenführung | Keine Mehrgeräte-Zusammenführung | Keine Versionskonfliktlösung im geprüften Adapter |
Buddy-/Care-Spielstand und Abenteuerfortschritt haben unterschiedliche Speicherschichten. Der automatische Upload in PhonemonGame.SaveNow spiegelt dessen Save.SavePath. Er belegt nicht, dass jede separate Abenteuerdatei oder jede Championänderung automatisch in derselben Cloud-Datei enthalten ist. Ein zukünftiger vollständiger Cloud-Ablauf muss diese Abdeckung ausdrücklich prüfen.
Lokales Speichern und Rückfallkopien
SaveFileStore verwendet drei Dateikandidaten: die Hauptdatei, eine temporäre .tmp und die vorherige Generation .bak. Beim Speichern wird zuerst die temporäre Datei geschrieben und auf den Datenträger geflusht, dann die vorhandene Hauptdatei als Backup kopiert und schließlich die neue Datei an deren Stelle bewegt.
| Ladereihenfolge | Bedeutung |
|---|---|
1. Vollständige .tmp | Neuester beabsichtigter Stand nach unterbrochenem Schreibvorgang |
| 2. Hauptdatei | Regulärer gespeicherter Stand |
3. .bak | Vorherige Generation |
Die aufrufende Speicherschicht validiert die Kandidaten. Ein lesbarer Text ist noch kein gültiger Spielstand. Eine erfolgreiche Wiederherstellung kann die Hauptdatei reparieren, damit der nächste Start wieder den regulären Pfad verwendet. Die Mechanik setzt einen Schreiber für das Speicherverzeichnis voraus; sie ist keine Zusammenführung paralleler Geräte.
Konto und Identität
Im lokalen Betrieb erstellt LocalDeviceAccountService eine stabile Geräte-ID und schreibt sie separat neben den Spielstand. Ein regulärer Spielstandreset soll damit nicht automatisch eine neue Identität erzeugen. Die ID ist kein Passwort, kein frei auswählbarer Spielername und kein universeller Wiederherstellungscode.
Mit aktiviertem Nakama authentifiziert sich der Adapter über diese lokale Geräte-ID. Eine abgelaufene Sitzung wird beim nächsten benötigten Zugriff erneut authentifiziert. Abmelden verwirft die Sitzung im Speicher, nicht automatisch die persistierte Geräteidentität.
Der Nakama-Adapter enthält einen LinkAppleAsync-Aufruf für ein bereits erhaltenes Apple-Identitätstoken. Der lokale Adapter lehnt diese Verknüpfung ab. Eine vollständige sichtbare Apple-Anmeldung einschließlich Tokengewinnung und Gerätewechsel ist dadurch nicht belegt und bleibt als Nutzerablauf in Entwicklung.
Upload: lokal zum Server
Nach einem erfolgreichen Care-Speichern prüft PhonemonGame.SaveNow, ob Cloud-Sync aktiviert ist. Dann startet ein asynchroner Upload. Der Adapter liest den Text der gespeicherten Datei und schreibt ihn in Nakama-Storage:
Collection: phonemon
Key: save
Lesen: nur Eigentümer
Schreiben: nur EigentümerEin erfolgreicher Upload liefert eine Serverversionskennung zurück. Eine fehlende oder leere lokale Datei und fehlgeschlagene Netzwerk- oder Serveraufrufe führen zu einem Fehlerbeleg. Die aufrufende Schicht protokolliert Fehler; sie ersetzt deswegen nicht den lokalen Stand.
Lokal gespeichert und Cloud-Upload bestätigt sind zwei verschiedene Ergebnisse. Ein erfolgreiches lokales Speichern bedeutet nicht, dass der Upload bereits fertig ist. Die hier untersuchte Implementierung belegt keine dauerhafte Warteschlange oder garantierte Offline-Nachlieferung.
Download und Konflikte: in Entwicklung
FetchRemoteAsync kann den Remote-Text samt Version, Eigentümer und Zeitstempel lesen. Existiert kein Remote-Objekt, liefert der Adapter keinen Spiegel zurück. Er schreibt den Text nicht in die lokale Spielstanddatei.
Für Uploads wird keine erwartete Remote-Version als Vorbedingung mitgegeben. Die zurückgelieferte Versionskennung ist daher kein eingebauter Konfliktschutz. Es gibt im geprüften Adapter keinen Dialog zur Auswahl zweier Stände, keine Fortschrittszusammenführung und keine nachgewiesene automatische Anmeldung desselben Kontos auf einem zweiten Gerät.
Daraus folgt für Nutzer: Ein gespeicherter Server-Spiegel allein ist noch keine zugesicherte Wiederherstellung nach Neuinstallation. Der aktuelle Ablauf wird nicht als plattformübergreifender Cloud-Save beworben.
Wiederherstellung und sinnvolle Fehlersuche
- Unterscheide lokale Speicherfehler von Uploadfehlern: Ein Netzwerkfehler kann bei weiterhin vorhandenem lokalen Stand auftreten.
- Halte bei einem konkreten Supportfall Plattform, Version, Zeitpunkt und die betroffene Funktion fest. Ein fehlender Gildenaufruf und ein fehlender Abenteuerstand sind unterschiedliche Fälle.
- Lösche lokale Daten nicht in der Erwartung, der vorbereitete Cloud-Adapter werde sie automatisch zurückladen.
- Plane Gerätewechsel erst mit einem tatsächlich freigegebenen Konto- und Wiederherstellungsablauf; der Code für eine Adaptermethode ist kein fertiger Nutzerfluss.
Weiterlesen: Gilde, Arena, Economy und Währungen und Shop und IAP.
Quellen und Datenstand
Quellrevision: 8a040ffc3170. Zahlen aus dem separat synchronisierten System-Snapshot; Codepfade manuell geprüft am 7. Oktober 2026. Das ist ein Quellstand, keine Produktions- oder Geräteabnahme.