Technische Informationen zum Dateiformat von BlueByte's BATTLE ISLE ================================ Die folgenden Informationen habe ich in einwöchiger Arbeit durch Analyse der Dateien im MAP-Directory gewonnen. Durch Versuch und Irrtum sowie logisches Kombinieren habe ich die gespeicherten Daten soweit möglich identifiziert. Ich finde das weitaus interessanter als ein Kreuzworträtsel und hoffe, daß sich möglichst viele Leute finden lassen, die dasselbe bei anderen komplexen Programmen machen, so daß man noch viel mehr Spaß an diesen Spielen hat. Da BlueByte es versäumt hat, seinem (wirklich tollen !!!) Spiel Battle Isle einen Leveleditor beizulegen, ist nach spätestens 32 Spielen die Luft raus. Im Battle Isle (von jetzt an BI) - Artikel der POWERPLAY ist das ja schon bedauernd angemerkt worden. Ich vermute, daß BlueByte vorhat, so in ungefähr einem halben Jahr, wenn alle die 32 level durchgespielt haben, mit dem Leveleditor auf den Markt zu kommen, vielleicht für schlappe DM 50.- oder so...(siehe SimCity). Ich hasse es aber, für etwas, das nach meiner Meinung zu so einem komplexen Taktikspiel gehört, nochmal extra zur Kasse gebeten zu werden (oder es vielleicht am Ende gar nicht zu bekommen, oh weh..). Darum habe ich mich, noch bevor ich die ersten drei Level durchgespielt hatte hingesetzt, und die Dateistrukturen untersucht. Herausgekommen ist diese Dokumentation, sowie drei Programme, mit denen man sich seine eigenen Level zusammenbasteln kann, ohne auf weitere Käufe angewiesen zu sein. Sorry BlueByte... Ich muß zunächst noch vorausschicken, daß ich nicht jedes einzelne Byte identifiziert habe. Die Bedeutung von einigen ist mir noch unklar, aber bei diesen konnte ich durch vielfältige Versuche herausfinden, daß nahezu beliebige Änderungen, oder aber das Fixieren auf einen bestimmten Wert, ohne jede Auswirkung auf den Programmablauf zu bleiben scheinen (ohne Garantie). Ich bezeichne solche Bytes als "unkritisch". Vielleicht setze ich mich nochmal dran und arbeite weiter, oder einer von euch findet es heraus. In letzterem Fall benachrichtigt mich bitte, für den ersteren Fall solltet ihr sporadisch nachsehen, ob ich eine neue Version veröffentliche (ein Verwaltungsprogramm für Levels kommt vielleicht noch in diesem Jahr). Auf alle Fälle erreicht ihr mich über die PCC-Mailbox in Duisburg unter 02065-74199 (2400 Bd) unter dem Namen Pius_XII (ihr seht, auch auf diesem Programm liegt mein Segen....). Bei Adressangaben in Files gilt immer folgende Konvention: Sektoren haben immer 512 Bytes und der erste Sektor hat die Nummer 1. Offsets dagegen beginnen bei 0 zu zählen. Das ist die Adressierungsart meines Monitors (Filemaster).Will man daraus ein Offset in einem File berechnen (z.B. für die fseek-Function) so geht das mit (Sector-1) *512 + Offset. Byteinhalte gebe ich fast immer in Hex an, kenntlich am vorangestellten 0x. Noch ein letztes Wort: Falls ihr erwartet, daß ich euch einen tollen grafischen Leveleditor geschrieben habe, muß ich euch leider enttäuschen. Meine Zeit ist auch nicht unendlich und ich habe viele, viele, viele andere Sachen zu tun. Darum habe ich auch nur eine Art Compiler geschrieben, der ein Textfile in einer Art "Levelbeschreibungssprache" einliest und daraus einen Level erzeugt. Vielleicht schreibt ja einer von euch das grafische Interface. 1.) Dateiorganisation Die Dateien, die die einzelnen Level beschreiben sind im Directory MAP zusammengefaßt. Ihr findet es auf der zweiten Diskette oder als Unterverzeichnis von BATTLEISLE auf eurer HD. Für jeden Level befinden sich in diesem Directory 3 resp. 4 Dateien. Die ersten 16 Level, die für den Zweispielermodus sind, bestehen aus 3, die restlichen 16, für den Computerspielermodus, aus jeweils vier. Die Dateien eines Levels haben als Namen eine zweistellige Dezimalzahl, dann einen Punkt und dann die dreistellige Erweiterung. Die ersten 16 Level tragen die Namen 00 bis 15, die restlichen die Namen 16 bis 31. Im Map-Directory sind übrigens noch zwei weitere Level versteckt. Ihr könnt diese Dateien einfach unter einen anderen Levelnamen kopieren (z.B. 00 oder 16) und dann damit spielen. Die Erweiterungen sind FIN, PMP und SHP. Bei den Computerleveln kommt noch die COM Datei dazu. 2.) Passwörter (PW) Die PWs sind im PMP-File zu Anfang gespeichert. Eine Änderung hier wirkt sich jedoch nicht auf das Spiel aus, d.h. ihr könnt hier hineinschreiben was ihr wollt, es gelten doch die alten PWs. Offensichtlich existiert noch eine weitere Datei, in der die PWs nochmal stehen, ich habe sie aber nicht gefunden (auch nicht gründlich danach gesucht, denn was soll man mit dem Ding?) Glücklicherweise kann man sie jedoch auslesen. Hier sind alle bekannten PWs der 32 Level (Bei einigen stand komischerweise kein gültiges PW an dieser Stelle): 2-Spieler Level PW Computer Level PW ----------------------------------------------------------------------- 0 FIRST 16 CONRA 1 GHOST 17 PHASE 2 GAMMA 18 EXOTY 3 MARSS 19 MOUNT 4 EAGLE 20 FIGHT 5 METAN 21 RUSTY 6 FOTON 22 FIFTH 7 POLAR 23 VESUV 8 TIGER 24 MAGIC 9 ????? 25 SPACE 10 ZENIT 26 VALEY 11 DONNN 27 TESTY 12 VESTA 28 TERRA 13 OXXID 29 SLAVE 14 ????? 30 NEVER 15 ????? 31 RIVER 3.) Das FIN-File Dieses File ist das am einfachsten aufgebaute. Es enthält die Hex-Karte, sowie deren Ausmaße. Zunächst zur Speicherung der Hexkarte. Wenn man sie genauer betrachtet fällt auf, daß man zwei aufeinanderfolgende Zeilen folgendermaßen zeichnen kann (dabei gehören die Felder die mit x bezeichnet sind zur ersten und die mit o bezeichneten zur zweiten Zeile): x x x x x x x x x oxoxoxoxoxoxoxoxox o o o o o o o o o o Man sieht also, daß die Reihen verzahnt sind. Das fällt auch im Spiel auf, wenn man den Cursor mit dem Joystick nach rechts bewegt. Dann wandert er ja auch im Zickzack nach rechts, folgt also einer Hexzeile. Diese Hexzeilen werden nun im FIN-File Zeile für Zeile abgespeichert, wobei die "Gummizeile" quasi "auseinandergezogen" wird. Im FIN-File stehen diese beiden Zeilen also als: xxxxxxxxxxxxxxxxxxxx oooooooooooooooooooo Das ist auch schon alles! Natürlich ist das FIN-File, ebensowenig wie die anderen Files, ein ASCII-File, sondern alle Daten sind binär gespeichert. Fast ausnahmslos werden übrigens 2-Byte Zahlen verwendet, in C müssen sie also als USHORT und nicht als int (4 Bytes) definiert werden. Der Aufbau des FIN-Files ist nun folgender: 2 Bytes für die Anzahl Spalten der Karte (maximal 64 !) 2 Bytes für die Anzahl Zeilen der Karte (maximal 64 !) Nun folgt Zeile für Zeile, wobei jedes Hexfeld in 2 aufeinanderfolgenden Bytes abgespeichert wird. Das erste Byte stellt den Terraincode, also die Landschaft dar, das zweite Byte stellt die auf diesem Feld zu Spielbeginn stehende Unit dar. Steht dort keine Unit, ist das zweite Byte auf 0xFF zu setzen. Ein Spielfeld mit 64 * 40 Feldern hat also 5124 Bytes (4 Byte Header + 64 * 40 * 2 ). Unit- und Terraincodes sind in zwei separaten Files enthalten (Terrain.iff bzw Unit.txt). Das Terrain-File stellt ein IFF-Bild dar, das z.B. mit DPaint ausgedruckt werden kann. Es enthält alle vorkommenden Terrains mit ihrem Code (danke Actionreplay...). Das Unit-File ist ein normales ASCII-File, das die Unitnamen und ihre technischen Daten enthält (solltet ihr eigentlich im Handbuch haben..) sowie zwei Codes. Die erste Zahl stellt die betreffende Unit als rote Unit dar, die zweite Zahl als gelbe. Habt ihr z.B. im FIN-File am Offset 4 die beiden Bytes 0302 so stellt das in der oberen linke Ecke des Spielfeldes ein Wiesenterrain dar (03) auf dem ein roter Demon steht (02). Hättet ihr dort stattdessen 0303, so wäre statt des roten ein gelber Demon dort stationiert, so einfach ist das. Ihr dürft nur die in den Tabellen angegebenen Terrain- und Unitcodes verwenden! Ich habe die anderen auch ausprobiert, glaubt mir: Es gibt weder neue Terrains noch neue Units, sondern allenfalls einen Rechnerabsturz. 4.) Das PMP-File Dieses File ist schon wesentlich komplizierter. Sein einziger Inhalt scheint die Übersichtskarte zu sein, die durch den Auge-Cursor auf den Schirm gebracht wird. "Scheint" deshalb, weil hinter den von mir identifizierten Bilddaten noch weitere Daten stehen, deren Sinn ich bis jetzt nicht erkennen konnte.Da ein Null-setzen dieser Bytes jedoch ohne erkennbare Wirkung blieb, habe ich sie als unkritisch eingestuft. Vielleicht wird die Karte ja auch nur verschwenderisch abgespeichert. Das kann durchaus so sein, denn am Fileanfang wird auch eine Bitplane komplett vergeudet, wie ihr gleich sehen werdet. Die ersten 8 Bytes (0-7) enthalten das PW.Bei den Zweispieler-Files steht davor noch eine laufende Nummer.Da diese 8 Bytes aber offenbar keinen Einfluß auf die PW-Abfrage im Programm haben, kann man sie auch ohne weiteres mit Space auffüllen. Nun folgen zwei Bytes (8-9), deren Sinn ich nicht kenne, aber Versuche haben gezeigt, daß ein Wert von 0x0F0F hier immer richtig ist. Die nächsten beiden Bytes (10-11) enthalten die Anzahl Bytes pro Bitplane + 24. Letzteres ist nämlich die Gesamtzahl Bytes, die für diesen Header draufgehen. Die Anzahl Bytes pro Bitplane errechnet sich als (Spalten * Zeilen) / 8. Hier dürfen übrigens nicht die Werte aus dem FIN-File verwendet werden, sondern nur die von Offset 21-23 (s.u.) !!!!!!! Jetzt folgen sechs unkritische Bytes (12-17), die auf 0 gesetzt werden können. Die folgende 2-Byte Zahl (18-19) enthält die Anzahl 16-Pixel Blöcke pro Zeile. Hat die Bitplane also z.B. 64 Spalten, so enthält eine Zeile 4 Blöcke a 16 Bit. Hier steht im Grunde also der Wert von Offset 20-21 geteilt durch 16. Es ist vielleicht ganz gut nur solche Karten zu erstellen, deren Spaltenzahl durch 16 teilbar ist, aber bisher habe ich auch bei anderen Ausmaße keine Abstürze o.ä. Katastrophen erlebt. Nun folgen zwei Bytes (20-21) die die Anzahl Spalten des Übersichtskartenbildes enthalten. Hierbei gilt es zu beachten, daß ein Hexfeld aus dem FIN-File durch einen 2*2 Block in der Übersichtskarte dargestellt wird, also durch 4 Bytes. Der Wert für die Spaltenzahl im Hexfile (FIN-File) ist also mit 2 zu multiplizieren und dann erst hier einzutragen ! Es folgen 2 Bytes (22-23) für die Anzahl Zeilen. Hier gilt dasselbe wie für die Spalten. Gesetzt den Fall, die Hexkarte mißt 16 Zeilen a 32 Spalten = 512 Felder. Dann mißt die Übersichtskarte 32 Zeilen a 64 Spalten = 2048 Pixel. Dieser Wert durch 8 ergibt 256 Bytes pro Bitplane. Am Offset 10 steht daher die Zahl 280 (=256 + 24). An genau diesem Offset beginnt jetzt die erste Bitplane. Der Rest, zwischen dem Ende des Headers und diesem Offset wird mit dem Wert 0xFF aufgefüllt. Ab 280 stehen 4 Bitplanes hintereinander. Die erste geht also von 280 bis 535 (=Sektor 2, Offset 23 ), die zweite von 536 (Sektor 2, Offset 24) bis 791 (=Sektor 2, Offset 279 ) usw. Nach der letzten Bitplane hängt noch mindestens eine weitere mit wirren Zahlen, die aber offenbar nicht benutzt wird, denn man kann alle Werte auf 0 setzen. Ich hänge da immer 3000 Nullbytes an, um ganz sicherzugehen. Die Anzahl Bytes pro Zeile in einer Bitplane errechnet sich als Spaltenzahl (von Offset 20-21) dividiert durch 8. Dieser Wert wird aber nicht gespeichert. Die Bitplanes sind nun völlig normal aufgebaut, d.h. zuerst wird die erste Zeile abgespeichert, dann die zweite usw. Danach kommt, wie gesagt, die zweite Bitplane, Zeile für Zeile usw. Die folgende Tabelle gibt Auskunft über die Farbzuordnung. Bei der dualen Notation gilt folgende Konvention: die erste Bitplane im File stellt die am weitesten links stehende Dualziffer (Stellenwert 8), die zweite Bitplane den Stellenwert 4, die dritte den Wert 2 und die vierte steht für die Einerstellen. Insgesammt gilt daher: Dezzahl Bitplanes Farbe 1 2 3 4 ---------------------------------------------------- 0 0 0 0 0 schwarz 1 0 0 0 1 hellgrün 2 0 0 1 0 dunkelrot 3 0 0 1 1 graugrün 4 0 1 0 0 hellrot 5 0 1 0 1 mittelgrün (hell) 6 0 1 1 0 graublau (dunkel) 7 0 1 1 1 hellgrau 8 1 0 0 0 weiß 9 1 0 0 1 mittelgrün (dunkel) 10 1 0 1 0 graublau (hell) 11 1 0 1 1 grau 12 1 1 0 0 mittelrot 13 1 1 0 1 dunkelgrün 14 1 1 1 0 dunkelblau 15 1 1 1 1 graubraun Die Zuordnung der Farben zu den Terraintypen habe ich mit einem Testprogramm ermittelt, das mir eine Tabelle ausgab. Ich verzichte hier auf dii Wiedergabe der Tabelle, denn im File BI_Compiler.C ist sie als Terrain_Color abgespeichert. An dieser Stelle noch ein Wort zur entsprechenden Funktion des BI_Compilers: Die erzeugte Übersichtskarte ist etwas eckig, da jedes Hexfeld exakt als 4 Pixel Block dargestellt wird. Vielleicht werde ich im Laufe dieses Jahres (1991) ein Programm entwickeln, das die Karte aus dem File extrahiert und als IFF-File abspeichert, so daß man sie nachbearbeiten kann und das Ergebnis wieder ins PMP-File übernimmt. Wie gesagt vielleicht....Schaut mal sporadisch in unsere Box.... Damit ist auch dieses File abgehandelt! 5.) Das SHP-File Wie ihr wißt, kann man zu Spielbeginn im HQ, in den Factories und Depots sowie in den Transportern bereits schöne Überraschungen in Form von Kriegsmaterial vorfinden. Die Informationen über diese Ladungen sind nun im SHP-File gespeichert. Die ersten 27 Bytes (0-26) sind mir wiederum unbekannt. Sie sind entweder 00 oder 01, aber der Wert scheint keinen Einfluß zu haben. Danach kommt ein Byte, das die Anzahl der noch folgenden Einträge in diesem File angibt, also die Gesamtzahl aller Objekte auf dem Spielfeld, die zu Spielbeginn irgendetwas enthalten. Ich beschreibe zunächst einmal die Form eines dieser Datensätze, danach gehe ich auf die Anordnung der Datensätze im File ein. Ein Datensatz besteht aus 12 Bytes mit folgenden Bedeutungen: Bytenr Inhalt ------------------------------------------------------------------------------ 0 Eigentümer dieses Objektes. 0=Rot, 1=Gelb, 2=Neutral (nur Gebäude) 1 Art des Objektes, das durch diesen Eintrag beschrieben wird. 0=HQ, 1=Factory, 2=Depot, 3=Transportfahrzeug 2 Index. Diese Nummer muß innerhalb der Artklasse (z.B. Depots oder Transporter) einmalig sein. Bedeutung wird weiter unten erklärt. 3 Aldiniumvorrat (nur bei Gebäuden) 4 Unbekannt, unkritisch bei 00 5-11 7 Bytes für die 7 möglichen Inhalte des Objektes. Hier steht eine Typennummer aus der Typtabelle, aber eine modifizierte. Soll z.B. ein FR-V Buster geladen sein (Unitnummer 10 für Rot, 11 für gelb), dann steht hier 5, also das ganzzahlige Ergebnis der Division der eigentlichen Unitnummer durch 2. Der Besitzer ergibt sich aus dem Besitzer des Objektes selber. Nun zu der Anordnung der Datensätze und zur Bedeutung des Index.das im Folgenden gesagte gilt separat für jede Gruppe von Objekten, also für alle HQs, für alle Factories, alle Depots und alle Transporter. Ich stelle den Sachverhalt mal am Beispiel der Transporter dar, weil das die komplizierteste Gruppe ist. Wenn man die Karte zeilenweise von oben nach unten betrachtet und jede Zeile von links nach rechts (also so wie wir lesen gelernt haben, Araber und Chinesen sind hier im Nachteil) dann treffen wir auf eine Reihe von Transportfahrzeugen. Alle Fahrzeuge, die in der Unittabelle als Transporter ausgewiesen sind müssen dabei beachtet werden! Denken wir uns jetzt die Fahrzeuge in der Reihenfolge, in der wir ihnen beim lesen der Karte begegnen in eine Liste eingetragen. Dann können wir dem obersten Fahrzeug in der Liste die Nummer 0 geben, dem nächsten die Nummer 1 usw. Diese Nummerierung geschieht ohne Rücksicht auf den Besitzer, nur die Reihenfolge zählt. Diese Nummer ist der oben erwähnte Index. Wenn ein Objekt nun keinerlei Inhalt haben soll, dann braucht man es nicht weiter zu berücksichtigen und kann es aus der Liste streichen. Aus den übriggebliebenen Objekten werden nun die oben beschriebenen Datensätze erstellt und in beliebiger Reihenfolge ins SHP-File geschrieben. Im SHP-File stehen also nur Einträge für nicht-leere Objekte. Dabei darf die vorher erteilte Indexnummer aber nicht mehr verändert werden! Auf diese Weise behandelt man also der Reihe nach die HQs, die Factories, die Depots und zum Schluß die Transporter (Bitte diese Folge einhalten). Innerhalb einer Gruppe können die Eintrage, wie gesagt, unsortiert sein. ACHTUNG: Wenn man in einem Datensatz einen anderen Besitzer einträgt, als das aufgrund der Position korrespondierende Objekt hat, hat man z.B. in einem roten Schiff gelbe Panzer (Was passiert dann eigentlich?). Tja, das wars schon wieder..... 6.) Das COM-File Das geht am schnellsten. Ich weiß GAR NICHTS über dieses File. Ich weiß nur, daß es bei allen Levels dabei ist, die einen Computerspieler ermöglichen und bei den anderen nicht. Ich habe die COM-Files wild untereinander ausgetauscht, habe sie zu den Zweispielerlevels dazukopiert, habe ihren Inhalt wild zerstört: Es tat sich absolut nichts, man hat das Gefühl, sie müssen nur da sein. Aus diesem Grunde kopiere ich einfach das größte COM-File (31.COM) zu jedem neu erstellten Level dazu (macht der BI-Compiler automatisch). Für Hinweise was es damit auf sich hat, wäre ich äußerst dankbar. Ich vermute (ohne jeden Beweis allerdings), daß sich hierüber irgendwie das Verhalten des Computergegners steuern läßt. Also: Jugend forscht........ 7.Organisation der neuen Level. Hier habe ich nur ein paar Tips für euch. Wenn ihr einen neuen Level anlegt, dann gebt ihm eine neue Nummer. Startet z.B. mit 34. der Compiler legt den Level für euch an (Achtung, er überschreibt einen bereits unter dieser Nummer vorhandenen Level!) .Ihr solltet alle neuen Level in einem eigenen Archivdirectory speichern. Wenn ihr dann einen Level spielen wollt, kopiert alle vier Files einfach ins MAP Directory unter der Nummer 00 oder 16, je nachdem ob ihr zu zweit oder allein spielen wollt (copy archiv/34.com map/00.com usw.....). Da die PWs fest vorgegeben sind, könnt ihr euren Level durch Angabe des entsprechenden PWs anwählen. 8.) Weitere Tips Ein kleiner Hinweis: Im BattleIsle-Programmdirectory steht das File UNIT.DAT. Darin sind alle Festwerte der einzelnen Unit gespeichert, also Bewegungswert, Produktionskosten usw. Ich habe die Daten allerdings nicht identifiziert, weil's mich nicht reizt, sie zu verändern, aber wer's mag.... Interessanter ist schon, daß darin auch die Namen der Units stehen. Wer also statt Demon lieber eine Infanterie hat und statt Crusaders lieber Leoparden, der kann die Texte mit einem Monitor verändern.