Was ist ein gutes Dateiformat zum Speichern von Spieldaten? [geschlossen]

Ich muss einige benutzerdefinierte Spieldaten speichern. Karte, Spieler usw.

Alle von ihnen haben "Unterobjekte". Beispielsweise haben eine Karte und eine Karte ein "Array" von Kacheln. dh hierarchische Daten. Hoffentlich nichts Binäres.

Was wäre ein gutes Format für diese?

Bisher habe ich überlegt:

Serailization: Dies ist SCHNELL und einfach, neigt aber dazu, zu brechen, wenn ich die zugrunde liegenden Klassen ändere :(

XML: Ich hasse es wirklich, das zu analysieren. Mein Testfall bestand aus mehr als 100 Codezeilen und schien selbst für ein sehr einfaches Format eine Menge "geschäftiger Arbeit" zu sein.

INI: wäre für hierarchische Daten wirklich ungeschickt.

Protobuf: Ich habe es nie benutzt, aber ich habe gelesen, dass man viel manuell herumspielen und pausieren muss, wenn man die Klasse wechselt.

Andere Optionen? Darum bin ich hier!

Edit: Das ist übrigens Java.

Bearbeiten 2:

Ich habe mich für "Controlled Binary Serialization" entschieden (siehe unten).

Vorteile:

• Es ist schnell

• Es ist klein (auf der Festplatte) und kann während des Lese- / Schreibvorgangs leicht komprimiert / dekomprimiert werden.

• Es ist super einfach, von Spiel und Toolset aus zu lesen / schreiben.

• Ich kann entscheiden, was von dem Objekt eingeschlossen / ausgeschlossen werden soll.

• Objekte / Daten können verschachtelt werden.

Nachteile:

• Kann nicht manuell bearbeitet werden (wie XML, YAML usw.)

• Kann nicht einfach mit Skripten gelesen / geändert werden

• Standardmäßig ist die Java-Serialisierung im Vergleich zu anderen Implementierungen ziemlich langsam / aufgebläht, aber sie ist stabil und funktioniert

Für die Anzeige hierarchischer Daten bietet sich YAML oder JSON an . Sie sind viel einfacher und einfacher zu analysieren als XML.

Eine andere Option wäre ein "kontrollierter" binärer Serialisierungsprozess. Jedes Objekt schreibt seinen Zustand kontrolliert aus, dh

void player::save(savegame &sgm)
{
    sgm.write(this->position);
    sgm.write(other properties);
    inventory.save(sgm);
}

id Tech 4 (Quake 4 / Doom 3 Engine) nutzt einen solchen Ansatz.

Ein gut gemachtes Binärformat hat wirklich alle Vorteile, es ist schnell, relativ klein und so flexibel, wie Sie es machen.

Wenn Sie ein Binärformat erstellen, sind Sie an keine Regeln gebunden, was ein großer Vorteil ist, aber ironischerweise hat dies hauptsächlich dazu beigetragen, dass Binärdateistrukturen einen schlechten Namen bekommen. XML, JSON und dergleichen treffen eine Menge Entscheidungen für Sie, sie sind alles andere als immer optimal, aber sie sind einigermaßen sichere Entscheidungen, die Ihnen normalerweise dabei helfen, einige ansonsten häufige Probleme zu vermeiden.

Identifizieren Sie diese Probleme, entwerfen Sie Ihr Format unter Berücksichtigung dieser Probleme, und Sie können ein großartiges Binärformat erstellen.

Wenn Sie nicht erfahren / sicher genug sind, um ein Binärformat zu erstellen, und die Datenmenge so gering ist, dass die Auswirkungen auf die Geschwindigkeit vernachlässigbar sind, empfehle ich Ihnen, JSON zu verwenden. Es ist einfach, erledigt aber die Aufgabe.

Die Wahl des Dateiformats hängt stark von Ihrem aktuellen Toolset und dem Spiel ab, das Sie erstellen möchten . Nachdem das gesagt worden ist...

Das Toolset ist einer der wichtigsten Faktoren bei der Auswahl eines Spieldateiformats. Wenn Sie ein Binärformat erstellen , müssen Sie immer sicherstellen, dass Sie über die Tools zur Eingabe Ihrer Spieldaten verfügen . Dies kann so einfach wie ein Hex-Editor oder so komplex wie ein Unreal-Editor sein.

Ich denke, der Hauptvorteil von XML, YAML oder anderen Sprachdateien ist, dass Sie sie einfach mit einem Texteditor bearbeiten können . Durch die Verwendung eines vorhandenen Standards wird sichergestellt, dass Sie nichts falsch machen können . Aber das ist extrem langweilig, wenn Sie tausend Dateien haben, was mich zu meinem nächsten Punkt bringt.

Spiel. Was für ein Spiel machst du? Warum ich sage, dass dies das Dateiformat beeinflusst? Denn wenn Sie so etwas wie einen 2D-Bombermann machen, könnten Sie mit einer einfachen Textdatei davonkommen, wie:

*********
*1     2*    1,2,3,4  - start point of players 1, 2, 3, 4
* + + + *    *        - walls
*       *    +        - crates
* + + + *
*3     4*
*********

Mit anderen Worten, wählen Sie immer das naheliegendste Format für Ihre spezifischen Daten . Rollenspiele sind das komplexeste Spielgenre. Sie benötigen viele Daten. Dies bedeutet jedoch nicht, dass Sie ein bestimmtes Format festlegen müssen , sei es binär oder textbasiert für alle Daten im Spiel.

• Karten, Partikel und andere grafische Elemente verwenden in der Regel ein benutzerdefiniertes Binärformat. Weil es der einfachste Weg ist, es zu implementieren . Es ist nicht normal, Karten in Textform zu beschreiben. Normalerweise bearbeitet über Karte / Ebene / Partikel-Editoren.
• Spieler, Gegenstände, Feinde, Fertigkeiten und Quests sind Statistiken, die sich auf die Spielbalance auswirken . Sie erfordern normalerweise viele, viele Eingaben und Anpassungen. Ich mache das gerne, indem ich es in eine XML-Datei lege, um die Implementierung zu vereinfachen, aber dennoch einen Objekteditor für die Designer habe, mit dem sie spielen können. Das Beste aus beiden Welten .

Im Allgemeinen möchten Sie Text in einem Textformat und Grafiken in einem Binärformat beschreiben. Folgendes soll Ihnen ein Beispiel geben:

<Skill>
    <Name>Fireball</Name>
    <Animation>fireball.dat</Animation> <!-- Graphics described in another file -->
    <Attack>1.3</Attack>
    <Cooldown>15</Cooldown>
</Skill>

Zusammenfassend kann ich sagen, dass Sie, wenn möglich, Ihre Daten nicht skripten, es sei denn, dies ist absolut notwendig . Dem Endbenutzer ist es egal, wie großartig das Format ist, solange das Spiel spielbar ist, das ist alles, was zählt.

Prost, Roy =)

BSON ist ziemlich nett. http://bsonspec.org/ . Es ist einfacher zu analysieren als JSON und besser darin, Binärdaten zu enthalten, hat aber immer noch eine schöne Struktur. Es ähnelt in gewisser Weise den Protokollpuffern. Der Nachteil ist, dass es außerhalb von Mongodb anscheinend eine Menge Werkzeugunterstützung dafür gibt.

BEARBEITEN: MsgPack ( http://msgpack.org/ ) ähnelt ebenfalls BSON und scheint mehr Bodenhaftung zu erlangen.

Was ist mit Ihrem benutzerdefinierten Binärdatenformat passiert? Wenn Sie Angst vor unformatierter Serialisierung haben, schreiben Sie Ihr eigenes System, das Felder nach Bedarf schreibt und sie zurückliest. Sie benötigen kein XML, was in der Tat zu umfangreich und komplex ist, wenn Sie die Transparenz, die das Format bietet, nicht benötigen. Definieren Sie einfach ein genau festgelegtes Dateiformat, und halten Sie sich daran. Möglicherweise können Sie Ihren Datensatz in jedem Datensatz erweitern, indem Sie ihn mit Nullwerten auffüllen (z. B. haben Sie jetzt einen 100-Byte-Datensatz, den Sie für die zukünftige Verwendung auf 150 auffüllen).
Fügen Sie eine Versionsnummer und möglicherweise eine Prüfsumme hinzu, damit Sie wissen, welche Felder ausgefüllt werden müssen, und prüfen Sie die Gültigkeit auf Richtigkeit.

Sie können XML oder ein anderes Format mit Base64-Einfügungen für bestimmte Daten mischen, und für Felder, die Lesbarkeit benötigen, können Sie den üblichen TEXT verwenden