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.

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 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.

Games for Windows Live, neben Steam eine der größten DRM-Plattformen, wird dieses Jahr komplett abgeschaltet. Was passiert mit den vielen Spielen, die die Verfügbarkeit der Authentifizierungs-Server zum Spielen zwingend voraussetzen? Tja, das ist natürlich eine blöde Sache. Das konnte ja keiner ahnen, dass solche Server aus wirtschaftlichen Gründen irgendwann mal vom Netz gehen würden.
Ein Spiel, das es im Moment voll erwischt hat, ist das neue Sim City 5 von EA. Dieses Beispiel ist besonders frustrierend, weil zum einen, Sim City ein typisches Casual-Game ist, für kurze und für lange Runden, für jung und für alt, das man problemlos mal eben auf dem Notebook auf Reisen spielen könnte. Problemlos KÖNNTE, wäre da nicht unser lieber Freund, der Onlinezwang, der eben genau das verhindert. Und zum anderen, weil Entwickler EA die Käufer kackdreist mit einer hundsdämlichen Lügengeschichte für dumm verkaufen wollte. Es hieß nämlich, Sim City 5 könne man unmöglich als Offline-Spiel umsetzen, weil die Berechnungen der simulierten Stadt viel zu komplex für die heute üblichen Quadcore-Desktop-PCs seien. Soso! Alles nur Show, wie ein Modder inzwischen enthüllt hat. Das ganze Server- und Multiplayer-Gedöns wurde ganz billig um das fertige Spiel herumgestrickt. EA wollte seine Kopierschutz-Schikane als großes Feature verkaufen und ist damit, nicht zuletzt wegen der total überlasteten Server, brutal auf die Schnauze gefallen. Wie selbstverständlich konnte sich zum Release niemand einloggen und spielen. Unnötigerweise, wie wir jetzt wissen. Nun gab EA sich öffentlich fast schon beleidigt: Sim City war ja NIE als Einspieler-Spiel konzipiert, weil … äh … ja weil wegen Multiplayer und Server halt. Basta, ihr Würmer! In den Staub! Meine Herren, was für eine peinlich schlechte Ausrede, nur um nicht zugeben zu müssen, dass es ein verdammter Kopierschutz ist. Sim City ist eigentlich ein so typisches Solo-Spiel, soliger geht’s kaum. Keine Sau interessiert sich für den Multiplayer-Rotz, das zeigen schon die diversen Testberichte. Ich habe beinahe jedes Sim City gespielt, und nie hatte ich mir ernsthaft gedacht: „Mann, wie cool wäre jetzt ein bisschen Multiplayer! Ich würde ja so gerne eine Straße zu meinem Nachbarn bauen!“.
Vor 16 Jahren mussten wir Diablo das erste Mal in den Untiefen der Katakomben unterhalb der Kathedrale von Tristram zur Strecke bringen. Vier Jahre später war es dann erneut an der Zeit, Diablo und seinen höllischen Brüdern den Garaus zu machen. Die Erwartungen waren groß, als Blizzard vor einigen Wochen nach schier endloser Wartezeit den dritten Streich veröffentlichte. Nachdem ich nun knapp 100 Stunden mit dem Spiel verbracht habe, was auch der Grund ist, warum ich derzeit so wenig schreibe, ist es nun Zeit für einen kleinen Kommentar. Handlungsdetails werde ich keine nennen, auch wenn diesen Artikel wohl niemand lesen wird, der nicht selbst schon jeden Aktboss zerlegt hat.
Es wird sehr viel mehr gelabert als noch in Diablo 2. Es vergehen kaum fünf Minuten in denen man nicht irgendwelche Tagebücher oder Schriftrollen findet, neue Monstertypen ausführlich vorgestellt werden, und beinahe jeder NPC will dem Spieler seine gesamte Lebensgeschichte erzählen. All das nimmt wahnsinnig viel Zeit in Anspruch. Wenigstens bekommt man hin und wieder sogar Erfahrungspunkte gutgeschrieben, wenn man sich das lahme Gesülze reinzieht. Dafür lohnt es sich dann eben doch. Eine weitere Motivationsquelle sollen die sogenannten Achievements bzw. Erfolge sein, von denen es im Spiel praktisch an jeder Ecke vier oder fünf gibt. Ich kann nicht behaupten, diese Erfolge zu verstehen, denn sie haben keinen Einfluss auf das Spielgeschehen, aber man freut sich irgendwie trotzdem darüber. Leider wird in Diablo 3 jeder Mückenschiss mit einem Erfolg belohnt: „Du hast Bossgegner XY besiegt – Erfolg freigeschaltet!“, oder: „Du hast Level 40 erreicht! Erfolg!“, oder am besten: „Du hast dir das ganze Geschwafel von diesem oder jenem NPC angehört! ERFOLG!!1“. Erfolg auf ganzer Linie. Bei den gefühlten Millionen an Erfolgen ist es kein Wunder, wenn ich nach 100 Stunden Spielzeit noch nichtmal die Hälfte davon habe, allerdings lege ich es ja auch nicht darauf an.
Ich muss sagen, die Physikengine steht Diablo 3 richtig gut. Es ist wirklich witzig zu sehen wie die erledigten Monster kreuz und quer über den Bildschirm fliegen. Die vielen zerstörbaren Einrichtungsgegenstände tragen ebenfalls positiv zu einem moderaten Realismusgrad bei. Activision Blizzard hat in Deutschland für die Lokalisierung offenbar etwas mehr Geld investiert als noch für die in Diablo 2, denn Fans von Hörspielen und Filmen werden einige bekannte Sprecher wiedererkennen. Die ersten, die mir aufgefallen sind, waren die von Seth Rogen, vom TNG-Klingonen Worf, vom holographischen Doktor der Voyager, von Liam Neeson und von Mr. Krabs aus „Spongebob Schwammkopf“. Die Spielercharaktere haben allesamt bekannte Sprecher wie z.B. von Kevin Bacon, Julianne Moore, Russell Crowe und Tobey Maguire.
Das Internet ist eine gigantische Schatzkiste. Das konnte ich in den letzten Jahren bei vielen Gelegenheiten immer wieder feststellen. Dieses Mal konnte ich eine ganz besondere Rarität ergattern, die ich schon seit meiner Kindheit haben will. Noch dazu stellte sich heraus, dass besagte Rarität in einem außergewöhnlich guten Zustand ist, praktisch kaum benutzt. Meine Sammlung wird damit endlich komplett, nach lächerlichen 21 Jahren.