Ihre Frage ist wirklich weit gefasst, da es so viele Genres gibt, aber hier ist die Perspektive eines professionellen Softwareentwicklers.
Sie haben eine Liste mit Kriterien angegeben, anhand derer Sie bestimmen möchten, welchen Datenpersistenzmechanismus Sie verwenden. Diese waren:
- Die Größe des Projekts.
- Die Plattform, auf die das Spiel abzielt.
- Die Komplexität der Datenstruktur.
- Portabilität von Daten unter vielen Projekten.
- Wie oft soll auf die Daten zugegriffen werden?
- Mehrere Datentypen für eine Anwendung
- Jeder andere Punkt ist für Sie von Interesse, wenn Sie sich für eine Verwendung entscheiden.
Zunächst müssen wir feststellen, welche Optionen uns zur Verfügung stehen. Da Sie keine Sprache oder Technologie angegeben haben, ist es schwierig, genau zu sagen, aber Sie versuchen wahrscheinlich, sich zwischen XML- und relationalem Datenbankspeicher zu entscheiden .
Ein wichtiger Unterschied zu machen ist , dass XML nicht wirklich ein Speicher ist Mechanismus so viel wie ein Serialisierungstechnik. Auf diese Weise können In-Memory-Strukturen für Ihr Spiel dargestellt werden. In Anbetracht dessen sprechen Sie wirklich von Flat File vs. relationalem Datenbankspeicher . Dies sind nicht die einzigen Optionen, aber sie kommen am häufigsten vor, daher werde ich sie verwenden.
Für flache Dateien:
- XML
- JSON
- YAML
- XAML
- Einfacher Text
Für Datenbanken:
- SQL Server
- MySQL
- DB2
- Orakel
- Viel mehr
BEARBEITEN: Sie fragten nach anderen Mechanismen als Dateien und relationalen Datenbanken. Der einzige andere bemerkenswerte Datenbanktyp, den ich regelmäßig gesehen habe, sind Datenbanken im Berkeley-Stil, die im Wesentlichen auf Schlüsselwerten basieren. Diese tendieren dazu, B-Bäume zum Strukturieren von Daten zu verwenden, damit die Suche schnell vonstatten geht. Diese eignen sich hervorragend für die Konfiguration / Einstellungssuche, bei der Sie genau wissen, was Sie möchten (z. B. geben Sie mir alle Telemetriedaten für "Stufe 1").
Nachdem wir alle Grundlagen aus dem Weg geräumt haben, gehen wir auf einige Ihrer Kriterien ein.
Die Größe des Projekts.
Einige mögen anderer Meinung sein, aber die Größe Ihres Projekts wird nicht unbedingt einen großen Einfluss auf Ihren Datenpersistenzmechanismus haben. Sie möchten eine wiederverwendbare Bibliothek von Funktionen erstellen, die Daten von jedem gewünschten Mechanismus speichern / laden. Ich würde sogar vorschlagen, eine Abstraktionsebene zu implementieren (sehen Sie sich das Adaptermuster an ), damit Sie Ihren Persistenzmechanismus bei Bedarf problemlos ändern können.
Allerdings kann die Verwendung von XML im Dateisystem bei kleinen Projekten möglicherweise gut funktionieren. Sie sollten jedoch einige Ihrer Sicherheitsbedenken (z. B. Verschlüsselung) berücksichtigen, damit die Player die Daten nicht nach Belieben ändern können.
Die Plattform, auf die das Spiel abzielt.
Die Plattform wird auch kein großes Problem sein. Sie sollten sich mehr Gedanken über Ihre Entwicklungsplattform als über die Zielplattform machen. Der Grund dafür ist, dass einige Sprachen bestimmte Arten von Markups oder Datenbanken besser verarbeiten als andere. Das heißt nicht, dass Sie keines der oben genannten Tools in fast jeder Sprache verwenden können, aber manchmal ist es am besten, die unterstützten Tools zu verwenden, die Ihnen zur Verfügung stehen. Jede Plattform unterstützt Flatfiles und parst XML. Auf mobilen Plattformen sollten Sie jedoch nach Möglichkeit die binäre Serialisierung in Betracht ziehen oder zumindest Ihr XML für die Speicherung optimieren.
Die Komplexität der Datenstruktur.
Das ist eine Art knifflige Sache. Relationale Datenbanken eignen sich hervorragend, um Entitäten und ihre Beziehungen zu speichern. Mit einem relationalen Speicherrepository können Sie die Struktur besser erzwingen als mit Dateien in einem Dateisystem. Berücksichtigen Sie die Arten von Beziehungen zwischen Ihren Entitäten sowie die Häufigkeit, mit der Sie sie ändern oder verwandte Entitäten finden. Für extrem komplexe Strukturen würde ich vorschlagen, die Datenbankroute zu wählen.
Portabilität von Daten unter vielen Projekten.
Wenn es um Portabilität geht, sollten Sie berücksichtigen, dass Datenbanken von Natur aus schwerer sind als Dateien. Es ist mit Installations- und Konfigurationsaufwand verbunden, verschiedene Datenbanken werden für verschiedene Plattformen verfügbar sein usw. SQLite ist ein ziemlich guter Weg, dies zu umgehen. Wenn es jedoch um Portabilität geht, werden Sie mit dateibasierten Lösungen wie XML wahrscheinlich leichter zurechtkommen.
EDIT: Es gibt einige andere Bedenken, die Sie in einem Ihrer Kommentare zur Portabilität angesprochen haben. Letztendlich möchten Sie nicht, dass Ihre Daten zu eng an ein Produkt oder einen Dateityp gekoppelt werden. Am besten ist es, wenn Sie Bestandsdaten (Ebenen, Gegner usw.) in einem abstrakten Format (durch Tabulatoren getrennte Dateien, XML usw.) speichern können, das Sie beim Kompilieren oder Laden einfach in einer Datenbank / einem Dateisystem analysieren und speichern können Zeit. Dies bedeutet, dass Sie Ihren Speichermechanismus aus einer Laune heraus austauschen und das Analyseteil einfach neu schreiben können.
Wie oft soll auf die Daten zugegriffen werden?
Viel Datenzugriff bedeutet viel E / A, es sei denn, Sie haben eine Art Caching-Mechanismus. Datenbanken behalten Strukturen im Speicher und eignen sich hervorragend zum Manipulieren und Abrufen von Daten. Wenn Sie wirklich ständig Daten speichern, sollten Sie sich an eine Datenbank halten.
Mehrere Datentypen für eine Anwendung
Das Volumen ist sicherlich eine Überlegung, aber wenn Sie nicht über das Bestehen von Tausenden oder Millionen von Objekten sprechen, wird das Dateisystem als Lösung immer noch akzeptabel sein.
Spiel Typ
Die Art des Spiels, das Sie erstellen, kann einen großen Einfluss auf die von Ihnen gewählte Plattform haben. Ja, für die meisten Nur-Client-Einzelspieler-Spiele ist die Verwendung einer komprimierten oder verschlüsselten Lösung auf Dateisystembasis in Ordnung. Wenn Sie jedoch über Spiele mit einer Online-Komponente sprechen, wäre das verrückt. Gehen Sie die Datenbank Route und sparen Sie sich die Kopfschmerzen. Lassen Sie den Server alle Ihre Daten mithilfe eines Back-End-Clusters verwalten.
Hoffe, einige dieser Rückmeldungen helfen. Es ist keineswegs vollständig, und die Entscheidung liegt letztendlich bei Ihnen, aber mein Kommentar sollte Ihnen einige Denkanstöße geben.
EDIT: Es gibt Zeiten, in denen ein hybdrid-Ansatz sehr sinnvoll ist. Angenommen, Sie entwickeln ein MMORPG. Auf der Clientseite können Sie zwischengespeicherte Daten zu anderen Spielern in einer nicht relationalen Datenbank speichern (wie oben erwähnt). Auf der Serverseite speichern Sie alle Spieldaten in einer relationalen Datenbank, um sie beizubehalten. Und auf der Clientseite speichern Sie wahrscheinlich Protokolldaten, Konfigurationsdaten usw. in XML- / Flat-Dateien, um den Zugriff zu vereinfachen.
Ein anderes Poster erwähnte auch, dass es manchmal schön ist, auch wenn Sie Daten für die Produktion in einer Datenbank speichern, eine Möglichkeit zu haben, stattdessen flache Dateien für die Entwicklung zu verwenden. Es kann einfach einfacher sein, ein anderes Produkt aus dem Mix zu entfernen .