Sonstiges: Entwicklertagebuch - Der Weg zum eigenen Switch-Spiel
Michael Grönert, am 26.12.2016, Seite 8 von 25
BadToxic Discord-Server | GameMaster Discord-Server | BadToxic auf Twitter
BadToxic auf Instagram | BadToxics Entwickler-Instagram | BadToxic auf YouTube
Teil 8: Speichern & Laden
Nun, da wir erste Zustände im Spiel verändern können, wie z.B. die Positionen von Gegenständen in unserem Inventar, wird es Zeit, sich mit einem Speichersystem zu beschäftigen. Auch hier gibt es einige Aspekte, die vorher gut geplant werden sollten und andere, die man theoretisch sofort angehen kann. Man kennt verschiedenste Varianten von anderen Spielen. In manchen Spielen ist man darauf beschränkt, nur an bestimmten Orten oder nach gewissen Ereignissen speichern zu dürfen. In anderen kann man das Spiel nahezu jederzeit unterbrechen und speichern. Manche Spiele speichern ausschließlich automatisch, während man in anderen zusätzlich und in wieder anderen nur manuell speichern kann. Oft gibt es eine feste Anzahl an nutzbaren Speicherplätzen, wohingegen andere Spiele theoretisch unendlich viele Spielstände erlauben, soweit der verfügbare Speicherplatz dies zulässt. Für diese Unterschiede gibt es mehrere Gründe. Zum Einen sollte es in das Gesamtbild des Spiels passen und nicht etwa durch lange Wartezeiten die Stimmung verfälschen oder durch zu häufig mögliches Speichern den Schwierigkeitsgrad beeinflussen. Vor allem bei älterer Hardware sind es auch die technischen Aspekte, wie eine geringe Speicherkapazität, die solche Entscheidungen stark beeinflussen.
Integration in das Spiel
Ich möchte zunächst auf jeden Fall die Möglichkeit haben, auf Knopfdruck speichern zu können und sei es nur zu Testzwecken. Ob das Spiel später immer nur selbstständig speichern soll, würde ich davon abhängig machen, wie lange solch ein Prozess auf der jeweiligen Plattform benötigt. Bräuchte das Spiel nach jeder Aktion, die einen Zustand verändert, eine Sekunde oder länger, um dies zu speichern, würde es den Spielfluss zu stark beeinträchtigen. Aber vielleicht möchte ich auch, dass der Spieler sich nicht nach Belieben absichern und Fehlentscheidungen rückgängig machen kann. Das würde dafür sprechen, ihm gar keine Kontrolle über das System zu überlassen. Aber das möchte ich erst später entscheiden, um es besser auf den Rest abstimmen zu können. Alternativ habe ich die Idee, eine Art Tagebuch als Item im Inventar mit sich zu führen, mit dem man jederzeit speichern kann. Dabei sollte der Spieler so viel Freiheit haben, sich selbst dieses Gegenstandes entledigen zu können, wenn er das denn möchte.
Ich beginne also mit zwei kleinen Buttons, beschriftet mit „S“ und „L“, mit denen ich zu jeder Zeit, in der ich mich auf der Overworld-Map befinde, speichern und laden können soll. Fürs Erste möchte ich nur die Position meines Charakters und die Item-Verteilung in meinem Inventar sichern können. Als nächstes habe ich mir Gedanken über das Dateiformat gemacht, in dem ich den Spielstand speichern möchte. Es stehen sich leicht lesbare Formate wie XML oder JSON und für Menschen unlesbare, binäre Varianten gegenüber. Ersteres ist leicht zu verstehen und zu verändern - das lädt zum Cheaten ein. Zweiteres sind unlesbare Aneinanderreihungen von Einsen und Nullen, die deutlich weniger Platz beanspruchen, als ausgeschriebene Worte. Gerade auf Konsolen, bei denen der Platz eine größere Rolle spielt und man nur schwer an Speicherdateien kommt, um sie mit einem Texteditor zu durchsuchen, würde ich der Lesbarkeit keinen Gewinn anrechnen, aber dem Sparen von Speicherplatz um so mehr.
Was und wie speichern?
In bisherigen Projekten, habe ich die Spielstände immer manuell angelegt, also die Dateien mit eigenem Code beschrieben und von ihnen gelesen. Dabei muss darauf geachtet werden, dass alle Reihenfolgen immer gleich bleiben und alles vollständig ist oder damit umgegangen werden kann, wenn mal etwas fehlt. Mit Unity kann man sich das Leben einfacher machen, indem man serialisierbare Daten-Objekte erstellt, die dann automatisch gespeichert und geladen werden können (siehe Serialisierbarkeit auf Wikipedia). Zwar lassen sich diese nicht so einfach optimieren wie bei manuell angelegten Verfahren, aber sie vereinfachen und beschleunigen den Prozess erheblich. Während ich einem solchen serialisierbaren Objekt einfach eine neue Variable geben kann, die dann mitgespeichert wird, müsste ich bei einer manuellen Variante jede Variable einzeln in die Datei schreiben.
Also lege ich ein serialisierbares Objekt an, welches für jeden Wert, den ich speichern können möchte, eine Variable bekommt. So z.B. die X- und Y-Koordinaten meines Charakters, aber nicht Z, denn momentan können wir uns nur auf einer Ebene bewegen. Dies eignet sich auch bereits als Beispiel für den Optimierungs-Spielraum:
1. Ich lasse nicht benötigte Informationen wie die Z-Koordinate weg.
2. Wertebereich: Je nachdem, wie groß meine Welt werden kann, könnte man die Koordinaten begrenzen. So reichen ggf. kleinere Datentypen aus, für die dann auch weniger Platz reserviert werden muss. z.B. reicht ein sbyte für Zahlen von -128 bis +127 und short für -32,768 bis +32,767.
3. Genauigkeit: Eben genannte Datentypen können nur ganze Zahlen behalten. Ich werfe also Stellen nach dem Komma weg. Ich könnte den Wertebereich auch dehnen oder stauchen und anders „codieren“ - etwa vor dem Speichern einen Wert durch acht teilen und nach dem Laden wieder mit acht multiplizieren.
4. Alternativen suchen: Statt der Koordinaten könnte ich feste Orte nutzen, also vorgegebene Speicherpunkte, um mir so die großen Zahlen zu sparen. Ich müsste mir also nur noch den Ort merken, etwa in Form einer viel kleineren Zahl.
Zu den Koordinaten kommen noch die Items. Bei diesen ist es etwas komplizierter, da es theoretisch beliebig viele, auch mehrfach vorhandene Gegenstände und sogar Inventare geben können soll. Beispiele für weitere Inventare wären Truhen oder Items, die weitere Objekte aufnehmen können - etwa unser GameGuy. Fürs Erste beschränke ich mich auf das Inventar meines Charakters selbst, welches eine Liste von Items beliebiger Länge sein kann, und einer weiteren Ebene an Items - wie gesagt, für unseren GameGuy.
Abstraktionsebenen
Auch beim Speichern hat es Vorteile, Vererbung zu nutzen und zu abstrahieren. Zum einen gibt es Speicherdaten für das Hauptspiel selbst, wie die oben genannten. Daneben gibt es Daten für die Minispiele und darunter welche, die alle gemeinsam haben. Beispielsweise sollen alle Spiele über einen Level verfügen und folglich müssen auch Erfahrungspunkte behalten werden können. Die Haupt-Speicherdaten können dann eine Liste an Minispiele-Daten halten, so könnte man komplett alles in eine einzige Datei packen. Alternativ können die Daten der Minispiele auch in separaten Dateien gehalten werden.
Bei diesen Überlegungen kamen jedoch Fragen auf: Kann man ein Spiel mehrfach besitzen? Und wenn ja, haben diese dann ihre eigenen Spielstände? Hieße das, man könnte unendlich große Spielstände erzeugen? Diese Fragen werde ich jetzt noch nicht beantworten. Es wird schließlich davon abhängen, wie viel Speicherplatz man auf der jeweiligen Plattform zur Verfügung haben wird.
Das sollte zunächst für einen kleinen Einblick in das Speichern und Laden genügen. Im nächsten Tagebucheintrag würde ich gerne die Schnittstelle zwischen den Minispielen und der Welt ausbauen - hier fehlen noch Menüs für alle möglichen Optionen. Im Speziellen würde ich auf das Fähigkeiten-System eingehen, welches ich hier unterbringe. Damit werden unsere Minispiele sich weiterentwickeln können.
Ihr möchtet die Auszüge aus dem Leben eines Entwicklers lieber in englischer Sprache lesen? Unter diesem Link findet ihr die englische Version dieses Tagebucheintrags!
ANZEIGE:
Um Kommentare zu schreiben, bitte oben einloggen oder jetzt Registrieren!