Seit Jahren angekündigt, und doch nie abgeliefert. Bis heute: Das neue Preview-Video zu meinem kleinen SPACOLA-Remake ist da. Nur endlos weiter über den Entwicklungsfortschritt zu schreiben, ist auf Dauer zu langweilig, und ein paar Bewegtbilder machen den Eindruck doch unendlich viel greifbarer, daher habe ich mich nach allem Zögern nun doch dazu durchringen können, ein bisschen was aufzuzeichnen und zusammenzuschneiden. Dass ich ein unentdecktes Talent für Videobearbeitung hätte, kann ich dadurch zwar leider nicht unter Beweis stellen, aber vielleicht reicht es wenigstens, um zu erkennen, wie das Remake mittlerweile aussieht. Und ohne weitere Umschweife, here we go:
Hauptsächlich soll das Video zur aktuellen Work-In-Progress Version 0.9.6 vom September 2020 (Corona Edition) zwei Dinge mehr oder weniger veranschaulichen: Erstens, das Spiel ist inzwischen fast durchgängig in Farbe spielbar, mit einer höheren Framerate, und es gibt eine ganze Menge erweiterte Features und Verbesserungen, neue Gegner, neue Waffen, hektische und gnadenlose Action, Replays, und noch so einiges mehr. Und zweitens, das Spiel ist leider auch nach zehn Jahren Entwicklungsszeit noch lange nicht fertig. Krass, ne?
Wie ich kürzlich jemandem sinngemäß schrieb, kann der Spieler in dem Remake noch keine echten Fortschritte machen, die Original-Levelskripte werden noch nicht vollständig unterstützt, die Gegner verhalten sich praktisch alle falsch, und es fehlt noch eine ganze Menge Kleinkram, der das Gameplay abrundet und das Geballer zu einem echten Spiel macht. Im Moment ist SPACOLA Eclipse mehr so eine Art 2D Arcade Retro Space-Sandbox, und noch kein wirkliches Spiel.
Falls sich jemand wundert, wieso das Fenster in dem Video so klein aussieht, und man viele Menüs so gar nicht vollständig sieht: Die Grafik ist problemlos skalierbar von 640×400 auf 1280×800 oder 1920×1200. Dadurch wird auch das Fenster größer. Für das Aufzeichnen des Gameplays in OBS wollte ich meine angestaubte Hardware aber nicht komplett überfordern, und habe daher nur die Standard-Auflösung gewählt. Im Vollbild macht das auch fast keinen Unterschied, lediglich einige Teile von geöffneten Dialogen und Menüs waren dadurch bei der Aufnahme eben nicht komplett im Bild und wurden abgeschnitten. Das ändert jedoch nichts daran, dass alles einwandfrei funktioniert.
Da ich – wie ebenfalls seit Monaten angekündigt – bald endgültig von Windows 7 zu Linux wechseln werde, und ich höchstwahrscheinlich gerade in der Anfangszeit doch so einiges an der Linux-Kompatibilität des Remakes schrauben muss, was mich vermutlich um Wochen oder sogar Monate zurückwerfen wird, wollte ich dieses Video auf jeden Fall vorher fertigstellen und hochladen, solange mein Setup noch perfekt läuft. Und ich bin wirklich ganz schön froh, dass das alte Thema jetzt mal vom Tisch ist. Jetzt kann ich endlich wieder den Kopf in den Sand stecken.
Was bisher geschah: Einem erfolglosen Remake-Entwickler ist es trotz aller Widrigkeiten schließlich doch noch gelungen, alle Originaldateien von SPACOLA mit Hilfe eines Debuggers in einem Atari ST-Emulator zu extrahieren. Doch das sollte noch lange nicht das Ende seiner abenteuerlichen Reise in die Heimcomputer-Vergangenheit des späten 20. Jahrhunderts sein, denn die antiken Hieroglyphen in den Originaldaten mussten erst noch aufwändig von einem gewieften Software-Archäologen entziffert und entschlüsselt werden. Dies ist seine haarsträubende Geschichte.
Da saß ich nun also, mit einem ganzen Haufen alter, unlesbarer Sprite-Dateien aus dem Spiel SPACOLA, ohne irgendeinen Hinweis, was ich damit anfangen könnte, und welche sagenhaften Geheimnisse diese historischen Dokumente letztlich bargen. Lediglich aus den perfekt erhaltenen Dateinamen ließ sich ungefähr ersehen, welche Sprites genau darin zu finden seien. Mein geschätzter Mit-Atarianer und Blogleser Gerry hatte mich glücklicherweise bereits Jahre zuvor mit einem wichtigen Zeitschriftenartikel aus der guten alten „ST Computer“ versorgt, in dem Meinolf Schneider höchstpersönlich im Jahr 1990 über die Entwicklung von Bolo und Esprit berichtet. Dieser Artikel erwies sich als pures Gold und enthielt so einige hochinteressante Einblicke und Fakten, die mir als Entwickler wiederum bedeutende Implementierungsdetails verrieten. Unter anderem beschrieb Meinolf darin einzelne Aspekte seines eigenen Sprite-Formats, den sogenannten „Shapelists“. Wie das Format aufgebaut war, war daraus zwar leider noch lange nicht ersichtlich, aber dafür andere wichtige Eigenarten, die später von Vorteil sein sollten.
Der Hex-Editor HxD zeigt eine SHL-Datei
Das Hilfsmittel Nummer eins war wiederum der Hex-Editor, mit dem ich mir die Dateien Byte für Byte quasi unter der Lupe ansehen konnte. Bei genauerem Hinsehen erkannte ich, dass diese Dateien immer aus mehreren „Blöcken“ bzw. Abschnitten bestehen, nämlich aus mindestens zwei, so wie im Falle der kleinsten Datei „SPI_MINE.SHL“. Diese spezielle Datei sollte mir schließlich zur Lösung des Rätsels dienen, da ich hierüber zum Glück ausreichend wusste. Da sie nachweislich aus genau zwei Blöcken besteht, wusste ich nun ziemlich sicher, dass nur die zwei einzelnen Sprites der beiden Sprengminen des Originals darin enthalten sein konnten. Ich wusste wie diese Sprites genau aussehen, wie groß sie sind, und am allerwichtigsten, dass diese Sprites zu einem großen Teil symmetrisch sind. Meine Chance bestand also darin, in den Shapelists nach genau diesen Symmetrien Ausschau zu halten. Würde ich eine Symmetrie im Bytemuster der Datei wiedererkennen, hätte ich schon einen äußerst wichtigen Ansatz gefunden.
Als ich einige Hexwerte (in Big Endian Bytereihenfolge) in der Shapelist in Dezimal umgerechnet hatte, fand ich so unter anderem die Dateigröße und die einzelnen Spritegrößen wieder, und so konnte ich sogar ausmachen, welches Sprite in welchem Block gespeichert ist. Ich konzentrierte mich also auf den kleineren ersten Block. Es dauerte nicht lange und ich hatte einen Teil ausgemacht, der symmetrisch aussah, und so folgerte ich, dass genau hier die Pixelinformationen begraben sein mussten. Bei einer Monochromgrafik war es zwar durchaus naheliegend, aber ich brauchte trotzdem einige Minuten, um darauf zu kommen, dass hier jedes Byte genau eine Reihe von 8 Pixeln darstellen konnte. Mit Hilfe des Windows-Taschenrechners ließ ich mir die Hex-Werte binär anzeigen, und so malte ich die gesetzten Bits auf ein Pixelgrid. Tatsächlich erkannte ich schon kurz darauf etwas, das zumindest teilweise nach den invertierten Umrissen der linken Hälfte des erwarteten Minen-Sprites aussah. Das war für mich erneut ein entscheidender Durchbruch. Ab hier war ich sicher, ich könne die Shapelists lesen.
In der Folge stellten sich mir bei der Analyse einige wichtige Merkmale des Dateiformats heraus: Die Sprites waren immer kodiert in „Scheibchen“ zu je 8 Pixeln Breite mit variabler Höhe. Zudem gab es pro Sprite meist zwei Schichten: Einen Hintergrund mit Transparenzinformationen, und einen Vordergrund. Manchmal gab es auch nur eine Schicht ohne Transparenz. Anschließend begann der nächste Block, der das nächste Sprite enthielt. Große Teile der Datei verstand ich bis dahin noch nicht, daher entschied ich mich zunächst, diese zu ignorieren, denn ich begann gleichzeitig damit, einen Konverter zu entwickeln, der SHL-Dateien laden und diese in ein anderes Grafikformat übersetzen konnte. Nach ein oder zwei Stunden hatte ich meinen Code schon soweit, dass er die beiden Minen aus der Originaldatei perfekt auf dem Bildschirm anzeigte. Ich wähnte mich bereits am Ziel, als ich zur Kontrolle eine andere SHL-Datei laden wollte, und der Konverter mit diversen Fehlern abbrach. Mit dem Format dieser Datei konnte er nichts anfangen, und so musste ich erneut mit dem Hex-Editor ran.
Ein monochromes Minen-Sprite aus der Shapelist mit Transparenzdaten in GIMP geladen
Ich entdeckte, dass Shapelists bisweilen mehrere „Versionen“ desselben Sprites beinhalteten, aber den Grund kannte ich nicht, bis sich herausstellte, dass jede folgende Sprite-Version im Grunde nur um jeweils einen Pixel nach rechts verschoben war. Die Lösung lieferte besagter ST-Computer-Artikel, in dem Meinolf erläuterte, dass er alle acht Möglichkeiten zur horizontalen Positionierung einer Grafik vorberechnete. Dies war nötig, weil er die Sprites direkt in den Grafikspeicher des Bildschirms kopierte, was natürlich nur in ganzen Bytes möglich war. Er schreibt hierzu genauer: „Will man die Figur auf eine beliebige horizontale Position darstellen, müssen die einzelnen Bits, die ja Bildpunkte repräsentierten, innerhalb eines Bytes verschoben werden. Und dies kann bei vielen zu zeichnenden Figuren für eine 72Hz-Animation zu langwierig sein.„. Diese bit-geshifteten Versionen sind in den Shapelists also allesamt enthalten. Ich entdeckte außerdem, dass die Shapelists im Header immer alle Offsets enthalten, die verwendet werden können, um direkt zum Beginn eines Blocks zu springen.
Nachdem ich meinen Konverter angepasst hatte und er flexibler mit dem Shapelist-Format umgehen konnte, erlaubte mir das bereits, einige Dutzend SHL-Dateien fehlerfrei zu laden, während so manche andere Datei jedoch noch Darstellungsprobleme hatte. Auch dies konnte ich wiederum korrigieren, so dass ich das SHL-Format dadurch immer besser zu verstehen lernte. Am Ende war mein Konverter problemlos in der Lage, alle Shapelists aus Bolo, Esprit, OXYD und Spacola zu laden. Die Shapelists aus OXYD 2 könnte er vermutlich auch konvertieren, aber diese müsste ich dazu natürlich erst mühsam aus dem Spiel holen. Eine letzte Erkenntnis konnte ich schließlich noch gewinnen: Zu jedem Sprite sind in der Shapelist die genauen horizontalen und vertikalen Pixeloffsets gespeichert, also die Zahlenwerte, um wieviele Pixel das Sprite relativ zur Position des entsprechenden Spielobjekts verschoben gezeichnet werden soll – im einfachsten Fall muss man das Sprite nämlich über dem Objekt zentrieren.
Ein Zusammenschnitt mehrerer konvertierter Shapelist-Inhalte aus Bolo (1987), Esprit (1989), und SPACOLA (1991)
Besagten Shapelist-Konverter habe ich mittlerweile nativ in das Remake SPACOLA ECLIPSE integriert, und das Spiel lädt folglich nicht nur die Original-Sounddateien, sondern inzwischen auch schon einige der Original-Spritedateien. Die Transition hin zu Shapelists ist aktuell noch im Gange und wird auch noch einige Monate andauern, aber der Vorteil ist für mich eindeutig: Absolute Originaltreue ohne unnötige Kompromisse. Durch die Verwendung von Shapelists werden all meine bisherigen Unsicherheiten verschwinden, ob ich dieses oder jenes Sprite auch wirklich pixelgenau und fehlerfrei gezeichnet habe, und ich kann meine geringe Aufmerksamkeit wieder anderen, deutlich wichtigeren Dingen widmen. Zum Beispiel dem Spiel.
Mit der Programmierung meines kleinen SPACOLA-Remakes habe ich übrigens heute vor exakt 10 Jahren begonnen. In dieser Zeit wuchs das Hobby-Projekt auf 54.300 Codezeilen in 326 Quelldateien an, und umfasst zusätzlich knapp 1500 Grafikdateien und 64 Audiodateien. Für volle 10 Jahre Entwicklungszeit ist das wahrlich nicht so viel, aber schneller bekomme ich es nicht hin. Ich habe eben mein ganz eigenes Tempo, das sowohl von motivierten als auch von faulen Phasen mitbestimmt wird. Dafür steckt trotzdem eine ganze Menge Herzblut, Schweiß und Erfahrung in meinem Werk. Wann das Spiel fertig oder wenigstens mal spielbar sein wird, steht weiterhin in den Sternen. Aber wer meine vielen kleinen Fortschritte bis heute fleißig verfolgt hat, und die Hoffnung immer noch nicht aufgegeben hat, den werde ich vielleicht in den kommenden Wochen doch noch ein bisschen überraschen können.
Eines meiner heiligsten Prinzipien bei der Entwicklung meines Remakes von Spacola ist Authentizität. In dieser Hinsicht bin ich leider ein Perfektionist. Zumindest so weit es mir technisch möglich ist, versuche ich mich immer zu 100% an den Originaldateien und an Originalmechanismen zu orientieren, und ich weiche nur davon ab, wenn es absolut nötig, wirklich sinnvoll, oder mit meinem Know-How sonst nicht machbar ist. Zu Beginn der Entwicklung konnte ich lediglich rein aus der Beobachtung nachimplementieren, ich musste notgedrungen tausende selbsterstellte Screenshots verarbeiten und Tonaufnahmen aus dem Emulator aufnehmen. Das Ergebnis war natürlich oft nah am Original dran, aber für mich nie authentisch genug. Glücklicherweise habe ich mittlerweile so einige Fortschritte gemacht, die mir meine Mission deutlich erleichtern. In den vergangenen Wochen habe ich einen äußerst wichtigen Meilenstein bei der Analyse des Originalspiels erreicht. Um verstehen zu können, was mir da konkret gelungen ist, muss ich etwas weiter ausholen. Daher hier ein kleiner technischer Exkurs in meine Welt.
Schon wie zuvor im 1990 veröffentlichten OXYD hat Spacola einen eigenen Kopierschutz in Form eines Dongles (das Codebuch). Im Gegensatz dazu sind die Codes allerdings mittlerweile ein integraler Bestandteil des Gameplays geworden, und nicht mehr nur Steine, die den Weg blockieren. Den Kopierschutz schlicht auszubauen hätte im einfachsten Fall bedeutet, direkt das Gameplay von Spacola zu verändern, die Siegbedingungen im Spiel zu entfernen; das Spiel wäre quasi sinnlos geworden. (Spoiler-Warnung: Dennoch ist einem findigen Entwickler vor wenigen Jahren auch das schon auf intelligente Weise gelungen.) Weiterhin bringt das Spiel jedoch noch einen raffinierten Crackschutz mit, um zu verhindern, dass der Kopierschutz überhaupt angegriffen werden kann. Die Daten der Dongleware-Spiele bis einschließlich OXYD lagen noch offen da, wenn auch in proprietären Dateiformaten (SHL, IMG, CMP, PAC), mit denen man so jedenfalls nichts anfangen konnte, bis auf die Sounddateien, die einfach im Rohformat vorhanden waren. Da OXYD schließlich geknackt werden konnte (und auch das Codebuch trotz absichtlich schlechtem Farbkontrast kopiert wurde), wurden die Daten in Spacola inzwischen gegen unbefugte Zugriffe geschützt. Dies macht es natürlich für interessierte Remake-Entwickler wie mich deutlich schwieriger, die eigentlich nicht den Kopierschutz entfernen wollen, sondern Einblick in die Spieldaten brauchen.
Wie sieht dieser Crackschutz nun eigentlich aus? Bei Spacola lagen weder die Spieldaten noch die ausführbare Datei in lesbarer Form auf der Diskette vor. Auf dieser gab es lediglich ein großes mit PFXPak erstelltes, selbstextrahierendes Programm, das das Spiel zur Laufzeit ausschließlich in den Arbeitsspeicher entpackt und dort ausführt. Laut PFXPak-Dokumentation bringt das nicht nur den Vorteil, dass man mehr nutzbaren Netto-Speicherplatz auf der Diskette hat, sondern auch Performance-Verbesserungen, da weniger Daten über das langsame Diskettenlaufwerk geladen werden müssen. Außerdem werden zum einen die einzelnen Dateien immer erst dann entpackt, sobald sie vom Programm referenziert, also im Spiel benötigt werden, zum anderen werden die Dateien auch gleich noch dekodiert, da sie teilweise nur in verschlüsselter Form vorliegen. Und selbst das ist noch nicht alles: Sogar wer glaubt, es sei ihm gelungen, das integrierte LHarc-Archiv des Entpackers aus der Datei zu extrahieren, und dieses von Hand entpacken will, erhält leider kein Spacola, sondern nur ein Programm, das eine kleine Grußbotschaft an den Hacker auf dem Bildschirm anzeigt und gleichzeitig die Festplatte vollmüllt, sofern eine angeschlossen ist. Ja, man musste sich als Spieleentwickler wohl irgendwie gegen Raubkopierer zur Wehr setzen. Der wenig freundliche Inhalt besagter Grußbotschaft wurde mit dem ersten und wahrscheinlich einzigen Spacola-Patch einige Wochen später zensiert.
Wer sich mit Atari ST-Emulation intensiver befasst, weiß, dass es mit dem STeem Debugger ein äußerst mächtiges Debugging-Werkzeug gibt, das genutzt werden kann, um sämtliche ST-Software zu analysieren und zu modifizieren. Fürs Reverse-Engineering ist ein brauchbarer Debugger quasi unverzichtbar. Als ich vor etlichen Jahren zum ersten Mal die Oberfläche des Debuggers öffnete, war ich wie erschlagen von den endlosen Möglichkeiten, die sich mir hier boten. Und mir war sofort klar, dass ich nicht die nötigen Fähigkeiten hatte, um hier irgendetwas zu bewegen, denn natürlich setzt so ein Debugger unter anderem auch ein tieferes Verständnis der Hardware voraus. In meinem Studium hatte ich wenigstens zwei Semester Rechnertechnik, in welchen ich die Grundlagen von 68K-Assembly lernte und auch sehr kleine Programme schrieb. Dies brachte mich zumindest theoretisch in die Lage, die Funktionen des Debuggers rudimentär zu verstehen. Doch als ich mich damals spaßeshalber in ein laufendes Programm einklinkte, Schritt für Schritt durch den Programmcode bewegte, und die Hieroglyphen verstehen wollte, die der Prozessor da ausführte, hörte der Spaß irgendwie auf. Mein Verstand konnte zwar mühsam und sehr langsam erfassen, was dort in jeder Zeile ausgeführt wurde, aber mir fehlte jeglicher Durchblick dafür, warum es ausgeführt wurde, an welcher Aufgabe der Programmcode gerade arbeitete. Es gab keinen Kontext. Es ist ein bisschen so als würde ich mir unter einem Mikroskop nacheinander die einzelnen Holzfasern genauer anschauen, um dadurch herausfinden zu wollen, worum es in dem Buch geht. Dabei könnte ich nicht einmal erkennen, welchen Buchstaben ich mir da gerade ansehe.
Der STeem Debugger mit laufendem Spacola beim Ladevorgang
Aber die ersten kleinen Fortschritte ermutigten mich, den Kopf nicht hängen zu lassen. Der Memory-Browser des Debuggers bietet zum Beispiel eine Suchfunktion und erlaubt das Editieren des Speichers zur Laufzeit. So kann man Texte in den Programmen finden und ersetzen, was nette Spielereien ermöglicht. Eine andere nützliche Funktion ist der Speicherdump, der es erlaubt, den kompletten Arbeitsspeicher in eine Datei zu schreiben. Mit diesem wertvollen Hilfsmittel hatte ich endlich einen ersten direkten Zugang zu vielen Spielinhalten, wenn es auch noch lange nicht lückenlos war. Im Audiobearbeitungsprogramm Audacity konnte ich dieses Speicherabbild als Rohdaten einlesen und die Sounds von Spacola hörbar machen und grob „ausschneiden“, was mir wirklich enorm half. Eines meiner Probleme mit dieser Methode war jedoch, dass ich nie wusste, wo eine Datei beginnt oder aufhört. Die Dateien waren nicht byteperfekt. Und jahrelang waren die Audiodateien leider die einzigen, auf die ich dadurch Zugriff erlangen konnte. Ich wollte aber unbedingt auch an die Grafikdateien herankommen. Später gelang es mir mit großem Aufwand, das „Rentenbescheid“-Bild, das nach gewonnenem Spiel als Urkunde zum Ausdrucken verwendet wird, zu extrahieren. Die Monochrom-Rohdaten habe ich unter anderem durch einen emulierten Drucker als virtuelle Hardcopy in eine Datei schreiben lassen, mühsam rekonstruiert und mit STAD v1.3 laden können. Dadurch konnte ich einen Screenshot anfertigen. Dies war ein weiterer Motivationsschub, der mich daran glauben ließ, irgendwann alles zu schaffen.
Ende 2018 begann ich erneut damit, das Originalspiel aufwändig Schritt für Schritt im Debugger zu beobachten. Ich hatte erst angefangen, mich mit den Breakpoints und den Read- und Write-Monitors vertraut zu machen, und war überzeugt davon, ich könnte die entpackten Dateien abfangen, während sie gerade in den Arbeitsspeicher geschrieben werden. Im selbstextrahierenden Programm gibt es glücklicherweise eine Dateitabelle, die Dateinamen, Dateigrößen und Byte-Offsets enthält. Dies war letztlich der Schlüssel zum Erfolg. Jemand mit mehr Erfahrung im Reverse-Engineering hätte natürlich sofort gewusst, was hier zu tun ist. Ich musste es erst durch unzählige Fehlversuche und Rückschläge lernen. Am Ende dauerte es bis zum Frühjahr 2020, dann hatte ich endlich einen Plan. Durch das geschickte Setzen der Read- und Write-Monitors und Zurückverfolgen der Lese- und Schreibzugriffe, konnte ich genau den Teil des Codes ausmachen, der direkt für das Entpacken aller Dateien zuständig ist. Anschließend musste ich nur noch den Program Counter, die Schleifendurchläufe und die Adress- und Datenregister überwachen, dadurch konnte ich sehen, welche Datei gerade verarbeitet wurde, wo die Daten gelesen und wohin sie geschrieben wurden, und wann der Schreibvorgang exakt beendet ist. Ich führte Notizen darüber, welche Dateien ich dadurch erhalten konnte und ob sie die richtige Größe haben, um ihre Richtigkeit zu verifizieren.
Das Debugging beim Entpacken der Dateien
Das Modifizieren der Dateitabelle im Programm erlaubte es mir sogar, den Entpacker dazu zu bringen, die „falschen“ Dateien zu entpacken, darunter auch eine Sounddatei, die offenbar gar nicht referenziert, also im Spiel selbst niemals verwendet wird. Dies war immens hilfreich und verkürzte die weitere Zeit, um auch die letzten verbliebenen Dateien zu bekommen. Später bemerkte ich noch, dass Spacola leider wieder mal schlauer war als ich: Viele Sounddateien wurden im Spiel komprimiert, d.h. in der Größe reduziert, andere Sounddateien wurden aber nur in irgendeiner Weise kodiert, also bei gleicher Dateigröße unlesbar gemacht. Hierzu musste ich einen weiteren Codeabschnitt ausfindig machen, der Sounddateien entschlüsselt. Die zentralen Breakpoints waren mir in der Folge heilig, ich habe sie akribisch notiert und verwendet, um nacheinander alle 104 Dateien mühsam zu entpacken, aus dem Memory-Browser zu extrahieren und mittels HEX-Editor byte-perfekt auf die Festplatte zu schreiben. Das Ergebnis sind 557 KByte an Rohdateien, die exakt so im Originalspiel verwendet werden: 50 Sounddateien, 48 Sprite-Dateien, vier Bilddateien, eine Textdatei und eine IMG-Datei. Als Bonus erhielt ich auch die ungeschützte SPACOLA.PRG, also die ausführbare Datei ohne den Packer. Diese lässt sich auch starten und lädt sogar das Titelbild, anschließend hängt sie sich leider auf. Allerdings habe ich mich entschlossen, dieses Problem nicht weiter zu verfolgen, da es sich wahrscheinlich nicht lohnt.
Für mich war das bis hierhin schon ein großartiger Durchbruch. Dies war ein Thema, das mir noch Jahre zuvor wie eine unlösbare Aufgabe erschien, und plötzlich liegen mir alle Daten offen, um sie endlich in unberührter Form in meinem Remake zu verwenden. Aber da war natürlich weiterhin diese eine nicht ganz unbedeutende Hürde: Das selbstentwickelte Dateiformat der Sprite-Dateien ist leider unbekannt, undokumentiert und es gibt kein öffentlich verfügbares Programm, das die Dateien lesen könnte. Scheint so, als sei ich in einer Sackgasse gelandet.
Und in der nächsten Folge lesen Sie: Die Sprites von Spacola.
Seit Jahren beschäftige ich mich auf meiner kleinen Webseite als großer Fan mit den Spielemeisterwerken von Meinolf Amekudzi und seiner Firma Dongleware, doch nie zuvor war es mir vergönnt, tatsächlich eine Neuigkeit direkt von dort zu vermelden. Vor kurzem hat Meinolf es in einem knappen Kommentar zu einem YouTube-Video von mir angedeutet, aber seit der Spielemesse Gamescom ist es offiziell: OXYD lebt! Meinolf arbeitet an einem echten Remake seiner bekannten Spielereihe. Seit OXYD magnum! Gold aus dem Jahr 1998 wird es erstmals wieder ein Originalspiel vom Schöpfer der Serie geben.
New versions of Oxyd® will be available in 2018. The new implementations will include a landscape designer, a WebRTC multiplayer mode, classic game restorations, a browser implementation, native mobile and desktop 3D apps and many more. Regards Meinolf.
Inzwischen gibt es einen Artikel auf heise.de (danke an Gerry für den Hinweis!), in dem über das geplante Remake berichtet wird. Dort ist unter anderem die Rede davon, dass es kostenlos im Browser spielbar sein wird, und dass es möglicherweise dieses Jahr noch online geht. OXYD soll einen Multiplayer-Modus mit bis zu 8 Spielern gleichzeitig bekommen. Außerdem will Meinolf sogar den Landschaftseditor beilegen, den er damals bewusst immer unter Verschluss gehalten hat (Wortlaut: „nicht käuflich, Anfragen zwecklos!“). Das wäre also ein echtes Novum. Aber der größte Knaller in meinen Augen ist, dass es so klingt, als wolle er sämtliche Original-Landschaften dem Remake beilegen (wenn Esprit damit ebenfalls gemeint ist, reden wir hier von über 600 Landschaften!).
Gamescom-Demo des OXYD Landscape Designers
Den Screenshot im heise-Artikel habe ich mir mal zur Analyse etwas näher angesehen. Dazu habe ich das Foto ganz unprofessionell entzerrt und geschärft, damit man es etwas besser erkennen kann. Dafür komme ich wahrscheinlich in Teufels Küche, aber das Risiko gehe ich jetzt einfach mal ein. Der auf dem Screenshot abgebildete Ausschnitt stammt übrigens aus dem klassischen OXYD, genauer gesagt Landschaft Numero 100 der Zweispieler-Link-Landschaften (also im Prinzip Landschaft 200). Da man rechts im Bild alle möglichen Steine auswählen kann, und außerdem die Landschaften untereinander aufgelistet werden, wird das wohl der Editor sein. Oben steht sowas wie „OXYD LandscapeDesigner“, darunter scheint ein Tab mit der Überschrift „Classic“ ausgewählt zu sein. Viel mehr kann ich nicht erkennen.
Die Tatsache, dass der Editor das Original-Tileset mit der Monochromgrafik der Atari ST Urversionen zeigt, freut mich ganz besonders. Diesen Grafikstil findet man heute nur noch sehr selten. Wenn also nicht nur der Editor so aussieht, sondern sich das Spiel auch mit dieser Grafik spielen lässt, wäre das eine Sensation für jeden echten Fan. Womöglich könnte es auch machbar sein, das Tileset mit einem simplen Mausklick z.B. auf die Farbversion der General Edition umzuschalten, oder auf die (eher gewöhnungsbedürftige) Grafik von Per.Oxyd. Je mehr Optionen die Fans bekommen, desto besser ist es. Ob das Remake auch mit den Magic-Steinen kommen wird?
Ausschnitt aus der Link-Landschaft #100 aus OXYD
OXYD oder OXYD3D? Angekündigt wurden eine Browserimplementierung (wie im Screenshot zu sehen), native Mobilversionen und „Desktop 3D-Anwendungen“. Offen bleibt, welche Desktop-Plattformen gemeint sein werden (alle?). Außerdem ist nicht sicher, ob der zur Gamescom demonstrierte Editor für ein klassisches 2D-Remake konzipiert ist, oder ob es hier doch um eine echte 3D-Fassung geht. Es gibt im Netz neue, offizielle Artworks, in denen es einmal einen normalen OXYD-Schriftzug und einen mit dem Text „OXYD3D“ gibt. Was auch immer am Ende herauskommt, ich bin sehr gespannt.
We will also launch Oxyd – a puzzle game that was originally released for the Atari ST. We loved this classic game so much that we had to reincarnate it. So, together with the original creator, Meinolf Amekudzi, we’re developing a cool version for smartphones and tablets.
Unabhängig davon wem das Spiel letztlich gehören wird, welche Grafik es haben, und wieviele von den guten alten Landschaften es mitbringen wird, als alter Atari-Mausschubser bin ich sehr dankbar für ein echtes Lebenszeichen von der legendären Spielefirma Dongleware. Die Dongleware-Webseite wurde im Jahr 2002 geschlossen, und erst im Jahr 2012 – leider ohne jeden Hinweis auf die Spielehistorie – erneut geöffnet. Ich bin sehr froh darüber, dass Meinolf sich endlich wieder mit der Spieleentwicklung befasst. Ohne seine Spiele wäre ich sicher nie Programmierer geworden. Ein wenig Heldenverehrung gehört also dazu, wenn ich sage, dass ich mich wie verrückt auf das Ergebnis freue, und ich mich dann auch nicht mehr mit Enigma quälen muss. Denn wenn ich ehrlich bin, hat sich Enigma nie so wie das Vorbild angefühlt. Es war einfach nicht OXYD genug.
Palim palim! Der unregelmäßige SPACOLA-Remake Fortschrittsbericht ist da! Och, keine Sorge, viel Fortschritt gibts nicht. Aber es gibt immerhin was zu sehen. In den vergangenen Monaten habe ich weitestgehend unter Linux Mint weiterentwickelt, und leider ging auch ein nicht unwesentlicher Teil der Zeit dafür drauf, Probleme zu beheben, die das Spiel nur unter Linux hatte. Zum Beispiel habe ich es lange Zeit nicht hinbekommen, dass das GUI-Fenster sowohl unter Windows als auch unter Linux immer exakt die gewünschte Größe hat. Wenn es unter Linux gepasst hat, war es unter Windows falsch. Wenn ich es dann für Windows korrigiert habe, war die Linux-Version plötzlich wieder schief. Wenn das programmatische Resizing des Fensters endlich überall funktionierte, ging dafür die Menüleiste nirgends mehr. Habe ich eine Sache repariert, geht eine andere Funktion kaputt. Es war wie bei einem Teppich, bei dem man eine Unebenheit mit dem Fuß ausbessern will, die sich dann nur immer wieder woanders auftut. Da soll mir nochmal einer sagen, Java sei wirklich plattformunabhängig. Swing ist es jedenfalls schonmal nicht. Ich habe viele graue Haare bekommen bis es endlich perfekt war. Die aktuelle Version funktioniert somit einwandfrei unter Windows und Linux.
Neue Artworks
In der Zwischenzeit habe ich viel mit neuen Artworks experimentiert und dabei kräftig mit GIMP gebastelt. Lange Zeit habe ich darüber gegrübelt, wie ich die Titelgrafiken designen soll, so dass sie sehr nahe am Original bleiben, und trotzdem viel Spielraum für eine Neuinterpretation im Sinne des Remakes erlauben. Mittlerweile habe ich ein mehr oder weniger einheitliches Design für den Fensterhintergrund, für den About-Dialog, für die Webseite und für den Splash-Screen beim Laden entworfen. Ja, das Remake hat jetzt einen eigenen Ladebildschirm, weil das Starten auf manchen Systemen doch schon mal die eine oder andere Sekunde länger dauern kann. Die Grafiken sind natürlich bei weitem nicht perfekt, aber ich glaube, man kann das erstmal so stehen lassen. Der Wiedererkennungswert ist schonmal ganz ordentlich.
Spiel laden und speichern
Die Funktionen zum Laden und Speichern der Spielstände sind jetzt endlich fertig. Genau wie im Original kann der Kaffee-Button genutzt werden, um den aktuellen Spielstand zu speichern. Zusätzlich gibt es außerdem die Möglichkeit, beliebig viele weitere Spielstände zu speichern und auch via Dateiauswahl wieder zu laden. Im Moment bezieht sich das Speichern jedoch nur auf den Zustand zwischen den Levels, nicht direkt IM Spiel. Ob eine solche Funktion noch nachgereicht wird, und ob das jemandem viel hilft, muss ich noch klären. Jedenfalls ist es klasse, dass man nun tatsächlich den Spielfortschritt in eine Datei persistieren und so jederzeit fortsetzen kann. Damit wäre ein wichtiger Punkt von meiner Todo-Liste gestrichen.
GEM-Schriftarten und Highscore-Liste
Die Remake-GUI verwendet jetzt konsequent drei verschiedene Original-TOS/GEM-Systemschriftarten, um so zusätzlichen Wiedererkennungswert zu generieren. Die Atari ST-Schriftarten erkennen Fans sofort. Nicht dass diese Schriftarten besonders hübsch oder gut lesbar wären, aber sie geben einem echten Nostalgiker doch schnell ein warmes Gefühl. Die Highscore-Liste wurde von mir deutlich erweitert. Zusätzlich wird nun der Highscore-Zeitstempel gespeichert, außerdem die Komplettierungsrate des Spiels in Prozent, damit man die Angaben besser vergleichen kann. Außerdem werden jetzt beliebig viele Einträge gespeichert. Im gerenderten Spiel selbst tauchen dann allerdings nur die ersten zehn Einträge auf, und dann auch nur deren Namen und Punktestand – die übrigen Werte werden einfach versteckt, um so nah beim Original zu bleiben wie möglich.
Besonders wenn man das Spiel auf Pixelverdoppelung stellt, also in der Auflösung 1280×800 spielen will, bremsen etwaige Post-Processing-Filter das Spiel leider so stark aus, dass es kaum noch Spaß machen kann. Zwar gibt es im Moment mit der Invertieren-Funktion nur einen einzigen Filter, aber ich wollte dort in Zukunft noch mehr Filter-Optionen anbieten, um den Look des Spiels den eigenen Bedürfnissen anzupassen. Nun, meine Idee war es, das Post-Processing immer nur auf die gerenderte Spielgrafik (in niedriger Auflösung) anzuwenden, und erst dann das Ergebnis hochzuskalieren. Würde ich erst hochskalieren und dann die Filter auf die hohe Auflösung anwenden, wäre das logischerweise viel langsamer. Leider machte dieser neue Ansatz es nötig, einige Teile des Renderings umzuschreiben, um die neue Reihenfolge der Arbeitsschritte zu ermöglichen. Zusätzlich implementierte ich eine Filterklasse, die es erlaubt, unbegrenzt viele verschiedene Filter ins Bild „einzuhängen“, um die Grafik zur Laufzeit jederzeit zu ändern. Der neue Code funktioniert wirklich erstaunlich schnell und schön flexibel. Die Änderungen haben sich gelohnt.
Neuer Anvisieren-Algorithmus für Geschütze
Man mag es kaum glauben, aber ich habe wirklich übermäßig viel Zeit in den Algorithmus für das Anvisieren der Geschütze investiert. Ich dachte ursprünglich, es genau richtig hinbekommen zu haben. Dann fiel mir jedoch beim Nachspielen des Originals auf, dass die Geschütze beim ST-Klassiker nie daneben feuern, egal wie schnell und egal wohin der Spieler sich bewegt. Das bedeutete, dass die Geschütze nicht nur den Winkel zum Spieler und dessen Bewegungsgeschwindigkeit in die Berechnung des Vektors einbeziehen, sondern bei bekannter eigener Geschossgeschwindigkeit auch den Abschusswinkel exakt so berechnen, dass die Geschosse den Spieler an einem unbekannten Punkt zielsicher treffen. Am Ende habe ich mir das Problem bestimmt ein dutzend Mal auf einem kartesischen Koordinatensystem skizziert und versucht herzuleiten, wie der Winkel berechnet wird. Ich wusste wie lang der Vektor sein dürfte, ich wusste nur nicht, wo er den anderen Vektor schneiden würde. Am Ende fand ich eine Lösung, indem ich den Spielervektor von der Position des Geschützes aus nahm, einen Kreis mit Radius der erlaubten verbleibenden Vektorlänge um diese neue Koordinate berechnete um die Schnittpunkte mit dem anderen Vektor zu finden. Der Vektor vom Geschütz zu diesen Schnittpunkten muss dann der Abschussvektor sein. Das ist dann zwar eine vergleichsweise teure Berechnung, aber sie funktioniert perfekt.
Levelgenerator-Verbesserungen
Den Levelgenerator habe ich wieder geringfügig verbessert. So funktionieren die Floodfilling-Methoden für Konfigurationen von Stationen, Powerups und schwarzen Löchern jetzt besser und erlauben auch die Übertragung von Parametern, wie aus dem Levelskript vorgegeben. Der Levelgenerator setzt nun korrekt die Deploy-Distanz für Gegner, die Deployment-Rate und die Anzahl gleichzeitig erlaubter Gegner. Außerdem habe ich eine Funktion eingebaut, die ich nur als „Shield-Powerup-Stacking“ bezeichnen kann, die mir im Original sehr merkwürdig vorkam. Ich bin mir immer noch nicht sicher, ob das ein Bug ist, oder ob es beabsichtigt war. Jedenfalls kann der Spieler seine Schutzschild-Option zeitlich deutlich verlängern, wenn er mit aktiviertem Schutzschild noch ein weiteres Schild-Powerup einsammelt. Ich müsste wohl auch noch prüfen, ob dieses „Feature“ in jeder Spacola-Version auftritt, oder nur in einer bestimmten. Jedenfalls ist das nun ebenfalls im Remake perfekt nachgebildet.
So, das waren wieder einige kleine Einblicke in die Entwicklung der vergangenen Monate. Ich bleibe am Ball und arbeite mich langsam voran. Der Quellcode umfasst inzwischen über 40.000 Zeilen und wächst stetig weiter.
