proggen.org

Hallo, in einigen anderen Threads hatte ich bereits davon erzählt: ich bastle (hauptsächlich um Neues zu lernen) an einem Framework (mit C++ und SDL) für 2D-Spiele mit isometrischer Darstellung (Diablo 2, Command & Conquer Tiberian Sun usw.).

Dabei brauche ich eine Art Dateiformat für Mapfiles (welche Kachel wo liegt usw.), Tilesets (welche Teile welcher Kacheln sind begehbar usw.) und "Entities". Unter Entities subsummiere ich alles was auf der Karte kreucht und fleucht: Skelette, Panzer, Feuerbälle, und was man sich alles überlegen kann.

Weil es so schön einfach ist einen Parser dafür zu schreiben - und weil die Art Dateien extrem einfach von Hand zu bearbeiten sind - verwende ich bisher INI-Files (wer die nicht mehr kennt: http://de.wikipedia.org/wiki/Initialisi ... tei#Aufbau)

Zum Beispiel folgendes Tileset:
dungeon.ini Dazu gehört eine Grafik mit mehreren Tiles, die ich anhand der Tilegröße und ihrer Indices (sowie etwas div und modulo ^^) rausschneiden und blitten kann.

Oder auch folgende Mapfile:
demo.ini Dabei unterscheide ich Boden-Kacheln (floor) und Wand-Kacheln (wall). Und auf Position (4,5) steht ein Skelett, das durch folgende Datei beschrieben wird:

skeleton.ini Ich will jetzt nicht jedes Detail der Dateien erklären - ist denke ich auch gar nicht notwendig.
Beim Laden einer Entity bekommt der Konstruktor den Dateinamen der Konfiguration, lädt diese erstmal und verpasst den Membervariablen dann den entsprechenden Wert.

Was haltet ihr von dieser Art der Datenhaltung? Sicherlich wird der ein oder andere mir zu XML raten. Wie wird es aber bei den "großen" Spielen (ich denke dabei an die MPQ-Dateien von Diablo2 oder die BIG-Dateien von C&C) gemacht? Soweit ich das überblicke, stecken da ja die Grafiken und Sounds mit drinnen, und sicher auch Konfigurationen Allein die Struktur der Daten finde ich schon hässlich: Ich weiß nicht so richtig, ob ich das so lassen sollte oder doch anders aufbaue (nicht nur die Ordnerstruktur ^^)

LG Glocke

Viele Programme nutzen zip-Archive, die sie dann umbenennen, also statt *.zip iwas wie *.cmf für "custom map file" oder was auch immer.
Dann wäre XML eine Option, wenn deine Maps größer werden kann man auch über binäre Datenspeicherung nachdenken, also ein int als int speichern und nicht als Text und du bildest dann einfach nur deine Datenstrukturen in der Datei nach. So wird es in der Regel für 3D-Modelle gemacht, weil bei mehreren Tausenden Punkten und Linien würde das mit Text nen leichten overheap bekommen.

cloidnerux hat geschrieben:Viele Programme nutzen zip-Archive, die sie dann umbenennen, also statt *.zip iwas wie *.cmf für "custom map file" oder was auch immer.

Die Idee kam mir auch schon. Das wäre für viele kleine Dateien sicher hilfreich.

cloidnerux hat geschrieben:Dann wäre XML eine Option, wenn deine Maps größer werden kann man auch über binäre Datenspeicherung nachdenken, also ein int als int speichern und nicht als Text und du bildest dann einfach nur deine Datenstrukturen in der Datei nach.

Ich denke darauf wird es sicherlich hinauslaufen was die maps angeht.

Prinzipiell könnte man auch Bilder (via SDL mit SDL_RWops) in eine Binärdatei schreiben. Nur weiß ich noch nicht, wie ich so eine Datei sinnvoll aufbaue. Effektiv brauche ich ja eine Art "Inhaltsverzeichnis", so nach dem Motto "Bild 1 ist x Bytes lang, Bild 2 y Bytes lang", damit ich dann die Bilder rauslesen kann. Sehe ich das richtig?

LG Glocke

Glocke hat geschrieben:Prinzipiell könnte man auch Bilder (via SDL mit SDL_RWops) in eine Binärdatei schreiben. Nur weiß ich noch nicht, wie ich so eine Datei sinnvoll aufbaue. Effektiv brauche ich ja eine Art "Inhaltsverzeichnis", so nach dem Motto "Bild 1 ist x Bytes lang, Bild 2 y Bytes lang", damit ich dann die Bilder rauslesen kann. Sehe ich das richtig?

Ich hatte mit Yoghurt kürzlich eine längere Aktion wegen serialisieren in Deiner Netzwerkfrage. Das Problem ist identisch: Du musst die Daten serialisieren. Du kannst Strukturen 1:1 wegschreiben - solange keine Zeiger enthalten sind.

Okay, ist der Ansatz mit diesem "Inhaltsverzeichnis" (nach wie vielen Bytes was zu finden ist und wie viele Bytes das lang ist) sinnvoll?

Glocke hat geschrieben:Okay, ist der Ansatz mit diesem "Inhaltsverzeichnis" (nach wie vielen Bytes was zu finden ist und wie viele Bytes das lang ist) sinnvoll?

Gibt verschiedene Möglichkeiten. Inhaltsverzeichnisse sind eine Möglichkeit, häufig finden sich sogenannte Chunks. Das Format selbst hat also keine geordnete Struktur, man findet einen Chunk-Identifier. Chunk-Identifier können beispielsweise ein Int sein, was quasi vier Buchstaben sein könnten. Zum Beispiel "MAP-" und hinter jedem Chunk die Größe des Chunks. Interessiert Dich "MAP-" nicht, springst Du einfach die entsprechenden Bytes weiter.
Hinter Map erwartest Du zuerst eine Struktur, die Breite und Höhe angibt: 2 ints. Danach folgen Breite mal Höhe Informationen mit dem Spielfeld.

Ein recht bekanntes Chunk-Format ist IFF. Von Microsoft kopiert, wurde u.a. WAVE draus. Chunk-Formate sind in der Regel Containerformate, das heißt, Du kannst reinpacken, was Du willst. Grafik, Ton, Text... Wenn Du mit einem Grafikprogramm eine Ton-Datei liest, überspringt das Programm einfach die Chunks, die es nicht versteht: Den Ton zum Beispiel.

Ich habe jetzt einige Zeit herum überlegt und werde erst einmal die Variante fahren, dass ich meine Struktur von INI- und Bild-Dateien weiterfahre, aber den Vorschlag mit den "umbenannten Zip-Archiven" (s.o.) umsetze.

Dazu habe ich noch eine Frage: Gehen wir mal davon aus, dass sich bei mir eine Masse von Kartenobjekten ansammelt. Darunter diverse Skelett-Arten (Skelettkrieger, Skelettmagier usw.) die als Gegner dienen sollen. Nun verwenden sie gemeinsam den gleichen Soundeffekt bei der Bewegung (z.B. ein knochiges Klappern). Prinzipiell gibt es ja zwei Möglichkeiten:

• Jedes Skelett-Archiv (das Frames und Konfiguration enthält) bekommt den Soundeffekt dazu. Damit besteht zwar ein gewisses Maß an Redundanz, jedes Skelett an sich ist aber individuell modifizierbar (z.B. könnte beim Skelettkrieger noch ein Rüstungsklappern bei der Bewegung dazukommen, welches beim ~magier nicht nötig ist).
• Alle "gemeinsam" genutzen Sounds werden in einem separaten Archiv gesammelt, so dass die Skelette gemeinsam auf ein und die gleiche Datei zugreifen können. Hier fällt klar die Redudanz weg (ist ja prinzipiell auch nicht nötig) und der Skelett-Bewegungs-Sound lässt sich an einer Stelle (im SFX-Archiv) ersetzen, so dass alle Skelette den gleichen Sound haben.

Die erstere Variante würde ich bisher bevorzugen. Da ist für mich klar, "was das Skelett alles beinhaltet" (Frames, Sounds, Konfiguration). Außerdem kann ich die Sounds dann individuell auf die genauen Objekte anpassen (und muss keinen Einheitssound für alle Skelette verwenden). Dagegen spricht die Redundanz. Allerdings frage ich mich, ob es bei einem Bewegungssound, der im OGG-Format vielleicht 10-15kb groß ist, so wichtig ist, dass man die Sounds zentral sammelt.
Was sagt ihr dazu?

LG Glocke

Also ich würde alle Sounds zusammen packen und die verschiedenen Einheiten über eine andere Datei definieren, wo nur so Sachen wie

• verwendete Sounds
• verwendete Grafiken
• Eigenschaften (Lebenspunkte, Schaden, Level, etc.)

festgelegt sind.
Vielleicht sogar als kleines Skript-File.

Dann hast du deine Assets beisammen und kannst die wirklichen Spielobjekte individuell gestalten. Eventuell lohnt es sich da sogar einen kleinen Editor zu schreiben, mit dem du die Objekte erstellen/ändern kannst und der dir die oben genannten Dateien(/Skripte) erstellt.

Yoghurt hat geschrieben:Eventuell lohnt es sich da sogar einen kleinen Editor zu schreiben, mit dem du die Objekte erstellen/ändern kannst und der dir die oben genannten Dateien(/Skripte) erstellt.

Über so einen Editor habe ich auch schon nachgedacht Wenn ich das doch mit Binärdateien mache (Konfiguration, Bilder und Sounds in eine Binärdatei gespeichert), würde sich ein Editor vermutlich richtig lohnen.

Yoghurt hat geschrieben:Also ich würde alle Sounds zusammen packen und die verschiedenen Einheiten über eine andere Datei definieren.

Alle Einheiten in eine Datei zu packen erscheint mir etwas ... keine Ahnung
Ich hab da vor Augen, ich will später eine weitere Einheit hinzufügen und muss dann dir große Einheiten-Datei laden, das Zeug anfügen und so
Wenn alle Einheiten in einer Datei wären, würde sich das aber für die Sounds in einer separaten Datei anbieten, da gebe ich dir recht

LG Glocke

Glocke hat geschrieben:

Yoghurt hat geschrieben:Eventuell lohnt es sich da sogar einen kleinen Editor zu schreiben, mit dem du die Objekte erstellen/ändern kannst und der dir die oben genannten Dateien(/Skripte) erstellt.

Über so einen Editor habe ich auch schon nachgedacht Wenn ich das doch mit Binärdateien mache (Konfiguration, Bilder und Sounds in eine Binärdatei gespeichert), würde sich ein Editor vermutlich richtig lohnen.

Ich denke das lohnt sich genau so für Archive oder sonst was (zumindest ab einem mittelgroßen Projekt), weil du dann nicht mehr die Dateien bearbeiten musst sondern das schön im Editor (nicht im Texteditor ) machen kannst.

Glocke hat geschrieben:

Yoghurt hat geschrieben:Also ich würde alle Sounds zusammen packen und die verschiedenen Einheiten über eine andere Datei definieren.

Alle Einheiten in eine Datei zu packen erscheint mir etwas ... keine Ahnung
Ich hab da vor Augen, ich will später eine weitere Einheit hinzufügen und muss dann dir große Einheiten-Datei laden, das Zeug anfügen und so
Wenn alle Einheiten in einer Datei wären, würde sich das aber für die Sounds in einer separaten Datei anbieten, da gebe ich dir recht

Ich glaube du hast mich etwas missverstanden.
Was ich meinte ist, dass du die Assets bündeln sollst. Zum Beispiel alle Einheiten-Sounds zusammen oder wenns sowieso nicht so viele Sounds sind, alle Sounds in ein Archiv.

Die Einheiten natürlich alle in einer seperaten Datei definieren, wie ich bei meinem letzten Post schon beschrieben habe.
Dann hättest du zum Beispiel zwei Dateien "skeleton_warrior.dat" und "skeleton_mage.dat". Darin sind dann die Eigenschaften der beiden Einheiten und die verwendeten Sounds definiert.
Willst du eine neue Einheit brauchst du nur eine neue Datei "skeleton_berserk.dat" erstellen und kannst darin die neue Einheit definieren und natürlich auch die Assets die schon da sind verwenden. So hast du nichts redundant gespeichert.