spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Kommt halt auf die Anwendung an. Du kannst ja ein komplett eigenes Format haben, was nur sehr spezifisch für ein Programm ist.

In üblichen anderen Datenbanken kann man ebenfalls alles ändern, wie man möchte. Es gibt ja zu Hauf irgendwelche Progamme, die Datenbanken auslesen/manipulieren können. Ansonsten müsstest du diese einfach verschlüsseln, wenn du nicht willst, dass die ein User sehen kann.

Was genau hast du denn damit vor?
Es gibt noch SQLite, das ist eine abgespeckte Embedded Datenbank.
Abfragen und benutzen tut man sie wie eine Datenbank (z.B. MySQL MS SQL usw.).

Wenn es dir nur um Configs oder Speicherstände geht würden ini Dateien (Config) oder XML (Config, Speicherstände) reichen.

Für XML verwende ich immer tinyxml.
Schreib mal was du damit vor hast, dann kann man dir besser helfen

Eine echte Datenbank wäre dafür sicherlich übertrieben. Immerhin hat Mysql oder ähnlich schon einen gewaltigen Overhead.
XML ist eignetlich ganz gut, ein Vorteil ist, dass du z.B. die config Dateien mit einem Texteditor ändern kannst und es viel robuster und schneller zu benutzen ist, als ein Binärformat, dafür aber natürlich etwas langsamer lädt und auch größer ist (sollte aber bei den meisten Projekten keine Rolle spielen).

tinyxml ist ok, aber prinzipiell Mist, die Erweiterung ticpp ist da schon sehr viel besser zu gebrauchen. Ich benutze ticpp auch für vieles, man kann nicht die ganzen fortgeschrittenen XML-Features benutzen aber dafür ist es klein und leicht zu benutzen.

Arrays sind in XML Daten natürlich schwer darzustelen, bzw. werden enorm groß und dann auch unleserlich. Da kann man dann evtl. doch auf Binärdateien zurückgreifen, muss man halt sehen, wie es so geht.

http://code.google.com/p/ticpp/

Gibt auch noch YAML (mit yaml-cpp als lib), welches viel leserlicher und genau so einfach zu parsen ist.

MOMENT ich würde nicht pauschal sagen, dass eine DB die relationale Datenschemas für ein Spiel unbedingt overkill wäre. Gut für Optionen etc pp. würde ich auch eher xml, ini, plaintext usw. empfehlen, aber gerade für den Spielstand habe ich doch die relationalen DBs lieb gewonnen, weil egal welche Variante man nimmt um die Daten ohne relationale Beziehungen abzuspeichern, läuft man Gefahr, dass böse Fehler passieren die man mit z.b. einer SQL DB vermeiden kann (wenn sie das entsprechend unterstützt).

Weil ansonsten kann es leicht passieren, dass man entweder z.b. für einen gegnertypen jedesmal das gleiche reinschreiben muss werden sich nicht gerade großartig von den Werten unterscheiden), oder man irgendwelche eindeutigen Kennungen einführen muss, die dann aber ggf an vielen Stellen geändert werden müssen, falls sich die Kennung ändert. Hier kann eine entsprechende DB schon helfen indem sie entsprechende Aktionen verhindert oder die Updates entsprechend verbreitet.

Wem das zu theoretisch war:
1. Option - alles ohne Verweise speichern bedeutet
Haus(name="erstes Haus", modell = "haus.x", hps = 400, preis = 800)
Haus(name="zweites Haus", modell = "haus.x", hps = 400, preis = 800)
<- viel Redundanz

2. Option - verweise einbauen
Haustyp(typ = "standardhaus", modell = "haus.x", hps = 400, preis = 800)
Haus(name="erstes Haus", typ = "standardhaus")
Haus(name="zweites Haus", typ = standardhaus")
<- vermeidung von Redundanz, aber was wenn sich der Typname ändert oder nicht mehr existiert?

3.Option - relationale DB nutzen
ähnlich wie 2. nur dass die DB entweder eine Veränderung verhindern oder entsprechende Einträge löschen kann, was viele Fehler vermeiden KANN (nicht muss).

Also je nachdem würde ich raten, einfach mal zu schauen, wie wichtig sowas wie "leicht zu ändern", "einfach zu handhaben", "wenig overhead" und "vorhandene vorkenntnisse" sind und entsprechend abzuwägen. Wobei ich als Argumente gegen eine DB nur das Erlernen von SQL, die installation einer entsprechende DB (was aber bei SQLite je entfällt) bzw. das Unvermögen die Daten per Editor zu ändern wirklich respektieren würde.
Wer willig ist SQL zu lernen oder es schon kann und Daten speichern will, die keine Optionen etc sind, dem rate ich zu einer DB .

Ich bin nicht überzeugt
Normalerweise wird man einen Spielzustand immer komplett im RAM haben wollen also nicht alle paar Frames eine Datenbankabfrage machen.
Dann würde man beim speichern und beim laden jeweils einmal alles schreiben und einmal alles lesen. Dadurch fällt doch schonmal der ganze nette Kram wie "man kann komplexe Anfragen an die Datenbank stellen" weg.
Im Gegenteil hat man immer noch einiges an Overhead und es ist schon komplizierter, als einfach ne Datei kurz zu öffnen und zu beschreiben.
Referenzen auf Objekte muss man so oder so manuell herstellen, man kann halt schlecht in einer relationalen Datenbank Zeiger speichern.
Und Eindeutigkeit von
werten, naja, wenn die Integrität vorm Speichern nicht gegeben war, läuft doch eh schon eine Menge schief. Wie gesagt man schreibt einmal alles und liest einmal alles da kann also nicht wirklich was passieren.

Im Gegenteil finde ich hierarchische Methoden wie z.B. XML-Dateien sehr viel intuitiver zu benutzen und das ist ja auch viel Näher an OOP als relationale Datenbanken.

Klar kann man Datenbanken auch gewinnbringend in Spielen einsetzen, aber für Spielstände sind sie meiner Meinung nach ungeeignet.