In Vorbereitung auf das baldige Ende von Windows als meinem Haupt-Betriebssystem nach mehr als 23 Jahren experimentiere ich unter anderem mit VirtualBox als Ausführungsumgebung für alte Windows-Versionen, um darin alte Spiele auch weiterhin verwenden zu können. Nachdem sich in meinem letzten Artikel zu diesem Thema PCem als PC-Emulator für Windows 98 SE zumindest im Rahmen meiner Stichprobe bereits als überraschend kompatibel und ergiebig erwiesen hat, wollte ich den Schwierigkeitsgrad nun deutlich erhöhen. Heute geht es um das Thema Virtualisierung mit der beliebten Open-Source-Lösung VirtualBox.

Die Unterstützung für Windows 95/98 unter VirtualBox ist bekanntermaßen miserabel, weil die Entwickler darauf bedauerlicherweise überhaupt keine Lust haben. Daher gibt es auch keinerlei Guest-Additions (wie etwa unter VMware), und die Hardware-Unterstützung ist bestenfalls rudimentär. Keine gute Voraussetzung, um damit Spiele testen zu wollen. Aber was wäre die Community ohne ihr Ideenreichtum, denn es gibt durchaus fundierte Anleitungen im Internet, um zum Beispiel Windows 98 einigermaßen genießbar zu machen. Wie einigermaßen genießbar das am Ende sein würde, darüber wollte ich mir nun selbst ein Bild machen, um zu sehen, ob diese Option für mich eine Zukunft haben könnte.

Google funktioniert im Jahr 2020 immer noch mit dem beliebten Internet Explorer 5

Wie bereits im Artikel zuvor möchte ich betonen, dass das hier keine Anleitung werden soll, denn für interessierte Mitleidende gibt es bereits genug Hilfestellung im Netz. Stattdessen gehe ich auf die Dinge ein, die mir aufgefallen sind. Während man bei der Konkurrenz von VMware zur Installation von Windows 98 zum Beispiel mit einer vollständigen Unattended-Installation und sehr leistungsfähigen Guest-Additions umschmeichelt wird, bekommt man unter VirtualBox nicht einmal einen Knochen hingeworfen. Windows 98 verbrennt Out-Of-The-Box unter VirtualBox mangels ACPI-Unterstützung leider CPU-Zyklen ohne Ende, was das Betriebssystem komplett unbenutzbar macht. Das Problem ist zwar lösbar, allerdings muss man dazu den Installationsvorgang etwas modifizieren.

Am Ende des recht langwierigen Prozesses hat man ein lauffähiges und auch noch relativ reaktionsschnelles Betriebssystem, aber die Grafik- und Soundtreiber bleiben leider ein Problem, und die Gast-zu-Host-Kommunikation ist minimal. Eine Internetverbindung über LAN lässt sich noch mühelos konfigurieren, und schon darf man mit dem gruselig antiquierten Internet Explorer 5 ins Netz. Selbstredend gibt es für den senilen Browser hier nicht mehr viel zu sehen, da die meisten Webseiten längst auf völlig neue Technologien setzen. Um die Grafikeinstellungen zu verbessern, ist der SciTech Display Doctor 7 heute das Non-Plus-Ultra, der einen universellen SVGA-Treiber mitbringt, mit dem man Windows 98 auf bis zu 1600×1200 Pixeln und sogar 32 Bit Farbtiefe einstellen darf. Letzteres soll angeblich die Performance unter VirtualBox deutlich verbessern. Zumindest in dieser Hinsicht bekommt man also ein ganz brauchbares, modernes Setup in angenehmer Auflösung.

Das Thema Sound ist unter VirtualBox leider ein gewaltiger Hemmschuh. Die Virtualisierungssoftware bringt wahlweise eine virtuelle SoundBlaster 16 oder einen RealTek AC’97-Chip mit. Der geneigte Retrogamer bekommt natürlich feuchte Augen, wenn er nur die SoundBlaster 16-Option sieht, denn die wäre ja vollkommen ausreichend in 99% der Fällen. Aber leider haben die Flachzangen bei Oracle wohl an der Implementierung gespart. Die Leistung ist selbst mit dem offiziellen Creative-Treiber nur schwer zu ertragen, und MIDI-Unterstützung sucht man vergeblich, womit man in vielen Spielen von vor 1998 eben gänzlich ohne Musik auskommen muss. Aber es gibt Hoffnung, denn technikversierte Community-Mitglieder haben stattdessen einen obskuren Windows 95-Treiber für den AC’97-Chip aufgetan, der schließlich sogar MIDI ermöglicht. Dies ist heute offenbar das Mittel der Wahl, wenn man Windows 98 verwenden möchte. Das Umkonfigurieren der VM ist zum Glück nur eine Angelegenheit von Sekunden, und schon hat man eine andere Soundkarte drin.

Noch ist wenig los am Ballermann, in Holiday Island von 1996 in VirtualBox

Nun war es also an der Zeit, ein paar wirklich alte Spiele auf meine Installation loszulassen, darunter das von mir geschätzte und heutzutage kaum noch bekannte „Holiday Island“ von der Firma Sunflowers Interactive. Hierbei handelt es sich um ein witziges Aufbauspiel für ein Urlaubs-Resort auf einer tropischen Insel, ähnlich wie das neuere Rollercoaster Tycoon. Holiday Island ist berüchtigt dafür, bereits ab Windows 2000/XP nicht mehr problemlos lauffähig zu sein. Es lässt sich oft mit Hilfe von Registry-Tricks und anderen technischen Kniffen starten, zeigt dann aber während des Spielens unterschiedlichste Probleme, ist also nur noch bedingt spielbar. Das fällt natürlich nicht auf, wenn man immer nur die ersten 5 Minuten vom Spiel sehen will, um zu beweisen, dass es läuft.

Die Installation von Holiday Island verlief noch beinahe ohne Zwischenfälle, aber der CD-Kopierschutz machte daraufhin Schwierigkeiten, und die SVGA-Autoerkennung schlug bei mir fehl. Der erste erfolgreiche Start des Spiels nach einiger Bastelarbeit im Installationsverzeichnis machte Hoffnung und die Videos liefen einwandfrei. Nachdem ich die ersten Gebäude platziert hatte, erhielt ich einen Bluescreen in der VM, das Spiel lief aber weiter. Soundeffekte und Musik funktionierten mit dem AC’97-Soundchip ganz passabel. Die Performance war im großen und ganzen halbwegs brauchbar, wenn auch nicht optimal. Die Tonausgabe stotterte gelegentlich. Das Optionsmenü zeigte teilweise keine Beschriftungen. Nach etwa 15 Minuten fiel der Sound plötzlich grundlos aus. Fazit: Das Spiel ist spielbar, aber ein wenig leidensfähig muss man mindestens sein.

Zweites Spiel auf meiner Liste war Sim City 2000. Dieses ließ sich ganz einfach installieren und starten. Die Animation im Hauptmenü funktionierte nicht (benötigt wohl 256 Farben), und im Spiel gab es bei mir keine Soundeffekte, aber die MIDI-Musik läuft immerhin. Die Spielperformance sah soweit gut aus. Das Soundproblem ist natürlich eine gewaltige Einschränkung, die ich nicht lösen konnte, aber spielbar ist es irgendwie. Anschließend wollte ich Theme Hospital kurz testen, aber auch hier hat der CD-Kopierschutz den Start verhindert, und ich wollte keine Zeit damit vergeuden, noch mühsam eine lauffähige Version zusammenzupatchen.

Ein Weltraum-Monster greift Atlanta an, in Sim City 2000 aus dem Jahr 1993 in VirtualBox

Das dritte getestete Spiel war Myst von 1993, ein ebenfalls von mir sehr geschätztes Rätselspiel. Auch hier lief die Installation zunächst rund, bis der Installer mir mitteilte, dass er nun Apple Quicktime installieren wolle, woraufhin aber die Installation plötzlich beendet war, und nichts mehr passierte. Ein wenig verdutzt startete ich das Spiel, was auch funktionierte, aber es gab kein Introvideo zu sehen. Stattdessen lag direkt das mysteriöse Buch vor mir. Mit zwei Mausklicks konnte ich es öffnen um zum Pier der Myst-Insel katapultiert zu werden, aber das Spiel hing sich an dieser Stelle auf. Die Transition funktionierte nicht. Ein Neustart der VM war nötig. Das Experiment war für mich hier beendet.

Spiele unter Windows 98 in VirtualBox? Leider nein. Naja, einiges funktioniert natürlich, manchmal sogar erfreulich gut. Anderes dagegen klappt nur mit Einschränkungen oder überhaupt nicht. Die Spielekompatibilität ist hölzern und unkomfortabel, die Performance ok – wenn man Glück hat -, aber gern auch ruckelig und eher langsam, der Sound geht entweder nicht oder stottert. Videos funktionieren mal prächtig unter Holiday Island, aber in Myst leider wieder nicht. Selbstverständlich kann ich nicht ausschließen, dass meine Windows 98-Installation und meine VM-Konfiguration sich noch verbessern lassen, aber zumindest mit Hilfe der üblichen Anleitungen von Fans im Internet lässt sich meines Erachtens nicht viel mehr herausholen. Daher betrachte ich mein Setup dahingehend als nahe am Optimum. Und dieses ist unglücklicherweise wenig optimal um damit meine kleine (wenig repräsentative) Auswahl von Spielen zu spielen. Ich fürchte also, dieses Thema brauche ich künftig nicht mehr weiterverfolgen.

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.

Herr, wirf Hirn vom Himmel! Und wieder habe ich so ein seltsames, altes Spiel durchgespielt. Was soll nur aus mir werden? Offenbar hatte ich in meiner Jugend wohl eindeutig ein Faible für Underdogs was den Spielekonsum betraf. Wo für andere in meinem Alter das PC-Tagesprogramm hauptsächlich aus den Command & Conquers, WarCraft 2, StarCraft sowie Age of Empires bestand (die ich natürlich allesamt ebenfalls spielte), interessierte ich mich dagegen zumeist eher für sowas wie KKND 2, Seven Kingdoms, das zuletzt von mir durchgespielte Theme Hospital, und genau für jenes Spiel, um das es heute in diesem Artikel geht: Beasts & Bumpkins.

Kennt ihr nicht? Wundert mich gar nicht. Beasts & Bumpkins von Worldweaver Productions aus dem Jahr 1997 war kein übermäßig bekanntes Spiel. Tatsächlich war es objektiv gesehen nicht einmal ein besonders gutes Spiel. Das kleine Echtzeitstrategiespiel für Windows 95, das im tiefsten Mittelalter spielt, landete in der deutschen Spielepresse von den Wertungen her im tiefsten Mittelmaß. Ich lernte es nur zufällig durch eine Demo auf der Beilage-CD der PC Games kennen. Aber was soll ich sagen: Bei mir und meinen jüngeren Geschwistern löste dieses seltsame Spiele-Kleinod allgemeine Heiterkeit aus. Es war die Kombination aus einer wirklich niedrigen Einstiegshürde, einem angenehm gemütlichen Wuselfaktor, einer buntfröhlichen, kindgerechten Comicgrafik, und der deutschen, zwar nicht ganz so kindgerechten, aber allemal witzigen Vertonung. Hinzu kommt, dass die Demoversion sehr leicht war, und dem Spieler keine größeren Verrenkungen abverlangte. Wir haben diese Demo wieder und wieder gespielt, und es wurde eigentlich nie langweilig, obwohl die Anzahl verfügbarer Gebäude schon irgendwie kümmerlich war.

Beasts & Bumpkins gehört leider zu jenen Kandidaten, die in der Erinnerung ganz wunderbar waren, aber dann leider doch etwas von ihrem nostalgischen Glanz verlieren, wenn man sich Jahre später noch einmal in den Kopf setzt, sie endlich durchzuspielen. Damit sage ich nicht, dass das Spiel schlecht ist. Es hat zweifellos seine guten Seiten, und es hat seine nervigen schlechten Seiten – und zwar einige davon. Hätte ich rückblickend lieber was anderes spielen sollen? Nein. Aber bin ich froh, dass es nun vorbei ist? Eindeutig ja. Aber fangen wir lieber ein Stück weiter vorne an.

Erstmalig durchspielen wollte ich Beasts & Bumpkins mit seinen 30 (ungefähr einstündigen) Missionen im Mai 2011, also vor knapp 9 Jahren, und zwar in einer Windows XP-VM unter VirtualBox, was auch schon damals perfekt funktionierte. In meinem damaligen ersten Anlauf gelangte ich immerhin bis Mission 19, die mir dann leider ein wenig unfair erschien, und so verlor ich ganz typisch für mich das Interesse. Aber dabei konnte ich es nicht belassen, und so unternahm ich nun im Corona-Quasi-Lockdown einen erneuten Anlauf und startete wieder ganz am Anfang. Überraschenderweise hielt ich diesmal bis zum bitteren Ende durch, obwohl ich mir zwischendurch schon nicht mehr so sicher war, ob das noch was wird.

In Beasts & Bumpkins baut man ein kleines mittelalterliches Bauerndorf auf, indem man Hütten, einen Brunnen, Hühnerställe, Weizenfelder und eine Bäckerei errichtet, und allmählich dabei zusieht, wie die zufriedene bäuerliche Bevölkerung sich mehret. Ein Trademark des Spiels ist die übertrieben ulkige Vertonung aller Figuren, z.B. der Bauern, die die Spielweise des Spielers kommentieren („Unser Herr ist große Klasse!“), lautstark ankündigen, dass sie eine Familie gründen wollen („Ich weiß worauf ich Lust hätte…“ – „Jooou!“), oder nörgeln, dass das mit der Familiengründung noch nicht klappt („Ich brauche weibliche Gesellschaft!“). Einige würden jetzt gerne darauf hinweisen, dass diese Sprachsamples sich leider schnell abnutzen und irgendwann stören, aber das war bei mir nicht der Fall. Im übrigen haben die meisten Spiele dieses Problem in irgendeiner Form („Affirmative!“, „Yes, Sir!“, „Acknowledged!“ etc.).

Nachdem die Siedlung einigermaßen floriert, muss man sich unter anderem um das Rekrutieren von Lakaien, Bogenschützen, Rittern, Kavalieren und sogar Zauberern kümmern, um das Dorf zu verteidigen. Außerdem darf man ein Rathaus errichten, um Steuern einzutreiben, einen Kerker, um Kriminelle zu bestrafen, und etwa eine Kelterei nebst Apfelhain, um die Bauern in die richtige Stimmung zu bringen, was wiederum dem Bevölkerungswachstum zugute kommt. Und es gibt noch eine handvoll weiterer Gebäude, die mal mehr und mal weniger nützlich sind. Wer jetzt erwartet, dass ich von den Holzfällern erzähle, vom Steinmetz, von Minen, um Erze zu schürfen, einem Schmied, um Waffen herzustellen, von Fischern, Metzgern, Schweinezüchtern, Münzprägereien, irgendwelchen komplexen Wirtschaftskreisläufen, der wird enttäuscht sein, denn Beasts & Bumpkins ist sehr minimalistisch was die Ressourcen anbelangt. Es ist kein Siedler oder Anno. Es gibt im Grunde nur drei Ressourcen im Spiel: Bevölkerung, Geld und Nahrung.

Die Missionen des Spiels erzählen die Geschichte von Lord Mildew, dem Spieler, der aus seinem eigenen Land vertrieben wurde, und nun zurückkehrt, um die verlorenen Ländereien Stück für Stück zurückzuerobern und gegen den „Schwarzen Herrscher“ zu kämpfen. Dabei bemühen sich die einzelnen Missionen zwar durchaus um Abwechslung, die meisten jedoch beschränken sich auf das Zerstören eines feindlichen Dorfes oder einer Monsterplage. Das Spiel ist nicht besonders schwer in klassischem Sinne, schon wenn man davon ausgeht, dass mir das Durchspielen gelungen ist. Ich würde dem Spiel einen mittleren Schwierigkeitsgrad bescheinigen, da es zwar durch die ersten idyllischen Tutorial-Missionen Anfänger anlockt, später jedoch immer öfter auch sehr knifflige, nervtötende und unfaire Stellen in einigen Missionen offenbart, die einfach zum Haareraufen sind. Um diese zu überwinden, braucht man starke Nerven, Durchhaltevermögen und eine Menge Glück. Und mit Glück meine ich, einmal pro Minute das letzte Savegame zu laden, wieder und wieder.

Ein Teil des Schwierigkeitsgrads besteht aus meiner Sicht darin, dass die Dorfgemeinschaft in permanenter Gefahr schwebt, meist grundlos auszusterben. Oft steht man nur ratlos da und muss dem Verderben zusehen. Manchmal, einige Minuten nach Beginn einer Mission, kommt es vor, dass die wenigen verfügbaren Frauen im Dorf sich anscheinend dazu entschließen, lesbisch zu werden und keine Kinder mehr zu bekommen. Das ist vor allem deshalb extrem ärgerlich, weil das Spiel gerne in den kritischen Startphasen zu einem ungesunden Ungleichgewicht der Geschlechter tendiert, und der Fortbestand der übertrieben zerbrechlichen Dorfgemeinschaft an einem seidenen Faden hängt. Die Folge ist, dass die wichtigen letzten Dorfbewohner kinderlos alt werden und aussterben. Schon wieder unverschuldet verloren, Levelneustart. Geldprobleme hat der Spieler die meiste Zeit eher nicht, dafür aber permanent Personalprobleme. Die einzigen Dorfbewohner, die überhaupt Berufe erlernen können, sind die Männer, und daher auch die vielseitigste Ressource im Spiel. Da aber die meisten Berufstätigen in Beasts & Bumpkins dummerweise keine Familien mehr gründen (warum auch immer), ist das ganze Spiel eine ständige Gratwanderung zwischen Ausbildung und Aussterben. Zum Glück kann man jeden Berufstätigen mit einigen Mausklicks umständlich wieder in einen Bauern zurückverwandeln, aber solche Verzweiflungsmaßnahmen kommen oftmals zu spät. Wenn die Dorfbewohner plötzlich aussterben, hilft es, wenn man nochmal lädt und exakt denselben Part erneut spielt. Die Dorfbewohner zeigen sich dann manchmal fortpflanzungswilliger als zuvor.

Die andere Schwierigkeit besteht leider darin, dass die eigenen Kämpfer besonders in größeren Gruppen in gefährlichem Terrain kaum noch beherrschbar sind. Größere Soldatengruppen zu kontrollieren (vor allem im Kampf) ist ein unmögliches und absolut schmerzhaftes Unterfangen. Die widerspenstigen Einheiten sind wie Lemminge, man muss sie permanent im Auge behalten, sonst laufen sie jedem Angreifer meilenweit hinterher, die selektierte Gruppe stiebt plötzlich ohne Grund auseinander, gerne auch kopflos direkt in tödliche Fallen hinein (selbst wenn diese mit einem unübersehbaren Schild markiert sind), Die eigenen Soldaten bekämpfen den Gegner entweder nicht oder rennen ihm stur hinterher in den sicheren Tod, sie bleiben niemals dort wo man sie hingeschickt hat. Es machte mich desöfteren wahnsinnig. Wenn mal wieder die komplette Truppe aus purer Dummheit in eine explosive Falle gerannt ist, obwohl man ihnen ausdrücklich befohlen hatte, die Stellung zu halten, hilft leider nur noch schamloses Save Scumming.

Viele Missionen sind nur in den ersten 20 Minuten schwer, weil man oft am laufenden Band von Wölfen, Zombies, Riesenwespen, Fledermäusen, und der Armee der Nachbardörfer angegriffen wird, während man kaum in der Lage ist, eine stabile Population aufzubauen, geschweige denn Soldaten auszubilden. Ständiges, frustriertes Neustarten der Mission ist die Folge. Paradoxerweise hören die Angriffe oft auf, sobald man endlich mal eine halbwegs brauchbare Verteidigung etabliert hat, weil bis dahin sämtliche gegnerischen Einheiten längst beseitigt wurden. Die feindlichen Dörfer, am Anfang noch eine ernstzunehmende Gefahr, entpuppen sich bei Missionsende als Geisterstädte. Dann wenn es eigentlich am spannendsten werden sollte, ist der Rest der Mission leider nur noch simples Durchlaufen mit den eigenen Figuren bis zum Ziel. Meiner Meinung nach ließe sich so etwas auch umsetzen, ohne den Schwierigkeitsgrad noch weiter in die Höhe zu treiben.

Was ich an dem Spiel mag: Das Aufbauen der Dörfer macht Spaß, das Erkunden der nett eingerichteten Levelkarten, die knuffigen, kleinen Rätsel, das Suchen der Missionsziele, und auch die Kämpfe gegen die Wildnis und gegen feindliche Dörfer, sofern man dabei eine Progression erkennt und sie fair sind.
Was ich an dem Spiel hasse: Missionen mit gnadenlosen Zeitlimits, sowie die vielen Kämpfe gegen endlos generierte Monster, die permanent in das Dorf einfallen. Dabei gibt es keinerlei Fortschritt, man gewinnt in den Kämpfen nichts, es werden nur die eigenen Truppen permanent zerrieben, was sehr an den Nerven zehrt. Es ist nicht spannend, es ist nur lästig und ruiniert mir den Spielspaß. Beasts & Bumpkins hat dahingehend leider keine Option für ein gemütliches Endlos-Spiel im Siedler-Stil, sondern nur die vordefinierten Missionen, was ich sehr schade finde. Jedes Aufbauspiel hätte einen solchen Modus verdient.

Interessant sind die beiden Puzzlemissionen, in denen man mit sehr knappen Ressourcen in sehr begrenzter Zeit gegen eine scheinbare Übermacht ankämpfen muss. Hier geht es um richtiges Timing, richtige Ressourcenverwaltung und richtiges Glück. Zudem muss man in vielen Missionen ganz stilecht auf Pestepidemien vorbereitet sein, wenn es mit dem Abtransport der verstorbenen Einwohner hapert. Verliert man das eigene Dorf im falschen Moment aus den Augen, kann es sein, dass Gevatter Tod bereits umgeht und das Dorf kaum noch zu retten ist. Einige Bugs sind mir (wiederkehrend) im Spiel aufgefallen. Ein Scharfrichter hat sich irgendwie in einem Haus verfangen und dann das ganze Haus versehentlich durch das Dorf getragen, bis es sich an einem anderen Haus verkeilt hat. Witzigerweise nicht einfach nur ein Grafikbug, weil die Dorfbewohner von dem verkeilten Haus den Weg versperrt bekamen und das Haus auch markierbar war, während der ursprüngliche Bauplatz bis auf das Fundament leer blieb und auch nicht mehr bebaubar war. Mehrmals ist es mir außerdem passiert, dass ein Ritter oder ein Lakai sofort während der Ausbildung zu einem alten Mann wurde. Man konnte den grummeligen Greis quer über die ganze Karte laufen lassen, und offenbar konnte er auch nicht mehr an Altersschwäche sterben, jedoch war er bei der kleinsten Verletzung tot. Jeder Spieler wird alle paar Missionen auf diesen oder jenen Bug treffen, denn davon gibt es einige.

Beasts & Bumpkins hat nach wie vor einen besonderen Platz in meinem Spielerherzen, und ich mag die Vorstellung, diesen Teil meiner Jugend endlich abgehakt zu haben, denn zurückkehren werde ich dorthin sicher nicht mehr. Das Spiel ist witzig und nett anzusehen, mit seiner pixeligen 640×480-Comicoptik, aber es kann auch ziemlich schwerfällig und wirklich nervig sein. Für neugierige Retrospieler sicherlich noch einen Blick wert, aber ich denke nicht, dass man sich intensiv damit befassen muss, wenn man kein grundsätzliches Interesse an dem Spiel hat. Und damit schließe ich dieses Kapitel nun, um mich dem nächsten Spiel auf meiner Liste zu widmen.

Wieder ist beinahe ein Jahr vergangen, seit ich den letzten Statusbericht zum SPACOLA-Remake abgeliefert habe, daher ist es nun ganz dringend an der Zeit, ein bisschen über die aktuellen Neuerungen seitdem zu plaudern. Bekanntlich habe ich eine ausgedehnte Winterpause eingelegt, so dass die Änderungen sich insgesamt in Grenzen halten, aber ein paar Fortschritte gab es durchaus. Die Entwicklung an dem Spiel verhält sich ein wenig wie ein Gletscher: Egal ob man sich heute, morgen, nächsten Monat oder nächstes Jahr danach erkundigt, wie weit das Spiel fortgeschritten ist, wird es immer so aussehen, als habe sich nichts bewegt – aber es bewegt sich doch! Und jede Änderung wird sogar schriftlich in meinem Devlog dokumentiert.

Smart-Aim

Die neueste Work-In-Progress-Version 0.92 bringt einige nette, aber hauptsächlich experimentelle Spielereien mit, die ich unbedingt ausprobieren wollte. Letztmalig kündigte ich die Möglichkeit eines Aimbots (Smart-Aim) für den Spieler an. Diesen habe ich nun tatsächlich eingebaut. Mit per Menü aktiviertem Smart-Aim muss der Spieler nur noch grob in die Richtung eines Gegners zielen und die automatische Zielhilfe passt den Schusswinkel bis zu einem gewissen Grad so an, dass ein Treffer garantiert ist. Wenn kein Treffer garantiert werden kann, greift die Zielhilfe dagegen nicht ein. Die Arbeit am im letzten Update-Artikel erwähnten Weapon-Interface ist vollständig abgeschlossen. Zusätzlich lassen sich nun ganz einfach per Mausrad die verschiedenen Waffen des Spielers durchschalten und im Spiel verwenden. Das muss nicht bedeuten, dass der Spieler im Endeffekt mehrere Waffen besitzt, aber er könnte theoretisch.

Eingabequellen

Nach dieser kleinen großen Baustelle eröffnete ich dann gleich die nächste, und so überarbeitete ich skrupellos die komplette Spielsteuerung. Meine Idee war die Entwicklung eines flexiblen InputReceiver-Interfaces, das es ermöglichen sollte, verschiedene Eingabequellen für Spieler-Inputs an die Spielerschiffe anzuschließen. Dies wird spätestens im Multiplayer-Modus ein sehr wichtiges Thema. Die konkreten InputReceiver-Implementierungen erzeugen getaktet (pro Update) einzelne „ControlActions“, also gekapselte Eingabedaten, die auf eine abstrahierte Maus und Tastatur anwendbar sind, um ein Spielerschiff und somit die Spielwelt zu beeinflussen. Genauer gesagt habe ich nun einen MouseInputReceiver, der (wie der Name schon sagt) direkt die Maus (und Tastatur) anzapft. Aber zusätzlich habe ich auch einen RemoteInputReceiver, der Benutzereingaben von anderen Mitspielern aus dem Netzwerk empfängt, einen ReplayInputReceiver, der Benutzereingaben aus einer persistierten Datenquelle einlesen und ausführen kann, und zuletzt einen BotInputReceiver, der in Echtzeit künstliche Benutzereingaben anhand eines vorgegebenen Regelwerks erzeugen kann. Moment … Replays? Bots?

Bots

Als ich über die technischen Möglichkeiten meiner dynamischen Gegner-KI, des fertigen Aimbots und der InputReceiver-Logik sinnierte, ist mir plötzlich aufgefallen, dass ich im Grunde schon die halbe Arbeit erledigt hatte, die nötig wäre, um einen kompletten Spieler-Bot zu entwickeln. Diese Idee hatte ich eigentlich schon zu Beginn des Projektes für Skirmish-Multiplayer-Spiele, wenn mal nicht genügend menschliche Mitspieler zur Verfügung stünden. Außerdem würde ein funktionaler Spieler-Bot mir die Arbeit beim Testen erleichtern, da ich nicht mehr gleichzeitig spielen und debuggen müsste, sondern mich auf das Wesentliche konzentrieren könnte. Allerdings fiel mir beim Implementieren auf, dass es wohl doch nicht so ein Spaziergang werden würde, wie ich zunächst dachte. Im Gegensatz zur Gegner-KI, die die Raumschiffe immer direkt steuern kann (drehen, beschleunigen, bremsen, schießen…), darf ein Spieler-Bot im Grunde nur Maus und Tastatur übernehmen, das Spieler-Raumschiff also indirekt mit simulierten Mausbewegungen und Mausklicks steuern. Mit Hilfe der InputReceiver war dies nun zumindest technisch kein Problem mehr. Aber natürlich musste die Logik dafür trotzdem erstmal geschrieben werden.

Nach einigen Tagen des Grübelns, Ausprobierens und auch Scheiterns hatte ich einen halbwegs glaubhaften Bot entwickelt, der in jedem Level losfliegen, bei Bedarf nützliche Powerups einsammeln, Gegner und Asteroiden beschießen und auch ins Ziel fliegen kann. Um das zu bewerkstelligen darf er im Grunde nur die Maus im Kreis bewegen, sowie die linke und die rechte Maustaste drücken. Er kann leider noch nicht ausweichen und ist auch sonst relativ blind und stur, aber er zielt immerhin ganz gut und gewinnt daher auch fast immer. Das Potenzial für Verbesserungen ist dafür enorm, z.B. müsste er verlorene Waren wieder einsammeln. Meine finalen Bemühungen, die Bewegungen des Bots realistischer zu machen, waren begrenzt erfolgreich. Dennoch ist das Ergebnis aus meiner Sicht schon beachtlich. Nebenbei fand ich eine deutlich bessere Methode, einen Abfangvektor zu einem beweglichen Zielobjekt im Level zu berechnen. Diese Methode habe ich mir sogar vorgemerkt, um sie bei der Gegner-KI einzubauen, als ich feststellte, dass das Ergebnis exakt genauso aussieht wie bei etlichen Gegnern im Originalspiel. Endlich war ich auf der richtigen Fährte, nachdem ich jahrelang keine Ahnung hatte, wieso meine KI sich immer irgendwie anders bewegt als im Original.

Replays

Gleich der nächste Knüller: Mit der Idee der InputReceiver konnte ich endlich Benutzereingaben im Spiel aufzeichnen und theoretisch jederzeit erneut ausführen. Fürs Aufzeichnen gibt es im Spiel nun einen ReplayRecorder, der die ControlActions pro Update ableitet und in einem Replay-Objekt speichert. Am Ende wird das Replay-„Tape“ finalisiert und kann im Speicher gehalten oder komprimiert in eine Datei gespeichert werden. Ein ReplayInputReceiver kann dieses Objekt wieder als Eingabequelle für den Spieler wählen. Vereinfacht gesagt, das komplette Gameplay eines Levels lässt sich aufnehmen und anschließend nochmal exakt identisch als Replay abspielen. Da die Aufzeichnung natürlich kein Film ist, sondern nur ein Protokoll aller Benutzereingaben auf einer Zeitachse, ist der Speicherbedarf geringer, aber das Replay anfällig für Veränderungen. Was ich damit meine, wird jetzt deutlich, wenn ich die nächste kleine große Baustelle erwähne, an der ich seit einigen Tagen arbeite.

Die Replays lassen sich zwar endlich perfekt aufnehmen und auch wieder abspielen, aber sie ergeben danach keinen Sinn mehr: Der Replay-Spieler macht zwar alles exakt so, wie das Tape es vorgibt, aber die Spielwelt eben nicht. Das Level sieht anders aus, die Gegner verhalten sich anders, nichts ist da wo es sein sollte. Folglich kracht der Spieler plötzlich wie ein Betrunkener überall dagegen, schießt meilenweit an den Gegnern vorbei, fliegt in die völlig falsche Richtung, und ist quasi nach wenigen Sekunden Gameover. Das Gameplay verlässt sich an sehr vielen Stellen auf Zufallszahlen, und auch die Levelgenerierung ist zufällig. Daran ist im Grunde gar nichts auszusetzen, da Spielentwicklung ganz ohne Zufallsgeneratoren kaum möglich wäre. Was mir nur noch fehlte, war der programmweite Einsatz von reproduzierbaren Zufallszahlen, die auf Basis eines gespeicherten Seeds funktionierten. Gleicher Seed bedeutete dann: Gleiches Level, gleiche Gegner, gleiches Verhalten, alles exakt gleich. Die Spielwelt musste vollständig deterministisch zufällig werden, und die Replays müssten den Seed speichern, der dann die Grundlage für das Replay bildet. Diese Umstellung ist leider sehr aufwändig und umfasst das Umschreiben vieler Bausteine der Levelgenerierung.

Spielereien

Nach diesem schwergewichtigen Problem möchte ich zum Schluss noch kleinere Physikspielereien erwähnen, die ich ins Remake eingebaut habe. Als kleine Option im Enhanced-Modus lassen sich die Stationen der Piraten quasi kugelsicher schalten, so dass die Geschosse des Spielers daran mit passendem Soundeffekt abprallen. Hierzu musste ich meinen Bounce-Code umschreiben, denn der sah bisher nur Kollisionen zwischen zwei beweglichen Objekten vor. Im Spezialfall einer Kollision zwischen einem unbeweglichen und einem beweglichen Objekt durfte eine Reaktion logischerweise nur auf das bewegliche Objekt erfolgen. Das Feuern auf die kugelsichere Station sieht schon recht witzig aus und die abgelenkten Kugeln fliegen einem um die Ohren. Ob das im fertigen Spiel Verwendung findet, steht natürlich auf einem anderen Blatt, aber es schadet nicht, wenn die Funktion schonmal eingebaut ist. Achja, eine weitere Option erlaubt jetzt das Zerstören der Stationen. Ich wollte einmal testen wie es aussehen könnte, wenn im Spiel ein großes Objekt gesprengt wird, und dabei kam diese kleine Funktion heraus. Es werden Unmengen an Explosionspartikeln erzeugt und die Station verabschiedet sich mit einem lauten Knall. Wie gesagt, natürlich nur eine Spielerei. Ergibt auch keinen Sinn, besonders dann nicht, wenn es die Zielstation war.

Eine letzte neue Option im Optionsmenü ist die Wahl der Spielgeschwindigkeit. Hierdurch lässt sich das Spiel mittlerweile erheblich verlangsamen. Für den Anfang kann man die Updaterate daher auf 1/2, 1/4, 1/8 oder 1/24 stellen. Dies ist allerdings nicht nur sinnlose Spielerei, sondern die erste Vorbereitung auf einen Rewrite der Spielengine, der früher oder später dringend nötig sein wird: Das völlige Entkoppeln von Update- und Drawrates, und die stufenlose Wahl der Spielgeschwindigkeit. Es muss also möglich sein, die Spielgeschwindigkeit z.B. drastisch zu reduzieren, aber trotzdem alle Spielobjekte weiter mit bis zu 72 fps flüssig zu bewegen. Denn aktuell bedeutet eine reduzierte Geschwindigkeit nur, dass die Spielwelt weniger oft aktualisiert wird, und dann spielt die Framerate eben keine Rolle. Das Spiel sieht dann leider nicht nach Zeitlupe aus, sondern nach Diashow.

Meilenstein

Es gibt da zwar noch so ein Thema, einen wichtigen Meilenstein, den ich unbedingt erläutern möchte, aber das werde ich demnächst in einem separaten Artikel abhandeln, da es sehr umfangreich wird.

Eine seltsame, geradezu verschrobene Person wie ich, die mit ihren Gedanken sowieso bei jeder Gelegenheit in der Vergangenheit ist, ständig der Vergangenheit nachhängt, ihr beinahe nachweint, verbringt auch übermäßig viel Zeit damit, nach Wegen zu suchen, die Vergangenheit für sich zu erhalten. Und die Nostalgie ist stark in mir. Praktisch schon als Jugendlicher wurde ich regelmäßig nostalgisch gegenüber sämtlichen Dingen, die ich aus der (damals noch gar nicht so lange zurückliegenden) Kindheit kannte. Das betrifft das übliche Spektrum typisch nostalgiegeladener Dinge von Spielsachen, Zeitschriften, TV-Serien, über Personen, alte Schulsachen, Musik, bis hin zu Orten, Snacks und Süßigkeiten, und in meinem Fall eben auch ganz besonders: Computer, Computerspielen und anderer Software.

Schon in den späten 90er Jahren befasste ich mich durchgängig mit Emulatoren für den Atari ST, den Amiga, den C64, sowie sämtlichen beliebten Spielekonsolen meiner Kindheit, bastelte an Konfigurationen und verwendete gerne Programme und Spiele, die praktisch als ausgestorben galten. Allein die Vorstellung, für mich wichtige veraltete Hardware auf einem einzigen modernen Notebook bzw. Rechner zu vereinen, komplett mit einer umfangreichen Softwarebibliothek, jederzeit auf Knopfdruck abrufbar, erfüllte mich mit einem wohligen Gefühl. An diesem kleinen Traum arbeite ich praktisch seit Jahrzehnten. Und die technischen Möglichkeiten werden von Jahr zu Jahr besser, weil die Prozessoren immer leistungsfähiger und die Festplatten immer größer werden.

Während ich etwa das Feld der Amiga- und Atari ST-Emulation, sowie der meisten Spielekonsolen von vor 1994 weitestgehend abgearbeitet und durchleuchtet habe, kam vor knapp 15 Jahren ein weiteres großes Thema auf meiner Agenda hinzu: PC-Emulation. Dabei mag es vordergründig zunächst schwachsinnig klingen, einen PC auf einem PC emulieren zu wollen. Doch so unlogisch ist das nicht. Der PC als Plattform ist mittlerweile so alt, ausdauernd und langlebig, dass er viele Äras und Iterationen von Hardwarestandards und Betriebssystemen durchlebt hat. Das ist zwar eigentlich fast überall so, aber nirgends waren die Schritte so groß wie hier: Die Spanne reicht mindestens von den ersten x86-Prozessoren in den IBM PCs von Anfang der 80er mit MS-DOS, über den 486ern, Pentiums, dem K5 und z.B. den Cyrix-Prozessoren Mitte der 90er mit Windows 3.x/Windows 95, bis hin zu deutlich modernerer Hardware wie Mehrkernprozessoren und vollständig multitasking- und multiuserfähiger Betriebssysteme wie Windows XP/Vista/7/8/10 und Linux. Und dabei habe ich nur einen ganz groben Querschnitt aufgezählt. Diese sich permanent verändernde Umgebung innerhalb der Plattform bringt es mit sich, dass Software, die beispielsweise heute noch tadellos läuft, morgen schon nur noch eingeschränkt mit Tricks zum Laufen gebracht werden kann, während sie übermorgen wegen Hardwareinkompatibilitäten und weggefallener Betriebssystemstandards überhaupt nicht mehr startet, und das ist nur völlig natürlich und irgendwo auch notwendig, denn manchmal müssen alte Zöpfe zum Wohl des Fortschritts abgeschnitten werden. Das haben wir bei Spielen und Programmen unter MS-DOS beobachtet, danach mit 16-Bit-Windows-Software, die heute garantiert nirgends mehr läuft, und inzwischen gehen auch 32-Bit-Programme allmählich unter. Gegensteuern kann man hier nur mit Kompatibilitätschichten, Virtualisierung und Emulation.

PC-Virtualisierung bzw. -Emulation gibt es schon sehr viel länger als ich mich damit befasse. „Bochs“ gibt es seit 1994 und „QEMU“ immerhin seit 2003. Mit beiden bin ich leider nie besonders gut klargekommen, sie sollen aber, in den richtigen Händen, äußerst leistungsfähige Werkzeuge sein. Bei den Virtualisierern erprobe ich VMware, VirtualBox und Virtual PC schon seit langem. Letzteres fand sogar in Form des vorkonfigurierten „Windows XP-Modus“ einst offiziell seitens Microsoft Einzug in Windows 7, um erwartete Kompatibilitätsprobleme zumindest abzufedern. Mit „DOSBox“ gibt es seit 2002 einen Emulator, der einen typischen DOS-Rechner mit allen Schikanen nachstellt, und der speziell für Spiele optimiert wird. Dieses kleine aber äußerst kräftige Tool ist so gut, dass es von Spieledistributionsplattformen wie GOG offiziell verwendet wird, um die Nutzung sämtlicher DOS-Spiele unter modernen Betriebssystemen zu ermöglichen. DOSBox emuliert den PC heute so akkurat und schnell, dass man im emulierten DOS sogar Windows 95 installieren und darunter Spiele spielen kann – leider mit diversen technischen Einschränkungen.

Soviel also zur Einleitung. Vor wenigen Monaten entdeckte ich eher zufällig einen weiteren Mitstreiter auf dem Gebiet der PC-Emulatoren: PCem. Dieses Programm ist vereinfacht gesagt das Windows-Gegenstück zu DOSBox, wenn auch noch lange nicht auf Windows beschränkt. PCem emuliert grundsätzlich eine ganze Vielzahl von alten Mainboards, Prozessoren, Grafikkarten, selbst einst beliebte 3D-Beschleuniger wie Voodoo und Voodoo2. Entsprechend lassen sich damit die allerersten PCs, bis hin zu PCs der Pentium MMX Ära emulieren. Die akkurate Low Level Emulation fordert jedoch ihren Tribut, so benötigt man zur Nachbildung meines damaligen 200 MHz Pentiums von 1997 heutzutage über den Daumen gepeilt knapp 4 GHz Taktrate auf einem einzelnen Kern, denn selbstredend lässt sich die Emulation eines Singlecore-Prozessors nicht einfach auf mehrere Kerne aufteilen. Das ist also mal eben das 20-fache an Leistung.

Das beste an PCem ist, dass er mit dem Ziel entwickelt wird, Spiele perfekt zu unterstützen, also einer der hardwareforderndsten Formen von Software, was mich insgesamt sehr begeistert hat. Wenn man den Gerüchten glauben durfte, soll die Voodoo2-Emulation inzwischen so brauchbar sein, dass hardwarebeschleunigte 3D-Spiele aus der Zeit kurz vor der Jahrtausendwende mit Abstrichen problemlos spielbar sein sollen. Dies wollte ich unbedingt selbst testen und so versuchte ich mich einmal an einer kleinen Demo-Installation, die einen halben Tag in Anspruch nahm.

Ich will hier an dieser Stelle bewusst nur einen Erlebnisbericht und kein Tutorial schreiben, weil die Installation leider relativ aufwändig ist, und es schon diverse brauchbare Anleitungen im Internet gibt. Der Aufbau einer lauffähigen Konfiguration in PCem ist nicht sehr intuitiv im Gegensatz zu DOSBox oder VirtualBox, aber die Mühe lohnt sich. So ist PCem nach der Installation leider völlig nutzlos, benötigt er doch eine ganze Reihe an BIOS-Dateien für die ganze Hardware, die man haben möchte. Die Verwendung derselben ist wohl nur so halblegal, die entsprechenden Dateien lassen sich aber an vielen Ecken finden. Hat man diese Hürde überstanden, darf man seinen emulierten Pentium zum ersten Mal einschalten und findet eine nicht bootfähige, unformatierte Festplatte vor. Nach einigen Fehlversuchen gelang es mir schließlich tatsächlich, mit Hilfe mehrerer Bootdisketten und meiner eigenen CD ein taufrisches Windows 98 SE zu installieren, das auch fehlerfrei bootete. Die größte Zeit aber beanspruchte die nervenaufreibende Schnitzeljagd im Internet nach Treibern für die SoundBlaster 16, der Voodoo2-Karte und DirectX 7.0, zudem generische Maus- und CD-ROM-Treiber, die ich ganz klassisch in die CONFIG.SYS und AUTOEXEC.BAT einpflegen durfte. Oh wie lange ich diese beiden Dateien schon nicht mehr gesehen habe. Nostalgie pur!

Das Betriebssystem machte einen stabilen, schnellen und vor allem makellosen Eindruck, im Gegensatz zu so mancher gleichförmiger Installation unter VMware Workstation, die mit Windows 9x oft schon beim Sound überfordert schien. Aber ich wollte mein neues altes System definitiv einer Feuerprobe unterziehen und beschloss daher, einen Klassiker aus meinen alten Tagen zu installieren, den ich wirklich sehr gerne und sehr lange gespielt habe: Need for Speed III: Hot Pursuit.
Die Installation von CD-Image verlief in PCem ausgesprochen gemütlich, und das Spiel startete schließlich (nach Korrektur der Hardwarekonfiguration und Installation noch fehlender Treiber) sogar ohne weitere Schwierigkeiten und plötzlich lief das actiongeladene Introvideo von NFS3 – fast ohne Ruckler. Eigentlich hatte ich erwartet, dass das Spiel mir zunächst via Dialogbox meldete, dass ich doch bitte die CD einlegen solle, so wie das früher (durch den CD-Kopierschutz) bei gebrannten Datenträgern ein generelles Thema war. Aber möglicherweise ist auch das in PCem gar kein Problem mehr.

Nun, was soll ich sagen. Schon kurz darauf drehte ich meine ersten paar Runden in der Corvette über meine Lieblingsstrecke, den Gebirgspass, in gnadenlosen Rangkämpfen gegen Lamborghinis, Ferraris, Aston Martins und anderen Sportwagen, teils auf der Flucht vor der Polizei, teils auch nur gegen die Zeit. Anfangs noch ein wenig wackelig mit etlichen Kollisionen, gewann ich mein altes Fahrgefühl bald wieder zurück und ehe ich mich versah, driftete ich wie vor über 20 Jahren mit Begeisterung in die Kurven, gab Vollgas auf den Geraden, versuchte die perfekten Bremspunkte zu finden, und schlängelte mich zwischen den gegnerischen Boliden hindurch auf dem Weg an die Spitze des Fahrerfeldes. Die Kompatibilität ist wie erwartet einwandfrei, es gibt keine Fehler oder grafische Glitches. Die Performance ist auf meiner Kiste nicht bahnbrechend, aber ausreichend schnell. Für die Standardauflösung des Spiels von 640×480 reicht es allemal, mehr ist nicht zu empfehlen. Die größte Schwierigkeit hierbei wird sein, dass die 3D-Beschleunigung paradoxerweise in Software emuliert wird, und so natürlich keine Vorteile von der Leistungsfähigkeit der physischen Grafikkarte erfährt. Dennoch gibt es spürbare Performanceverbesserungen durch den Einsatz der Voodoo2-Schnittstelle im Gegensatz zum Software-Renderer.

Die Demonstration war für mich ein voller Erfolg, vielleicht nicht komplett repräsentativ, aber in jedem Fall sehr beeindruckend. PCem erlaubt keine Festplatten-Snapshots wie bei Virtualisierungssoftware üblich, aber meine perfekt eingerichtete, unberührte Konfiguration habe ich für die Zukunft weggesichert und werde auf diese künftig regelmäßig zurückgreifen. Auch erwarte ich weitere Verbesserungen durch die jährlich erscheinenden, neueren Versionen von PCem, so dass das Retro-Spielvergnügen immer besser wird und auch die mit ziemlicher Sicherheit existierenden Grenzfälle unterstützt. Mal sehen welches Spiel ich als nächstes installiere. Vielleicht Interstate ’76. Es sollte jedenfalls ein echter Problemfall sein, der heute nur noch sehr schwer lauffähig gemacht werden kann.

Nach anfänglichen Zweifeln vor etlichen Jahren ob wir jemals in der Lage sein würden, die früheren Windows-Spiele (ab circa 1993 bis Anfang der 2000er) jemals lückenlos in spielbarer Form zu bewahren, abseits natürlich vom Weiterbetrieb der echten Legacy-Hardware, bin ich nun überzeugt, dass für Retrogamer wie mich endlich goldene Zeiten anbrechen. Mit DOSBox, PCem, VirtualBox, VMware und diversen anderen Lösungen, die glücklicherweise allesamt nicht nur für Windows sondern auch Linux und mitunter anderen Plattformen verfügbar sind, dürfte die sich stetig verbessernde Kompatibilität endlich flächendeckend ermöglichen, auch hartnäckige Fälle von Spielen perfekt spielbar zu machen und somit vernünftig zu erhalten. Und natürlich muss man sich auch nie wieder Sorgen über eine ewige Abhängigkeit von Windows machen, denn egal ob Spiele für DOS, Windows 95/98 oder XP: Heute läuft endlich (fast) alles überall. Und hey, mit Wine und Proton sind wir sogar schon für die Spiele danach wirklich gut aufgestellt, mit unzähligen Optimierungen und Verbesserungen, die monatlich dazukommen. Wahrlich goldene Zeiten sind das.