XML oder PlayerPrefs für Savegames?

Neulich kam im Support-Forum meines C#-Unity-Kurses die Frage auf, warum wir im Kurs den Spielstand in XML-Dateien und nicht in Unitys PlayerPrefs speichern. Dem Teilnehmer erschien die Serialisierung nach XML sehr viel aufwändiger und außerdem wäre die Schutzstufe des textuellen XML-Formats sehr niedrig, da jeder, also auch Spieler, die Datei verändern könnten.

Weshalb wir im Kurs PlayerPrefs nicht verwenden

PlayerPrefs sind in ihrer Struktur sehr begrenzt und eigenen sich nur zur Speicherung einzelner Werte (z.B. Float, Int, String). Komplexere Strukturen (fängt z.B. schon bei den häufig benutzten Typen Vector3 und Quaternion an, von eigenen Klassen ganz zu schweigen) sind nicht möglich. Im Verlauf des C#-Videokurses wechseln wir später von statischen Werten zu dynamischen Listen, so dass eine beliebige Anzahl von Objekten und Werten flexibel in das Savegame eingebunden werden kann. Das ist mit PlayerPrefs ebenso wenig möglich wie z.B. die Verwaltung mehrerer paralleler Spielstände. (Technisch ganz präzise: theoretisch zwar möglich, aber man müsste ein sehr aufwändiges Indizierungssystem selbst programmieren, das dann Listenfunktionen nachahmt.)

PlayerPrefs eigenen sich meiner Meinung nach deshalb eher im Sinne einer ‚Cookie‘-Logik, also für das schnelle und einfache Sichern und Laden von einzelnen Werten, wie z.B. Programmeinstellungen.

PlayerPrefs sind zudem schwer zu überprüfen und zu verwalten. Um eine Liste der gespeicherten Werte zu sehen, müsste man Tools schreiben oder in der Windows-Registry wühlen. Auf MacOS oder anderen Geräten wird es noch schwieriger, zumal sich auch die Speicherorte technisch noch unterscheiden. Insbesondere für einen eLearning-Kurs, bei dem die Nachvollziehbarkeit im Vordergrund stehen sollte, ist das denkbar ungüstig.

Weshalb wir hier XML verwenden

XML kann beliebige verschachtelte Strukturen ausdrücken und bleibt dabei lesbar und nachvollziehbar. Da ich davon ausgehe, dass viele Teilnehmer des Kurses verstehen wollen, wie die Technik funktioniert, eignet es sich daher hervorragend, um den Prozess zu erklären, weil transparent ist, welche Daten wie/wann/wohin fließen.

Mit solchen dateibasierten Serialisierungsformaten ist es sehr leicht möglich, Spielstände zu öffnen, anzusehen, zu speichern, weitere parallel dazu anzulegen und komplexe Strukturen in einem Zug zu speichern und zu löschen. Dass .net hierfür bereits Serialisierungsmechnismen zur Verfügung stellt, die die Umwandlung vom Arbeitsspeicher in XML und zurück übernehmen, macht die Sache noch viel einfacher.

Zu den Nachteilen von XML gehört ein gewisser Overhead an strukturgebenden Daten.

Werbung

Das Problem der Offenheit

Die Einsehbarkeit von XML kann natürlich unerwünscht sein, da nicht nur Entwickler, sondern auch jeder mit ein wenig technischer Sachkenntnis Veränderungen vornehmen kann. Eine Alternative wäre dabei die binäre Serialisierung, die im Prinzip ähnlich arbeitet, aber kein XML, sondern eine Binärdatei generiert. Diese ist nicht mehr so intuitiv zu verstehen.

Die „Sicherung“ von Dingen wie z.B. Savegames ist ein seit jeher kontrovers diskutiertes Thema. Meine persönliche Meinung ist (mittlerweile), dass es sich in den seltensten Fällen lohnt, viel Aufwand in Schutzmaßnahmen zu stecken. Insbesondere als kleines Team oder Einzelentwickler sollte man seine Schaffenskraft statt dessen lieber auf die Verbesserung der eigentlichen Spielinhalte konzentrieren, denn:

• PlayerPrefs sind genauso (wenn nicht sogar noch einfacher) zu manipulieren wie XML-Dateien, sie liegen nur an anderer Stelle.
• Binärformate können ebenso manipuliert werden, es erfordert nur mehr Sachkenntnis. Nicht ohne Grund gibt es seit es Spiele gibt auch Trainer und Cheat-Tools, die genau das machen. Einige dieser Tools greifen sogar auf den Arbeitsspeicher zu, so dass es egal ist, wie/wo das Savegame gespeichert wird.
• Anti-Cheats sind meiner Meinung sowieso nur bei Multiplayer oder irgend einer Form von Wettbewerb zwischen Spielern (z.B. Highscores) relevant und dann eigentlich nur durch Integration von Server-Komponenten absicherbar. Wenn ein Single-Player auf seinem Gerät durch Verändern des Savegames schummeln will – soll er doch. Warum ist das ein Problem – er betrügt nur sich selbst. 🙂
• Man kann Verschlüsselungen einsetzen, um die Lesbarkeit der Datei zu erschweren, aber auch das ist nicht vollkommen sicher, insbesondere da C#-Programme leicht zurück zu kompilieren und die Logik somit zu analysieren und replizieren ist. (Davon abgesehen kann es sein, dass man beim Einsatz von Verschlüsselungstechnik gegen die Exportregelungen der USA verstößt und damit das Produkt für amerikanische Plattformen wie Steam oder Google Play Store disqualifiziert.)
• … und sicher noch vieles mehr.

Zusammengefasst

Wir verwenden im Kurs XML, gerade weil es durch seine Lesbarkeit für Menschen sehr einfach manuell zu überprüfen ist und dabei eine große Flexibilität bietet. Zusätzlichen Aufwand durch Umsetzung der Objektserialisierung hat man nur am Anfang, später dreht es sich um und die Speicherung über PlayerPrefs wäre unter Umständen sogar sehr viel aufwändiger.