Datenbanken in Spielen?

[Seraph]

In den letzten paar Tagen haben wir mehrmals darueber gegruebelt, ob wir die Aufgabe der Verwaltung von Daten nicht an eine Datenbank uebertragen. Dafuer sprechen viele Gruende, dagegen eher wenige. Einer der entgegensprechenden Gruende ist, dass es moeglichst ohne Dienste-Installation laufen soll.

Kennt ihr effiziente Datenbanksysteme welche ohne "tiefe" Installation laufen koennen?

Waere eine Datenbankinstallation (auch eine "tiefe") fuer einen Spieler ertragbar? Was ist eure Meinung dazu?

[j-x]

ich benutze bei meinen Programmen SQLite, da es ohne Dienst auskommt (ist eine schlanke Bibliothek)

[Chromanoid]

Also für Java gibt es da natürlich ziemlich viele... :D

ansonsten vielleicht hier mal schauen ;):
http://en.wikipedia.org/wiki/Embedded_database

[Lynxeye]

Die Nebula Engine von Radon Labs macht genau das schon seit Jahren und mehreren Enginegenerationen. Kann also nicht so schlecht sein der Ansatz. ;)
Beim Spiel Drakensang kann man direkt in der Datenbank herumpfuschen. Selbst die Spielstände werden einfach als deferentieller DB Dump abgelegt, was dort sehr viel Arbeit erspart.

ALs Backend nutzen die Radon Leute auch SQLite, da es sich direkt ins Programm integrieren lässt, ohne zusätzliche Dienste. Ich glaube das ist der ideale Weg, den ein Spiel gehen sollte. Ich stelle es mir allerdings etwas schwierig vor, alle möglichen Spielaktionen auf SQL zu mappen. Das es möglich ist beweißt allerdings wieder einmal die Nebula.

Falls ihr noch in der Konzeptionsphase seid, in der sich so etwas direkt mit einbauen lässt, würde ich es auf jeden Fall versuchen. Bei schon fortgeschrittenen Systemen wird es evtl. ein größerer Aufwand, aber das kannst nur du selbst entscheiden.

[Seraph]

Danke fuer eure Antworten. :)

Ich wollte allerdings nicht eher antworten, bevor ich mir die einzelnen Datenbanken nicht mal angesehen habe. Nun bin ich bei Microsofts SQL CE haengen geblieben, da sie gut ins Gesamtkonzept passt.


Ich ueberlege immer noch was dieses Ja...-Dings bedeutet, welches Chromanoid erwaehnt hat. ;)

[odenter]

Meinst Du "embedded database"? Das bedeutet "eingebettete Datenbank", also eine Datenbank die praktisch in Deinem Programm steckt und keinen extra Server/Dienst benötigt um zu funktionieren.

SQLite oder Berkeley DB sind sowas, auf Wikipedia findet man aber ja auch eine Liste an solchen Datenbanken.

Ich würde SQLite empfehlen, ist schlank und schnell, oder eben Berkeley DB falls es keine Sql-Datenbank sein muss.

[Seraph]

Ja, ich meinte embedded databases. Man hat mich ja schon weiter oben auf deren Existenz hingewiesen, ebenso wie auf eine "Liste" in der Wikipedia. Wie gesagt, momentan nutze ich MS SQL CE, da es gut ins Gesamtkonzept passt, sprich .net, nativ 64 Bit, Lizenz passend, bearbeitbar direkt in VS, etc. :)

[odenter]

Laut der Liste auf Wikipedia ist die CE-Version auch eine embedded database.

[Seraph]

Genau, deshalb nutze ich sie ja. :)

[dv]

SQLite würde ich nur einsetzen, wenn ich einen konkreten, unmittelbaren Nutzen davon habe. Es "einfach so" mal reintun, weil es halt gut klingt, führt zu problemen, denn SQLite muss getuned werden, die SQL-Statements ebenfalls etc. Die Datenstrukturen, die man bei Gameplay hat, sind oft zu einfach für SQL, und die für Rendering etc. erfordern zu niedrige Latenzen.

[Chromanoid]

Ich würde für ein Spiel auch nur DBs benutzen, wenn ihr wirklich extrem viele Datenmengen persistieren müsst... Man könnte natürlich auch Texturen, Modelle und Daten in der DB speichern und so gleich Ressourcen-Zugriff erledigen... Ansonsten fallen mir nur wenig Spiele ein wo das wirklich nötig wird. In den meisten Rollenspielen, kann man ja eigentlich alle Fortschritte in einer Hash-Tabelle speichern (Script-Trigger haben dann einfach einen projektweiten eindeutigen String-Identifizierer)... Das ist jedenfalls erst mal performanter und einfacher als eine Datenbank... Auch Objekte könnte man alle zum Speichern einfach in einem dicken Array auf die Festplatte serialisieren...

[Seraph]

Die genaue Datenmenge ist noch nicht bekannt, zumal wir versuchen auch einiges eher generisch zu generieren.

Ich kann mich auch nicht mit dem Gedanken anfreunden Assets in einer DB zu speichern.

Und bestimmte Dinge werden natuerlich im Speicher gehalten, solange sie relevant sind. Momentan sind wir am Gruebeln ob wir das "Metagame" welches im Hintergrund laeuft direkt auf die Datenbank zugreifen lassen oder auf Objekte die wir dafuer im Speicher halten.

Der Vorteil einer DB ist u.a. die Performance und vor allem auch das Suchen von bestimmten Objekten bei groesseren Datenmengen.

Und ich kann dem nur bedingt zustimmen, dass eine Hash-Table einfacher zu benutzen ist als eine Datenbank.

[odenter]

SQLite würde ich nur einsetzen, wenn ich einen konkreten, unmittelbaren Nutzen davon habe. Es "einfach so" mal reintun, weil es halt gut klingt, führt zu problemen, denn SQLite muss getuned werden, die SQL-Statements ebenfalls etc.

Klar das muss man aber bei jedem DMBS, unter dem MSSQL-Server sind z.B. die INNER JOINS schneller als alle anderen Joins, entsprechend sollte man seine Struktur (der Tabellen) dann auch aufbauen.
Und richtig schnell sind die Server sowieso nur, wenn sie die Datenbank in den Speicher lutschen können. Wenn die Datenbank erst von der Platte lesen muss, dann kann man das auch gleich selbst machen und direkt in Strukturen einlesen.