Schlagwort-Archive: Spiel

Ich will jetzt nicht unbedingt behaupten, dass ich fleißig bin, aber wenn ich mal ausnahmsweise nicht faul bin, dann bin ich so richtig nicht faul. Nach einer längeren Abwesenheit und gleichzeitigen Arbeitspause an meinem Spiele-Remake, bin ich nun endlich wieder dran. Mich hat aus irgendeinem mysteriösen Grund plötzlich wieder die Motivation eingeholt, und sofort konnte ich zumindest wieder etliche Kleinigkeiten angehen und Fehler korrigieren. Allerdings habe ich durch Zufall ganz unerwartet einen weiteren Meilenstein bei der Entwicklung erreicht; einen Punkt auf meiner To-Do-Liste, den ich definitiv irgendwann umsetzen wollte, selbst wenn dies einen Nutzen nur theoretischer Natur auf dem Papier bringt.

Was bisher geschah: Einem unfassbar mäßig begabten Entwickler eines Spiele-Remakes, der zwar nicht vom Erfolg seines Projektes überzeugt, aber dafür wenigstens nicht von seinem Ziel abzubringen ist, war es gelungen, die Original-Dateien des Atari ST-Spiels SPACOLA mit Hilfe eines Debuggers zu entpacken und anschließend sogar das undokumentierte Format der Sprite-Dateien zu dechiffrieren und einen eigenen Konverter zu schreiben. Dies sollte ihm endlich einen wichtigen Einblick in die Hintergründe der Unterhaltungssoftware einer längst vergessenen Zivilisation geben. Wie hatten unsere Vorfahren einst Spiele entwickelt? Wurden die Quellcodes damals noch in Keilschrift verfasst? Mussten Benutzer an einer Kurbel drehen, wenn sie ihren Heimcomputer starten wollten? Waren antike Computerprogramme auch nur in schwarzweiß? (In diesem Fall, ja!). Unermüdlich arbeitete der selbsternannte Software-Archäologe weiter an den historischen Dokumenten, um vielleicht irgendwann einmal das perfekte Remake zu erschaffen.

Teil 3 meines fortlaufenden Hintergrundberichts: Es war eigentlich reiner Zufall als ich im Internet auf die Reverse-Engineering-Erkenntnisse von Jeremy Sawicki aus dem Jahr 2003 stieß. Der hatte diverse OXYD-Spiele in ihren Farbversionen für den IBM-PC erfolgreich analysiert und deren Formatspezifikationen offengelegt, darunter das Levelformat, die Grafik- und Sounddateien. Seine Dokumentation war unter anderem nützlich bei der Entwicklung des freien OXYD-Klons Enigma. Als ich mir die Angaben zum Grafikformat genauer ansah, erkannte ich plötzlich viele Gemeinsamkeiten zu den PAC-Dateien, die in den alten Monochromversionen der frühen Dongleware-Klassiker Verwendung fanden. Diese Dateien enthielten binäre Vollbildgrafiken für die Spiele seit Esprit (1989) und bis mindestens OXYD2 (1991).

Ich hatte mich natürlich längst selbst mehrfach daran versucht, das seltsame Dateiformat zu dekodieren, zuletzt auf Grund meiner Erfolge beim Konvertieren der Sprite-Dateien, doch das PAC-Format widersetzte sich meinen Annäherungsversuchen konsequent. Bis auf einige sehr offensichtliche Headerinformationen konnte ich kaum sinnvolle Werte herauslesen, und meine einzigen Erkenntnisse über das Kompressionsverfahren bestanden darin, dass das Bild in Blöcke unterteilt wird, und die Pixelinformationen grundsätzlich durch ein XOR-Verfahren invertiert von oben nach unten beschrieben werden. Durch Manipulieren der Dateien im Hexeditor und anschließendem Beobachten der Auswirkungen in OXYD, stellte ich erstaunt fest, dass die Dateistruktur eine sehr eigenwillige sein musste, weil oft komplett unvorhersehbare und unintuitive Artefakte im Bild dadurch enstanden. Als ich keinerlei Gesetzmäßigkeiten ausmachen konnte, gab ich mein Vorhaben desillusioniert auf.

Seit heute weiß ich endlich sehr genau, was das große Problem war. Von Sawickis Arbeit angespornt, begann ich endlich an der Entwicklung eines eigenen Konverters, den ich letztlich in mein Remake einbauen wollte, so wie bereits getan beim Konverter für Sprite-Dateien. Ich studierte die Formatspezifikationen und implementierte die Dekompressions- und Zeichenroutinen. Ohne nun zu sehr ins Detail zu gehen (wer alles wissen möchte, kann die Originalseite lesen), besteht jede Packed-Bitplane-Datei aus einem Header, einem Bitstream und einem Bytestream. Der Bitstream beschreibt dabei die gesamte Struktur des Bildes, sowie Angaben über die Kompressionsmethodik, und der Bytestream enthält die tatsächlichen Pixeldaten, die entsprechend gezeichnet werden müssen.

Jedes Bild hat die Auflösung von 640×400 Bildpunkten und ist in Blöcken von je 16×16 Pixeln aufgeteilt. Der Bitstream beschreibt dabei, wie das Bild nacheinander in Reihen von Blöcken, Blöcken, Blockquadranten und Reihen von Pixeln in immer kleinere Häppchen aufgespalten wird, wobei jedes Element entweder übersprungen oder gezeichnet werden kann. Müssen Pixel gezeichnet werden, so wird ein Byte aus dem Bytestream gelesen und dessen Bits als Pixel interpretiert, abhängig von einer der Pixelreihen darüber, die miteinander XOR-verknüpft werden, also je nachdem ob ein Bit gekippt wird oder nicht. Die Formatspezifikation von Sawicki ist dabei technisch betrachtet soweit korrekt, aber leider an mehreren Stellen etwas unpräzise formuliert, so dass ich mehrere Fehler machte, deren Behebung mich viel Zeit gekostet hat.

Das Titelbild „TITLE.PAC“: Die einzelnen Fortschritte während der Entwicklung des PAC-Konverters von oben nach unten. (Rote Bereiche sind nur Hintergrund, wo noch nichts gezeichnet wurde.)

Während der Entwicklung fiel mir jedoch auf, dass Sawicki eines der Features des proprietären Dongleware-Formats definitiv nicht kannte: Neben dem Invert-Flag, das festlegt, ob das fertige Bild noch invertiert werden muss, gab es in meinem Archiv eine einzelne Datei, die ein undokumentiertes Flag setzt. Zum Glück konnte ich am Output des Konverters bereits erkennen, was dem Bild fehlte: Es musste ein Dithered Pattern („Schachbrettmuster“) mittels XOR über das gesamte fertige Bild gezeichnet werden, um die ursprüngliche Grafik wiederherzustellen. Dieser Modus wird wohl zwar nur sehr selten angewandt, aber mein Konverter unterstützt dieses Feature nun ebenfalls. Im Endeffekt war es mir in geschätzt sechs bis sieben Stunden gelungen, eine Implementierung abzuliefern, die sämtliche 16 PAC-Dateien, die ich aus vier Spielen gesammelt hatte, fehlerfrei einzulesen und anzuzeigen vermochte.

Ohne das hilfreiche Dokument wäre ich immer noch nicht schlauer, und sonst einen Konverter zu schreiben, hätte ich wahrscheinlich nur geschafft wenn ich viele Wochen und Monate in mühsames Debugging der Spiele investiert hätte. Ob ich mir diese Zeit jemals hätte nehmen wollen, sei mal dahingestellt. Nun bin ich umso glücklicher über diese angenehme Abkürzung, die ich nehmen konnte. Der Konverter ist fertig und bereits ins Remake eingebaut. Dadurch bin ich jetzt endlich in der Lage, auch die originalen Grafikdateien in unveränderter Form im Remake einzulesen und zu verwenden. Das macht – wie eingangs im Absatz beschrieben – für den Spieler absolut keinen Unterschied, für mich als Entwickler mit Perfektionsdrang aber einen gewaltigen.

Mein SPACOLA-Remake kann nun die ursprünglichen Sounddateien, die Sprites und die Grafikdateien korrekt lesen. An der Interpretation der originalen Leveldaten arbeite ich mich weiterhin Schritt für Schritt voran, sie werden aber immerhin schon komplett eingelesen. Alles was jetzt noch vollständig fehlt: Die Musikdaten im SMS Synthesizer-Format von Jürgen Piscol. Ob ich dieses Kapitel jemals abschließen werde, lässt sich im Moment noch nicht einmal sagen. Andererseits, wer weiß schon, ob sich nicht doch wieder jemand findet, der zufällig eine detaillierte Analyse des Formats in Schriftform für mich zur Einsicht hat. Dann könnte nämlich alles ganz schnell gehen.

Das „Boss Is Coming“-Bild aus OXYD2, dargestellt im PAC-Konverter, zeigt den Datenbank-Manager „Phoenix“ von den Application Systems Heidelberg

Und falls sich nun jemand fragt, wieviele PAC-Dateien in SPACOLA Eclipse denn nun eingelesen und angezeigt werden können: Es sind ganze vier Dateien! Erstens, das Titelbild beim Laden des Spiels. Zweitens, das typische HUD mit dem Radar auf der rechten Seite. Drittens, der Rentenbescheid zum Ausdrucken nach Abschluss des letzten Levels. Die vierte und letzte PAC-Datei ist tatsächlich ein ungenutztes Bild, das die Kontaktadresse des Dongleware-Verlages enthält. Vermutlich wurde es in einer früheren Version des Spiels verwendet, und dann durch ganz normalen Text in der Dongleware-Schriftart ersetzt. Alle diese vier Originaldateien werde ich nun ins Remake einbauen und in irgendeiner Weise nutzen, damit sich der ganze Entwicklungsaufwand auch gelohnt hat.

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.

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.

Ende der 90er Jahre war es leicht, ein Bullfrog- und Peter Molyneux-Fan zu sein. Die britische Spielefirma kannte ich bereits seit meiner Kindheit von Powermonger und Populous auf dem Atari ST, später spielte ich auch Theme Park und Hi-Octane, und auch in Syndicate Wars investierte ich viel Zeit. Das Jahr 1997 brachte uns gleich zwei Kracher von der Insel: Dungeon Keeper und Theme Hospital. Ersteres räumte für seine innovative Spielidee und grandiose Umsetzung viele Preise ab, letzteres stand dagegen ein wenig in dessen Schatten. Es wurde zwar lobend und wohlmeinend beurteilt, es habe zwar nicht ganz die Klasse des wesentlich bekannteren Freizeitpark-Vorgängers von 1994, aber sei dennoch ein witziges und angenehm zu spielendes, solides Werk, vielleicht ein wenig verbuggt, aber doch insgesamt gut. Und schon nach kurzer Zeit geriet das Spiel in Vergessenheit.

Theme Hospital ist ein Krankenhaus-Aufbauspielchen mit isometrischer 2D-Comic-Grafik, witzigen Fantasiekrankheiten und schrägen Animationen. Wer als Kind eine Playmobil-Arztpraxis betrieben hat, wird Theme Hospital lieben. Zu knuffig sind die vielen kleinen Leute, die durch die Gänge tapsen, ihrer Arbeit nachgehen, sich behandeln lassen, oder die Toilette aufsuchen. Die Grafik ist farbenfroh und nach damaligen künstlerischen Maßstäben wunderbar gepixelt. Der Schwierigkeitsgrad lässt sich in drei Stufen einstellen, ist aber insgesamt höchstens moderat. Da die Windows 95-Version heute nicht mehr überall besonders gut läuft, und diese bei mir auch unter VirtualBox in einer XP-VM leider extreme Performance-Probleme hatte, musste ich zur DOS-Version (Gepatchte deutsche Version 1.0.0.1) in der Emulation via DOSBox greifen, was problemlos funktioniert hat.

Mein jüngeres, 15-jähriges Ich würde wohl ungläubig gucken, wenn ich ihm erzählte, dass er noch fast 20 Jahre braucht, bis er das Spiel tatsächlich durchspielt. Aber es ist endlich vollbracht. Und so wurde Theme Hospital hiermit zum allerersten Spiel, das ich komplett in DOSBox bis zum Ende gespielt habe. Nachdem ich die Demoversion nach 1997 schon gespielt hatte bis der Arzt kommt, enttäuschte mich die Vollversion, die ich mir nicht mehr als zwei Jahre später besorgte, zunächst maßlos. Der Grund war recht simpel: Die ersten paar Levels sind wunderbar zu spielen, und haben mich genauso sehr mitgerissen wie die Demo. Und dann kamen die Epidemien.

Epidemien sind Zufallsereignisse und im wahrsten Sinne des Wortes die Pest in Theme Hospital. Sie machen mir das Spiel zur Hölle, was mir auch Ende der 90er schon unangenehm aufgefallen ist, weshalb ich es frühzeitig aufgegeben habe. Wer von einer Epidemie heimgesucht wird, kann diese entweder pflichtbewusst freiwillig melden und zahlt pauschal 10.000 Dollar Strafe. Das ist schon nicht leicht zu stemmen, besonders weil Epidemien in den höheren Levels ständig auftreten, gerne auch gleich mehrmals hintereinander, und man dadurch ruckzuck pleite ist und den Level von vorne beginnen darf.

Sinnvoller ist es, die Epidemien zu vertuschen und heimlich zu bekämpfen. Dann muss man eigentlich nur die betroffenen Patienten suchen und händisch mit der Maus markieren. Die Krankenschwestern können dann die markierten Patienten impfen. Schließlich muss man nur noch dafür sorgen, dass die Epidemie-Patienten schnell geheilt werden, bevor das Gesundheitsamt Wind davon bekommt. Dumm nur, dass hier absolut nichts funktioniert: Die Krankenschwestern übersehen minutenlang einzelne markierte Patienten, selbst wenn sie direkt davorstehen, selbst wenn man zehn extra neu angestellte Krankenschwestern direkt neben ihnen abstellt. Im schlimmsten Fall ignorieren sie die Patienten bis zum bitteren Ende.

Und sogar wenn alle Patienten erfolgreich geimpft sind: Ob und wieso eine Epidemie vom Gesundheitsminister entdeckt wird, scheint reiner Zufall zu sein. Beim allerersten Fall zahlte ich astronomische 36.000 Dollar Strafe und war auf einen Schlag ruiniert – Level verloren, alles für die Katz. Ein anderes Mal sind es „nur“ 8000 oder gar 4000 Dollar Strafe, und hin und wieder gewinnt man und bekommt plötzlich 9000 Dollar Entschädigung für eine Epidemie. Oft reicht es, wenn man dieselbe Epidemie via Savegame ein zweites oder drittes Mal spielt, ohne dass man den Eindruck hat, weniger falsch gemacht zu haben, schon ändert sich das Ergebnis extrem. Die Epidemien scheinen komplett fehlerhaft zu sein, und machen das Spiel fast ungenießbar. Denn eigentlich will man bauen und verwalten, und sich nicht ständig davor fürchten müssen, dass die nächste Epidemie mir das Level ruiniert. Dass die Epidemien oftmals schon in der frühesten Spielphase fast ausschließlich Krankheiten betreffen, die man noch nicht einmal behandeln kann, ist nur ein weiteres der unzähligen Probleme des Spiels.

Doch zum Glück gibt es für diesen Bug auch gleich einen Konter-Bug. Wenn man das Spiel sofort speichert, bevor man eine Epidemie „angenommen“ hat, kann man durch geduldiges Neuladen und Epidemiewarnung wegklicken, die Epidemiewarnung irgendwann gänzlich verschwinden lassen. Wenn das passiert, taucht im gesamten restlichen Level keine weitere Epidemie mehr auf, denn der Epidemiestatus scheint dadurch im Nirvana zu hängen. Durch diesen kleinen Kniff wurde das Spiel für mich tatsächlich wieder spielbar. Ein wirtschaftlich rentables Krankenhaus mit einem guten Ruf aufzubauen, ist schließlich schon schwer genug. Und selbst wenn man den Bug nicht triggern kann, kann man durch das Zurückgehen auf ein älteres Savegame die kommende Epidemie oft noch vermeiden.

Auch wenn es grausam klingt: Patienten, deren Gesundheitszustand sich rapide verschlechtert (zu erkennen an dem traurigen Smiley, der sich Schritt für Schritt in einen Totenschädel verwandelt) sofort aus dem Krankenhaus schmeißen, wenn sie nicht offensichtlich kurz vor der Heilung stehen. Das Spiel bestraft Sterbefälle nämlich rigoros. Zum einen ist der Imageschaden pro verlorenem Patienten deutlich spürbar, zum anderen fehlt in der Jahresendabrechnung der großzügige Keine-Sterbefälle-Bonus von 10.000 Dollar, der gerade in höheren Levels über Sieg oder Pleite entscheidet. Des Krankenhauses verwiesene Patienten mindern den guten Ruf dagegen auch in größeren Zahlen kaum. Daher am besten knallhart bleiben und die schwerkranken Patienten konsequent vor die Tür setzen, bevor sie zum Problem werden. Bei längeren Warteschlangen kippen die Menschen garantiert früher oder später reihenweise um, und der Sensenmann freut sich über das gute Geschäft. Später habe ich dann zum Glück begriffen, dass das Spiel von mir erwartet, Räume mehrfach zu bauen. Am Ende ist es keine Seltenheit mehr, dass man fünf, sechs oder noch mehr Allgemeinmediziner gleichzeitig beschäftigt.

Achja, die Erdbeben, das nächste Ärgernis in dem Spiel. Wiederholt kam es vor, dass einwandfreie medizinische Räume, die erst Sekunden zuvor von einem Handwerker repariert worden waren, durch ein folgendes Erdbeben zerstört wurden, obwohl das gar nicht passieren dürfte. Und zerstörte Räume sind dann im Spiel auch noch unbenutzbarer Platz, der sich nicht für alles Geld der Welt renovieren lässt. Oft reicht gefühlt schon ein winziger Kratzer an einem Diagnose- oder Behandlungsgerät und beim nächsten Erdbeben fliegt einem alles um die Ohren. Es nervt wirklich sehr.

Weiter gehts mit den Notfällen: Am Anfang ist man meistens ganz froh, wenn man mit der Pharmatheke, dem Entlüfter, und der Polyklinik wenigstens ein paar einfache Basiskrankheiten heilen kann, um nicht sofort rote Zahlen schreiben zu müssen, und dann kommt ein Notfall rein: Vier Patienten mit außerirdischer DNA. Oder 13 Patienten mit Verstrahlung. Schön für euch, ich kann euch nicht helfen. Aber sobald man endlich alle Krankheiten diagnostizieren und behandeln kann, kommen keine Notfälle mehr rein. So ist Theme Hospital. Genauso albern wie seine Animationen.

Einmal war ein Arzt aus irgendeinem Grund unter einem Billardtisch im Personalraum gefangen. Bei einem angekündigten Notfall mit sechs Patienten sind vier erst gar nicht aufgetaucht. Ich habe die ganze Karte nach ihnen abgesucht. Entsprechend wurde mir der Bonus verwehrt, weil ich nur zwei retten konnte. Und das kam später mehrmals vor. Gleich mehrere Ärzte wollten ums Verrecken ihre endlose Ausbildung zum Berater nicht abschließen. Irgendwann war ich mir sicher, dass ich einen Bug gefunden hatte. Als ich schließlich aus Verzweiflung den Lehrer ausgewechselt habe, sind nur eine Sekunde später auf einen Schlag fast alle Ärzte gleichzeitig zu Beratern aufgestiegen.

Die deutschen Texte in dem Spiel sind leider voller Fehler, numerische Werte werden falsch eingesetzt oder falsch umgerechnet („Sie haben Diagnosegeräte von 100 2.121996e-314rforscht.“, „Melden Sie die Epidemie, müssen Sie eine Strafe von 1852392736 zahlen.“). Einige „Tipps“ sind komplett irreführend und wenig hilfreich („Ihre Empfangsdamen sind total erschöpft. Veranlassen Sie sofort, daß sie eine Pause einlegen.“). Eine meiner Krankenschwestern wollte ihren Behandlungsraum partout nicht mehr verlassen, litt dadurch am Ende unter einem Burnout, und verlangte schließlich eine Gehaltserhöhung nach der anderen. Die Liste der Fehler ließe sich vermutlich noch eine Weile fortsetzen.

Kann ich das Spiel unter den gegebenen Umständen und trotz seiner vielen Problemchen überhaupt noch empfehlen? Aber unbedingt! Theme Hospital mag ein bisschen sperrig sein, es mag verbuggt sein, aber es hat Charme, es hat Spielwitz, es ist spannend, fordernd, es ist nett anzusehen, und der Wuselfaktor ist relativ hoch. Man muss mit seinen Macken umgehen können, dann macht das Aufbauen auch heute noch gehörigen Spaß. Leider krankt die Einzelspieler-Kampagne an einem Problem, das viele vergleichbare Aufbauspiele haben: Es ist furchtbar repetitiv. Im Prinzip baut man 12 Krankenhäuser auf, bis man den Abspann sieht. Von der Rezeption bis zum allerletzten Behandlungsraum muss man jedes Krankenhaus immer wieder von vorne hochziehen und liebevoll einrichten. Und es ist oft frustrierend, wenn man wirklich viel Zeit und Mühe in den Aufbau eines Krankenhauses investiert hat, endlich alles perfekt und rund läuft, den Level-Ende-Bildschirm sieht, um dann gleich wieder bei Null anfangen zu müssen. Irgendwann war dann auch bei mir die Luft raus. Da war ich dann doch froh, dass das Spiel nicht 20 oder gar 30 Levels hat.

Auch wenn es mit Two Point Hospital seit kurzem einen offiziellen inoffiziellen 3D-Nachfolger von den Original-Designern gibt, ist das für mich kein Grund, Klassiker wie diesen aus meinem Kopf zu verdrängen, denn ich hatte an Theme Hospital in meiner Jugend eine Menge Freude, und nun habe ich dieses Kapitel für mich mit einem kleinen Sieg abgeschlossen. Außerdem gibts Theme Hospital noch gänzlich ohne Steam-Zwang, und das ist mir heutzutage sehr viel Wert.

Vor zwei Jahren erschien ein kleiner, pixeliger Stern am Indie-Spielehimmel: Stardew Valley. Ein erfrischend alternatives Spiel, das Gemütlichkeit und ein Heile-Welt-Gefühl ausstrahlt, weitestgehend gewaltfrei daherkommt (sofern man möchte), und den Spieler einerseits an die Hand nimmt, um ihm eine Rahmenhandlung zu bieten, ihm andererseits völlig freie Hand lässt, da es eigentlich ein Endlosspiel ist. Stardew Valley ist im Kern ein Bauernhof- und Dating-Simulator in 2D-Retro-Optik und basiert auf dem SNES-Spiel „Harvest Moon“ von 1996.

Meine Erinnerungen an Harvest Moon sind leider inzwischen ziemlich verblasst, aber ich weiß noch, dass ich es sehr gerne gespielt habe, wenn auch nicht besonders eifrig oder gar erfolgreich. Mein Alltag bestand darin, den eigenen Hof von Unkraut und Gestein zu befreien, ein paar Felder anzulegen, in einem kleinen Wasserloch zu fischen, und im Dorf die hübsche Kirchenmaus mit kleinen Geschenken zu beeindrucken. Letzteres hat wie erwartet nur mäßig gut funktioniert. Die Musik war eintönig und repetitiv, aber frisst sich dafür umso schneller ins Hirn. Harvest Moon sah aus wie ein zu jener Zeit typisches 2D-JRPG (mit etwas simplerer Tileset-Grafik), und spielte sich auch exakt so – mit dem Unterschied, dass man keine Burgen aufsucht, um Endgegner zu besiegen.

Stardew Valley tritt das Erbe des SNES-Klassikers an und erweitert es liebevoll um viele neue, aber passende Elemente. Der Spieler übernimmt den verwaisten Bauernhof des verstorbenen Großvaters, um der Hektik und betäubenden Einöde der Großstadt zu entkommen. Dafür müssen Steine, Gehölz und Unkraut entfernt, Bäume gefällt und kleine Beete angelegt sowie täglich gegossen werden. Man kann frei nach Belieben zum Angeln gehen, im Dorf einkaufen, Leute kennenlernen, Dorffeste besuchen, kleine Monster in der Mine jagen, im Wald Beeren sammeln, und vieles mehr. Nach kurzer Zeit kommt wahlweise ein Hund oder eine Katze als Haustier dazu. Hühnerställe, Pferdeställe, Kuhställe, eine Mühle, ein Brunnen, ein Silo, mit ausreichenden Resourcen kann der Spieler seinen Bauernhof ständig erweitern. Zentrum des Spiels ist das freundliche Dorf „Pelikan“ im Sternentautal, dessen zahlreiche Einwohner jeweils einen ganz individuellen Lebensrhythmus und Tagesablauf haben. Man kann ihnen dabei zusehen, wie sie zur Arbeit gehen, in der Kneipe abhängen, sich ein Eis kaufen, am See angeln, oder wöchentlich im Aerobic-Kurs ihre müden Knochen wieder in Schwung bringen. Es ist eine lebendige Gemeinschaft mit vielseitigen Charakteren.

Im Spiel kann man mit viel Geduld auch das Herz einer beliebigen (ledigen) Figur aus dem Dorf gewinnen und diese schließlich heiraten. Die allmählichen Fortschritte in einer aufkeimenden romantischen Beziehung honoriert das Spiel mit Cutscenes, in denen der Spieler Entscheidungen fällen muss, die den weiteren Verlauf der Romanze positiv oder negativ beeinflussen. Meine Partnerwahl fiel dabei ganz logisch auf Penny, die junge, belesene Lehrerin. Mit ihr konnte ich auf Anhieb sympathisieren. Penny schämt sich insgeheim dafür, als einzige im Dorf in einem Wohnwagen zu hausen, und das ganz dem Klischee entsprechend mit ihrer alkoholkranken Mutter. Kinder sind ihr immens wichtig, und sie ist eine ruhige Persönlichkeit, die nur davon träumt, irgendwann auf einem eigenen Hof zu leben. Ich musste dieses arme Mädel also einfach aus seinem Elend befreien. Inzwischen sind wir glücklich verheiratet, auch wenn sie mir kaum eine Hilfe ist. Sie kocht selten, obwohl sie kaum was zu tun hat, und auch um die Tiere und Pflanzen kümmert sie sich nicht. Meistens steht sie in der Gegend rum, oft liest sie, hin und wieder geht sie einkaufen. Damit kann ich umgehen.

Zum Zeitpunkt der Artikelveröffentlichung habe ich genau 94 Stunden in das Spiel investiert. Die Haupthandlung, die ich nach ungefähr 86 Stunden abgeschlossen habe, dreht sich um das verfallene Gemeindehaus von Pelikan, in dem kleine Naturgeister hausen. Der gnadenlos kapitalistische Marktleiter des Joja-Supermarktes will es aufkaufen und in eine Lagerhalle umfunktionieren. Doch der Spieler kann sich entscheiden, das alte Gemeindehaus Stück für Stück wieder herzurichten, indem er den freundlichen Geistern kleine Artefakte schenkt. Gelingt ihm das, wird er zum Held der Stadt ernannt. Aber auch abseits dieses Rahmens gibt es im Spiel sehr vieles zu entdecken und zu erledigen.

Von dem Spiel war ich lange Zeit sehr gefesselt, zumindest solange man noch ein klares Ziel vor Augen hatte. Nie wusste ich, ob ich heute vielleicht den einen Fisch angeln würde, der mir noch zur Komplettierung eines Zwischenziels fehlte. Eine Lösung habe ich bewusst nie gelesen, da das dem Spiel natürlich die Herausforderung nimmt. Einige Rätsel sind leider noch offen geblieben, andere habe ich schließlich irgendwann lösen können. Störend empfinde ich lediglich die tägliche Routine, die sich irgendwann einstellt. Das Spiel erlaubt es mir beispielsweise, das Füttern der Tiere oder das Gießen der Pflanzen zu automatisieren, nicht jedoch das morgendliche Einsammeln der Eier, das Melken der Kühe, oder das Scheren der Schafe. Rechnet man alle unvermeidbaren täglichen Pflichten zusammen, fehlen einem meist bereits die ersten 6 Stunden jedes ohnehin recht kurzen Spieltages, ehe man zum Einkaufen, Steineklopfen, Angeln etc. kommt. Gerade am Anfang weiß man die seltenen Regentage wirklich zu schätzen, denn dann braucht man sich zumindest nicht um die Pflanzen zu kümmern.

Von der Retrografik bin ich sehr angetan. Es sieht zwar leider nicht alles wie aus einem Guss aus (pixelige 2D-Sprites, aber dann eine hochauflösende Angelschnur, schiefe Pixel bei der Uhr, unterschiedlich große Pixel bei Animationen…), aber der Stil bleibt zumindest für die alten Hasen unter den RPG-Fans weiterhin reizvoll. Stardew Valley triggert bewusst den Sammeltrieb bei den Spielern, indem es Buch über alle Fortschritte und gefundene Artefakte führt, und man regelmäßig neue Lokationen freischalten kann. Blöd ist es, wenn man bestimmte Dinge beispielsweise nur im Herbst bekommen kann, und man dann ein weiteres Jahr warten muss, weil man den Zeitpunkt gerade verpasst hat. Aber Stardew Valley ist wie gesagt eine angenehme Möglichkeit, dem tristen Alltag zu entkommen, um einen anderen Alltag auf dem Bauernhof zu erleben. Wer sich einen solchen Zeitfresser erlauben kann, sollte dem Spiel eine reelle Chance geben.

Stardew Valley ist bei GOG DRM-frei regulär für 13,99 EUR zu haben, findet sich aber regelmäßig deutlich vergünstigt im Sale wieder. Aktuell befindet sich ein Mehrspieler-Coop-Modus in der Betaphase, der wohl in einigen Wochen auch final im Spiel verfügbar sein sollte. Mit Hilfe neuer Fan-Modifikationen lässt sich sogar die Vier-Spieler-Limitierung des Mehrspielermodus aushebeln, so dass beliebig viele Farmer gemeinsam über den Bildschirm wuseln können.