Bevor hier tatsächlich noch Schimmel ansetzt, belästige ich die werte Leserschaft lieber nochmal mit den aktuellsten Vorgängen in Bezug auf die Webseite und SPACOLA Eclipse. Hierzu habe ich mir eine kleine Liste bereitgelegt, die ich jetzt in einem mehr oder weniger kurzen Artikel abfrühstücken möchte. Am liebsten hätte ich die Gelegenheit genutzt, meine Meinung zur kürzlich angekündigten st-computer-Ausgabe kundzutun, doch wie es scheint, bekommen die Käufer die Februar-Ausgabe frühestens Mitte März, daher wird das wohl noch etwas dauern.

Stattdessen habe ich die Aufmerksamkeit für mein kleines Dongleware-Museum in kreative Energie umgewandelt und einige Einträge hinzugefügt bzw. erweitert. Hinzugekommen ist das wenig bekannte Spiel „The Dragon’s Power“, das von Dongleware 1994 vertrieben wurde, von welchem ich erst vor wenigen Monaten erfuhr. Ebenfalls ist mir entgangen, dass ich doch tatsächlich eines der Schneider’schen TOS-Gimmicks vergessen habe: Das Accessory „Blackhole“, das den Papierkorb in ein schwarzes Loch verwandelt. Es war eigentlich nur eine Beilage zum TOS-Gimmick „Trashy“. Die Beschreibungen der Gimmicks habe ich zusätzlich erweitert und mir auch die Quelltexte der kleinen Programme abgespeichert. Einen Teil der Codes kann ich vielleicht in das Remake-Projekt einbringen.

Besonderen Dank möchte ich an dieser Stelle übrigens einer Leserin des Blogs aussprechen, die mir aus heiterem Himmel ihr OXYD-Buch (guterhalten), und das passende Spiel auf CD per Post geschickt hat. Das war eine äußerst schöne Überraschung. Eine kleine Aufwandsentschädigung habe ich ihr dafür natürlich zukommen lassen. Meine Dongleware-Büchersammlung wurde auch durch einen weiteren SPACOLA Sternenatlas vergrößert, den ich für nicht einmal vier Euro bestellen konnte. Der Einband ist leider ein wenig beschmiert, und auch kleine Eselsohren waren wie erwartet drin, aber ich denke ich kann mich nicht beklagen. Damit habe ich nun also vier SPACOLA-Codebücher in meinem Besitz. Einem weiteren Leser und fleißigen Bolo-Spieler ist es zu verdanken, dass ich bei nächster Gelegenheit eine kleine Levelgalerie für Bolo (1995) und Dia-Bolo einweihen kann. Diese ist zwar nicht ganz vollständig, aber was nicht ist, kann ja noch werden. Der nächste Urlaub ist insoweit schon verplant.

Was gibts über SPACOLA Eclipse zu sagen? Der Fortschritt ist unverändert langsam, aber beständig. Der Zähler steht jetzt bei 20.000 Java-Codezeilen. Jeden Tag bemühe ich mich um ein oder zwei Änderungen, ein paar Fehler zu beheben, ein paar Grafikdateien zu korrigieren, etc. Die Februar-Version steht ganz im Geiste der Originaltreue und Platzersparnis. Ich habe herausgefunden, dass das PNG-Dateiformat sogar 1-Bit-Farbtiefe kennt (echt monochrom!) und habe sämtliche 700+ Grafikdateien einzeln umgewandelt und neu gespeichert. Am Ende hatte ich 64 Kilobyte von 415 gespart. 15% unnötige Daten entfernt, also wenn das nichts ist. Außerdem ist es mir gelungen, mit einem Hexeditor und viel Geduld in mühsamer Kleinstarbeit den SPACOLA-Rentenbescheid aus einem Memory-Dump des ST-Spiels zu extrahieren, und zusätzlich (endlich byte-genau) fast alle SDD-Sounddateien, also exakt so wie sie vor der „Kopierschutz-Kompression“ aussahen. Anschließend habe ich die Soundbibliothek meines Remakes so erweitert, dass sie die Original-8-Bit-PCM-Dateien importieren und verwenden kann. Damit wäre ich wieder einen kleinen Schritt näher am Atari-Vorbild.

Nachdem ich mich also im Februar weitestgehend nur um die Technik unter der Haube gekümmert habe, ist diesen Monat wieder mal das Gameplay dran. Die letzten Tage gelang es mir, alle 14 Minenfeld-Konstellationen aus den Levels des Originals zu analysieren und in meinem Code umzusetzen. Nun steht dem geplanten Parser für die Levelkonfiguration der ST-Version nicht mehr viel im Wege. Das Level-„Skript“ habe ich inzwischen zu etwa 80% entschlüsselt, nur einige wenige Parameter, die etwa das Standardverhalten der Gegner ändern, oder Häufigkeitsmodifikatoren sind mir leider nicht ganz klar. In meinem Analyseprozess ist mir übrigens aufgefallen, dass die Entwickler in ihrer Levelkonfiguration eindeutig einen Fehler gemacht haben: In Level 14 müssten laut Skript sämtliche Sektoren mit Minenfeldern ausgestattet sein, doch da taucht kein einziges auf. Das Problem ist, dass sich dort im Skript jemand vertippt hat, so dass gar keine Minenfelder erzeugt werden. Im Debugger konnte ich bereits nachstellen, dass sich das Level deutlich ändert, wenn man den Tippfehler im Speicher korrigiert. Wenn ich nicht von dem Spiel besessen wäre, wäre das wahrscheinlich nie jemandem aufgefallen.

Jetzt stehe ich vor einer merkwürdigen Entscheidung: Tippfehler im Remake korrigieren und das Level so nachstellen, wie die Entwickler es sich eigentlich gedacht hatten – oder Tippfehler beibehalten, und das Level so nachstellen, wie es das Originalspiel auch wirklich dargestellt hat? Vor einem ähnlichen Problem stand vor einigen Jahren der Entwickler des Dungeon-Keeper-Remakes „KeeperFX“, der bei seiner Reverse-Engineering-Odyssee herausgefunden hat, dass die Bullfrog-Programmierer einen ganz blöden Fehler im Zusammenhang mit dem „Machtwort“-Zauberspruch nie richtig beheben konnten. In der Folge war der Zauberspruch viel schwächer als er eigentlich sein müsste. Nachdem er den Fehler nun also gefunden und im Remake behoben hatte, und der Zauberspruch plötzlich genau die Wirkung zeigte, wie es von Anfang an gedacht war, war das Balancing im Spiel leider total im Arsch. Logisch: Das Spiel war immer nur mit dem „verkrüppelten“ Zauberspruch getestet und feingeschliffen worden. Tatsächlich gibt es im Remake nun die Möglichkeit, den Fehler für die Originalkampagne wieder zu „aktivieren“, um das bekannte Spielbalancing nicht zu verändern. Vielleicht sollte ich das Problem auch via Optionsmenü lösen, und so dem Spieler die Entscheidung überlassen.