Speichern/Laden von Spielzuständen

[Jonathan]

Wie speichert ihr Spielzustände?
Im Moment benutze ich boost::serialization. Das schöne ist, dass man für kleine Funktionen echt nur eine Mini-Funktion schreiben muss, die fürs Laden und Speichern benutzt werden kann. Toll ist auch, dass Zeiger automatisch aufgelöst werden und man somit mehrere Objekte mitsamt ihrer "Abhängigkeiten" speichern und wieder laden kann.
Schlecht ist allerdings, dass das ganze furchtbar kompliziert ist. Durch diesen ganzen TMP-Quatsch kriegt man Fehlermeldungen, bei denen es eine Viertelstunde dauert, bis man erst mal verstanden hat, was einem der Compiler sagen will und danach geht es mit lustigen Laufzeit-Exceptions weiter. Ist man einmal drin, behebt man natürlich auch solche Fehler mit einer gewissen Routine aber gerade jetzt merke ich, dass man schon nach einem halben Jahr fast wieder von vorne anfangen muss. Und außerdem mag ich es nicht, wenn im Hintergrund zig Dinge geschehen, die sich anfühlen wie schwarze Magie, und ich so nicht direkt merke, ob ich nicht vielleicht aus Versehen etwas furchtbar falsch oder ineffizient mache.
Früher habe ich ticpp benutzt, um alles als XML-Datei zu speichern. Natürlich macht das die Speicher- und Ladefunktionen länger, aber dafür hat man auch die volle Kontrolle. Wenn ich bei boost::serialization zwischen Aufrufen des Ladens und Aufruf der Ladefunktion meiner ersten Klasse satte 13 Funktionen (extra Nachgezählt) im Callstack dazwischen habe, schränkt das doch die Debugbarkeit enorm ein.

Und dann gibt es ja immer noch so nette Spezialfälle: Man möchte eigentlich auch weitestgehend das selbe Format für Spielstände und Levels haben, damit man sich die Arbeit nicht 2 mal machen muss. Das wird kniffelig, in einer Bibliothek, die einem alles abnimmt und fummelig, wenn man alles selber machen soll. Ansich hört es sich ja so trivial an, den aktuellen Spielzustand auf der Festplatte zu speichern, aber irgendwie ist es dann letztendlich doch viel zu viel Arbeit, als einem lieb ist.

Ok, also irgendwelche Tipps, Vorschläge, Artikel oder Bibliotheken, die einem das Leben leichter machen können?

[antisteo]

Zyklenfreie Datenstrukturen wie Bäume oder Records sind ja easy zu serialisieren.
Und für alles andere kann man die Objekte durchnummerieren und diese Indizes als adressraumunabhängige Zeiger benutzen.

[Jonathan]

Ja, das habe ich mir auch schon überlegt. Mir geht es hier aber eher um den highlevel Ansatz, als an die lowlevel Umsetzung.

[antisteo]

Ja, das habe ich mir auch schon überlegt. Mir geht es hier aber eher um den highlevel Ansatz, als an die lowlevel Umsetzung.

Highlevel wäre eine managed Sprache mit Annotations und Reflections günstig. Es gibt für Java massig Persistenz-Frameworks, die dir deinen kompletten Zustand der Applikation serialisieren kann, bloß weil du ein paar Klassen mit @Persistent markierst.

[simbad]

Serialisierung ist schick, wenn du Daten zwischen Anwendungen oder auch zwischen Maschinen kopieren willst. Da kann man dann so lustige Sachen wie Threads komplett von einer Maschine auf die andere bringen.
Zum Speichern von Spielständen, besonders wenn sich die Struktur ändern kann, was während der Entwicklung ja öfter mal vorkommt, halte ich serialization für ein wenig ungünstig.
Man kann aber in serialisierungen auch fehlende Inhalte überspringen. Also wenn in dem Datenstrom was drin ist, das die Struktur nichtmehr kennt, dann kann man das elegant überspringen. Umgekehrt kann man fehlendes im Datenstrom oft durch defaults ersetzen.

Ist aber alles sehr fummelig.

Da bist du mit XML oder selbst mit ini-Format, sections/attribute=value konstukten, besser dran.

[dot]

Da ich es gerade gestern in einem Talk gehört hab: Ich denke ein interessanter Aspekt was das Speichern/Laden von Spielzuständen angeht ist, dass man im Zeitalter von mobile Gaming etc. (falls du vorhast auf mobilen Plattformen zu laufen), daran denken sollte, dass deine Anwendung ihren State in einem sehr kurzen Zeitram speichern und wiederherstellen können muss (wenn das OS sie anhält). Einfach direkt sämtliche internen Datenstrukturen zu Serialisieren etc. ist da in der Regel wohl keine Gute Idee. Besser ein System implementieren, das den Zustand inkrementell speichert, d.h. praktisch immer den momentanen Zustand im Hintergrund schon großteils gesichert hat und nur diese Sicherung ständig updated während es läuft. Oder z.B. sowas wie ein Save Point System. Abgesehen davon wird es dem Spieler immer besser gefallen, wenn er beim Speichern nicht ewig warten muss. Und wenn das Spiel dann mal abstürzt, hat man möglicherweise nix verloren ;)

[spobat]

@dot:
Den inkrementellen Ansatz finde ich, besonders auf mobilen Plattformen, nicht so toll, da du staendig eine Datei offen hast und schreib/lese zugriffe hast, waehrend das eigentliche spiel laeuft.
Genau sowas versucht man ja waehrend eines laufenden spiels zu vermeiden.
Die mir bekannten Mobilen Plattformen, iOS, Android, WP schiessen alle passende Events los, wenn's was wichtiges gibt, wie beispielsweise, dass die App in der Hintergrund geraet oder sie neu geoeffnet wird.
Fuer gewoehnlich macht man das abspeichern asynchron, sodass alles perfekt fluessig am ui thread ablaeuft. (Ob dass dan eine oder zwei sekunden dauert, ist ja egal)
Im endeffekt hast du so aber wertvolle Rechenleistung gespart.

Es kommt eben auch auf das Spiel an.
Wird bei einem rpg der Zustand nur beim schliessen der app gemacht, waere das katastrophal.
5 Stunden lang gespielt und dann faellt der ploetzlich der Strom aus? Der Spieler wird dein game die naechsten 5 monate nicht mehr anruehren.
Da sind zusaetzliche Save Points sicher sinnvoll.

[dot]

Die mir bekannten Mobilen Plattformen, iOS, Android, WP schiessen alle passende Events los, wenn's was wichtiges gibt, wie beispielsweise, dass die App in der Hintergrund geraet oder sie neu geoeffnet wird.

Ja, aber das problem ist:

Fuer gewoehnlich macht man das abspeichern asynchron, sodass alles perfekt fluessig am ui thread ablaeuft. (Ob dass dan eine oder zwei sekunden dauert, ist ja egal)

Es ist eben nicht egal wie lang das dauert. Zumindest Windows gibt dir nur ein paar Sekunden und wenn du bis dahin nicht fertig bist, killt es deinen Prozess komplett, da ist dann auch nix mit anderem Thread. Der Talk aus dem diese Empfehlung zu inkrementellem Speichern stammt, handelte genau über Windows 8 und mobile Plattformen ;)
Die MSDN sagt's noch deutlicher:

Generally, your app should save its state immediately in the event handler when the suspending event is received, and generally take less than a second to save its data. If an app does not return from the suspending event within 5 seconds, Windows assumes that the app has stopped responding and terminates it.

Als Benutzer würd mich das extrem nerven, wenn ich grad was am Handy spiel und dann ruft mich wer an und ich kann erst mal ein Weilchen nicht abheben, weil das Spiel erst speichern muss. Oder noch besser: Ich kann erst nicht abheben und verlier dann auch noch meinen kompletten Spielstand, weil das Spiel zu lange gebraucht hat...

Und die Sache mit dem Stromausfall ist doch auch ein Paradebeispiel dafür, was inkrementelles Speichern abseits von mobilen Plattformen bringt...

[BeRsErKeR]

Ich würde Chunks benutzen. Dadurch kannst du z.B. für Level und Spielstände das gleiche Format nehmen, indem du z.B. nur den Level-Chunk nutzt. Du kannst so sogar einen Spielzustand im Leveleditor öffnen usw. Chunks eignen sich auch sehr gut für inkrementelles Speichern, da du nur bestimmte Chunks aktualisieren oder hinzufügen musst. Man kann außerdem sehr einfach bestimmte Informationen als Chunk rausziehen. Wie granular du die Chunk-Hierarchy anlegst liegt dann bei dir. Z.B. kann ein Level-Chunk aus vielen Sub-Chunks bestehen oder auch nicht.

[spobat]

Als Benutzer würd mich das extrem nerven, wenn ich grad was am Handy spiel und dann ruft mich wer an und ich kann erst mal ein Weilchen nicht abheben, weil das Spiel erst speichern muss. Oder noch besser: Ich kann erst nicht abheben und verlier dann auch noch meinen kompletten Spielstand, weil das Spiel zu lange gebraucht hat..

Hierzu 2 Dinge: Das Speichern laeuft, oder sollte, asynchron ablaufen. Als nutzer bemerkst du davon dann ueberhaupt nichts. Es wird abgespeichert, waehrend die neue App bereits auf dessen Thread sein eigenes sueppchen kocht :).
Das das abspeichern >= 5s dauert ist imo eher ungewoehnlich, muss aber respektiert werden.

Wenn du, sagen wir direkt nach beendetem call, zurueck ins Spiel gehst hat sich da vermutlich gar nichts geaendert, es muss voraussichtlich nicht einmal neu geladen werden, da es nie recyclet wurde, sondern sich die ganze zeit im Arbeitsspeicher befand.

Ich vermute mal vage, dass es ihm aber auch gar nicht um mobile Plattformen geht.
Ist der Talk, von dem du geredet hast, online aufzufinden?

[dot]

Ich vermute mal wage, dass es ihm aber auch gar nicht um mobile Plattformen geht.
Ist der Talk, von dem du geredet hast, online aufzufinden?

Gibts natürlich online: http://channel9.msdn.com/Events/Windows ... tyle-Games bei 00:31:43

[Schrompf]

Danke für den Link! Unabhängig vom Thema "Serialisierung": Ich hab so das Gefühl, dass das bald wichtig werden wird.

Zum Thema Serialisierung: ich habe das bisher von Hand programmiert: eine kleine Streamklasse, auf der alle beteiligten Objekte jeweils ein Segment (mit Startkodierung, Versionsnummer und Byte-Größe) aufmachen und ihren Kram da reinschreiben. Die Start-/Endkodierung ist praktisch für die Fehlerprüfung, was bei binären Dateiformaten ja sonst schnell zu üblem Fehlverhalten führen kann. Die Versionsnummer erlaubt ein einfaches Verändern des Dateiformats im Nachhinein, und die Größe wird vom Segment-Destruktor automatisch eingesetzt, damit das Programm beim Laden nachher Segmente überspringen kann, in denen eine Exception geflogen ist.

Das System funktioniert prächtig, aber es ist etwas viel Arbeit, die Daten in jedem beteiligten Objekt von Hand zu speichern und zu laden. Hier könnte ein automatisches System in einer Reflection-fähigen Programmiersprache durchaus die eine oder andere Minute Tipperei ersparen.

Beispiel:

Code: Alles auswählen

void Objekt::Speichern( Strom& strom, bool istSpielstand )
{ 
  TSegmentSchreiber segment( strom, 'CODE', VERSION);

  BasisKlasse::Speichern( strom, istSpielstand);

  segment << bla << blubb;

  if( istSpielstand )
    segment << wibbl << wobbl;

Es ist ein einfaches System, zugegeben. Aber es hat sich über viele Jahre und erstaunlich viele Änderungen an allen möglichen Klassen hinweg bewährt.

[dot]

Danke für den Link! Unabhängig vom Thema "Serialisierung": Ich hab so das Gefühl, dass das bald wichtig werden wird.

Oh ja. Schau dich mal auf Channel 9 um, ist eine wahre Goldgrube. Speziell die BUILD 2011 Conference ;)

Außerdem z.B.: http://blogs.msdn.com/b/b8/

[simbad]

Ich lasse solche Serialisierungen vom Code-Generator meiner UML-Tools erledigen. Von Hand tippen würde ich wohl schnell einfach aufhören solche Techniken einzusetzen.
Der Code-Generator ist aber bezüglich der Auswahl der Klassen, die serialisiert werden sollen noch Überarbeitungsbedürftig. Das ganze erzeugt dann C++-Code.

[kimmi]

Ich rate dringend davon ab, direkt den Zustand all deiner Objekte direkt in ein File zu serialisieren. Spätestens wenn du für ein Update Aktualisierungen vorgenommen hast, fällt das Rücklesen flach. Auch ich rate zu so etwas wie XML, ein eigenes Binärformat oder JSON ( im Hinblick auf Mobile-Anwendungen ).

Und wie ich gesehen habe, hat das auch scon einer zum Besten gegeben :).

@dot Wenn dein asynchron ablaufender Task für den IO etwas länger braucht, schiesst Windows den unter Mobile-Devices ab? Wollen die damit Batterien schonen? Bzw. muss der Tread immer Rückmeldung geben, dass er wirklich noch läuft und nicht hängt?

@Edit: Kaum etwas text geschrieben und alle Antworten sind bereits da :)...

Gruß Kimmi

[spobat]

Wenn dein asynchron ablaufender Task für den IO etwas länger braucht, schiesst Windows den unter Mobile-Devices ab? Wollen die damit Batterien schonen? Bzw. muss der Tread immer Rückmeldung geben, dass er wirklich noch läuft und nicht hängt?

Kommt darauf an:
Die app hat genau 5 Sekunden zeit, danach wird die App komplett gefreezt und es wird kein code mehr ausgefuehrt.
Ist es tatsaechlich so, dass eine app, egal in welchem zustand sie atm ist, laenger als 5s keine response von sich gibt, dann crasht sie.
Es kann natuerlich sein, dass sich das hier ueberlappt.


@dot
Ist die tatsache, dass der Typ in dem von dir geposteten Video c++/cli nutzt irgendwie logisch erklaerbar?

[dot]

@dot
Ist die tatsache, dass der Typ in dem von dir geposteten Video c++/cli nutzt irgendwie logisch erklaerbar?

Das ist kein C++/CLI sondern C++/CX ;)

[Jonathan]

Ja, ich glaube ich werde auf XML umsteigen. Letztendlich ist Serialisation ja nicht genau das, was ich machen müsste und obwohl boost::serialization viele Komfortfeatures hat, fühlt es sich in der Benutzung an wie Assembler (was die Komplezität, Fehleranzahl und Zeit für deren Behebung angeht).
Die Speicher/Ladefunktionen brauchen dann vielleicht 2-3 mal so viel Code, aber letztendlich ist das doch zu verkraften. Außerdem habe ich mehr Kontrolle darüber, was da eigentlich passiert und bin auch flexibler.

Inkrementelles Speichern ist für mich zunächst kein Thema, so kompliziert will ich es gar nicht haben. Ansich sind die Ladezeiten da glaube ich auch gar nicht so das Problem: Kritisch wird es eher die ganzen Assets zu laden, sind die einmal im Speicher geht das erstellen der Spielwelt daraus hoffentlich recht flink. Von daher mach ich mir keine großen Gedanken über Geschwindigkeit oder Speicherplatz, XML-Dateien sind einfach viel robuster und flexibler und können notfalls ja auch noch komprimiert werden (womit zumindest wieder die Größe nahezu ausgeglichen sein sollte).

Wo wir gerade dabei sind: Irgendwelche Bibliotheksvorschläge? Ich habe bisher ticpp benutzt, RapidXML sieht aber auch nett aus. Sollte halt vorrangig möglichst komfortabel sein.

[dot]

Wieso genau XML? Muss der User die Dateien editieren? In der Regel nicht, oder? Dafür willst du in der Regel möglichst schnell speichern und laden. Genau das ist aber gerade nicht die große Stärke von Textdateien. Ich würde zu einem Binärformat raten.

[Jonathan]

Ich finde, XML ist sehr einfach robust zu programmieren. Ich kann mir alle erzeugten Dateien ansehen und Kleinigkeiten auch schonmal im Texteditor ändern. Ich merke direkt, wenn ich aus versehen das Format geändert habe, oder sonst irgendetwas durcheinander kommt. Das ganze ist eher plattformunabhängig, als Binärdateien. Und die Bibliotheken nehmen mir viel Arbeit ab, ich kann bei Ladefehlern sehr einfach sehr genaue Fehlermeldungen produzieren.
Wenn du einen guten Tipp für eine Bibliothek hast, die mich Binärdateien ähnlich einfach benutzen lässt, würde ich mir das durchaus gut überlegen. Aber im Moment sehe ich die Lade/Schreibgeschwindigkeit der XML-Datei nicht als das große Problem an, die ganzen Vorteile sind aber durchaus nützlich.
Es ist ja auch so, dass ich eher komplexe Objektstrukturen habe. 3D-Modelle würde ich natürlich Binär speichern, eben wegen der Geschwindigkeit. Bei Arrays wird XML halt wirklich hässlich, aber die habe ich ja so gut wie nie.

[dot]

Naja, ich bin wohl einfach kein sooo großer Fan von XML. Gerade das Programmieren von Code der XML Dateien liest, sich mit Tags und Attributen rumquälen und so, find ich eigentlich alles andere als angenehm, ganz besonders wenn es auch noch robust sein soll. Die Portabilität der Dateien ist natürlich ein Argument für XML, die Frage ist allerdings ob du wirklich Savegames von einem Gerät auf ein völlig anderes Gerät kopieren können musst...

[antisteo]

Ich bin persönlich ja ein JSON-Fan, da JSON kompakter ist.

Aber egal ob JSON oder XML, es gibt da draußen jede Menge Tools, die mir automatisch Code zum Auslesen eines JSON oder XML in meine Datenstrukturen ausformuliert. Und falls die einem nicht passen, schreibt man sich seinen Code eben von Hand oder, falls es viel Code ist, ein eigenes JSON-Serialisierungs-Werkzeug.

[Thoran]

Also ich verwende bisher protobuf von google. Auch wenn es ursprünglich als Netzwerkmessagingprotokoll entworfen wurde, läßt es sich sehr schön dazu verwenden Daten zu serialisieren und deserialisieren. Ich verwende protobuf momentan zum Speichern meiner Projekte in meinem Qt-basierten FSM-Editor, sowie zum Speichern und Laden meiner Level (wobei ich dort als prototyp mit einem XML-Format angefangen habe). Was mir gut gefällt ist, dass ich sowohl binär als auch textuell schreiben und lesen kann und das mehr oder weniger mit einem 4-Zeiler. Das Datenmodel läßt sich in Textdateien spezifizieren, die dann zum Erzeugen der Codeklassen verwendet wird.

Thoran

[spobat]

@antisteo

Bei interop sachen arbeite ich generell auch am liebsten mit JSON (e.g. REST services),
in dem fall hier ist aber das binaerformat klar ueberlegen. Die dateien sind kleiner und ein unnoetiges parsen bleibt dir erspart.
Ich sehe hier keinen Vorteil eines ASCII formats.