Informationen in eine Datei auslagern

[Coolies]

Hi,
Ich bin grad dabei mir zu überlegen wie ich am besten Spielerinformationen in eine Datei speicher Mit Informationen mein ich z.b. name,password,level,pos usw.
Bis jetzt sieht meine datei wie folgt aus

Name: balbal
Password: blabla
usw.

halt alles untereinander

Das System funktioniert bei wenig infos ganz gut aber umso mehr informationen dazu kommen desto schwerfälliger wird es...

Meine Frage ist nun, ob es einen besseren weg gibt mein problem zu lösen?


danke

[RySa]

Was meinst du denn mit "schwerfälliger" ? Ist es schwerer für dich die Daten zu verarbeiten ? Ich würd auch gerne wissen wie du die Daten beim auslesen verarbeitest.

[fastjack]

Properties, XML, Serialisierung...

[TheDarkRose]

File-Datenbanken wie sqlite oder embedded H2?

[turtle]

Zitat:

	Informationen mein ich z.b. name,password,level,pos usw.

Also, ich zähle da VIER Werte pro User. Das kann locker in einer Properties Datei gespeichert und geladen werden, selbst wenn Du da ein Mega-Spiel mit mehreren tausenden Spielern implementierst. Da wird nichts schwerfällig.

[Coolies]

danke für eure Antworten

Momentan lese ich jede zeile aus, "splitte" den String (split) und überprüfe dann mit equals was in dieser zeile steht

1
2
3
4
5
...balblabla zeile auslesen...
String[] splittArray = zeile.split(": ");
if(splittArray[0].equals("Name")) {
 ...weiter...
}

und das find ich halt irgendwie schwerfällig..=)

Properties hört sich schon sehr interessant an,
Serialisierung hab ich noch nicht ganz verstanden, das muss ich mir nochmal genauer anschauen und XML scheint sehr komplex zu sein, das muss ich mir ebenfalls in ruhe anschauen...

ich denke mal "Properties" ist genau das, was ich gesucht habe =)
ansonsten hab ja noch genug Ausweichmöglichkeiten

nochmal danke an alle

[RySa]

Also properties wären je nach Umfang geignet. Falls du 100+ Spieler haben solltest, dann ist es vielleicht bisschen "unschön" dann so etwas zu machen

p1.name=Player 1
p1.lvl=15
p2.name=Player 2
........
........
........
p423.name=Player 423
........

Was ich damit sagen will ist, dass wenn die Menge an Daten groß wird, und die Daten dauerhaft und sicher gespeichert werden sollen. Dann ist eher eine Datenbank zu empfehlen.
Properties Dateien sind (wie der Name schon sagt) für Konfigurationszwecke geschaffen, und nicht für Speicherung solcher Daten. Ebenso xml's (ok, diese vielleicht noch z.B für den Import/Export der Daten), die xml müsstest du aber nach jeder Änderung entweder neuschreiben oder über JDOM "aktualisieren", was für diesen Zweck einfach viel zu viel Aufwand wäre. Versuchs vlt. mit 'ner Datenbank

[turtle]

Ich stimme RySa zu, dass es unschön werden kann.

Daher würde ich auch zu einer DB raten (z.B. Derby embedded), wenn bereits abzusehen ist, das da viele User gepflegt werden müssen.

Aber natürlich handelt man sich dabei auch Probleme ein. Möchte man mehrere Attribute hinzufügen, hat man Migrations-Aufwand, weil halt in allen Zeilen die neuen Attribute gesetzt werden müssen. Das kann bei derartigen Mini-DBs überschaubar sein, ist aber in grossen Projekten auch ein grosser Aufwand, der Wochen/Monate dauern kann.

Hängt also von den Anforderungen ab: Anzahl_User/Änderungshäufigkeit/Skalierbarkeit. Musst halt also Du entscheiden.

Ich rate eigentlich sehr oft, eine interne embedded SQL-DB zu nehmen, weil dann der SQL/Java-Code bereits geschrieben wurde. Hinterher dieses auf eine mächtigere, performantere DB umzustellen, ist dann sehr einfach.

Aber nach dem, was Du bisher geschrieben hast, habe ich den Eindruck dass ein RDBMS Overkill für Deine Anforderungen wäre. Du solltest nur darauf achten, dass Dein Code für den Zugriff l"leicht" auf ein RDBMS geändert werden könnte (Stcihwort: DAO-Pattern, Programmierung gegen Interfaces). Dein Restprogramm sollte also keine Kenntnis darüber benötigen, ob die Daten aus einer Properties-Datei, XML-Datei oder RDBMS kommen.

[freez]

Ich würde dir auch zu einer Datenbank raten, wenn du mehr Daten hast. Es würde aber reichen, wenn du eine Datenbank hast, die ohne Service läuft, also direkt von deiner Anwendung gestartet wird.

Ich habe aber trotzdem noch 2 weitere Empfehlungen:
bei nicht allzu vielen Daten könntest du, wie meine Vorredner schon gesagt XML nehmen und per Xstream deine Objekte direkt ins xml speichern:

1
2
XStream xstream = new XStream(new DomDriver()); // does not require XPP3 library
xstream.toXML(MeinObjekt, new FileWriter(file)); //Speichern

oder bei größerer Datenmenge, aber dafür kannst du das File nicht mit einem Texteditor bearbeiten => db4o ... eine Objektorientierte Datenbank, die direkt in ein File schreibt und von deiner Anwendung gestartet wird:

1
2
ObjectContainer db = Db4oEmbedded.openFile(Db4oEmbedded.newConfiguration(), DB4OFILENAME);
db.store(MeinObjekt);

[RySa]

Deswegen sollte man sich vorher überlegen, welche "attribute" brauche ich für die Spieler. Auch wenn diese in der ersten Version noch nicht genutzt werden, du aber schon Pläne hast, es später zu nutzen, sind die schon jetzt anzulegen (wie der turtle schon sagte, eine Datenbank einmal erstellt und mit Daten befüllt, ist nachher sehr aufwendig zu ändern).

Jetzt wissen wir natürlich nicht, was du genau vor hast zu machen. Aber ich denke, dass auch eine kleine MySQL Datenbank, die auch auf dem Xampp läuft, für kleinere und nicht komerzielle Projekte geignet ist. Das musst dann aber du entscheiden, unter Beachtung deiner Kentnisse

EDIT: Noch mal kurz zu xml. Wenn du dich dafür entscheiden solltest, dann aber nur, wenn die xml-Datei wirklich klein wird (sonst füllst du dir über JDOM den Arbeitsspeicher voll), und nur wenn du nur Informationen über die Spieler speichern möchtest. Für Infos über andere "Objekte" müsstest du idealerweise mehrere xml-Dateien haben, was auch wiederrum sch...e ist. Ich würd aber generell von xml- und vor allem über JDOM abraten.

Der Grund dafür - ich nehme an, du willst keine Infos von Spielern im Speicher behalten, die nicht "eingeloggt" sind. Und du die Daten über die einzelnen Spieler nur beim einloggen, einmal abrufen willst. Nun wenn du JDOM benutzt, wirst du jedes mal wenn sich ein Spieler einloggt gezwungen, die gesamte XML in den Arbeitsspeicher zu laden, um nur an diese Informationen zu kommen. Ist einfach schlecht. Am besten Vergiss die Idee mit xml-Files :P Properties genauso. Eine Datenbank ist das, was du suchst :P

[Coolies]

danke für eure Antworten
ich hab mein Projekt nicht näher beschrieben, da ich dachte das macht die ganze sache nur unnötig komplizierter aber da ihr mir so kräftig geholfen habt, will ich das auch nicht offen lassen.
Also... hab mir ein spiel mit der JMonkeyEngine3 zusammengebastelt (besser nachgebaut) und bin nun dabei einen Multiplayer zu kreieren, momentan werden die Informationen über Objekte und Spieler in Dateien gespeichert, dass fand ich nicht besonders schick und hab nach einer andere möglichkeit gesucht(so nun war ich hier).
Da ich mich mit Java erst seit kurzen befasse, waren mir die verschiedenen Möglichkeiten nicht bekannt...
aber hab mich für ne MYSQL Datenbank entschieden(XAMPP), wie ihr mir das geraten habt.


Directupload.net - Dgmcyqwmh.jpg

[Semox]

Knuffiges Bild...

Irgendwie verstehe ich noch nicht ganz warum das Speichern der Spielstände schwerfällig sein soll.

Wie oft soll das denn geschehen? Ununterbrochen wäre natürlich schlecht, weil die HDD anzurufen extrem teuer ist. Oder willst Du in Intervallen speichern, dann fällt das nicht ins Gewicht. Meinst Du nicht?

Das bißchen Daten kann man auch problemlos im Speicher über JDOM behalten. Fällt doch nicht wirklich ins Gewicht.

Erkläre doch mal wie die Struktur Deines Spiels ist. Client-Server? Peer-to-Peer? Lokal? Man weiß noch nichts über die Kommunikation. Erst wenn das bekannt ist, lohnt es sich darüber nachzudenken, ob und wie etwas persistiert bzw. anderen zugänglich gemacht werden soll oder nicht.

Viele Grüße,
Semox

[RySa]

Zitat:

	Das bißchen Daten kann man auch problemlos im Speicher über JDOM behalten. Fällt doch nicht wirklich ins Gewicht.

Das "bisschen" Daten, macht über JDOM schon bei einer 50mb Datei Probleme (bei der Standardgröße des Heap Spaces). Und ich denke nicht das eine Planung: "joah, jetzt habe ich noch wenig Daten, also mach ich das mal so, falls nötig werd' ich es später ändern" unbedinkt schlau ist. Falls er nachher nicht mehr mit xml-Dateien auskommen würde, müsste er die ganze Struktur umschreiben. (na gut, xammp ist bei "großen" Projekten/Spielen auch nicht so das tollste, da kann man aber die Datenbank einfach mal exportieren).

[TheDarkRose]

Xampp mitliefern/vorraussetzen bezeichne ich jetzt mal als schrottig. Eine embedded DB wie H2 oder Derby, kann genau das selbe leisten wie MySQL und braucht aber kein schrottiges Softwarepaket wie xampp

[RySa]

Zitat: TheDarkRose

	Xampp mitliefern/vorraussetzen bezeichne ich jetzt mal als schrottig. Eine embedded DB wie H2 oder Derby, kann genau das selbe leisten wie MySQL und braucht aber kein schrottiges Softwarepaket wie xampp

ekhm ?

Zitat:

	Also... hab mir ein spiel mit der JMonkeyEngine3 zusammengebastelt (besser nachgebaut) und bin nun dabei einen Multiplayer zu kreieren, momentan werden die Informationen über Objekte und Spieler in Dateien gespeichert, dass fand ich nicht besonders schick und hab nach einer andere möglichkeit gesucht(so nun war ich hier).

Wer redet hier über das "mitliefern" ? Was haben denn die Spieler bitte schön mit der Datenbank zu tun ? Höchstens nur der Server, und den zwingt ja keiner unbedingt xampp zu nutzen... und ihn würde (jetzt noch zumindest) der TO hosten...Außerdem war xampp nur ein Beispiel. Es ging mir eher um MySQL an sich, und man kann sich die Datebank als Service auch anders laufen lassen...

[Marlon]

Eine Datenbank lohnt sich meiner Meinung nach für so eine kleine Aufgabe nicht.
Bei meinem Spiel habe ich es ganz simpel gelöst.
Die Properties Dateien werden mittels eines BufferedReaders Zeile für Zeile eingelesen, jede Zeile wird in eine Liste (Hashtable) gespeichert, durch diese dann später durchiteriert wird.
Mit hashTable.get(key) kannst du dann ganz praktisch auf das jeweilige Attribut zugreifen.
Ist es nicht vorhanden, wird null zurückgeliefert.

[fastjack]

Für Properties-Dateien brauchst Du aber nicht extra einen Reader zu schreiben, nutze einfach die java.util.Properties.

[TheDarkRose]

Zitat: RySa

	Wer redet hier über das "mitliefern" ? Was haben denn die Spieler bitte schön mit der Datenbank zu tun ? Höchstens nur der Server, und den zwingt ja keiner unbedingt xampp zu nutzen... und ihn würde (jetzt noch zumindest) der TO hosten...Außerdem war xampp nur ein Beispiel. Es ging mir eher um MySQL an sich, und man kann sich die Datebank als Service auch anders laufen lassen...

Naja, sobald dann das Spiel kommerziell läuft, fällt MySQL aus Lizenzgründen sowieso weg. PostgreSQL wäre noch zu nennen. Aber alles nur möglich wenn die Datenbank zentral liegt. Und dann sollte dies auch nur von Serverseitigen Diensten angesprochen werden. Eine Datenbank am Client (im Spiel) direkt anzusprechen sollte man nur wenn dies eine Embedded Datenbank im Spiel ist.

[RySa]

Zitat:

	Die Properties Dateien werden mittels eines BufferedReaders Zeile für Zeile eingelesen, jede Zeile wird in eine Liste (Hashtable) gespeichert, durch diese dann später durchiteriert wird.

Also Properties Dateien mit einem BufferedReader zu lesen (also manuell) macht irgendwie überhaupt keinen Sinn. Dafür gibt es ja das "java.util.Properties" Klasse, die automatisch intern eine Hashtable erstellt (wie der fastjack schon sagte).Wenn Properties, dann schon richtig. Ich sagte aber dass es "unschön werden kann". Ist aber auch Geschmacksache. Man kann ja natürlich in der property Datei, die Infos über jeden spieler mit loginname.lvl = 50, loginname.exp = 355672567. Und die Properties halt abspeichern, wenn sich ein Spieler ausloggt, bzw. wenn der Server abstürtzt, oder der Spieler disconnected wird. Könnte man durchaus machen. Aber wie gesagt. Alles hängt von der "größe" des Projekts ab
__________________

[Marlon]

Zitat: RySa

	Also Properties Dateien mit einem BufferedReader zu lesen (also manuell) macht irgendwie überhaupt keinen Sinn. Dafür gibt es ja das "java.util.Properties" Klasse, die automatisch intern eine Hashtable erstellt (wie der fastjack schon sagte).Wenn Properties, dann schon richtig. Ich sagte aber dass es "unschön werden kann". Ist aber auch Geschmacksache. Man kann ja natürlich in der property Datei, die Infos über jeden spieler mit loginname.lvl = 50, loginname.exp = 355672567. Und die Properties halt abspeichern, wenn sich ein Spieler ausloggt, bzw. wenn der Server abstürtzt, oder der Spieler disconnected wird. Könnte man durchaus machen. Aber wie gesagt. Alles hängt von der "größe" des Projekts ab __________________

Na, bei mir klappts auf jedenfall ohne Probleme, Aufwand: 15 Minuten.
Habe mich leider schon zu sehr daran gewöhnt das Rad neu zu erfinden...