Durch die Verwendung dauerhafter Daten kannst du zwischen Spielsitzungen Daten pro Spieler nachverfolgen und speichern. Das eröffnet dir eine Vielzahl fortlaufender Spielmodi, bei denen Spieler das Spiel verlassen und zurückkehren können, um ihre Ziele weiter zu verfolgen oder den gleichen Spielstatus wie beim Verlassen vorzufinden.
Für dauerhafte Daten werden Daten wie das Profil oder Statistiken in Verse für jeden einzelnen Spieler gespeichert. Diese Daten können dann jedes Mal aktualisiert werden, wenn sich der Wert der Daten ändert. Da diese Daten dauerhaft sind, bleiben sie über Spielsitzungen hinweg erhalten und sind jedes Mal verfügbar, wenn sich der Spieler online im Spiel befindet.
Überleben, Tycoon, RPG und Roguelites sind einige Beispiele für Spielmodi, die dauerhafte Daten nutzen. Bei dieser Art von Spielmodi müssen die Spieler Gegenstände sammeln, um langfristige Ziele zu erreichen, die das Spielgeschehen bestimmen.
Nutze dauerhafte Daten in deinen Verse-Scripts, um Informationen zu speichern, die pro Spieler und pro Modul gespeichert werden. Implementiere dauerhafte Daten in Spielmodi dort, wo du Spieler halten möchtest, indem du beständigen Fortschritt belohnst.
Sieh dir das Tutorial zu dauerhaften Spielerstatistiken an, um die Implementierung dieser dauerhaften Daten selbst zu üben.
Dauerhafte Daten können in Verse erstellt und verwendet werden, aber es gibt auch Kreativmodus-Geräte, die über grundlegende Funktionalität verfügen, die dauerhafte Daten unterstützen. Weitere Informationen findest du unter Fortbestand-Geräte.
Was dauerhafte Daten in Verse bedeuten
In Verse ist eine in einem Modul definierte Variable global für alle laufenden Spiel-Instanzen, bei denen die Variable im Geltungsbereich liegt. Mit Ausnahme der modulbereichsbezogenen Variablen, die mit der Sitzung assoziiert sind, erfordert eine modulbereichsbezogene Variable Persistenz, also das Speichern der Daten über das aktuelle Spiel hinaus. Daher gibt es Beschränkungen dahingehend, welche Typen im Modulbereich verwendet werden können.
Derzeit kannst du die folgenden Typen im Modulbereich verwenden:
| Erlaubte modulbereichsbezogene Typen | Definition | Einschränkungen |
|---|---|---|
| Daten jeden Typs, der durch | Daten werden nur während der aktuellen Sitzung gespeichert und bleiben nicht über nachfolgende Runden hinweg bestehen. |
| Daten jeden Typs, der durch | Der Zugriff auf die dauerhaften Daten des Spielers ist nur erlaubt, wenn sich der Spieler im aktuellen Spiel befindet. |
Wenn ein Spieler ein Spiel verlässt oder sich nicht in der aktuellen Sitzung befindet, kannst du seine Daten in dieser Spielsitzung nicht mehr speichern oder darauf zugreifen. Wenn der Spieler zurückkehrt oder das gleiche Spiel erneut spielt, kannst du auf seine Daten zugreifen und sie aktualisieren.
Erstellen dauerhafter Daten in Verse
Du kannst deine eigenen dauerhaften Daten für jeden Spieler erstellen, die fortlaufend aktualisiert, gespeichert und wieder aufgerufen werden können, wenn ein Spieler dem Spiel wieder beitritt. Während der Spielersuche prüft das Spiel auf dauerhafte Daten für den neuen Spieler. Wenn der Spieler über dauerhafte Daten verfügt, werden die Daten geladen und für Verse-Scripts verfügbar gemacht.
Wenn der Spieler über dauerhafte Daten für eine Insel verfügt und das Laden der Daten fehlschlägt, kann der Spieler der Insel nicht beitreten. Das ist eine Schutzmaßnahme, die verhindert, dass dauerhafte Daten im Fall eines Datenladefehlers überschrieben werden.
Um dauerhafte Daten in deinem Verse-Code zu erstellen, definierst du eine globale weak_map-Variable, die den Spielertyp als Schlüssel und einen dauerhaften Typ als Wert verwendet. Eine vollständige Liste der Typen, die dauerhaft sein können, findest du unter Dauerhafte Typen.
In dem folgenden Beispiel verwendet die globale „weak_map“-Variable MySavedPlayerData den Spielertyp als Schlüssel und eine Ganzzahl als Wert. Das Speichern eines Ganzzahlwerts für einen Spieler in dieser Variable bedeutet, dass die Daten über Spielsitzungen hinweg bestehen bleiben und jederzeit aufgerufen und aktualisiert werden können, wenn sich der Spieler im Spiel befindet.
var MySavedPlayerData:weak_map(player, int) = map{}
Wenn du deine dauerhaften Daten definiert hast, musst du die Daten für jeden Spieler initialisieren. Dazu kannst du prüfen, ob es bereits gespeicherte Daten für diesen Spieler gibt, und dann den Spieler und einen Anfangswert zu weak_map hinzufügen.
# Runs when the device is started in a running game
OnBegin<override>()<suspends>:void =
InitialSavedPlayerData:int = 0
Players := GetPlayspace().GetPlayers()
for (Player : Players):
if:
not MySavedPlayerData[Player]
set MySavedPlayerData[Player] = InitialSavedPlayerDataDas vorherige Beispiel hat nur einen Ganzzahlwert gespeichert, aber du kannst auch andere Typen verwenden, wie Klassen und Arrays, um weitere Daten für jeden Spieler in weak_map zu speichern. Eine vollständige Liste der Typen, die du verwenden kannst, findest du unter Dauerhafte Typen.
Das folgende Verse-Beispiel zeigt, wie du ein benutzerdefiniertes Spielerprofil in einer Klasse definieren kannst, das gespeichert, aktualisiert und später für einen Spieler aufgerufen werden kann. Die Klasse player_profile_data speichert Informationen für einen Spieler, wie die verdienten EP, seinen Rang und die Aufträge, die er abgeschlossen hat.
player_profile_data := class<final><persistable>:
Version:int = 0
Class:player_class = player_class.Villager
XP:int = 0
Rank:int = 0
CompletedQuestCount:int = 0
QuestHistory:[]string = array{}
var PlayerProfileDataMap:weak_map(player, player_profile_data) = map{}Der Umfang der Daten, die du pro Spieler und Insel speichern kannst, ist begrenzt. Wenn du Daten speicherst, solltest du prüfen, wie deine Aktualisierungen sich auf die Gesamtgröße auswirken, indem du die Funktion 'FitsInPlayerMap' verwendest. Ausführliche Informationen findest du unter Testing Persistent Data Is Within Limits.
Da du nun weißt, wie du deine eigenen dauerhaften Daten erstellst und sie für jeden Spieler initialisierst, solltest du dir die Best Practices ansehen. Dort findest du empfohlene Methoden für die Arbeit mit dauerhaften Daten in Verse.
Ändern der Daten zwischen veröffentlichten Versionen deiner Insel
Nachdem du die aktuelle Version deiner Insel veröffentlicht hast, müssen alle aus einer vorherigen Version der Insel gespeicherten Daten in späteren Versionen der Insel unterstützt werden, wenn du Aktualisierungen an den dauerhaften Daten vornimmst.
Um das sicherzustellen, wird in UEFN eine Prüfung zur Abwärtskompatibilität durchgeführt. Wenn der Verse-Code nicht mehr mit der aktuell veröffentlichten Version kompatibel ist, kommt es zu einem Kompilierungsfehler. Diese Abwärtskompatibilität-Prüfung wird immer in folgenden Fällen ausgeführt:
Klicke in der UEFN-Werkzeugleiste auf Sitzung starten.
Klicke in der UEFN-Werkzeugleiste auf Änderungen pushen oder Verse-Änderungen pushen.
Veröffentlichen deiner Insel zum ersten Mal.
Aktivieren einer neuen öffentlichen Version deiner Insel.
Diese Abwärtskompatibilitätsprüfung ist im Wesentlichen eine Typprüfung des Werttyps der modulbezogenen weak_map-Variable. Bei einfachen Typen wie Ganzzahlen kann der Typ nach der Veröffentlichung der Insel nicht geändert werden. Dazu gehören structs, bei denen du die Strukturdefinition nach der Veröffentlichung der Insel nicht ändern kannst.
Derzeit ist der einzige dauerhafte Typ, dem du nach der Veröffentlichung deiner Insel weitere Daten hinzufügen kannst, der Typ Klasse, solange neue Felder über Standardwerte verfügen. Das bedeutet, dass das Laden gespeicherter Daten aus einer vorherigen Version die neuen Felder und ihre Standardwerte umfasst. Weitere Details zur Verwendung von Klassen als dauerhafte Daten findest du in den Best Parctices.
Zurücksetzen dauerhafter Daten für deine Insel
Wenn du einmal ein Zurücksetzen der dauerhaften Daten für deine Insel erzwingen musst, kannst du dazu in Verse einen Standardwert für die dauerhaften Daten in weak_map für den Spieler zuweisen, wenn er der Insel beitritt.
Um zu wissen, ob die Daten des Spielers bereits zurückgesetzt wurden, kannst du einen Versionswert für deine Klasse aufnehmen und ihn als Teil deiner dauerhaften Daten mit den neuen Änderungen aktualisieren. Das ist eine der unten aufgeführten Best Practices. Sieh dir also unbedingt auch die anderen an!
Dauerhafte Typen in Verse
Im Folgenden findest du die dauerhaften Typen, die du in deiner modulbereichsbezogenen weak_map-Variable verwenden kannst:
| Typ | Beschreibung |
|---|---|
Array | Ein Array ist dauerhaft, wenn der Typ der Elemente im Array dauerhaft ist. |
char32 | Zeichenwerte sind dauerhaft. |
char8 | Zeichenwerte sind dauerhaft. |
class | Eine Klasse ist in den folgenden Fällen dauerhaft:
|
Farbwerte sind dauerhaft. | |
enum | Enum ist dauerhaft, wenn sie mit dem Bezeichner „persistable“ definiert wurde. |
float | Fließkomma-Werte sind dauerhaft. |
int | Ganzzahlwerte sind dauerhaft. |
logic | Logikwerte sind dauerhaft. |
map | Eine Karte ist dauerhaft, wenn sowohl der Schlüssel als auch die Werttypen dauerhaft sind. |
option | Eine Option ist dauerhaft, wenn ihr Wert dauerhaft ist. |
struct | Eine Struktur ist in den folgenden Fällen dauerhaft:
Du kannst eine dauerhafte Struktur nicht verändern, sobald du deine Insel veröffentlicht hast. Aus diesem Grund empfehlen wir die Verwendung dauerhafter Strukturen nur, wenn sicher ist, dass das Schema konstant bleiben wird. Tupel |
tuple | Ein Tupel ist dauerhaft, wenn jeder Elementtyp dauerhaft ist. |
Vector2-Werte sind dauerhaft. | |
Vector2i-Werte sind dauerhaft. | |
Vector3-Werte sind dauerhaft. |
Testen mit dauerhaften Daten
Wenn du das Verhalten dauerhafter Daten vor der Veröffentlichung der neuesten Version deiner Insel testen möchtest, kannst du das folgende Verhalten in deinem Inseleinstellungen-Gerät sowohl für die Einstellung Persistenzverhalten: Spieltestsitzung als auch in der Einstellung Persistenzverhalten: Bearbeitungssitzung festlegen:
| Verhalten dauerhafter Daten | Beschreibung |
|---|---|
Aus Live importieren | Sitzungsdaten aus Live-Daten importieren, wenn Live-Daten verfügbar sind. Das macht es erforderlich, dass die Insel live veröffentlicht wurde und dass der Spieler in der Live-Version der Insel gespielt hat. Wenn Live-Daten verfügbar sind, werden die Spieltest-Sitzungsdaten mit einer Kopie der Live-Daten als Seed versehen. Das kann beim Testen von Probleme mit dauerhaften Daten sehr nützlich sein, die mit Änderungen an deiner Insellogik in Verbindung stehen. |
Neuen Nutzer simulieren | Startet den Spieler mit neuen dauerhaften Daten, als ob er die Insel zum ersten Mal spielt. |
Das Verhalten Aus Live importieren und Neuen Nutzer simulieren funktioniert sowohl für die Verse-Persistenz als auch für Persistenz-Geräte wie das Speicherpunkt- und das Tracker-Gerät. Neuen Nutzer simulieren führt die Sitzung mit leeren Daten für die Verse-Persistenz als auch die Fortbestand-Geräte aus, ohne Live-Daten zu ändern. Aus Live importieren lädt die dauerhaften Daten aus beiden, wenn Live-Daten verfügbar sind.
Bei deinem Spieltest werden Einstellungen für das Verhalten der Persistenzdaten angewendet. Es gibt zwei verschiedene Szenarien, in denen du Tests mit dauerhaften Daten durchführen kannst:
Bearbeitungssitzung: Einstellungen für das Verhalten der Persistenzdaten werden angewendet, wenn du eine Sitzung über UEFN startest. Das bedeutet, dass dauerhafte Daten über mehrere Spiele innerhalb einer einzelnen Sitzung hinweg fortbestehen können. Wenn du die Sitzung verlässt und eine neue Sitzung startest, werden die Persistenzdaten zurückgesetzt und die Einstellungen für das Verhalten der Persistenzdaten werden wieder übernommen.
Spieltest-Sitzung: Die Einstellungen für das Verhalten der Persistenzdaten werden angewendet, wenn du einen Spieltest im Creator-Portal einrichtest und ein Spieltester entweder über einen Spieltestcode oder einen privaten Link-Code beitritt. Die Einstellungen für das Verhalten der Persistenzdaten werden nur beim ersten Beitritt des Spielers angewendet. Wenn der Spieler den Spieltest verlässt und ihm erneut beitritt, bleiben seine Daten die Sitzungen übergreifend erhalten und die Einstellungen für das Verhalten der Persistenzdaten werden nicht erneut angewendet. Um die dauerhaften Daten zurückzusetzen, musst du einen neuen Spieltest-Link-Code erstellen.
Bei Inselaktualisierungen, die sich darauf auswirken, wie dauerhafte Daten verwaltet und aktualisiert werden, solltest du beide Szenarien testen, sowohl mit dem Start einer Sitzung über UEFN als auch mit einem Spieltest, der einen Link-Code verwendet. Achte darauf, dass du Änderungen, die du an den dauerhaften Daten vornimmst, sowohl mit Live-Daten als auch mit simulierten neuen Benutzerdaten testest. So kannst du sicherstellen, dass deine Aktualisierungen sowohl für aktuelle Spieler deiner Insel als auch für neue Spieler funktionieren.
Effekte der Veröffentlichung neuer Versionen deiner Insel
Sobald deine Insel veröffentlicht wurde, wird ein dauerhafter Datensatz für Spieler erstellt, wenn ihre Daten in weak_map gespeichert werden. Diese Daten werden dann gespeichert und bei jedem nachfolgenden Besuch deiner Insel geladen.
Wenn neue Versionen deiner Insel veröffentlicht werden, werden dauerhafte Daten automatisch in der neuen Version zusammengeführt. Weitere Informationen findest du unter Ändern der Daten zwischen veröffentlichten Versionen deiner Insel.
Effekte des Zurücksetzens deiner veröffentlichten Insel
Wenn du über das Creator-Portal deine Insel auf eine vorherige Version zurücksetzt, werden die dauerhaften Daten für alle Nutzer zurückgesetzt.
Es gibt derzeit keine Unterstützung für die Benachrichtigung der Spieler darüber, dass ihre Daten von einem Rollback betroffen sind.
Das führt dazu, dass kürzlich vorgenommene Aktualisierungen der Spielerdaten verloren gehen. Möglicherweise werden Spielerdaten auch vollständig zurückgesetzt. Das trifft selbst dann zu, wenn der Rollback keine internen Änderungen der Logik umfasst, die sich auf die dauerhaften Daten auswirken würden.
Aufgrund der Auswirkungen auf dauerhafte Daten empfehlen wir, die Rollback-Funktion nur als letzten Ausweg zu nutzen.
Einschränkungen
Im Folgenden findest du Beschränkungen für die Arbeit mit dauerhaften Daten in Verse.
Maximale Größe von dauerhaften Objekten
Die Daten, die pro Spieler in einer weak_map gespeichert werden können, sind begrenzt.
Ein weak_map-Datensatz ist die Datengesamtmenge, die mit einem einzelnen weak_map-Element assoziiert ist. Ein einzelner weak_map-Datensatz hat eine maximale Datengröße von 256 Kilobyte (kB) pro Spieler.
Wenn ein 'weak_map'-Wert gespeichert wird, wird die Speichergesamtmenge berechnet, die für die Speicherung der Daten erforderlich ist.
Im Folgenden findest du einige Beispiele für Daten, welche die Beschränkung von 256 kB sprengen würden:
Ungefähr 24.000
float- oderint-Werte.Ungefähr 200.000 Zeichen Text. Das entspricht ungefähr 60 Seiten Text in einem durchschnittlichen Roman.
Wenn du versuchst, Daten für einen Spielerdatensatz zu speichern, die größer als 256 kB sind, schlägt der Speichervorgang fehl und es wird ein Verse-Laufzeitfehler erzeugt.
Mit der Verse-Helferfunktion FitsInPlayerMap kannst du Speicherfehler vermeiden. Die Funktion FitsInPlayerMap nimmt eine Kopie des Datensatzes, den du speichern möchtest, und prüft seine Größe. Wenn der Datensatz gespeichert werden kann, ist der Funktionsaufruf erfolgreich. Andernfalls (wenn der Datensatz zu groß ist) schlägt er fehl.
Die Funktion FitsInPlayerMap ist besonders praktisch, wenn du mit einem dynamischen Array oder einer Map mit Daten arbeitest und ihnen neue Elemente hinzufügst. Die Aktualisierung eines int, float oder logic, das zuvor in dem dauerhaften Datensatz enthalten war, ändert nicht die Größe des dauerhaften Datensatzes.
Maximale dauerhafte schwache Maps der Spieler pro Insel
Eine einzelne Insel kann bis zu vier dauerhafte Variablen haben, d. h. vier weak_map-Variablen mit player als Schlüsseltyp. Diese Anforderung wird vom Verse-Compiler durchgesetzt.
Erforderliche schwache Map mit Klassen-Typ
Mindestens ein weak_map-Wert der dauerhaften Variable muss eine Klasse sein, wenn die Grenze für die maximalen dauerhaften Variablen erreicht wurde. Damit soll sichergestellt werden, dass den Variablen später weitere Daten hinzugefügt werden können, während gleichzeitig die Abwärtskompatibilität nachfolgender Inselveröffentlichungen sichergestellt wird.