Speicherkonzept, persistenz

[Empire Phoenix]

Ich bin derzeit dabei ein etwas größeres hobby projekt spiel zu programmieren.
Nun suche ich nach einem sinnvollen einfachen konzept wie ich das Speichern verwirklichen kann, bislang habe ich nur mit relationalen Datenbanken gearbeitet, aber ich halt den aufwand alles manuell auf Query ebene zu machen viel zu aufwendig und fehleranfällig.
Habe daher einige Sachen gefunden so wie zb Hibernate, jedoch verstehe ich nciht ganz ob die mir wirklich das bieten was ich suche:

Was ich suche ist ein Systen mit dem ich Objectfelder (die teilweise aber selten auch Objecte sind) direkt in eine Datenbank serialisieren kann, und umgekehrt mithilfe einer id/oder ähnlich sie wieder laden kann, alle felder gesetzt werden und ich dann am ende eine funktion wie activate() aufrufen lassen kann, (zur initialisierung aller nicht speicherbaren teile, wie zb physic objecte, netwerk synchronisation. Einige Objecte werden variable und undefinierte Felder besitzen, das würde ich direkt mit einem STring speichern normalerweise aka "hp_200-ammo_20-armor_10", jedoch finde ich diese Lösung nicht optimal und wollte mal fragen was es da für alternativen gibt.

 

[newcron]

Zunächst mal die Frage:
muss es denn überhaupt eine Datenbank sein? Bei einem (normalen) Spiel hast du dein komplettes Datenmodell ohnehin die ganze zeit im Speicher und musst es nur beim speichern und laden auslesen bzw. schreiben.

Eine Datenbank ist dabei vielleicht völlig übertrieben - du könntest dein Datenmodell beispielsweise einfach in eine Datei Serialisieren (mit einem ObjectWriter) und anschließend wieder auslesen. In dem Zusammenhang wäre eventuell auch das Keyword "transient" für dich interessant.
Soll es etwas schicker sein, warum dann nicht XML nehmen? Das kannst du mit Bibliotheken wie JAXB oder JibX einfach als XML speichern und solches auch wieder laden.

 

[Empire Phoenix]

Ja doch sollte eine Datenbank sein, weil das ganze netzwerkbasiert und über einen kleinen Cluster laufen soll, und ich den selben Datenbestand bei allen Rechnern haben will/muss. Daher denke ich das in diesem Fall eine DAtenbank mal nicht übertreiben ist.

 

[Steev]

Ich kenne jetzt zwar kein System, das deinen Anforderungen entspricht, aber ich denke, dass es wirklich nicht schwer ist, so etwas selbst zu machen.
Du brauchst doch eigendlich nur eine Id für jede Objektinstanz und den User-Name der ein Objekt ablegt. Diese beiden Felder würde ich neben einer Id-Nummer als Primärschlüssel für eine Objektwert-Tabelle erstellen.
Dann würde ich eine Interface Storeable oder so machen, die mir eine Methode vorschreibt, wo man das Attribut x abspeichern kann. Dann müsste man einfach nur noch eine Klasse schreiben, die anhand dieser Interface Objekte in die Datenbank speichert oder von der Datenbank liest.

 

[ice-breaker]

Ja doch sollte eine Datenbank sein, weil das ganze netzwerkbasiert und über einen kleinen Cluster laufen soll, und ich den selben Datenbestand bei allen Rechnern haben will/muss. Daher denke ich das in diesem Fall eine DAtenbank mal nicht übertreiben ist.

eventuell Terracotta JVM Clustering?

Ansonsten vllt einen OR-Mapper wie Hibernate für eine Datenbank wie MySQL/PostgreSQL?

 

[Empire Phoenix]

Hibernate habe ich ir jetzt mal genauer angeguckt, und es wirkt eigentlich exact so wie etwas was ich brauche, aber eine Frage dazu habe ich noch, wenn mehrere Cluster stücke auf den selben eintrag einer Tabelle zugreifen, garantiert Hibernate dann das die daten synchron sind, (von wegen dem lokalen Cache)

 

[ice-breaker]

Ich habe Hibernate noch nicht genutzt, aber bis auf Terracotta's Clustering kann dir eigentlich keine Software garantieren, dass der Wert auf einem anderen Server nicht einen anderen Wert angenommen hat.
Die Terracotta-Lösung macht eben synchronized-Blöcke für den ganzen Cluster, deshalb funktioniert bei denen das.

 

[Empire Phoenix]

Hm ja ist aber etwas sehr heftig, wenn auch ein interessantes konzept. Werde mir erstmal genauer überlegen wie ich das umsetzten kann.