Archiv verlassen und diese Seite im Standarddesign anzeigen : Weltdatenstruktur
mekakic
2009-02-19, 17:23:34
Hallo
ich arbeite mit einem Freund gerade an einem kleinen RPG - hauptsächlich als Spaß und um Erfahrungen zu sammeln; zu ernst ist die Sache nicht.
Es geht jetzt langsam darum Weltdaten in die Engine zu laden und ein Form zu haben, um sie in Tools (die es noch nicht gibt) zu speichern. Erst hatten wir über etwas XML artiges nachgedacht, haben uns dann aber erstmal dagegen entschieden.
Ich bin dann über Google Protocol Buffer (http://code.google.com/intl/de-DE/apis/protocolbuffers/docs/overview.html)s gestolpert. Wäre das tauglich für so ein Projekt, sollte man sich eher was eigenes überlegen oder gibt es was Sinnvolleres?
Hallo
ich arbeite mit einem Freund gerade an einem kleinen RPG - hauptsächlich als Spaß und um Erfahrungen zu sammeln; zu ernst ist die Sache nicht.
Es geht jetzt langsam darum Weltdaten in die Engine zu laden und ein Form zu haben, um sie in Tools (die es noch nicht gibt) zu speichern. Erst hatten wir über etwas XML artiges nachgedacht, haben uns dann aber erstmal dagegen entschieden.
Ich bin dann über Google Protocol Buffer (http://code.google.com/intl/de-DE/apis/protocolbuffers/docs/overview.html)s gestolpert. Wäre das tauglich für so ein Projekt, sollte man sich eher was eigenes überlegen oder gibt es was Sinnvolleres?
ist doch die frage, mit welcher sprache ihr arbeitet. viele sprachen verfuegen ueber notwendige mittel um ihre datentypen auf einem datentraeger zu speichern und auszulesen.
xml ist viel zu lahm. das ist keine meinung, sondern erfahrung. zur not gibt es sowas wie yaml, ini, aber wie gesagt,,,
naja, die argumente auf der seite da sind echt arm ;)
<person name="John Doe" email="jdoe@example.com" />
mein tipp: mach dir nicht zuviele gedanken drum. nimm das was am einfachsten ist. es ist ein hobby projekt und keines was in der Computer Bild Spiele punktabzug bekommt weil es 95s statt 90s laedt.
Ziel bei euch sollte produktivitaet sein, oder?
viel unterschied wird es da echt nicht geben, serialisieren ist wie code schreiben, es gibt viele verschiedene syntax und es ist rein subjektiv was am besten ist.
gut abstrahiert kannst du am ende das subsystem austauschen, falls es riesige probleme bereitet.
ich kenne leute die ihre rpg-level als bitmap abspeichern, in den bitmaps IDs fuer objekte encoden und es laeuft auch, sogar vom server streambar fuer viele user gleichzeitig.
...perfektion ist wenn man nichts mehr wegnehmen kann... ;)
The_Invisible
2009-02-19, 18:20:43
hab dafür mal so ein einfaches eigenes protokoll in plaintext geschrieben, für die daten die da anfielen war es mehr als schnell genug.
sqlite sollte hierfür aber auch interessant sein.
naja, viele wegen führen nach rom...
mfg
Es geht jetzt langsam darum Weltdaten in die Engine zu laden und ein Form zu haben, um sie in Tools (die es noch nicht gibt) zu speichern. Erst hatten wir über etwas XML artiges nachgedacht, haben uns dann aber erstmal dagegen entschieden.
Definiere mal Weltdaten. Ohne genauere Beschreibung wir dir niemand einen brauchbare Empfehlung geben können.
xml ist viel zu lahm.
Das kommt ja wohl eindeutig auf den Parser an. SAX mit Xerces-C++ war bei mir nie lahm.
Monger
2009-02-19, 19:18:52
Das kommt ja wohl eindeutig auf den Parser an. SAX mit Xerces-C++ war bei mir nie lahm.
Naja, auch der schnellste Parser wird bei einer mehrere GB großen XML Datei lahm! ;)
(Und ja, mir ist sowas auf Arbeit schon übern Weg gerannt. Da werden komplette Datenbanken auf XML rausserialisiert. Uargs!)
Dr.Doom
2009-02-19, 19:52:10
Wieso auch nicht, ist doch dann super portabel. *g*
Shink
2009-02-19, 19:59:21
Naja, auch der schnellste Parser wird bei einer mehrere GB großen XML Datei lahm! ;)
(Und ja, mir ist sowas auf Arbeit schon übern Weg gerannt. Da werden komplette Datenbanken auf XML rausserialisiert. Uargs!)
Ja, hättet ihr halt ein proprietäres Format genommen und alles wäre superschnell gegangen:wink:
Man vergisst oft dass das Datenformat normalerweise nur einen konstanten Faktor einnimmt: Wenn es so viele Daten sind dass XML zu langsam ist... dann war man erstens sehr fleißig beim Daten erfinden und zweitens wäre es mit etwas anderem auch nicht schnell.
Im Prinzip ist es also egal; vielleicht auch mal überlegen ob man sich durch IOC mit Swing etwas an Programmier/Architekturaufwand ersparen kann/will, dann ist die Wahl ja klar. Ansonsten ist es prinzipiell egal was man nimmt; ich würde aber nur ungern etwas nehmen wofür es keine ausgefeilten Parser gibt die man selbst nicht so gut hinbekäme. Also XML, JSON oder von mir aus auch Protocol Buffers. Wenn man viel suchen muss kann es auch eine Datenbank sein; hat aber auch seine Nachteile.
Monger
2009-02-19, 20:13:14
Man vergisst oft dass das Datenformat normalerweise nur einen konstanten Faktor einnimmt: Wenn es so viele Daten sind dass XML zu langsam ist... dann war man erstens sehr fleißig beim Daten erfinden und zweitens wäre es mit etwas anderem auch nicht schnell.
Naja... und man vergisst gerne das Dateisystem.
Manchmal hat man einfach sehr viele Daten, die aber ständigen (wenn auch geringen) Änderungen unterworfen sind. Dann ist es natürlich ziemlich blöd, in eine Textdatei rauszuserialisieren, weil man bei jeder kleinen Änderung wieder den ganzen Klumpatsch anfassen muss. Für sowas ist eine Datenbank da.
Manchmal ist es auch höllisch schwierig, eine Datenstruktur sauber auf XML abzubilden. Nicht alles ist ein Baum (oder meinetwegen ein Wald). Wenn man binär rausserialisiert, ist es völlig egal wie die Objektstruktur intern aussieht - man kriegt sie genau so raus wie man sie reingeschoben hat. Dafür verliert man an Portabilität und Robustheit...
XML ist ein ziemlich vielseitiger Datencontainer, aber eben nicht mehr. In dem Fall den der TS beschrieben hat, würde ich wohl auch zu einer hundsgewöhnlichen Serialisierung greifen, es sei denn ich finde bereits eine passende Datenstruktur die sauber auf XML abbildbar ist.
Manchmal ist es auch höllisch schwierig, eine Datenstruktur sauber auf XML abzubilden. Nicht alles ist ein Baum (oder meinetwegen ein Wald). Wenn man binär rausserialisiert, ist es völlig egal wie die Objektstruktur intern aussieht - man kriegt sie genau so raus wie man sie reingeschoben hat. Dafür verliert man an Portabilität und Robustheit...
Probleme die beim Serialisieren auftreten, weisen häufig auf ein nicht sauberes Klassendesign hin. Alles einfach binär rauszudumpen ist in C++ wegen Pointern auch nicht drin. Falls er überhaupt C++ verwendet.
In dem Fall den der TS beschrieben hat, würde ich wohl auch zu einer hundsgewöhnlichen Serialisierung greifen, es sei denn ich finde bereits eine passende Datenstruktur die sauber auf XML abbildbar ist.
Welchen Fall hat er denn beschrieben?
Weltdatenstruktur ist so nichtssagend wie Grafikdaten. Da kann man einfach keine Empfehlung geben.
Das einzige was vielleicht einen Trend in Richtung andeuten könnte, wäre der Datenaustausch der Runtime mit Editoren. Dafür eignet sich "hundsgewöhnliche" Serialisierung eigentlich weniger.
SimonX
2009-02-19, 22:54:35
xml ist viel zu lahm. das ist keine meinung, sondern erfahrung. zur not gibt es sowas wie yaml, ini, aber wie gesagt,,,
Nur wenn man standard XML Parser benutzt ...
Wir benutzen einen von mir selbst geschriebenen XML DOM Parser, der auf einem Core eines 2.6GHz Core2 Quad 150 MiB beliebiges XML pro Sekunde parsen kann und auch noch so nebenbei XPath-Zugriffe in O(1) bereitstellt.
Der Parser wird beim Real-Time Billing/Rating bei den grössten Mobilfunkbetreibern (z.B. TIM Itally) eingesetzt. TIM benutzt leider die deutlich langsameren IA-64. Da gehen nur 90MiB pro Sekunde. Aktuelle Sparc's liegen so bei 80MiB pro Sekunde.
Naja, auch der schnellste Parser wird bei einer mehrere GB großen XML Datei lahm! ;)
Das wird er auch bei YAML und anderen Textformaten.
Shink
2009-02-20, 08:24:15
XML ist ein ziemlich vielseitiger Datencontainer, aber eben nicht mehr. In dem Fall den der TS beschrieben hat, würde ich wohl auch zu einer hundsgewöhnlichen Serialisierung greifen, es sei denn ich finde bereits eine passende Datenstruktur die sauber auf XML abbildbar ist.
Klar ist XML bei weitem nicht für alles geeignet für das man es nimmt.
Im Falle des TS (der ja so genau auch nicht dokumentiert ist...) stell ich mir das so vor dass er natürlich noch keinen Map Editor o.ä. hat und sich trotzdem irgendwie eine Welt zusammenzimmern möchte ohne Hardcoding. Da fänd ich "hundsgewöhnliche Serialisierung" relativ unpraktisch.
ScottManDeath
2009-02-20, 08:39:37
http://www.boost.org/doc/libs/1_38_0/libs/serialization/doc/index.html
Damit kann man einfach komplexe Datenstrukturen, auch mit Zeigern usw. serialisieren, als Text, XML (zum debuggen/entwickeln), oder Binary (final). Man muss fuer jede zu serialisierende Klasse eine Methode schreiben, fuer viele STL und boost datentypen existieren sie schon, z.b. auch fuer die boost smartpointer.
http://www.boost.org/doc/libs/1_38_0/libs/serialization/doc/index.html
Damit kann man einfach komplexe Datenstrukturen, auch mit Zeigern usw. serialisieren, als Text, XML (zum debuggen/entwickeln), oder Binary (final). Man muss fuer jede zu serialisierende Klasse eine Methode schreiben, fuer viele STL und boost datentypen existieren sie schon, z.b. auch fuer die boost smartpointer.
Toller Vorschlag!
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.