Input/Output Brauche Rat bei effizienter Speicherung großer Datenmengen

[Fu3L]

Ich bräuchte euren fachkundigen Rat in einem Gebiet, in dem ich bisher noch nicht viel Erfahrung sammeln konnte:

Ich schreibe momentan an einem Spiel und stehe jetzt vor der Frage, wie ich die einzelnen Quadranten meiner großen Spielwelt am effizientesten speichern kann... Da ich von diesen recht viele hätte, würde ich die am liebsten in eine Datei bzw. eine Archiv packen. Sonst würde das Sichern eines Spielstandes beim Kopieren wegen der vielen kleinen Minidateien ewig lange brauchen (siehe alte Minecraft-Spielstände^^). Wie ich Dateien aus einem ZIP-Archiv lese, weiß ich bzw. ich weiß, wo ichs nachlesen kann^^. Aber wie speichert man am besten die Daten?
Diese Dateien müssen zum einen ein recht großes float-Array enthalten mit den Höhendaten des Terrains, aber auch die Positionen von Modellen wie Bäume oder Felsen sollten dadrin stehen. Vielleicht auch Informationen über besondere Objekte, die veränderbar sind (weil man sie zum Beispiel einsammelt). Bei einer Binärdatei stelle ich mir das recht umständlich vor (und habe auch nur mit RandomAccess-File bisher was gemacht), ein xml-file dagegen scheint mir zu langsam zu sein und zu groß zu werden...

Ich hoffe ich konnte verständlich machen, was mir unklar ist und hoffe auf euren fachkundigen Rat^^

 

[SlaterB]

ein Punkt reingeworfen: beim Spiel Siedler fand ich früher beeindruckend, dass eine ganze Karte nur mit einem Zufalls-Seed 45894 beschrieben wurde, der Rest leitete sich daraus auf deterministische Weise ab,
gilt für viele andere Anwendungen sicher ähnlich, betrifft aber eben nur rein zufällige Begebenheiten, keine manuell gebaute Spielwelt,
nicht die darin vorgenommenen Änderungen

vielleicht kannst du das aber auch als Ausgangsbasis verwenden oder zumindest für einen Teil der Daten, etwa Verteilung von Bäumen/ Höhenstufen,
zusätzliche Speicherung von konkreten Einzelinformationen steht dem ja nicht entgegen

wobei das nicht nur die Speicherung betrifft, wenn man so vorgeht muss natürlich auch die Kartenerstellung usw. danach arbeiten,
je nachdem kann das bisherige Konzepte auf den Kopf stellen

 

[Fu3L]

Ja, bei Minecraft leitet sich auch die ganze Welt aus einem Seed her (den man mitlerweile auch slebst angeben und so Karten reproduzieren kann) Das finde ich auch beeindruckend.. Bei mir habe ich mir noch keine abschließendenn Gedanken gemacht, ob ich noch extra Zufall mit einbaun will^^ Aber wäre das nicht auch rechenintensiv, wenn man das jedes Mal, wenn ein neuer Bereich erreicht wird, alles neu berechnet werden muss? ???:L

Kann das leider nicht abschätzen...

 

[SlaterB]

na gut, dann war das ja nicht so neues, aber eben ausgesprochen,
zur neuen Frage auch eine Mutmaßung von mir, aber ich glaube ich bin weniger Experte als du, habe nichtmal ein aktuelles derartiges Programm:

rechenintensiv ist der Aufbau eines Bereichs, ja, aber nicht unbedingt abhängig vom Wie,
ob die Länge, Breite und Höhe des nächsten Berges von drei Zufallszahlen + dämpfenden Faktoren oder drei Zahlen aus einer Textdatei abhängt..,
falls aus diesen drei Zahlen 1000 Klötze erstellt werden müssen, um mal in Minecraft-Sprachweise zu bleiben, dann sind die drei Zahlen am Anfang wohl nicht der entscheidene Faktor, wobei sicherlich noch mehr Informationen benötigt werden,

allein schon ob nur paar abstrakte Zahlen oder jeder Klotz an sich in der Datei gespeichert werden ist eine Frage an sich,
unabhängig davon wo diese Zahlen herkommen

sofern die Datei nicht gerade eine Arbeitsspeicher-Auslagerung ist, wird dir diese nicht viel nützen gegenüber einer neuen (Zufalls-)Welt,
ich glaube elementare Programmentscheidungen werden kein großer Teil der Arbeit sein,
sondern die stumpfsinnige tausendfache Umwandlung derselben in was immer die Engine benötigt,

aber ist jetzt vielleicht auch etwas kühn angenommen,
falls wiederum detaillierte Balancing-Entscheidungen global durchgerechnet werden müssen..,
etwa Ressourcen in einem Strategiespiel für mehrere Parteinen..

 

[Fu3L]

allein schon ob nur paar abstrakte Zahlen oder jeder Klotz an sich in der Datei gespeichert werden ist eine Frage an sich, unabhängig davon wo diese Zahlen herkommen

Das meine ich vor allem, ob das nicht rechenintensiv ist, eben das Kreieren der Positionen aller 1000 Blöcke zur Laufzeit (um auch Minecraftsprache zu nutzen^^) (meine Welt soll schon so sein, wie man es aus RPGs kennt, soll nämlich ein RPG werden^^)...

sondern die stumpfsinnige tausendfache Umwandlung derselben in was immer die Engine benötigt,

das könnte ich mir auch vorstellen, weiß es aber leider auch nicht genauer^^ Ein Denkanstoß war es aber auf jeden Fall schon, dass ich zumindest die "statischen" Teile der Welt vllt gar nicht zu speichern brauche..

Mir ist übrigends noch ein Spiel eingefallen, wo das mit dem Zufallsseed genutzt wird: Anno 1404^^
Und weil ich es so beeindruckend finde, aus ein paar Zahlen eine Welt zu kreieren, spornt mich das grad an, das auch können zu wollen

Mit welcher Technik ich das Speichern am besten umsetzen kann, weiß ich aber immer noch nicht so recht.. Mal angenommen, ich würde die deterministische Variante wählen, dann käme vllt ein xml-file für den Rest in Frage..
Aber ich würde trotzdem gerne noch mehr Meinungen hören zum Speichern an sich, wie groß die Datenmenge nun auch immer sein mag.

 

[Guest2]

Moin,

als Tipp (und um der eigentlichen Frage auch aus dem Weg zu gehen ), falls Du deine Welt prozedural erzeugen möchtest: GPU Gems 3: Chapter 1. Generating Complex Procedural Terrains Using the GPU | NVIDIA Developer Zone
(Nicht unbedingt einfach, aber optisch sehr heiß )

Viele Grüße,
Fancy

 

[Fu3L]

Danke für den Link, das sieht wirklich genial aus
Ich hoffe, das geht mit der JMonkeyEngine, dass ich nebenbei selbst auch die GPU anspreche (habe bisher die Annehmlichkeit der Engine genutzt, um selbst nichts mit OpenGL machen zu müssen und dementsprechend dazu wenig wissen^^ Aber man wächst ja mit seinen Aufhaben^^ )

Edit: mir fällt auch gerade ein, wenn ich das Terrain System der JME nutze, kann ich für die "Bodenplatte" nichts mit Überhängen machen.. aber vllt schaff ichs ja, daraus dann Modelle zu speichern aus dem, was über den Boden hinausgeht^^ :rtfm:

 

[Fu3L]

Ich finde zwar das Generieren auch viel interessanter als das Speichern, aber vllt weiß ja doch noch jemand was zu meiner eigentlichen Frage?^^

(Zum Generieren öffne ich vllt demnächst mal nen eigenen Thread, dann kann man da weiter diskutieren^^)

 

[Guest2]

Ok, auch wenn ich bei jME nicht wirklich weiterhelfen kann und da auch nicht weiß, wie Objekte vorgehalten werden, aber bevor keiner antwortet (aus reiner OpenGL Sicht):

Ich würde zu einer (eingebetteten) Datenbank greifen. Jedes sichtbare Objekt der "Welt" kann dann zur Laufzeit z.B. in einem VBO vorgehalten werden. Die zur Erzeugung des VBO notwendigen Daten (also meistens mindestens x,y,z,s,t, x,y, ...) könnten in der DB als BLOB gespeichert werden. Das hat den Vorteil das alle notwendigen Vertexdaten in einem "Rutsch" aus der DB in den Speicher der Grafikkarte übertragen werden können. Ich würde zusätzlich noch für jedes Objekt einen weiteren BLOB für ein VBO der Boundingbox, sowie (außerhalb des BLOB) die Koordinaten der Boundingbox ablegen.

Zur Laufzeit könntest Du dann aus der DB alle Objekte holen, welche möglicherweise im sichtbaren Bereich liegen (anhand der Koordinaten der Boundingbox). Für diese Objekte baust Du dann die Boundingbox aus dem BLOB der Boundingbox (als VBO). Via Hardware Occlusion Queries lässt sich dann feststellen, ob das Objekt wirklich sichtbar ist oder nicht. Falls ja, den zugehörigen VBO (jetzt die wirklichen Geometriedaten) aus dem BLOB bauen und das Objekt darstellen.

Je nach Spieltyp und Szene muss man vermutlich mit dem Timing und den Schwelwerten, wann Objekte geladen werden (und wann wieder "vergessen" werden), etwas experimentieren, ehe das geschmeidig aussieht, dürfte dann aber (relativ) beliebig skalieren.

Viele Grüße,
Fancy

 

[Fu3L]

Danke für den neuen Denkanstoß, an eine Datenbank habe ich bisher gar nicht gedacht (bisher nur MySQL-Datenbanken über localhost genutzt, was bei nem Spiel ja nicht so super ist^^)

Ich versuche mal mein Verständnis von der Repräsentation von Meshs in der JME zu beschreiben:

Jedes Mesh besteht aus Dreiecken. Man muss dafür ein Array vom Typ Vector3f mit den Vertices übergeben, dazu dann ein Vector2f Array "texture coordinates" (wenn ich das richtig verstehe, muss man hier Werte angeben, die in Bezug zur Größe des Meshes stehen (das Beispielmesh ist ein Quadrat und geht von 0,0 bis 3,3 in der Diagonalen und für die Texturcoordinaten isses auf mal 1,0;0,0;0,1;1,1) und dann noch ein int[], das die Reihenfolge der Verbindungen angibt (gegen den Uhrzeigersinn)^^
In den JME-Klassen, die Terrain darstellen, wird noch ein normalenArray übergeben, welches im Mesh-Tutorial keine Erwähnung findet^^

So werde ich das Terrain zwar nicht direkt in den Grafikspeicher laden können, aber ich denke, dass es trotzdem effizient sein dürfte? (zumindest ist es so mit der DB leichter zu laden, wenn es ähnlich wie bei MySQL funktioniert^^)
Und was für eine DB sollte ich dann wählen? Ich kenne das wie gesagt nur über localhost und es gibt ja anscheinend viele verscheidene Varianten^^

Eine eigene TerrainKlasse müsste ich aber trotzdem schreiben, da in der JME keine Überhänge etc. möglich sind, aber das sollte ich hinbekommen^^ Cool ist aber, dass die JME Backface Culling zB gleich mit übernimmt.

Wobei ich aber einen Kommentar zitieren möchte, der nicht gerade Mut macht:

Create the LOD index array that will seam its edges with its neighbour's LOD.
This is a scary method!!! It will break your mind.

 

[muckelzwerg]

Lies Dich einfach mehr in die Spieleprogrammierung ein. Es gibt jede Menge Abhandlungen für das Speichern von Höhenmaps oder effizientes Speicher von vermeintlich endlosen Welten etc.

 

[Fu3L]

Das Problem ist, wenn man wenig Ahnung hat in Sachen effizienter Datenspeicherung, kann man auch schlecht beurteilen, welches Tutorial den eigenen Anforderungen am besten entspricht und das erschlägt einen irgendwie^^

Wenn du jetzt einen Link aus dem Hut zaubern könntest, der auf ein passendes Tutorial verweist, wäre ich dir sehr dankbar
Kurzzusammenfassung an die Anforderungen: Speicherung eines TerrainModells (Überhänge etc. wären schon klasse, deswegen reicht eine einfache HeightMap nicht aus), inklusive Infos über die Texturen, sowie weitere statische Modelle und das irgendwie effizient^^

 

[muckelzwerg]

Die Fähigkeit wirst Du so oder so erwerben müssen.
Nein ich hab spontan keinen Link dazu. Lies doch mal auf Gamasutra, Gamedev etc.
Außerdem findest Du oft auch gute Paper zu sowas bei IEEE oder ACM.

 

[Fu3L]

Vllt bin ich tatsächlich grad nicht in der Lage die richtigen Suchbegriffe zu wählen.. Bisher war Fancys Beitrag für mich wertvoller als alles was Google lieferte.
Irgendwo las ich zwar, dass eine DB nicht dafür gedacht ist, nur jede Minute oder so Daten zu ändern (als jemand fragte, wie Minecraft-Maps gespeichert werden^^), aber mir scheint die Nutzung einer DB sehr sinnvoll^^ Allein schon, weil es mir wesentlich weniger fehleranfällig und leichter zu ändern zu sein scheint, über einen Query an Daten zu kommen, als irgendwelche Bit-Offsets zu nutzen. Und da diese Systeme von richtigen Profis geschrieben werden, ist es obendrauf vllt sogar noch schneller, als wenn ich selbst was bastle^^
Ich habe hier im Forum von H2 gelesen und werde das mal testen. Ist das eine passende Wahl?

 

[schalentier]

Was ist denn deine Frage eigentlich? Beschreib mal deine Datenstruktur etwas genauer, sonst kann dir keiner einen passenden Hinweis geben.

Wenn du eine Heightmap speichern willst, oder eine 3D-Map (wie Minecraft) ist eine Datenbank aeussert ungeeignet imho. Dann brauchst du ja eine Tabelle in der Art:
[c]x | y | z | block_id[/c]

Zu jedem Block oder Pixel musst du also noch die Koordinate speichern. Wenn fuer die Pixel 1 Byte ausreichen, brauchste also 3x4 + 1 Byte pro Pixel. Das ist ne gnadenlose Speicherverschwendung... als Alternative kannst du einen bestimmte Bereich deiner Welt in einem Chunk/Quadrant fester Groesse speichern. Also ein Array mit den Pixeln/Bloecken. Dafuer gibts auch was in der DB (CLOB, BLOB). Allerdings musst du diese Struktur dann im Javaprogramm verarbeiten, die Datenbank hilft dir dann "nur" noch beim Abspeichern der Arrays.

Oder willst du statische Meshs in der Datenbank ablegen? Auch das halte ich fuer ziemlich fragwuerdig, denn die Meshs werden ja im Grunde einmalig zum Start des Spiels geladen und die Grafikkarte kopiert. Ne Datenbank ist doch eigentlich zum Finden von rel. wenigen Daten aus einer gigantisch grossen Gesamtmenge gedacht.

Zudem hast du Recht, Datenbanken sind sauschnell beim Lesen (genauer beim Finden), aber recht langsam beim Schreiben (da muessen ja noch die Indexe aktualisiert werden usw).

 

[Spacerat]

Hmm... selber ausprobiert habe ich es noch nicht, aber dieses hier brachte mich einst auf die Idee, dass sich Terrains damit sehr gut erstellen lassen und vor allem auch mit sehr viel weniger Stützpunkten als Heightmap auskommt. Für das Berechnen der Zwischenpunkte lässt sich am Ende sogar die Optics-Engine neuerer NVidia-Karten heranziehen. Diese berechnet deren Anzahl dann anhand der Nähe zur jeweiligen Bodenfläche (sozusagen LODs). Ohne Optics lässt es sich natürlich auch über die GPU lösen. Die Anzahl der Zwischenpunkte wird dann Anhand eines Präzisionswertes (z.B. 0% entspr. 1000 oder 100% entspr. 0 Zwischenpunkte). Speichern braucht man dann nur noch sehr wenig Höhenwerte. was mir dabei aber nicht Klar werden will, ob sich so auch Felsvorsprünge modellieren lassen.
Zum speichern der ganzen Daten scheint mir dieses hier recht interessant, sofern es auch - warum sollte es nicht - mit einem DirectByteBuffer funktioniert, auf das dadurch der JavaHeap nicht so belastet wird und evtl. gehen die Schreib- Lesevorgänge damit auch schneller.

 

[Fu3L]

Was ist denn deine Frage eigentlich? Beschreib mal deine Datenstruktur etwas genauer, sonst kann dir keiner einen passenden Hinweis geben.

Meine urspürungliche Frage ist ja gerade, wie meine Datenstruktur am besten aussehen sollte

Aber nachdem ich mich gestern Abend dran setzte Marching Cubes zu implementieren und es tatsächlich funktioniert, ist mir jetzt klarer, wie die Welt gespeichert werden soll. Zu Beginn der Erkundung eines Gebietes, werde ich meherere "Noise-Maps" generieren (oder andere Informationen, die eine Dichtefunktion versorgen könnten) und damit dann das Terrain zur Laufzeit modellieren. Dazu müssen dann aber noch die Positionen von Gebäuden/Bäumen/Artefakten abgespeichert werden. Außerdem müssen spezielle Gebiete gekennzeichnet sein (wie etwa der Einflussbereich einer Stadt (damit zum Beispiel Sounds wechseln können oder ein Ereignis ausgelöst werden kann). Außerdem sind dann natürlich informationen über die Stadt (zB Bewohner) nötig..

Eine Datenbank scheint mir dabei wirklich sehr verlockend, weil es für mich beim Implementieren den geringsten Aufwand bedeutet... Die Änderungen würden sich bei mir auch in Grenzen halten. Nur wenn man ein neues Gebiet betritt (das dann generiert wird), müsste gespeichert werden oder eben, wenn der Spieler einen Quest abschließt oder so, müsste gespeichert werden oder halt, wenn der Spieler auf Speichern drückt^^ Ich kann allerdings eben nicht einschätzen, ob ich vielleicht einen wirklich großen Nachteil übersehe oder unterschätze^^

@Spacerat: Das mit den Bezierkurven scheint ja recht üblich zu sein bei der Darstellung von 3D-Objekten und bietet den Vorteil, ganz einfach Anpassungen am LOD vorzunehmen ohne störende Kanten zu haben. Aber Marching Cubes scheint momentan das höchstgepriesene zu sein, auch wenn man da eben dieses Kantenproblem hat (gibts aber ne Dissertation zu, die eine Möglichkeit erwähnt, das zu vermeiden^^).

 

[Spacerat]

@Fu3l: Upsi... Ich hatte mir Minecraft noch gar nicht angesehen, aber die Erwähnung von Siedler und Anno 1404 hätten mich eigentlich drauf aufmerksam machen müssen, dass des Landscaping gar nicht so anspruchsvoll sein muss. Jetzt, da ich mir mal das Video auf der Minecraft-Seite betrachtet habe, komme ich zu dem Schluss, dass es noch viel anspruchsloser geht (sorry, aber das ist meine subjektive Meinung), mit "Lego" :lol: was mich fragen lässt, ob das so gewollt ist. Okay, MineCraft mal aussen vor. Lanscaping wie man es von Siedler oder Anno 1404 her kennt ist mir zum ersten mal - wenn auch untexturiert - in SimCity2000 begegnet. Dort konnte man während des Spieles auch noch "wahllos" Gebirge und Senken erstellen. So ganz "wahllos" ging das zwar dann auch nicht, weil man stets an einen Maximalwert an Schritten gebunden war. Erhob man also ein Gelände über diesen Wert hinaus, erhoben sich auch die umliegenden Felder. Die Höhen wurden dann mit den Koordinaten in der HeightMap für den Spielstand gespeichert. beim Laden dieses Spielstandes wurde eine Laufzeit Heightmap generiert, in welcher die berechneten Werte der Höhen für jede einzelne Bodenplatte standen. Andersherum, wenn man zur Laufzeit eine "nicht Spielstand Höhe" über den Maximalwert veränderte und dabei eine "Spielstand Höhe" veränderte, wurde diese Höhe natürlich auch im Spielstand ersetzt.
Naja... worauf ich mit dem Ganzen hinaus will; Wenn man für seine HeightMaps gewisse Regeln festlegt (z.B. maximale Steigung), ist man nicht mehr gezwungen jede einzelne Höhe im Spielstand zu speichern. "LPO" lol funktioniert also auch hier. Ob man nun Bezierkurven oder was auch immer für die Berechnung Laufzeithöhen verwendet bleibt jedem selbst überlassen.
Nun weiss ich allerdings nicht, ob du, nachdem die Beziers für dich uninteressant geworden sind, meinen vorherigen Beitrag überhaupt noch weiter gelesen hast. In dem 2. Link ging es nämlich um die effiziente Speicherung der Daten per ByteBuffer und FileChannel. Das solltest dir vllt. noch mal ansehen.

 

[schalentier]

@Fu3l: Du kannst hier nicht einfach fragen, was die optimale Datenstruktur ist, ohne dein "Problem" zu erklaeren.

Wichtig waere erstmal die Festlegung, ob du eine 2D Spielwelt, eine 2.5D Spielwelt (Heightmap) oder eine richtige 3D Spielwelt hast (Minecraft, Marching Cubes).

Oder willst du eine 2.5D (Duke Nukem) oder 3D (Quake) Spielewelt? Dann brauchst du was voellig anderes (BSP oder Portal-Engine).

@Spacerat: Der Clou an Minecraft ist, dass die Welt - im Gegensatz zu jedem mir bekannten Spiel - beliebig gross ist. Ganz so trivial dann vielleicht doch nicht ;-)

 

[Fu3L]

@Fu3l: Du kannst hier nicht einfach fragen, was die optimale Datenstruktur ist, ohne dein "Problem" zu erklaeren.

Wichtig waere erstmal die Festlegung, ob du eine 2D Spielwelt, eine 2.5D Spielwelt (Heightmap) oder eine richtige 3D Spielwelt hast (Minecraft, Marching Cubes).

Oder willst du eine 2.5D (Duke Nukem) oder 3D (Quake) Spielewelt? Dann brauchst du was voellig anderes (BSP oder Portal-Engine).

@Spacerat: Der Clou an Minecraft ist, dass die Welt - im Gegensatz zu jedem mir bekannten Spiel - beliebig gross ist. Ganz so trivial dann vielleicht doch nicht ;-)

Ich glaube das habe ich reichlich erklärt, wenn auch etwas verstreut in den ersten Posts^^
Eine 3D-Spielwelt mit der JMonkeyEngine für ein RPG mit einer Welt, die, wenn sie noch nicht erkundet wurde, zur Laufzeit neu generiert wird (Mein Traum von einem Spiel, dass für mich selbst etwas Unbekanntes bereit hält )
Und das geht, wie ich durch Fancys Link gelernt habe, wohl recht praktisch durch eine Dichtefunktion, die ihre Werte zB aus meheren "Noise-Maps" bezieht und dann per Marching Cubes in ein Mesh verwandelt wird. (Allerdings ist mir da noch nicht klar, wie ich so geniale Formationen, wie solche, die dort im letzten Drittel zu sehen sind, hinbekomme). Dazu bedarf es dann, wie gesagt, noch Informationen über die Positionen von weiteren 3D-Modellen, zB Gebäuden.

@Spacerat: Das zweite sehe ich mir doch noch einmal genauer an, ich habe es zugegebenermaßen nur überflogen und so schnell auch nicht ganz die Funktionweise nachvollziehen können.
Wenn ich das richtig sehe, befreit mich das nicht davon, wissen zu müssen, bei welcher Byte-Nummer welche für mich in dem Moment relevante Information steht... das ist das was mich so zu DBs hinzieht^^ Aber ich werde heute Nacht noch einmal genauer gucken

PS: Minecraft ist wirklich Klasse (aber ich mochte früher auch LEGO^^ )

 

[Spacerat]

@Schalentier: Okay... dann ist's was anderes. Aber iwie bin ich mir sicher, dass des bei 3D oder 2,5D Landscapes auch geht -> randomized HeightMaps.

@Fu3l: Der Zugriff auf eine solche Datei geschieht natürlich Index-Sequentiell (vergleichbar mit einem Verzeichniseintrag eines Dateisystems). Bei dieser Speichermethode habe ich mich von Egosoft's X-Reihe und der Havok-Engine (Oblivion, Fallout3) inspirieren lassen aber selbst so, also mit FileChannel und ByteBuffer noch nicht ausprobiert. Der ByteBuffer sollte sich natürlich "direct" verwenden lassen, sonst macht's keinen Sinn und man wäre mit 'ner DB wohl besser bedient. Schliesslich geht's hier immer noch darum den Java-Heap möglichst wenig zu belasten
3D-Welten lassen sich natürlich auf viele Arten erstellen - also MineCraft möchte ich bei meinem Wissensstand gerne schnell wieder vergessen . Eine Art, inspiriert durch Oblivion oder Fallout3, wäre z.B. eine kartenweise Anordnung von einzelnen Cells, welche sich, je nach dem wo man sich befindet und zur Vefügung stehendem Speicher, "on the fly" hinzu- bzw. wieder entladen lassen. Eine Cell beinhaltet die HeightMap des für diese Cell relevanten Landscapes, eine Map an GameObjects und eine weitere für NPCs. Woran man letztendlich auch noch denken muss; Während des Spiels dürfen sich die ursprünglichen Daten der Gesamtwelt niemals verändern, weil ein "Neues Spiel" dann fatalerweise nicht mehr möglich wäre. Praktisch muss man "ingame" deswegen mit einer Kopie aller Daten arbeiten und eben in diesem Punkt ist eine Datenbank höchst unkomfortabel. Ein Dateisystem wie in X oder anderen Games sind jedoch nur in ihrer Erstellung recht schwerfällig, weil diese auch erst aus einem GameEditor heraus gepackt werden müssen.

 

[Fu3L]

Während des Spiels dürfen sich die ursprünglichen Daten der Gesamtwelt niemals verändern, weil ein "Neues Spiel" dann fatalerweise nicht mehr möglich wäre.

Da sagst du was, an das ich noch gar nicht gedacht hatte.. Ich will zwar in jedem neuen Spiel neues Terrain generieren lassen, ABER wenn ich mehrere Spielstände pro Spiel zulassen würde, aber die evtl. recht groß werdenden Landschaften nicht in diese einzelnen Spielstände packen möchte, hätte ich evtl. das gleiche Problem. Insbesondere wenn evtl. in einer späteren Entwicklungsphase, wenn das "normale" erstma läuft, größere Events vllt die Landschaft verändern können...

Dieses cell-weise Vorgehen hatte ich mir auch schon überlegt (Das wäre anders mit dem vorhandenen Terrain-System der JME auch gar nicht möglich gewesen^^) und werds wohl auch mit dem neuen Vorgehen so machen..
Aber ich werde morgen weiter drüber nachdenken, jezz isses mir hier zu warm^^ xD