Lunar Lander (1969–1979): Vom PDP-8 zur Atari-Arcade

Name: Spy Hunter (1983) – Straßenkrieg, Agentenfantasie und Arcade-Tempo
Item: Spy Hunter
Author: MansionManiax

Es war eine Zeit, in der der Blick zum Mond nicht nur von Fernsehkameras geprägt war, sondern von Rechenzentren, Terminals und der stillen Faszination für Zahlen. Als die Apollo-Missionen Ende der 1960er Jahre ihren Höhepunkt erreichten, begann sich parallel ein Gedanke in Universitäten und Forschungseinrichtungen zu verfestigen: Wenn sich eine Mondlandung berechnen lässt, lässt sie sich auch simulieren. Aus dieser Überlegung entstand eines der frühesten Beispiele interaktiver Software, das später unter dem Namen „Lunar Lander“ bekannt wurde – weniger als einzelnes Spiel, sondern als eine fortlaufende Reihe von Programmen, die sich über ein Jahrzehnt hinweg entwickelten.

Den Ausgangspunkt bildet eine Fassung aus dem Jahr 1969, geschrieben von Jim Storer auf einem PDP-8. Das Programm entstand in der Sprache FOCAL, die für mathematische Berechnungen konzipiert war. Von Unterhaltung im heutigen Sinne kann hier kaum die Rede sein. Der Benutzer gab in regelmäßigen Abständen Schubwerte ein, woraufhin der Rechner Höhe, Geschwindigkeit und verbleibenden Treibstoff ausgab. Die Simulation lief rundenbasiert, und jede Eingabe stellte eine Entscheidung dar, deren Konsequenzen erst im nächsten Schritt sichtbar wurden. Es war ein Dialog zwischen Mensch und Maschine, geprägt von Zahlen, nicht von Bildern.

Eine zentrale Rolle bei der Verbreitung spielte später David H. Ahl, der das Programm in BASIC überführte und in seinem 1973 erschienenen Buch „101 BASIC Computer Games“ veröffentlichte. In Varianten wie ROCKET, ROCKT1 oder ROCKT2 wurde das Spiel zu einem festen Bestandteil der frühen Heimcomputerkultur. Listings wie das vorliegende zeigen, wie direkt die Verbindung zwischen Raumfahrt und Programmcode war. Variablen wie Höhe, Geschwindigkeit oder Masse wurden nicht abstrahiert, sondern nahezu unverändert aus der physikalischen Beschreibung übernommen. Selbst die Gravitation erscheint als konstante Größe im Code – reduziert, aber erkennbar.

Ein Blick in den ursprünglichen FOCAL-Code verdeutlicht diese Nähe zur Technik besonders eindrucksvoll. Die Ausgabe beginnt wie ein Funkdialog: „CONTROL CALLING LUNAR MODULE. MANUAL CONTROL IS NECESSARY“. Darauf folgen Parameter wie Treibstoffmenge, geschätzte Fallzeit und Kapselgewicht. Die Berechnungen selbst basieren auf vereinfachten Bewegungsgleichungen, die in diskreten Zeitschritten ausgewertet werden. Geschwindigkeit und Höhe werden fortlaufend aktualisiert, wobei der Schub als Gegenkraft zur Mondgravitation wirkt. Diese Form der numerischen Integration war typisch für die damalige Zeit, in der Rechenleistung begrenzt war und komplexe Gleichungen auf einfache Iterationen reduziert werden mussten.

Dabei zeigt sich auch ein Detail, das erst Jahrzehnte später wieder größere Aufmerksamkeit erhielt: In frühen Versionen fehlt ein Faktor in der Positionsberechnung, was zu leichten Abweichungen führt. Solche Ungenauigkeiten waren kein Ausnahmefall, sondern Teil einer Programmierpraxis, die stark vom Experiment geprägt war. Dass sich diese Eigenheiten durch verschiedene Versionen zogen, unterstreicht die Idee einer fortlaufenden Entwicklung, bei der Programme weniger abgeschlossen als vielmehr weitergegeben und verändert wurden.

Der nächste bedeutende Schritt erfolgte 1973 mit einer grafischen Umsetzung durch Jack Burness auf einem DEC-GT40-Terminal. Hier wurde aus der reinen Textsimulation erstmals eine visuelle Erfahrung. Die Darstellung erfolgte in Vektorgrafik, gesteuert über einen Lichtgriffel. Damit rückte das Geschehen näher an das heran, was später als Videospiel wahrgenommen wurde, ohne die mathematische Grundlage zu verlieren. Die Simulation lief nun in Echtzeit, und die Kontrolle über das Landemodul erhielt eine unmittelbare, physische Komponente.

Als Atari 1979 eine Arcade-Version veröffentlichte, war das Konzept bereits etabliert. Mit Lunar Lander wurde die Simulation in ein Münzspiel überführt, ohne ihren Kern vollständig aufzugeben. Die Darstellung blieb vektorbasiert, die Steuerung erfolgte über einen analogen Schubhebel, der dem Spieler eine fein abgestufte Kontrolle ermöglichte. Im Unterschied zu den früheren Versionen trat nun ein wirtschaftlicher Aspekt hinzu: Treibstoff entsprach Spielzeit, und zusätzliche Münzen konnten genutzt werden, um eine drohende Bruchlandung abzuwenden. Damit verband sich die nüchterne Logik der Simulation mit den Anforderungen der Spielhalle.

Im direkten Vergleich zu zeitgleichen Titeln wie Asteroids fällt auf, wie unterschiedlich die Ansätze waren. Während Asteroids auf Reaktion und Tempo setzte, verlangte Lunar Lander Präzision und Planung. Diese Unterschiede spiegelten sich auch im kommerziellen Erfolg wider. Schnellere, unmittelbare Spiele erreichten ein breiteres Publikum, während simulationsnahe Konzepte eher eine kleinere, spezialisierte Spielerschaft ansprachen. Automatenbetreiber mussten abwägen, welche Geräte sich wirtschaftlich lohnten, und entschieden sich häufig für Titel mit höherer Umschlagrate.

Trotz dieser Unterschiede blieb der Einfluss von Lunar Lander erhalten. Das Prinzip, physikalische Systeme interaktiv erfahrbar zu machen, findet sich in späteren Simulationen ebenso wie in modernen Spielen, die mit realistischen Bewegungsmodellen arbeiten. In der Forschung wird Lunar Lander daher gelegentlich als frühes Beispiel einer Adaptionsgeschichte beschrieben, in der sich ein Konzept über verschiedene Plattformen, Sprachen und Nutzungskontexte hinweg verändert, ohne seinen Kern zu verlieren.

Ein Arcade-Automat kostete Ende der 1970er Jahre mehrere tausend US-Dollar, was inflationsbereinigt einem heutigen Betrag im Bereich von etwa 9.000 bis 14.000 Euro entspricht. Diese Investition machte deutlich, dass jedes Spiel nicht nur technisch, sondern auch wirtschaftlich bestehen musste. Lunar Lander zeigt exemplarisch, wie eng Technik, Wissenschaft und Markt in dieser frühen Phase miteinander verbunden waren.

Am Ende steht kein einzelnes Spiel, sondern eine Entwicklungslinie: von einer mathematischen Simulation auf einem Minicomputer über grafische Experimente bis hin zur kommerziellen Arcade-Version. Lunar Lander steht damit weniger für einen Moment als für einen Prozess – einen, in dem sich aus Berechnungen langsam ein Spiel formte.

Adventureland (1978) – Der Moment, in dem Abenteuer nach Hause kamen

Es war eine Zeit, in der Computer noch keine Selbstverständlichkeit waren, sondern Versprechen. Während sich Großrechner in Universitäten und Forschungseinrichtungen bereits als Werkzeuge etabliert hatten, begann sich im Jahr 1978 langsam ein neuer Gedanke durchzusetzen: dass diese Maschinen auch in den eigenen vier Wänden stehen könnten. In genau diesem Moment erschien ein Spiel, das auf den ersten Blick unscheinbar wirkte, sich rückblickend jedoch als einer der entscheidenden Übergangspunkte herausstellen sollte – Adventureland.

Hinter diesem Titel stand Scott Adams, ein Programmierer, der von einem der frühesten Computerabenteuer überhaupt fasziniert war: Colossal Cave Adventure. Doch während dieses noch auf Großrechnern lief und damit nur einem kleinen Kreis zugänglich war, verfolgte Adams ein anderes Ziel. Er wollte ein vergleichbares Erlebnis auf einem Heimcomputer ermöglichen – konkret auf dem TRS-80 Model I, einer Maschine, die in ihrer Grundausstattung mit gerade einmal 16 Kilobyte Arbeitsspeicher auskommen musste. Was zunächst wie ein unüberwindbares Hindernis klingt, wurde letztlich zum Ausgangspunkt einer der ersten echten Designentscheidungen der Spielegeschichte.

Anstatt ein Spiel im klassischen Sinne zu programmieren, entwickelte Adams ein System. Adventureland besteht nicht aus fest codierten Abläufen, sondern aus einer strukturierten Sammlung von Daten, die von einem Interpreter verarbeitet werden. Räume, Gegenstände und Zustände sind keine fest verdrahteten Elemente, sondern Einträge in einer Tabelle, die vom Programm gelesen werden. Damit entstand – wenn auch unter anderen Vorzeichen – eine der frühesten Formen dessen, was man heute als Game Engine bezeichnen würde. Der eigentliche Vorteil dieses Ansatzes zeigte sich unmittelbar: Neue Spiele konnten entstehen, ohne die technische Grundlage neu entwickeln zu müssen. Tatsächlich folgten innerhalb kurzer Zeit weitere Titel wie Pirate Adventure oder Voodoo Castle, die auf genau diesem Fundament aufbauten und über Adams’ Firma Adventure International vertrieben wurden.

Inhaltlich präsentiert sich Adventureland hingegen bemerkenswert nüchtern. Eine ausgearbeitete Geschichte existiert praktisch nicht. Stattdessen besteht das Ziel darin, dreizehn verstreute Schätze zu finden und an einem bestimmten Ort abzulegen. Wälder, Höhlen und vereinzelte fantastische Elemente bilden den Rahmen, doch sie dienen weniger der Atmosphäre als der Funktion. Aus heutiger Sicht mag das beinahe enttäuschend wirken, doch diese Reduktion war kein Mangel, sondern eine Konsequenz der technischen Rahmenbedingungen. Jeder zusätzliche Satz, jede komplexere Beschreibung hätte wertvollen Speicher verbraucht. Die Entscheidung für Kürze war also keine stilistische, sondern eine zwingende.

Diese Beschränkung zeigt sich besonders deutlich im Eingabesystem. Der Parser von Adventureland arbeitet mit einem Zwei-Wort-Schema, bestehend aus Verb und Objekt. Befehle wie „GET LAMP“ oder „GO NORTH“ bilden das Fundament der Interaktion. Dabei reicht es sogar aus, die ersten drei Buchstaben eines Wortes einzugeben – ein weiterer Hinweis darauf, wie konsequent Adams auf Effizienz bedacht war. Im Vergleich zu späteren Adventures, die vollständige Sätze verstehen konnten, wirkt dieses System stark reduziert, doch es erfüllte seinen Zweck: Es machte das Spiel auf einem Heimcomputer überhaupt erst möglich.

Was Adventureland dabei besonders deutlich zeigt, ist die Denkweise seiner Zeit – und die offenbart sich vor allem in den Momenten, in denen das Spiel scheinbar „unfair“ wirkt. Wer die Höhle ohne Licht betritt, wird ohne Vorwarnung bestraft. Wer einen wichtigen Gegenstand zurücklässt oder an der falschen Stelle einsetzt, kann sich unbemerkt in eine Situation manövrieren, aus der es kein Zurück mehr gibt. Das Spiel erklärt nichts, es kommentiert nichts – es registriert lediglich. Diese Konsequenz ist kein Versehen, sondern Teil des Systems.

Gerade darin liegt ein wesentlicher Unterschied zu späteren Adventures. Während Titel wie Zork begannen, ihre Welten logisch aufzubauen und den Spieler subtil zu führen, bleibt Adventureland kompromisslos funktional. Räume existieren nicht, weil sie eine glaubwürdige Umgebung formen, sondern weil sie eine Aufgabe erfüllen. Gegenstände sind keine Requisiten einer Geschichte, sondern Schlüssel in einem System aus Bedingungen und Zuständen.

Das wird besonders im Umgang mit dem Inventar deutlich. Die begrenzte Tragfähigkeit zwingt den Spieler dazu, früh eine Art „Basislager“ zu etablieren, an dem gefundene Schätze gesammelt werden. Wer diesen Zusammenhang nicht erkennt, läuft Gefahr, sich selbst den Fortschritt zu blockieren. Ebenso typisch ist die Notwendigkeit, scheinbar bedeutungslose Orte mehrfach zu besuchen – nicht, weil sich die Welt verändert hätte, sondern weil der Spieler es inzwischen getan hat.

Aus heutiger Sicht wirken viele dieser Situationen spröde oder gar ungerecht. Doch sie spiegeln eine Zeit wider, in der Spiele weniger als geführte Erfahrung verstanden wurden, sondern als Herausforderung, die es zu entschlüsseln galt. Adventureland verlangt kein Reaktionsvermögen und keine Geschicklichkeit – es verlangt Aufmerksamkeit, Geduld und die Bereitschaft, aus Fehlern zu lernen.

Der zeitgenössische Blick fiel entsprechend aus. In People’s Computers / Recreational Computing wurde das Spiel als „a true tour-de-force … on only a 16k TRS-80“ bezeichnet – eine Einschätzung, die weniger das eigentliche Spiel als vielmehr die technische Leistung würdigte. Auch 80-U.S. / Basic Computing empfahl den Titel ausdrücklich jenen Spielern, die bereit waren, sich auf eine Herausforderung einzulassen, und betonte gleichzeitig die ungewöhnlichen und teils humorvollen Situationen, die sich daraus ergaben. Diese Stimmen machen deutlich, dass Adventureland bereits damals nicht als perfektes Spiel verstanden wurde, sondern als bemerkenswerter Schritt.

Im direkten Vergleich mit Zork, das ursprünglich auf Großrechnern am MIT entwickelt wurde, treten die Unterschiede klar zutage. Während Zork mit komplexeren Sprachstrukturen, einer zusammenhängenden Welt und einem deutlich stärkeren Fokus auf Atmosphäre arbeitet, bleibt Adventureland bei seiner reduzierten, systematischen Herangehensweise. Doch dieser Vergleich greift nur bedingt, denn beide Spiele entstammen unterschiedlichen Voraussetzungen. Zork konnte auf deutlich leistungsfähigere Hardware zurückgreifen und profitierte von einem größeren Entwicklungsteam, während Adventureland aus der Notwendigkeit heraus entstand, mit minimalen Ressourcen auszukommen. Entscheidend ist daher weniger, welches Spiel „besser“ ist, sondern welches den entscheidenden Schritt gemacht hat.

Und dieser Schritt liegt eindeutig bei Adventureland. Es brachte das Konzept des interaktiven Abenteuers aus den Universitäten in die Wohnzimmer. Es zeigte, dass Spiele nicht nur möglich, sondern auch vermarktbar waren. Der ursprüngliche Verkaufspreis von rund 24,95 US-Dollar – inflationsbereinigt heute etwa 90 bis 100 Euro – unterstreicht dabei, dass es sich nicht um ein beiläufiges Experiment handelte, sondern um ein ernstzunehmendes Produkt.

Auffällig ist dabei, wie schnell sich Adventureland über seine Ursprungsplattform hinaus verbreitete. Innerhalb weniger Jahre erschien das Spiel auf einer Vielzahl von Systemen – vom Apple II über den Commodore 64 und den ZX Spectrum bis hin zu eher spezialisierten Geräten wie dem TI-99/4A oder dem Exidy Sorcerer. Auch Systeme wie der Commodore PET 2001, der Commodore VIC-20, die britischen Mikrocomputer BBC Micro und Acorn Electron sowie der Dragon 32/64 und frühe IBM-kompatible PCs gehörten zu den Plattformen, auf denen Adams’ Adventure-Interpreter zum Einsatz kam. Diese breite Streuung war kein Zufall, sondern direkte Folge des zugrunde liegenden Systems: Da die Spielwelt als Daten organisiert war, musste im Grunde nur der Interpreter an die jeweilige Hardware angepasst werden.

Gerade diese Portierungen zeigen jedoch, wie unterschiedlich sich ein scheinbar identisches Spiel anfühlen konnte. Die ursprüngliche TRS-80-Version blieb die technisch roheste Form. Ihre Texte sind knapp, die Reaktionszeiten durch die Kassettenspeicherung spürbar, und der Parser reagiert strikt auf die bekannten Zwei-Wort-Befehle. Hier zeigt sich das Spiel am unmittelbarsten als Produkt seiner Entstehungsbedingungen – reduziert, funktional, kompromisslos.

Auf Systemen wie dem Apple II oder dem Commodore PET änderte sich zunächst weniger am Inhalt als an der Geschwindigkeit und Stabilität. Diskettenlaufwerke verkürzten Ladezeiten erheblich, und die Darstellung wirkte durch klarere Monitorausgaben oft angenehmer lesbar. Der Kern blieb jedoch unverändert, was diese Versionen zu den „authentischsten“ Alternativen zur TRS-80-Fassung macht.

Mit dem Aufkommen farbfähiger Heimcomputer verschob sich der Schwerpunkt leicht. Versionen für den Commodore 64, den Atari 8-bit oder den ZX Spectrum erhielten teilweise grafische Ergänzungen – einfache Illustrationen, die einzelne Szenen begleiteten. Diese Bilder waren kein integraler Bestandteil des Spiels, sondern eher eine visuelle Rahmung, die dem Titel eine modernere Anmutung verlieh. Gleichzeitig blieb die eigentliche Interaktion strikt textbasiert. Interessanterweise veränderte diese Ergänzung die Wahrnehmung stärker als das Spiel selbst: Während die ursprüngliche Version die Fantasie vollständig dem Spieler überließ, boten die Grafikversionen erste visuelle Interpretationen der Spielwelt.

Auf kleineren Systemen wie dem Commodore VC-20 oder dem Acorn Electron zeigten sich dagegen erneut die Grenzen der Hardware. Hier mussten Texte teilweise weiter gekürzt oder Speicher effizienter genutzt werden, was den ohnehin minimalistischen Stil noch stärker verdichtete. Diese Fassungen wirken bisweilen fast wie Essenzen des Originals – noch direkter, noch reduzierter.

Die IBM-PC-Versionen schließlich markieren bereits den Übergang in eine neue Ära. Mit mehr Speicher und verbesserten Ein- und Ausgabemöglichkeiten ließen sich komfortablere Varianten umsetzen, ohne jedoch die grundlegende Struktur zu verändern. Gerade hier wird deutlich, wie langlebig das ursprüngliche Konzept war: Selbst auf deutlich leistungsfähigeren Systemen blieb das Spiel im Kern identisch.

Bemerkenswert ist dabei, dass keine dieser Versionen das ursprüngliche Design grundlegend verändert. Es gibt keine erweiterten Handlungsstränge, keine neuen Mechaniken, keine „verbesserten“ Rätsel im modernen Sinne. Stattdessen zeigt jede Portierung vor allem eines: die Anpassungsfähigkeit eines Konzepts, das von Anfang an nicht an eine bestimmte Maschine gebunden war. Während viele andere frühe Spiele eng mit ihrer Hardware verwoben blieben, ließ sich Adventureland nahezu unverändert übertragen – ein Umstand, der seine Rolle als eines der ersten wirklich plattformübergreifenden Spiele unterstreicht.

Gerade im direkten Vergleich dieser Versionen wird deutlich, dass sich nicht nur die Technik entwickelte, sondern auch die Erwartungshaltung der Spieler. Was auf dem TRS-80 noch als bemerkenswerte Leistung galt, wirkte wenige Jahre später bereits schlicht. Doch anstatt zu verschwinden, passte sich Adventureland an – leise, unspektakulär und gerade deshalb bemerkenswert konsequent.

Rückblickend betrachtet wirkt vieles an Adventureland roh, reduziert und bisweilen widerspenstig. Doch genau darin liegt seine Bedeutung. Es ist kein Spiel, das den Spieler an die Hand nimmt, sondern eines, das ihn zwingt, selbst zu verstehen, wie es funktioniert. Und vielleicht ist das der entscheidende Punkt: Die eigentliche Aufgabe besteht nicht darin, die Schätze zu finden – sondern die Logik hinter dem Spiel zu begreifen.

Vom QDOS zu MS-DOS: Wie ein improvisiertes Betriebssystem zur Grundlage der PC-Ära wurde

Seattle, Frühjahr 1980. In den Büroräumen von Seattle Computer Products sitzt ein junger Entwickler über einem neuen Projekt. Die Firma hat gerade eine Prozessorplatine für den Intel 8086 entwickelt – eine leistungsfähige 16-Bit-CPU, die auf dem damals verbreiteten S-100-Bus eingesetzt werden soll. Doch ohne ein Betriebssystem bleibt die Hardware kaum nutzbar. Also beginnt der Ingenieur Tim Paterson, ein eigenes System zu schreiben. In wenigen Wochen entsteht ein funktionierendes System, das intern den pragmatischen Namen „Quick and Dirty Operating System“ erhält. Jahrzehnte später erinnerte sich Paterson nüchtern an diese Situation: Er habe das System schlicht geschrieben, „weil wir ein Betriebssystem für die 8086-Karte brauchten“, und damals nicht gedacht, dass daraus einmal etwas Bedeutendes entstehen würde.

Als im August 1981 der IBM PC vorgestellt wurde, lief bereits eine weiterentwickelte Version dieses Systems auf der neuen Maschine. In den folgenden Jahren verbreiteten sich Varianten dieses Systems auf hunderten Millionen Personal Computern weltweit. Bis Anfang der 1990er-Jahre hatte Microsoft bereits rund 100 Millionen Lizenzen von MS-DOS verkauft. Hinzu kamen kompatible Varianten wie IBM PC-DOS oder DR-DOS sowie die später auf DOS aufbauenden Systeme Windows 95, Windows 98 und Windows Me, deren installierte Basis die tatsächliche Verbreitung noch erheblich vergrößerte. In vielen Regionen kamen zudem große Mengen nicht lizenzierter Kopien hinzu. Der Ursprung dieser Entwicklung lag jedoch nicht bei IBM und auch nicht bei Microsoft, sondern bei einem kleinen Hardwareunternehmen im Bundesstaat Washington. Dort entstand 1980 ein Betriebssystem namens 86-DOS, das ursprünglich nur dazu gedacht war, eine neue Prozessorplattform überhaupt nutzbar zu machen.

Seattle Computer Products war zu dieser Zeit ein vergleichsweise kleines Unternehmen aus der Region Seattle, das vor allem Erweiterungskarten und Prozessorboards für den S-100-Bus herstellte. Gegründet wurde die Firma 1978 von Rod Brock. Der Markt für Mikrocomputer befand sich damals in einer Phase rasanten Wachstums, doch die Softwarelandschaft war stark fragmentiert. Der De-facto-Standard war CP/M von Digital Research, ein Betriebssystem für 8-Bit-Prozessoren wie den Intel 8080 oder Zilog Z80. Viele Hersteller warteten auf eine angekündigte 16-Bit-Variante namens CP/M-86, doch deren Entwicklung verzögerte sich.

Für Unternehmen wie Seattle Computer Products stellte das ein praktisches Problem dar. Die neue 8086-Hardware konnte zwar technisch überzeugen, doch ohne ein Betriebssystem war sie für Entwickler und Anwender kaum attraktiv. In dieser Situation begann Tim Paterson im Frühjahr 1980 mit der Entwicklung eines eigenen Systems.

Das Projekt erhielt intern zunächst den Namen QDOS, eine Abkürzung für „Quick and Dirty Operating System“. In frühen Anzeigen und Produktinformationen von Seattle Computer Products wurde diese Bezeichnung zeitweise auch öffentlich verwendet. Schon bald entschied sich das Unternehmen jedoch für den Namen 86-DOS, der sich direkt auf den verwendeten Intel-Prozessor bezog und professioneller wirkte.

Technisch war das System bemerkenswert kompakt. Der ursprüngliche Kernel bestand aus nur etwa sechs Kilobyte Assemblercode, eine Größe, die selbst für damalige Verhältnisse ungewöhnlich klein war. Dennoch enthielt das System bereits die grundlegenden Funktionen eines Diskettenbetriebssystems: einen Kommandointerpreter, Dateiverwaltung sowie eine Programmierschnittstelle, über die Anwendungen mit dem Betriebssystem kommunizieren konnten.

Bei der Gestaltung orientierte sich Paterson teilweise an CP/M, das damals praktisch der Industriestandard für Mikrocomputer darstellte. Viele Befehle und Strukturen wurden bewusst ähnlich gehalten, um Entwicklern den Übergang zu erleichtern und die Portierung bestehender Programme zu vereinfachen. Gleichzeitig versuchte er jedoch, einige Schwächen des Vorbilds zu vermeiden. Besonders kritisch sah er die Art und Weise, wie CP/M Diskettenzugriffe organisierte. Das System benötigte oft mehrere Umdrehungen der Diskette, um alle benötigten Daten eines Tracks einzulesen, was den Zugriff vergleichsweise langsam machte. Paterson versuchte deshalb, die Diskettenorganisation effizienter zu gestalten und unnötige Rotationen zu vermeiden.

Eine wichtige technische Entscheidung war die Nutzung einer File Allocation Table (FAT) zur Verwaltung von Dateien. Diese Struktur hatte Paterson zuvor aus Microsofts Disk-BASIC kennengelernt und adaptierte sie für sein Betriebssystem. Das FAT-Dateisystem erlaubte eine flexiblere Organisation von Dateien und wurde später zu einem der langlebigsten technischen Elemente der gesamten DOS-Familie.

Die ersten Versionen von 86-DOS waren bewusst minimalistisch gehalten. Das System bot nur eine begrenzte Zahl grundlegender Befehle – etwa zwanzig interne und externe Kommandos –, mit denen Dateien verwaltet und Programme gestartet werden konnten. Für Entwickler reichte diese Umgebung jedoch aus, um erste Anwendungen für den neuen 16-Bit-Prozessor zu schreiben.

Seattle Computer Products begann 1980 damit, seine 8086-Hardware zusammen mit 86-DOS anzubieten. Anzeigen aus dieser Zeit zeigen Komplettpakete aus CPU-Karte, Support-Board und Betriebssystem für Entwickler und Systembauer. Für das Unternehmen selbst war die Software jedoch vor allem ein praktisches Werkzeug, um die eigene Hardware überhaupt nutzbar zu machen.

Während diese Entwicklung im Nordwesten der USA stattfand, arbeitete IBM an einem Projekt, das später als IBM PC bekannt werden sollte. Um die Entwicklung zu beschleunigen, entschied sich das Unternehmen bewusst gegen eine vollständig proprietäre Architektur. Stattdessen sollten möglichst viele Komponenten aus bereits verfügbaren Standardbausteinen bestehen. Für den Prozessor fiel die Wahl auf den Intel 8088, eine Variante des 8086 mit 8-Bit-Datenbus.

Auch beim Betriebssystem wollte IBM auf vorhandene Lösungen zurückgreifen. Der naheliegendste Kandidat war Digital Research, dessen CP/M damals den Markt für Mikrocomputer dominierte. Im Sommer 1980 nahmen IBM-Vertreter daher Kontakt mit dem Unternehmen auf, um über eine Version namens CP/M-86 für den neuen Rechner zu sprechen.

Die Gespräche verliefen jedoch nicht wie geplant. Verschiedene Berichte schildern unterschiedliche Details, doch fest steht, dass keine Einigung zustande kam. Eine häufig erzählte Version besagt, dass Gary Kildall, der Gründer von Digital Research, an diesem Tag nicht persönlich an den Verhandlungen teilnahm und die Gespräche zunächst von seiner Frau Dorothy McEwen geführt wurden. Sie weigerte sich, eine von IBM verlangte Geheimhaltungsvereinbarung zu unterschreiben, ohne sie vorher juristisch prüfen zu lassen. Als Kildall später zurückkehrte, war die Situation bereits festgefahren. Ob es danach noch weitere Gespräche gab, ist unter Historikern umstritten. Am Ende kam jedoch kein Vertrag zustande.

IBM suchte daher nach einer Alternative und wandte sich an ein kleines Unternehmen aus Seattle, das bereits Software für verschiedene Mikrocomputer geliefert hatte: Microsoft.

Microsoft war zu diesem Zeitpunkt vor allem als Hersteller von Programmiersprachen bekannt. Besonders Microsoft BASIC war auf zahlreichen Mikrocomputern der späten 1970er-Jahre im Einsatz. IBM beauftragte das Unternehmen daher zunächst damit, eine BASIC-Version für den neuen Personal Computer bereitzustellen. Erst im Verlauf dieser Zusammenarbeit entstand auch die Frage nach einem geeigneten Betriebssystem.

Microsoft selbst besaß jedoch noch keines. Hier kam eine Erinnerung von Paul Allen, dem Mitgründer des Unternehmens, ins Spiel. Allen wusste von dem Betriebssystem, das bei Seattle Computer Products für den 8086 entwickelt worden war. Für Microsoft bot sich damit eine Möglichkeit, schnell eine Grundlage für ein neues PC-Betriebssystem zu erhalten.

Ende 1980 erwarb Microsoft zunächst eine Lizenz für 86-DOS von Seattle Computer Products. Kurz darauf entschied sich das Unternehmen jedoch, sämtliche Rechte an der Software vollständig zu übernehmen. Durch diesen Schritt erhielt Microsoft die Kontrolle über die Weiterentwicklung des Systems und konnte es auch unabhängig an andere Hersteller lizenzieren.

Um das System rasch an die Anforderungen des IBM-PC-Projekts anzupassen, holte Microsoft schließlich auch Tim Paterson selbst ins Unternehmen. Der Entwickler wechselte 1981 von Seattle Computer Products nach Redmond und arbeitete dort an der Anpassung seines Systems für den Intel 8088 des neuen Personal Computers.

Erst im Laufe dieser Arbeit wurde ihm klar, für welchen Kunden das Projekt tatsächlich bestimmt war. In späteren Interviews erinnerte sich Paterson, dass Microsoft intern zunächst lediglich von einem neuen Computer eines großen Herstellers gesprochen habe. Erst nach und nach wurde deutlich, dass es sich um den geplanten Personal Computer von IBM handelte. Für Paterson, der wenige Monate zuvor noch ein Betriebssystem für eine S-100-Prozessorplatine geschrieben hatte, bedeutete diese Erkenntnis eine unerwartete Wendung: Aus einem improvisierten Werkzeug für eine einzelne Hardwareplattform wurde plötzlich das Betriebssystem eines Rechners, der kurz darauf zu einer neuen Standardplattform der Personal-Computer-Industrie werden sollte.

Als der IBM PC im August 1981 schließlich vorgestellt wurde, erschien das Betriebssystem unter dem Namen PC-DOS. Parallel dazu behielt Microsoft jedoch das Recht, das System auch unabhängig von IBM zu lizenzieren und unter eigener Bezeichnung zu vertreiben.

Diese Vertragsstruktur erwies sich im Rückblick als entscheidend. Während IBM seine eigene Variante des Systems verwendete, konnte Microsoft das Betriebssystem an die wachsende Zahl von IBM-PC-kompatiblen Computern lizenzieren. Als in den folgenden Jahren immer mehr Hersteller sogenannte PC-Klone auf den Markt brachten, wurde MS-DOS zum gemeinsamen Softwarefundament dieser neuen Computerplattform.

Aus dem kleinen Projekt, das Tim Paterson ursprünglich als pragmatische Lösung für eine einzelne Prozessorplatine geschrieben hatte, entstand so die Grundlage für MS-DOS. In den folgenden Jahren wurde dieses System zum dominierenden Betriebssystem der PC-Welt und prägte eine ganze Generation von Personal Computern.

Die Geschichte von 86-DOS zeigt damit eine typische Konstellation der frühen PC-Industrie: Ein kleines Hardwareunternehmen löst ein unmittelbares technisches Problem, ein Softwareanbieter erkennt das größere Marktpotenzial – und aus einer pragmatischen Zwischenlösung entsteht schließlich eine der prägendsten Plattformen der Computergeschichte.

688 Attack Sub (1989): U-Boot-Simulation im Kalten Krieg

Als Ende der 1980er-Jahre mehrere militärische Simulationen auf Heimcomputern erschienen, war das Interesse an moderner U-Boot-Technik plötzlich ungewöhnlich groß. Einen wichtigen Anteil daran hatte der internationale Erfolg von Tom Clancys Roman The Hunt for Red October aus dem Jahr 1984, der erstmals einem breiten Publikum erklärte, wie Sonar, Jagd-U-Boote und taktische Manöver unter Wasser funktionieren. Gleichzeitig wurden Heimcomputer wie IBM-PC, Amiga und Atari ST leistungsfähig genug, um Instrumente, Karten und taktische Anzeigen gleichzeitig darzustellen. In dieses Umfeld hinein veröffentlichte Electronic Arts im Jahr 1989 die U-Boot-Simulation 688 Attack Sub, die den Spieler in die Rolle eines Kommandanten eines modernen nuklearen Jagd-U-Bootes versetzte.

Der Titel verweist direkt auf die Los-Angeles-Klasse (SSN-688) der US-Navy, eines der wichtigsten Jagd-U-Boote der späten Phase des Kalten Krieges. Alternativ kann der Spieler ein sowjetisches Boot der Alfa-Klasse steuern. Diese Wahl spiegelt die militärische Konfrontation der damaligen Zeit wider und erzeugt zugleich unterschiedliche Spielstile. Während das amerikanische Boot über fortschrittlichere Sensorik und mehr elektronische Unterstützung verfügt, erreicht das sowjetische Modell höhere Geschwindigkeiten, besitzt jedoch weniger technische Hilfsmittel. Selbst optisch unterscheiden sich beide Varianten: In der sowjetischen Version erscheinen einige Anzeigen mit kyrillischen Schriftzeichen, obwohl die Spieltexte weiterhin englisch bleiben.

Statt spektakulärer Außenansichten konzentriert sich 688 Attack Sub ganz auf die Instrumente im Inneren eines Jagd-U-Bootes. Der Spieler bewegt sich zwischen verschiedenen Stationen der Kommandozentrale – etwa Sonarraum, Navigationskonsole, Waffensteuerung und Periskop – und bedient dort die Systeme des Bootes.

Die Jagd beginnt meist unspektakulär: Auf dem Sonar taucht zunächst nur eine unklare Geräuschsignatur auf. Ist es ein Handelsschiff, ein Zerstörer oder ein feindliches U-Boot? Erst durch längere Beobachtung oder aktives Sonar lässt sich der Kontakt identifizieren. Gleichzeitig muss der Spieler darauf achten, selbst möglichst unentdeckt zu bleiben.

Geschwindigkeit, Kurs und Tiefe beeinflussen, wie leicht das eigene Boot geortet werden kann. Fährt man zu schnell, entsteht Kavitation – Luftblasen an den Propellern erzeugen Geräusche, die gegnerisches Sonar leicht aufspüren kann. Auch Thermoklinen, Temperaturschichten im Wasser, können die Ausbreitung von Schall verändern. Ein zusätzliches Schleppsonar, das sogenannte Towed Array, verbessert zwar die Hörfähigkeit, reduziert aber die Geschwindigkeit des Bootes.

Erst wenn Position und Ziel eindeutig sind, beginnt der Angriff. Torpedos müssen geladen, ausgerichtet und im richtigen Moment abgefeuert werden. Danach verfolgt der Spieler auf der taktischen Karte, ob der Angriff erfolgreich ist – während gegnerische Schiffe versuchen, mit Täuschkörpern oder eigenen Torpedos zu reagieren. Viele Missionen bestehen deshalb weniger aus schnellen Gefechten als aus nervenaufreibender Geduld unter Wasser.

Die ursprüngliche Version des Spiels wurde für MS-DOS entwickelt und setzte stark auf Mausbedienung. Instrumente und Anzeigen konnten direkt angeklickt werden, was eine präzise Steuerung der verschiedenen Systeme ermöglichte. Auch die Versionen für Amiga und Atari ST übernahmen dieses Konzept weitgehend, da diese Systeme ebenfalls standardmäßig mit einer Maus betrieben wurden. Bei der späteren Mega-Drive-Fassung musste die Benutzeroberfläche hingegen an die Steuerung eines Gamepads angepasst werden. Statt direkter Mausinteraktion bewegt der Spieler dort einen Cursor mit dem Steuerkreuz zwischen den einzelnen Stationen des U-Boots und aktiviert sie per Tastendruck. Dadurch blieb die Struktur der Simulation erhalten, obwohl die Bedienung vereinfacht werden musste.

Zeitgenössische Magazine reagierten überwiegend positiv auf die Simulation. Die französische Zeitschrift Génération 4 bezeichnete das Spiel als „la plus belle et la plus complète jamais sortie sur compatibles“ und vergab hohe Bewertungen für Grafik und Realismus. In deutschen Magazinen wurde besonders die Atmosphäre der Unterwasserjagd hervorgehoben. Ein Test im Happy Computer Special 5/89 beschreibt die Situation etwa so: „Der Horchposten lauscht gespannt auf die Schraubengeräusche des Zerstörers…“. Das Magazin lobte vor allem die taktischen Möglichkeiten der Simulation.

Internationale Wertungen lagen meist im Bereich zwischen etwa 80 und 90 Prozent. Magazine wie Commodore Computing International, The Games Machine oder Amiga Format vergaben entsprechend hohe Bewertungen und bestätigten damit den Eindruck einer technisch anspruchsvollen Simulation.

Die Entwicklung des Spiels wurde von John W. Ratcliff geleitet, der gemeinsam mit Paul Grace und Randall Breen auch das Design verantwortete. Für die grafische Gestaltung waren Michael Kosaka und Wilfredo J. Aguilar zuständig. Die Soundeffekte stammen von Rob Hubbard, einem der bekanntesten Komponisten der Heimcomputerära.

Auch die Präsentation des Spiels war ungewöhnlich. Die Verpackung der PC-Version war im Stil eines militärischen Geheimdokuments gestaltet und trug entsprechende Hinweise wie „CLASSIFIED“. Obwohl auf der Box ausdrücklich stand, dass das Spiel nicht kopiergeschützt sei, musste der Spieler vor Beginn einer Mission einen Sicherheitscode eingeben. Dieser Code befand sich im Handbuch und musste durch das Nachschlagen eines bestimmten U-Boot-Namens gefunden werden. Die Codes waren über das gesamte Handbuch verteilt und dienten damit als indirekter Kopierschutz.

Die Erstauflage enthielt außerdem ein kleines Extra: einen „688 Hunter/Killer“-Patch, der unter der Schrumpffolie der Verpackung lag. Weitere Besonderheiten waren die Möglichkeit, zwei Spieler über Modem oder Null-Modem-Kabel gegeneinander antreten zu lassen, sowie eine Installation, bei der der Spieler seinen Vornamen eingeben musste. Dieser Name wurde anschließend auf der Diskette gespeichert und erschien in späteren Spielsitzungen automatisch wieder.

Rückblickend gilt 688 Attack Sub als einer der frühen Vertreter moderner U-Boot-Simulationen auf Heimcomputern. Viele der hier verwendeten Ideen – insbesondere die Kombination aus Sonaranalyse, taktischer Navigation und realistischen Sensoren – wurden später weiterentwickelt. Hauptentwickler John W. Ratcliff arbeitete in den folgenden Jahren an weiteren Titeln dieses Genres, darunter SSN-21 Seawolf und schließlich Jane’s 688(I) Hunter/Killer, die das Konzept deutlich ausbauten.

F-29 Retaliator (1989) – Amiga-Flugsimulation zwischen Action und Anspruch

F-29 Retaliator erschien zu einer Zeit, in der das Genre der militärischen Flugsimulationen bereits klar umrissen war, sich aber zugleich in einer Phase des Umbruchs befand. Während Titel wie F-16 Falcon oder F-19 Stealth Fighter auf möglichst realistische Flugmodelle, komplexe Avionik und nüchterne Präsentation setzten, wählte Digital Image Design bewusst einen anderen Weg. F-29 Retaliator wollte kein Lehrbuch sein, sondern ein Spiel, das Geschwindigkeit, Zukunftsvision und Zugänglichkeit miteinander verband, ohne den Anspruch einer ernstzunehmenden Simulation vollständig aufzugeben. Dieses Spannungsfeld prägt den Titel bis heute.

Im Mittelpunkt stehen zwei Kampfflugzeuge, die zur Entstehungszeit des Spiels selbst noch Projektionsflächen militärischer Zukunftsfantasien waren: der experimentelle F-29 mit vorwärts gepfeilten Tragflächen und der damals noch streng geheime Advanced Tactical Fighter F-22. Beide Jets verkörpern den futuristischen Charakter des Spiels und vermitteln das Gefühl, Maschinen zu fliegen, die ihrer Zeit voraus sind. Spielerisch unterscheiden sich die Flugzeuge nur geringfügig, doch ihre Präsenz allein war für viele Spieler ein entscheidender Reiz. F-29 Retaliator erlaubte es, Technik zu fliegen, die es so noch nicht gab – oder zumindest noch nicht öffentlich.

Der Spielaufbau gliedert sich in vier Kampagnen mit ansteigendem Anspruch. Den Einstieg bildet ein Trainingsabschnitt in Arizona, der als Einweisung konzipiert ist und grundlegende Manöver, Start- und Landeprozeduren sowie den Waffeneinsatz vermittelt. Es folgen drei Kriegsschauplätze, die im Pazifik, im Nahen Osten und in Europa angesiedelt sind. Jeder dieser Abschnitte bringt eigene Missionsprofile mit sich und steigert sowohl den Schwierigkeitsgrad als auch die taktische Vielfalt. Luftkämpfe gegen feindliche Jäger, präzise Luft-Boden-Angriffe, Eskortmissionen und Verteidigungsaufgaben wechseln sich ab. Die große Anzahl an Einzelmissionen sorgt dafür, dass das Spiel auch über längere Zeit abwechslungsreich bleibt.

Charakteristisch für F-29 Retaliator ist die Balance zwischen Spielbarkeit und Anspruch. Die Steuerung bleibt überschaubar und zugänglich, ohne trivial zu wirken. Zwar erreicht das Spiel nicht die Tiefe klassischer Hardcore-Simulationen, doch genau darin lag für viele Spieler sein Reiz. Zeitgenössische Tests stellten immer wieder fest, dass F-29 Retaliator eher ein Action-Simulator als eine kompromisslose Simulation sei – ein Ansatz, der insbesondere Spielern entgegenkam, die fliegen wollten, ohne sich durch seitenlange Handbücher zu arbeiten. Die Simulationselemente sind präsent, dominieren das Spiel aber nicht.

Technisch setzte F-29 Retaliator Maßstäbe. Die vollständig polygonale 3D-Grafik wirkte zur Veröffentlichung außergewöhnlich schnell und flüssig. Besonders das Scrolling wurde in der Fachpresse immer wieder hervorgehoben. Der Detailgrad der Landschaften ist bewusst reduziert, was Übersicht und Geschwindigkeit zugutekommt. Städte, Startbahnen, Schiffe und Bodenziele werden durch klare geometrische Formen dargestellt, die funktional bleiben und eine schnelle Orientierung erlauben. Das Cockpit selbst wirkt sachlich und zweckmäßig; mehrere Anzeigen liefern Radar-, Navigations- und Waffeninformationen, ohne den Spieler zu überfordern.

Klanglich schlägt F-29 Retaliator einen bewusst zurückhaltenden Ton an. Für Musik und Soundeffekte zeichnete Matthew Cannon verantwortlich. Auf eine dauerhafte musikalische Untermalung während der Einsätze wird verzichtet; stattdessen konzentriert sich die akustische Gestaltung auf Triebwerksgeräusche, Warnsignale, Waffen- und Explosionssounds. Diese Reduktion unterstützt den nüchternen Charakter der Simulation und lenkt den Fokus auf Flugführung, Navigation und taktische Entscheidungen. Zeitgenössische Tests merkten an, dass der Sound im Vergleich zur Grafik weniger spektakulär ausfällt, sahen darin jedoch keinen spielerischen Nachteil. Vielmehr fügt sich die Geräuschkulisse unaufdringlich in das Gesamtbild ein.

Entwickelt wurde F-29 Retaliator von Digital Image Design, veröffentlicht von Ocean Software. Produzent war Jon Woods. Konzept und Design stammen von Martin Kenwright, der zugleich große Teile der grafischen Gestaltung verantwortete und auch das Handbuch verfasste. Die Lead-Programmierung der Amiga-Version übernahm Phillip Allsopp, unterstützt von Russell Payne in der 3D-Programmierung. Die außergewöhnlich flüssige Polygon-Engine, die von der Presse immer wieder hervorgehoben wurde, geht maßgeblich auf diese Zusammenarbeit zurück. Zusätzliche 3D-Grafiken steuerte Joanne Drury bei. Weitere Rollen entstanden im Rahmen der Teamarbeit bei Digital Image Design; über diese Kernfunktionen hinaus sind keine eindeutig verifizierten Einzelzuordnungen überliefert.

Zeitgenössisch wurde F-29 Retaliator überwiegend positiv aufgenommen. Die ASM lobte insbesondere das schnelle 3D-Scrolling und die enorme Missionsvielfalt, merkte jedoch an, dass der grafische Detailgrad zugunsten der Geschwindigkeit reduziert wurde. Power Play beschrieb das Spiel als „knackige Flugsimulation“, die nicht die Tiefe eines Falcon erreiche, dafür aber deutlich zugänglicher sei. In der Amiga-Wertung erreichte F-29 Retaliator dort 79 Prozent, mit starken Einzelwertungen für Technik und Spielbarkeit. Auch international fiel die Resonanz ähnlich aus. ZZap!64 betonte den gelungenen Spagat zwischen Zugänglichkeit und Anspruch und hob insbesondere die Geschwindigkeit, das Bewegungsgefühl und die Missionsvielfalt hervor. Rückblickend galt das Spiel weniger als ultimative Simulation, sondern als eigenständiger Vertreter seines Genres.

Ein bemerkenswertes Kuriosum stellt ein inoffizielles Add-on dar. Das britische Magazin ZERO veröffentlichte in Ausgabe 12 (Oktober 1990) eine exklusive Special Mission, die das Originalspiel voraussetzte. In dieser Zusatzmission flog der Spieler einen Retaliator über dem Arktischen Ozean und traf neben russischen MiG-Jägern auch auf außerirdische Raumschiffe, deren Design unverkennbar an die Zylonen aus der klassischen Battlestar Galactica-Serie erinnerte. Die Mission fungierte zugleich als augenzwinkernder Verweis auf das damals in Entwicklung befindliche nächste Projekt von Digital Image Design, Epic.

Technisch blieb F-29 Retaliator nicht frei von Schwächen und gilt rückblickend als vergleichsweise buganfällig. Einige dieser Fehler entwickelten jedoch fast schon Kultstatus. Besonders bekannt ist ein Bug, bei dem der Spieler auch nach dem Schleudersitzausstieg weiterhin Kontrolle über das Flugzeug behält – was es theoretisch ermöglicht, das eigene Wrack noch zu steuern und sich selbst zu rammen. Solche Eigenheiten wurden in zeitgenössischen Tests kritisch erwähnt, trugen aber auch zur Legendenbildung rund um das Spiel bei.

Auch die Darstellung der Flugzeuge sorgte für Diskussionen. Der auf den Verpackungen gezeigte F-22 entspricht optisch nicht dem im Spiel dargestellten Modell, was dem damaligen Geheimhaltungsstatus des realen Projekts geschuldet war. Umgekehrt ist der F-29 keine reine Fantasie: Er basiert auf dem real existierenden Grumman X-29-Experimentalflugzeug mit vorwärts gepfeilten Tragflächen, dessen Erscheinungsbild dem Ingame-Modell deutlich näherkommt. Die Amiga- und Atari-ST-Cover sowie das Titelbild aller Versionen basieren auf Konzeptkunst von Lockheed Martin, konkret auf einem Gemälde des futuristischen Designers Syd Mead aus dem Jahr 1988, das den damals noch geheimen Advanced Tactical Fighter zeigte.

Auch langfristig blieb F-29 Retaliator in der Erinnerung der Fachpresse präsent. Amiga Joker wählte das Spiel in Ausgabe 01/1991 auf Platz 3 der besten Simulationsspiele des Jahres 1990. Amiga Power nahm es im Mai 1991 auf Platz 36 in seine Liste der „All Time Top 100 Amiga Games“ auf. Auf dem Atari ST wurde der Titel ebenfalls gewürdigt: ST Format listete F-29 Retaliator in Ausgabe 01/1991 unter den neun besten Simulationsspielen des Jahres 1990.

Rückblickend markiert F-29 Retaliator einen Übergang. Es steht zwischen den nüchternen Militärsimulationen der achtziger Jahre und den stärker inszenierten Flugsimulationen der frühen neunziger. Digital Image Design legte mit diesem Titel den Grundstein für spätere Werke wie TFX oder EF2000. F-29 Retaliator bleibt als Spiel in Erinnerung, das zeigte, dass Geschwindigkeit, Zugänglichkeit und Zukunftsvisionen im Flugsimulator-Genre kein Widerspruch sein müssen – sondern ein eigenes, unverwechselbares Erlebnis formen können.

F-29 Retaliator erschien erstmals 1989 für den Amiga und gilt auf dieser Plattform als Leitversion. Digital Image Design entwickelte das Spiel primär mit Blick auf die Fähigkeiten des Amiga, insbesondere auf die schnelle polygonbasierte 3D-Darstellung, die in zeitgenössischen Tests häufig hervorgehoben wurde. Ebenfalls 1989 folgte eine Umsetzung für den Atari ST, die inhaltlich weitgehend identisch ausfiel und das gleiche Missions- und Kampagnenmaterial bot, technisch jedoch stärker von der Hardware limitiert war.

Die MS-DOS-Version erschien erst 1991 als nachgereichte Konvertierung. Sie brachte kleinere Erweiterungen mit sich, darunter einen Zwei-Spieler-Modus über Nullmodem, blieb grafisch jedoch bewusst kompatibel zu einer breiten PC-Basis (EGA/VGA mit 16 Farben). Inhaltlich entsprach sie im Wesentlichen den 16-Bit-Versionen, profitierte aber je nach Hardware von höherer Bildrate. Später entwickelte Ocean Japan noch Versionen für den PC-98 und FM-Towns.

Super Cars 2 – 1990 by Magnetic Fields / Gremlin Graphics

Super Cars II erschien im Frühjahr 1991 für den Amiga, später auch für den Atari ST, entwickelt von Magnetic Fields und veröffentlicht von Gremlin Graphics. Das Spiel ist ein Top-Down-Rennspiel mit starkem Action- und Waffenfokus und stellt die direkte Fortsetzung von Super Cars aus dem Jahr 1990 dar. Die Entwicklung fällt in eine Phase, in der Magnetic Fields innerhalb kurzer Zeit mehrere erfolgreiche Rennspiele veröffentlichte. Bereits Lotus Esprit Turbo Challenge war 1990 erschienen und hatte sich rasch als einer der populärsten Arcade-Racer auf Heimcomputern etabliert. Noch im selben Jahr folgte Super Cars, das die Draufsicht ins Zentrum rückte. Super Cars II greift diese beiden Linien auf und führt sie 1991 in einem deutlich erweiterten Konzept zusammen.

Die kreative Verantwortung lag erneut bei Shaun Southern und Andrew Morris, die bereits seit den frühen 1980er-Jahren gemeinsam arbeiteten. Schon auf C64 und VIC-20 hatten sie mit schnellen Arcade-Spielen Erfahrungen gesammelt, bevor sie sich auf dem Amiga mit Rennspielen einen Namen machten. Southern zeichnete primär für Programmierung und Spieldesign verantwortlich, während Morris den visuellen Stil prägte. Super Cars II ist daher keine Neuausrichtung, sondern eine konsequente Weiterentwicklung einer bestehenden Designphilosophie.

Am grundlegenden Spielprinzip hält der Nachfolger fest: Aus der Vogelperspektive treten bis zu zehn Fahrzeuge gleichzeitig auf geschlossenen Rundkursen gegeneinander an. Ziel ist es, sich über mehrere Rennen hinweg möglichst viele Punkte zu sichern. Neu ist vor allem der deutlich erhöhte Umfang. Während im ersten Teil maximal vier bis fünf Fahrzeuge gleichzeitig unterwegs waren, ist das Feld nun erheblich größer. Entsprechend dichter, aggressiver und unübersichtlicher fallen die Rennen aus. Nur die besten fünf Fahrzeuge eines Rennens erhalten Punkte, was besonders im Mittelfeld für permanentes Gedränge sorgt.

Das Spiel bietet insgesamt 21 Strecken, aufgeteilt in drei Schwierigkeitsgrade mit jeweils sieben Kursen. Die Strecken unterscheiden sich deutlich stärker als noch im Vorgänger. Brücken, Tunnel, Sprungschanzen, sich öffnende und schließende Tore sowie Bahnübergänge mit durchfahrenden Zügen sorgen für Abwechslung und verlangen präzises Timing. Viele Kurse sind so angelegt, dass reines Tempo nicht ausreicht. Fehler werden unmittelbar bestraft – entweder durch Zeitverlust oder durch Schäden am Fahrzeug.

Eine der wichtigsten Änderungen betrifft das Fortschrittssystem. In Super Cars II besitzt der Spieler nur noch ein einziges Auto, das über die gesamte Saison hinweg weiterentwickelt wird. Nach jedem Rennen erhält man Preisgeld, das in einem Shop für Upgrades und Waffen ausgegeben werden kann. Zur Auswahl stehen Motorverbesserungen, zusätzliche Panzerung, Turbo-Beschleuniger sowie ein breites Arsenal an Waffen: Vorwärts- und Rückwärtsraketen, zielsuchende Raketen, Minen und eine sogenannte Super-Rakete, die das Fahrzeug umkreist. Ergänzt wird dies durch Front- und Heckrammen, mit denen Gegner direkt attackiert werden können.

Das Wirtschaftssystem spielt dabei eine zentrale Rolle. Reparaturen kosten Geld, ebenso jede Aufrüstung. Wer zu aggressiv fährt oder häufig kollidiert, gerät schnell in finanzielle Schwierigkeiten. Gleichzeitig lassen sich bestimmte Teile günstig kaufen und später teurer verkaufen, was eine einfache, aber wirkungsvolle ökonomische Komponente ins Spiel bringt. Damit unterscheidet sich Super Cars II deutlich von vielen zeitgenössischen Arcade-Rennspielen, die ausschließlich auf schnelle Einzelrennen setzten.

Zwischen den Rennen wird der Spieler regelmäßig mit kurzen Dialog- und Entscheidungsszenen konfrontiert. Polizisten, Journalisten, Sponsoren oder Umweltinspektoren stellen Fragen, deren Beantwortung unmittelbare Auswirkungen hat. Je nach Wortwahl drohen Geldstrafen oder es winken zusätzliche Einnahmen. Diese Szenen sind humorvoll inszeniert, greifen aber real in den Spielverlauf ein und verstärken den Eindruck einer zusammenhängenden Rennkarriere.

Technisch zeigt sich Super Cars II auf dem Amiga solide bis sehr überzeugend. Die Strecken sind farbenreich gestaltet, die Fahrzeuge klar voneinander unterscheidbar. Das Scrolling bleibt auch bei voller Gegnerzahl flüssig. Der Sound stammt von Barry Leitch (unterstützt von Ian Howe) und beschränkt sich im Rennen bewusst auf Motor-, Reifen- und Explosionsgeräusche. Musik erklingt vor allem in Menüs und Zwischensequenzen. Die Atari-ST-Version ist inhaltlich identisch, wirkt jedoch grafisch schlichter und klanglich reduzierter.

Ein wesentliches neues Feature ist der Splitscreen-Zwei-Spieler-Modus. Zwei Spieler treten gleichzeitig auf derselben Strecke gegeneinander an, jeder mit eigener Bildschirmhälfte. Gerade in dieser Variante entfaltet das dichte Streckendesign seine volle Wirkung und machte das Spiel zu einem der beliebtesten Mehrspieler-Rennspiele seiner Zeit.

Die zeitgenössische Rezeption von Super Cars II fällt auffallend unterschiedlich aus und spiegelt deutlich die redaktionellen Schwerpunkte der jeweiligen Magazine wider. Britische Zeitschriften reagierten nahezu euphorisch. Computer and Video Games schrieb im Juni 1991:

“The graphics have been spruced up, there's plenty more hazards thrown in (the jumps are an excellent addition) and your motorised steed is far more animated … As a sequel, it's superb. … The best racing game since Gremlin's Lotus.”
(„Die Grafik wurde aufpoliert, es gibt deutlich mehr Gefahren (die Sprünge sind eine hervorragende Ergänzung) und das motorisierte Gefährt wirkt wesentlich lebendiger … Als Fortsetzung ist es hervorragend. … Das beste Rennspiel seit Gremlins Lotus.“)

CVG vergab 91 % und hob besonders den Zwei-Spieler-Modus und die neuen Power-Ups hervor.

Ähnlich positiv äußerte sich CU Amiga im April 1991. Dort heißt es:

“Supercars 2 is basically an extension of the first game, with the welcome addition of a two-player mode.”
(„Supercars 2 ist im Grunde eine Erweiterung des ersten Spiels, ergänzt um die willkommene Ergänzung eines Zwei-Spieler-Modus.“)

Zur Streckenstruktur schrieb CU Amiga:

“There are 21 tracks, with seven per level. The circuits themselves are a great improvement from the flat racing track of the first game: now you have bridges, jumps, tunnels, and opening and closing doors.”
(„Es gibt 21 Strecken mit jeweils sieben pro Schwierigkeitsgrad. Die Kurse selbst sind eine große Verbesserung gegenüber den flachen Rennstrecken des ersten Spiels: nun gibt es Brücken, Sprünge, Tunnel sowie sich öffnende und schließende Tore.“)

Auch die Steuerung wurde dort differenziert betrachtet:

“Once the game has loaded, the player has a choice of whether to have the firebutton as an accelerator or brake.”
(„Nach dem Laden des Spiels kann der Spieler wählen, ob der Feuerknopf als Beschleunigung oder als Bremse fungieren soll.“)

Zum Mehrspieler-Modus hieß es:

“The long awaited two-player split-screen mode is both fast and furious.”
(„Der lang erwartete Zwei-Spieler-Splitscreen-Modus ist sowohl schnell als auch furios.“)

CU Amiga kam zu einer Gesamtwertung von 90 %.

Deutlich kritischer fiel hingegen die Rezeption in deutschen Magazinen aus. ASM (6/91) erkannte zwar die technische Qualität an, formulierte jedoch klar:

„Doch nun zum Hauptkritikpunkt, der die gute Grafik stark im Wert mindert: Die Steuerung!“

Trotz hervorragender Optik bemängelte die Redaktion die Eingewöhnungszeit und vergab lediglich 57 %.

Auch Power Play (6/91) blieb zurückhaltend. Zwar wurde die Action als ansprechend beschrieben, gleichzeitig jedoch betont:

„Ohnehin keine realistische Fahrsimulation, sondern unkompliziertes Renn-Actionspiel.“

Die Vogelperspektive und die Übersicht im Splitscreen wurden kritisch gesehen. Auch hier lautete die Wertung 57 %.

Diese Spannbreite ist weniger ein Widerspruch als Ausdruck unterschiedlicher redaktioneller Erwartungshaltungen. Während britische Magazine den Arcade-Charakter, den Spielfluss und den Mehrspieler-Modus in den Vordergrund stellten, bewerteten deutsche Redaktionen stärker unter dem Gesichtspunkt von Steuerung, Übersicht und Simulationstiefe.

Bei seiner Veröffentlichung kostete Super Cars II rund 24,99 Pfund in Großbritannien beziehungsweise 85 D-Mark in Deutschland. Inflationsbereinigt entspricht dies heute etwa 80 bis 100 Euro, womit das Spiel klar im damaligen Vollpreissegment angesiedelt war.

Rückblickend gilt Super Cars II als der ausgefeilteste Teil der Reihe. Es bündelt die Erfahrungen aus Lotus Esprit Turbo Challenge und Super Cars und erweitert sie um mehr Strecken, mehr strategische Tiefe und einen prägenden Zwei-Spieler-Modus. Ohne das Genre neu zu erfinden, verfeinert es dessen Mechaniken so konsequent, dass es bis heute als Referenz für klassische Combat-Racer aus der Vogelperspektive gilt.

Crystal Raider (1986) – Mastertronics kompromissloses Logik-Plattformspiel für Atari 8-Bit

Crystal Raider erschien 1986 beim britischen Budget-Publisher Mastertronic und gehört zu jenen Spielen, die ihre wahre Natur erst nach einigen Minuten offenbaren. Was zunächst wie ein klassisches Jump-’n’-Run wirkt, entpuppt sich rasch als streng durchdachtes Logik- und Präzisionsspiel, das Geduld und Planung über schnelle Reflexe stellt. Der Spieler steuert einen namenlosen Abenteurer durch ein weit verzweigtes Labyrinth aus fünfzig einzelnen Bildschirmen, deren Ziel stets darin besteht, sämtliche Kristalle einzusammeln und den richtigen Ausgang zu finden.

Bereits der offizielle Begleittext der Kassette formuliert diesen Anspruch ungewöhnlich offen: „Crystal Raider is not an arcade adventure. It is in fact a set of logic problems and should be approached in that way.“ („Crystal Raider ist kein Arcade-Abenteuer. Es handelt sich vielmehr um eine Reihe von Logikproblemen, die auch so angegangen werden sollten.“)

Diese Selbsteinordnung ist bemerkenswert ehrlich und trifft den Kern des Spiels präzise. Unüberlegtes Springen führt fast immer zum Verlust eines Lebens. Gegner bewegen sich nach festen Mustern, Plattformen erscheinen und verschwinden scheinbar willkürlich, und jeder Raum verlangt eine exakt geplante Abfolge von Bewegungen. Zusätzlich setzt das Spiel den Spieler mit einer begrenzten Sauerstoffanzeige unter permanenten Zeitdruck, der strategisches Vorgehen erzwingt, ohne Hektik zu erlauben.

Die Levelstruktur ist bewusst nicht linear angelegt. Viele Bildschirme besitzen mehrere Ausgänge, die zu unterschiedlichen Bereichen führen, wodurch sich ein labyrinthisches Geflecht ergibt. Orientierung ist hier keine Nebensache, sondern elementarer Bestandteil des Spiels. Wer erfolgreich sein will, muss sich Wege merken oder – ganz im Sinne der 1980er-Jahre – eigene Karten anfertigen. Jeder vollständig geräumte Bildschirm belohnt den Spieler mit einem zusätzlichen Leben sowie einer Auffrischung des Sauerstoffvorrats. Theoretisch lassen sich so bis zu 55 Leben ansammeln, doch spätere Abschnitte fordern diese Reserve gnadenlos ein.

Die britische Fachpresse brachte diese Ambivalenz treffend auf den Punkt. Computer Gamer schrieb im März 1987 zur Atari-8-Bit-Version:
„To add to your troubles there are platforms that appear and disappear almost at will and you have to plunder the crystals before your limited oxygen runs out. You get an extra life for clearing a screen and an oxygen top up, so you should be able to finish the game with the available 55 lives! Unfortunately, it isn't that easy.“ („Zu all deinen Problemen kommen Plattformen hinzu, die scheinbar nach Belieben erscheinen und verschwinden, während du die Kristalle plündern musst, bevor dein begrenzter Sauerstoffvorrat aufgebraucht ist. Für das Räumen eines Bildschirms erhältst du ein zusätzliches Leben und eine Sauerstoffauffrischung, sodass man meinen könnte, man könne das Spiel mit den verfügbaren 55 Leben beenden. Leider ist es nicht so einfach.“) Die daraus resultierende Wertung von 54 Prozent spiegelt diesen Eindruck exakt wider: fair, logisch, aber kompromisslos anspruchsvoll.

Auch die deutsche Power Play erkannte den besonderen Charakter des Spiels. In Ausgabe 3/1988 wurde Crystal Raider als anspruchsvoller Titel beschrieben, der sich deutlich von vielen zeitgenössischen Plattformspielen abhob. Hervorgehoben wurde insbesondere die Größe des Labyrinths sowie die Notwendigkeit, systematisch vorzugehen. Mit einer Wertung von 7,5 von 10 Punkten wurde das Spiel als empfehlenswert für geduldige Spieler eingeordnet.

Technisch präsentiert sich Crystal Raider funktional und zurückhaltend. Musik fehlt vollständig, Soundeffekte sind minimalistisch, erfüllen jedoch ihren Zweck. Die Grafik ist klar strukturiert und stets gut lesbar. Eine Besonderheit stellt der optionale Nachtmodus dar, bei dem nur der unmittelbare Bereich um die Spielfigur sichtbar bleibt. Zusätzlich existieren im regulären Spielverlauf einzelne dunkle Räume, die Orientierung und Planung weiter erschweren und dem Spiel eine beinahe klaustrophobische Atmosphäre verleihen.

Rückblickend würdigte Retro Gamer das Spiel 2009 als zeitlos fordernden Vertreter seiner Gattung: „A simple but engaging game about an explorer hunting for crystals.“ („Ein simples, aber fesselndes Spiel über einen Entdecker auf der Jagd nach Kristallen.“). Weiter heißt es: „There are approximately 50 screens of platform trickery to navigate, with multiple paths to take on many levels allowing you to choose your own route.“ („Es gilt, rund 50 Bildschirme voller Plattform-Tücken zu durchqueren, wobei viele Ebenen mehrere Wege bieten und dem Spieler erlauben, seine eigene Route zu wählen.“)

Preislich entsprach Crystal Raider vollständig der Mastertronic-Philosophie. In Deutschland lag der Kassettenpreis bei rund 10 DM, inflationsbereinigt heute etwa 12–15 Euro. Dafür erhielt man kein kurzlebiges Actionspiel, sondern ein konsequent durchdachtes Werk, das Planung, Geduld und Konzentration einforderte.

Heute gilt Crystal Raider nicht als Mainstream-Klassiker, wohl aber als typischer Vertreter einer kompromisslosen Designhaltung der 1980er-Jahre. Es ist ein Spiel, das nicht gefallen will, sondern fordert – und genau darin liegt bis heute seine besondere Faszination.

Erhältlich für: Atari 8-bit (400/800, XL, XE) – Kassette; Atari 8-bit (XL/XE) – Diskette

Bombuzal (1989) – 250 Level Puzzleklassiker | MansionManiax

Bombuzal ist eines jener Spiele, bei denen man oft erst mit zeitlichem Abstand begreift, warum sie sich so hartnäckig im Gedächtnis festgesetzt haben. Nicht wegen einer Geschichte, nicht wegen charismatischer Figuren und schon gar nicht wegen audiovisueller Effekte. Bombuzal hinterließ Eindruck, weil es den Spieler ernst nahm. Es sprach ihn nicht an, es erklärte sich nicht, es versuchte nicht, ihn zu umwerben. Es stellte ihn schlicht auf eine schwebende Insel aus Kacheln, ließ die Zeit anlaufen – und überließ ihm die Verantwortung für alles, was danach geschah.

Schon der Einstieg ist bezeichnend nüchtern. Keine Einführung, kein Tutorial, keine Einblendung mit wohlmeinenden Tipps. Man sieht Bomben, Felder, Abgründe. Man sieht, dass man nur einen Schritt Platz hat, um sich nach einer Explosion in Sicherheit zu bringen. Und man versteht sehr schnell, dass dieses Spiel nicht verzeiht. Bombuzal basiert vollständig auf Ursache und Wirkung. Jede Handlung verändert das Spielfeld dauerhaft, jede Entscheidung schließt andere Möglichkeiten aus. Ziel ist es, alle Bomben eines Levels zu zünden, ohne sich selbst den letzten Fluchtweg abzuschneiden oder in die Tiefe zu reißen. Der Weg dorthin ist niemals offensichtlich.

Das Spielfeld besteht aus einer Vielzahl unterschiedlich reagierender Felder. Normale Kacheln werden durch Explosionen zerstört, andere bleiben unversehrt. Es gibt Felder, die nur einmal betreten werden dürfen, solche, die unter Belastung zusammenbrechen, und spezielle Transportfelder, die Bomben oder den Spieler weiterleiten. Bomben selbst unterscheiden sich in ihrer Wirkung: kleine Explosionen erfassen nur das eigene Feld, größere reißen angrenzende Kacheln mit. Da der Spieler sich nach dem Zünden einer Bombe nur um ein einziges Feld bewegen kann, entscheidet oft eine scheinbar unbedeutende Position über Erfolg oder Scheitern. Hinzu kommen Teleporter, die Bombuzal an andere Stellen versetzen, Spinner, die die Bewegungsrichtung verändern, sowie Gegner, die sich nach festen, aber nicht sofort durchschaubaren Mustern bewegen und nur indirekt durch Explosionen beseitigt werden können. Jeder Level ist ein in sich geschlossenes System, das verstanden werden will. Die Anleitung listet diese Elemente sachlich auf, fast wie ein technisches Regelwerk, und überlässt das eigentliche Lernen vollständig dem Spieler.

Genau darin liegt die besondere Qualität von Bombuzal. Das Spiel zwingt dazu, mehrere Züge vorauszudenken. Nicht nur: Welche Bombe zünde ich zuerst? Sondern: Welche Felder bleiben danach noch begehbar? Wo stehe ich nach der Explosion? Welche Kettenreaktionen löse ich aus, die ich im Moment der Entscheidung noch gar nicht sehe? Fehler entstehen selten aus Unwissen, sondern aus Ungeduld. Bombuzal bestraft diese Ungeduld konsequent, aber nie unfair. Jeder Fehlschlag ist im Nachhinein nachvollziehbar.

Entwickelt wurde Bombuzal 1988 für Amiga und Atari ST von David Bishop und Antony Crowther, zwei Vertretern einer sehr britischen Designhaltung, bei der Klarheit und Regelstrenge über Inszenierung stehen. Crowther, zugleich Entwickler und Spielejournalist, vertrat stets die Auffassung, dass gutes Game Design aus sauberen Mechaniken entsteht, nicht aus erzählerischem Überbau. Bombuzal ist die vielleicht konsequenteste Umsetzung dieser Überzeugung. Die technische Realisierung übernahm Ross Goodley, der zugleich für die Musik verantwortlich war. Der Sound bleibt bewusst im Hintergrund – funktional, zurückhaltend, ohne Anspruch auf Aufmerksamkeit. Er soll nicht führen, sondern Raum lassen.

Ein wesentlicher Teil des Kultstatus von Bombuzal erklärt sich durch seinen enormen Umfang. 250 Levels umfasst das Spiel, was für ein reines Denkspiel Ende der 1980er außergewöhnlich war. Noch bemerkenswerter ist, wie diese Levels entstanden. Bombuzal war nie ausschließlich das Werk eines kleinen Kernteams. Crowther stellte ein einfaches Level-Editor-System zur Verfügung und lud Kollegen, Entwicklerfreunde und Redakteure ein, eigene Aufgaben zu entwerfen. Bombuzal wurde dadurch zu einem stillen Gemeinschaftsprojekt der Szene.

Zu diesen Gastdesignern gehörte Geoff Crammond, dessen Levels bereits jene systematische, fast ingenieurhafte Denkweise erkennen lassen, die ihn später mit seinen Formula-One-Simulationen berühmt machen sollte. Ebenfalls beteiligt war Andrew Braybrook, bekannt für technisch präzise, logisch durchkonstrierte Spiele, bei denen jedes Element seinen festen Platz hat. Einen bewussten Kontrast setzte Jeff Minter, der zu diesem Zeitpunkt längst als schillernde Kultfigur der britischen Szene galt. Sein Bombuzal-Level, in dem Explosionen ein Lama und einen kleinen Dunghaufen hinterlassen, ist kein bloßer Gag, sondern ein augenzwinkernder Kommentar: Selbst im strengsten Regelwerk darf Platz für Persönlichkeit und Humor sein.

Auch die enge Verbindung zur Magazinlandschaft jener Zeit ist im Spiel selbst sichtbar. Gary Liddon und Gary Penn gestalteten gemeinsam ein Level, das ein riesiges ZZAP-Logo formt – eine selbstironische Hommage an ZZAP!64, das Bombuzal intensiv begleitete. Solche Details zeigen, dass Bombuzal nicht als isoliertes Produkt entstand, sondern als Teil eines lebendigen Austauschs zwischen Entwicklern, Redakteuren und Spielern.

Technisch fand Bombuzal seinen Weg auf zahlreiche Systeme. Die Commodore-64-Version von 1988 wurde von Bishop und Crowther selbst umgesetzt. 1989 folgte eine DOS-Fassung, programmiert von Tony Love, die das Spielprinzip erfolgreich auf den IBM-PC übertrug. 1990 erschien schließlich eine Umsetzung für das Super Nintendo, programmiert von Shinobu Michiura (im Abspann als Super Mic), mit Musik von Hiroyuki Masuno (Hiro) und zusätzlichen Charakterdesigns von Kiminari Sueda, H. Kamigaki und T. Sunahori. In Nordamerika wurde das Spiel unter dem Titel Ka-Blooey veröffentlicht – ein deutlich verspielterer Name, der den kulturellen Unterschied in der Vermarktung widerspiegelt, während das Spiel selbst unverändert blieb.

Als Bombuzal 1988/89 seinen Weg in die Magazine fand, wurde schnell deutlich, dass man es hier nicht mit einem gewöhnlichen Denkspiel zu tun hatte. In Happy Computer wurde es als Titel beschrieben, der „im Stil von ‚Boulder Dash‘ kommt“, zugleich aber „im wahrsten Sinne des Wortes explosionsgeladen ist“. Die Redaktion bescheinigte Bombuzal ein „recht intelligentes Spielprinzip“ und lobte, dass die Aufgaben „nicht zu knifflig und damit von jedermann lösbar“ seien, wies jedoch auch auf problematische Situationen hin, in denen Teleporter-Zufälle Level „total unlösbar“ machen könnten. Trotz dieser Einschränkungen fiel das Gesamturteil positiv aus.

Auch die ASM analysierte Bombuzal 1989 sehr präzise. Dort wurde betont, dass es sich um ein Spiel handle, bei dem man „nicht nur den Joystick, sondern auch die kleinen grauen Zellen kräftig anstrengen muß“. Besonders hervorgehoben wurde die Notwendigkeit, jeden Level zunächst zu analysieren, statt impulsiv zu handeln. Auffällig ist der frühe Versionsvergleich: Die C64-Fassung wurde als sehr spielbar beschrieben, während die Atari-ST-Version wegen ihrer hakeligen Steuerung kritisiert wurde, was sich spürbar auf Motivation und Spielfluss auswirke.

Rückblickend wirken diese zeitgenössischen Einschätzungen bemerkenswert treffend. Bereits damals wurden sowohl die Stärken als auch die Eigenheiten klar benannt: die Strenge der Regeln, der enorme Umfang, aber auch der schmale Grat zwischen Planung und Zufall. Bombuzal wurde nicht als gefälliges Spiel verstanden, sondern als Herausforderung. Genau das verleiht ihm bis heute seine Beständigkeit. Es steht exemplarisch für eine Designhaltung der späten 1980er-Jahre, in der man davon ausging, dass Spieler bereit sind, zu scheitern, zu beobachten und neu anzusetzen. Bombuzal erklärt nichts, entschuldigt nichts und schenkt nichts – und gerade deshalb bleibt es als Denkspiel von ungewöhnlicher Klarheit in Erinnerung.

Erhältlich für: Amiga, Atari ST, Commodore 64, MS-DOS (PC), SNES (Super Nintendo)

Spy Hunter (1983) – Straßenkrieg, Agentenfantasie und das Arcade-Gefühl der Kontrolle

Warum steuert man in einem Arcade-Spiel ein Auto mit dem Steuerhorn eines Flugzeugs? Diese Frage stellt sich nicht aus technischer Neugier, sondern aus ehrlicher Verwunderung. Schließlich wollte man hier keinen Jumbo auf die Landebahn bringen, sondern mit quietschenden Reifen über amerikanische Highways jagen. Und doch stand man 1983 vor dem Spy Hunter-Automaten, legte die Hände an ein Yoke, trat ein Gaspedal und hatte binnen Sekunden das Gefühl, etwas ausgesprochen Richtiges zu tun.

Der popkulturelle Kontext lieferte dafür reichlich Vorlagen. Ein Jahr zuvor hatte Knight Rider das Bild des intelligenten Autos geprägt, während im Kino mit Octopussy der aktuelle James-Bond-Film lief. Zwar verzichtete dieser auf ein neues Gadget-Wunderauto, doch der bewaffnete Lotus Esprit aus den Vorgängerfilmen war noch präsent genug, um klare Assoziationen zu wecken. Autos, Geheimagenten, Technik, Gadgets – all das lag Anfang der Achtziger förmlich in der Luft.

Tatsächlich wurde Spy Hunter in einer frühen Entwicklungsphase als James-Bond-Lizenzspiel konzipiert. Die Parallelen sind offensichtlich: ein anonymer Agent, ein spezialisiertes Fahrzeug, endlose Verfolgungsjagden und technische Spielereien, verbunden mit dem Versprechen, der Situation stets einen Schritt voraus zu sein. Dass es nicht zur offiziellen Lizenz kam, lag nicht an mangelnder Passung, sondern an den Kosten. Der Wegfall des Namens erwies sich jedoch als Vorteil. Ohne feste Figur, ohne Kanon und ohne narrative Verpflichtungen konnte sich das Spiel ganz auf das konzentrieren, was Arcade-Spiele am besten konnten: Tempo, Haltung und Übersicht. Die Wahl des Peter-Gunn-Themas anstelle einer Bond-Titelmelodie unterstreicht diesen Schritt perfekt – vertraut im Tonfall, aber eigenständig im Ausdruck.

Ganz von der Hand zu weisen ist allerdings auch ein anderer zeitgenössischer Einfluss nicht. Der Name des Fahrzeugs – Interceptor – ruft unweigerlich Assoziationen an Mad Max und The Road Warrior hervor. Max Rockatanskys schwarzer V8 Interceptor stand nicht für Geheimdienst-Glamour, sondern für Straßenkrieg, Improvisation und Durchsetzungsfähigkeit. Beide Filme waren zu Beginn der Achtziger noch präsent genug, um das Bild der Straße als Kampfzone zu prägen. Ob diese Nähe bewusst gesucht wurde oder zufällig entstand, lässt sich nicht belegen – die gedankliche Verbindung ist jedoch auffällig. Auch Spy Hunter verhandelt den öffentlichen Raum nicht als Verkehrsfläche, sondern als feindliche Umgebung, in der Geschwindigkeit und Aufmerksamkeit über Erfolg oder Scheitern entscheiden.

1983 erschien Spy Hunter als Arcade-Spiel von Bally Midway und war von Beginn an als kompromissloser Spielhallentitel konzipiert. Der Spieler übernimmt die Rolle eines namenlosen Agenten im G-6155 Interceptor und fährt, solange er kann. Es gibt kein Ziel, kein Ende, keine Verschnaufpause. Gegnerische Fahrzeuge versuchen, den Interceptor von der Straße zu drängen oder direkt zu zerstören, während zivile Autos den Verkehr beleben und gleichzeitig zur moralischen Stolperfalle werden, denn ihre Zerstörung wird mit Punktabzug bestraft. Aus dieser simplen Konstellation entsteht ein permanenter Spannungszustand: aggressiv genug, um zu überleben, ohne den Überblick zu verlieren.

Ein weiteres zentrales Spielelement ist der sogenannte Weapons Van, ein bewaffneter Lastwagen, der in regelmäßigen Abständen auftaucht. Wer es schafft, im richtigen Moment auf dessen ausklappende Rampe zu fahren, wird belohnt: Ölspuren, Rauchwände oder – nach entsprechender Aufrüstung – Raketen erweitern das Arsenal des Interceptors. Der Weapons Van lässt sich nicht rufen oder planen; er erscheint einfach, und der Spieler muss reagieren. Genau dieses Prinzip verleiht Spy Hunter seinen typischen Rhythmus. Es ist kein Spiel, das sich durch Vorbereitung gewinnen lässt, sondern durch Aufmerksamkeit und Timing.

Erst vor diesem Hintergrund ergibt die Steuerung des Automaten ihren vollen Sinn. Bally Midway verzichtete bewusst auf einen klassischen Joystick und setzte stattdessen auf ein Steuerhorn, das eher an ein Cockpit als an einen Spielautomaten erinnerte. Trigger und Daumentasten erlaubten die getrennte Auslösung der Waffenfunktionen, ergänzt durch einen Zweigang-Schalthebel. Spy Hunter verlangte nicht nur schnelle Reaktionen, sondern Koordination – Hände, Fuß und Kopf gleichzeitig. Fehler entstanden selten aus Langsamkeit, sondern aus Überforderung.

Die Technik des Automaten trug dieses Spielgefühl maßgeblich. Die MCR-III-Hardware ermöglichte flüssiges vertikales Scrolling und eine klare Bilddarstellung auf einem vertikal eingebauten Monitor, während mehrere Prozessoren die Spiel- und Soundlogik parallel abarbeiteten. Schüsse, Motorengeräusche und Effekte verschmolzen mit der permanenten musikalischen Begleitung zu einem dichten akustischen Gesamtbild. In der Spielhalle war Spy Hunter akustisch sofort präsent.

Auch die zeitgenössische Presse erkannte früh, worin die Stärke des Spiels lag. CRASH begrüßte die spätere Budget-Neuauflage mit den Worten: „Aaah, it’s nice to see this classic come back again on a budget label“, während Sinclair User nüchtern feststellte, dass das Spiel simpel wirke, aber genau darin seine Stärke liege.

Gerade vor diesem Hintergrund wird verständlich, warum die zahlreichen Umsetzungen für Heimcomputer und Konsolen einen schweren Stand hatten. Spy Hunter war eng an seine ursprüngliche Hardware gebunden. Systeme mit nur einem Feuerknopf mussten Waffenfunktionen zusammenlegen oder automatisieren, wodurch das charakteristische Gefühl von Übersicht häufig verloren ging. Besonders schwach fielen Umsetzungen aus, die das Spiel auf reine Reaktionsarbeit reduzierten. Als vergleichsweise gelungen galten hingegen Fassungen, die zumindest den Rhythmus des Originals bewahrten – insbesondere auf dem Commodore 64 sowie dem ZX Spectrum.

Einige Portierungen sind darüber hinaus auch personell greifbar: Die ColecoVision-Fassung nennt Michael Price (Game Adaptation), Jesse Kapili (Computer Graphics) und Roland J. Rizzo (Audio Adaptation), die Amstrad-CPC-Version wurde bei Choice Software von Sean Pearce programmiert und grafisch umgesetzt, und die BBC Micro-Fassung nennt David Hoskins in den In-Game-Credits. Für Atari 2600 ist als Programmer Jeff Lorenz dokumentiert. Andere Plattformen bleiben hingegen ohne gesicherte namentliche Zuschreibung.

Rückblickend ist Spy Hunter kein Spiel, das man über einzelne Features erklärt. Es funktioniert als geschlossenes Ganzes. Steuerung, Technik, Musik und Spielmechanik greifen ineinander und erzeugen ein Erlebnis, das sich kaum zerlegen lässt. Vielleicht erinnert man sich deshalb weniger an konkrete Gegner oder Highscores als an das Gefühl, vor diesem Automaten zu stehen – Hände am Yoke, Fuß auf dem Pedal, während das Peter-Gunn-Thema unaufhörlich antreibt.

Spy Hunter war kein Spiel, das man spielte, um es zu beenden. Es war eines, das man spielte, um es auszuhalten – solange die Konzentration reichte, solange die Straße noch lesbar blieb, solange der nächste Fehler nicht der letzte war. Und genau darin liegt seine bleibende Qualität. Es wollte nichts erklären – nur, dass man fährt.

Erhältlich für: Arcade, PC Booter, Commodore 64, Atari 2600, Apple II, Atari 8-bit, ZX Spectrum, ColecoVision, Amstrad CPC, BBC Micro, NES.

California Games (1987) – Epyx und das kalifornische Lebensgefühl auf Diskette

Wie stark ein Spiel auf die eigene Jugend eingewirkt hat, merkt man oft erst viele Jahre später – dann, wenn man längst glaubt, alles schon eingeordnet zu haben. Bei mir passiert das zuverlässig bei einer Wiederholung von Die nackte Kanone. In der legendären Szene, in der Dr. Albert Sacks nach seinem missglückten Anschlag auf die Queen von einer ganzen Kaskade an Fahrzeugen überrollt und schließlich von einer Marschkapelle niedergetrampelt wird, erklingt unaufhaltsam „Louie, Louie“. Und in genau diesem Moment bin ich nicht mehr im Film, sondern wieder vor dem Bildschirm: Halfpipe, BMX, Strand – California Games. Wer diese Melodie hört und nicht sofort dort landet, hat die Achtziger entweder verpasst oder sie auf der falschen Plattform erlebt.

Für viele Spieler meiner Generation kam noch eine zweite, ebenso prägende Erinnerung hinzu. California Games wurde auf dem Commodore 64 oft nicht als gekaufte Originaldiskette erlebt, sondern als weitergereichte Kopie – inklusive Cracker-Intro. Besonders präsent blieb dabei das Emblem von Eagle Soft Incorporated: ein Adler mit einer Diskette im Schnabel. Dieses Bild war kein Bestandteil des Spiels im eigentlichen Sinne, aber es gehörte für viele untrennbar dazu. Es war der inoffizielle Vorspann einer Zeit, in der Spiele nicht nur gespielt, sondern getauscht, gesammelt und weitergegeben wurden – und in der sich solche Intros fast ebenso tief ins Gedächtnis einbrannten wie die Spiele selbst.

California Games erschien 1987 in einer Phase, in der Epyx nach dem großen Erfolg von Summer Games und Winter Games längst zu den prägenden Namen der internationalen Spieleszene zählte. Die sogenannte „Games“-Reihe hatte Sportspiele neu definiert: weniger als nüchterne Simulationen, sondern als kurzweilige, kompetitive Mehrdisziplinentitel, die auf Zugänglichkeit und unmittelbaren Spielspaß setzten. California Games übertrug dieses bewährte Konzept erstmals nicht auf ein globales Sportereignis, sondern auf einen klar umrissenen kulturellen Raum – das kalifornische Lebensgefühl der 1980er-Jahre, geprägt von Sonne, Strand, Trendsportarten und jugendlicher Ungezwungenheit.

Bereits die Sprache des Handbuchs macht deutlich, wie bewusst Epyx dieses Lebensgefühl inszenierte. Begriffe wie „rad“, „aggro“ oder „tubular“ entstammen dem amerikanischen Jugend- und Surfer-Slang jener Zeit. „Rad“, abgeleitet von „radical“, bezeichnete etwas besonders Cooles oder Beeindruckendes und war vor allem im Skate- und BMX-Umfeld verbreitet. „Aggro“ ist eine Verkürzung von „aggressive“ und stand im sportlichen Kontext für einen entschlossenen, risikofreudigen Fahrstil, etwa bei waghalsigen Tricks in der Halfpipe. „Tubular“ stammt ursprünglich aus der Surfszene und bezeichnete ideal geformte Wellenröhren; im erweiterten Sprachgebrauch entwickelte sich der Begriff zu einem allgemeinen Ausdruck für etwas Außergewöhnliches oder Perfektes. Dass Epyx diese Begriffe konsequent einsetzte, war kein beiläufiger Stilgriff, sondern ein bewusster Versuch, das Spiel sprachlich ebenso fest in der kalifornischen Popkultur zu verankern wie grafisch oder spielmechanisch.

Dieses kulturelle Selbstverständnis setzte sich auch musikalisch fort. Die zentrale Melodie von California Games basiert auf dem Rock-’n’-Roll-Song „Louie, Louie“, geschrieben 1957 von Richard Berry. Berühmt wurde das Stück vor allem durch die Version der Kingsmen aus dem Jahr 1963, deren rohe, beinahe anarchische Darbietung dem Lied Kultstatus verlieh. Über Jahrzehnte hinweg entwickelte sich „Louie, Louie“ zu einem Symbol unkomplizierter, rebellischer Rockmusik. Für California Games war diese Melodie ideal: einfach, sofort wiedererkennbar und kulturell tief verankert, zugleich locker genug, um das unbeschwerte Sport- und Strandgefühl des Spiels zu transportieren.

Spielerisch setzte California Games auf sechs Disziplinen, die damals als typische Trendsportarten galten: Halfpipe-Skateboarding, Foot Bag, Surfing, Roller Skating, BMX Cycling und Flying Disc. Jede dieser Sportarten folgt einer eigenen Steuerungs- und Wertungslogik. Es existiert kein einheitliches Bedienkonzept, sondern ein Nebeneinander unterschiedlicher Spielmechaniken, was wesentlich zum Reiz, aber auch zur Ungleichheit der Umsetzungen beitrug.

Die ursprünglichen Fassungen für Apple II und Commodore 64 bildeten die konzeptionelle Grundlage. Vor allem die C64-Version etablierte sich früh als Referenz, da sie alle Disziplinen ausgewogen vereinte. Die Steuerung erwies sich als präzise, insbesondere beim Halfpipe-Skateboarding und BMX-Cycling, wo exaktes Timing entscheidend ist. Grafik und Animationen blieben klar strukturiert, der Mehrspielerfaktor wurde in zeitgenössischen Tests besonders hervorgehoben und machte California Games zu einem typischen Spiel für gemeinsame Runden.

Auf dem Amiga verlagerte sich der Schwerpunkt stärker in Richtung Präsentation. Die höhere Auflösung und erweiterte Farbpalette sorgten für weichere Animationen und ein insgesamt flüssigeres Erscheinungsbild. Gleichzeitig wurde die Steuerung von Teilen der Presse als etwas weniger direkt empfunden, was verdeutlicht, dass technische Überlegenheit nicht automatisch ein besseres Spielgefühl garantierte.

Die Umsetzungen für ZX Spectrum und Amstrad CPC mussten größere Abstriche hinnehmen. Beide Versionen blieben funktional, wirkten jedoch reduzierter und verloren einen Teil der Leichtigkeit, die die Kernfassungen auszeichnete. Sie gelten heute eher als zeittypische Pflichtumsetzungen denn als prägende Varianten des Spiels.

Eine besondere Stellung nimmt die Atari-2600-Version ein, die erst 1988 erschien. Hier war aufgrund der extremen Hardware-Beschränkungen keine klassische Portierung möglich, sondern nur eine weitgehende Neuinterpretation. Disziplinen wurden vereinfacht, Animationen stark abstrahiert, und das Spiel näherte sich eher einer symbolischen Darstellung der Sportarten an als einer direkten Umsetzung. Zeitgenössische Tests würdigten zwar den technischen Aufwand, ein derart komplexes Mehrdisziplinenspiel auf dem betagten VCS zu realisieren, machten aber keinen Hehl daraus, dass diese Fassung spielerisch und visuell deutlich hinter den Heimcomputer-Versionen zurückblieb. Besonders kritisch wurde dabei die Preisgestaltung gesehen: Inflationsbereinigt lag die VCS-Version mit etwa 65–70 Euro sogar über dem Niveau der technisch deutlich überlegenen C64-Fassungen.

Deutlich überzeugender fielen die Konsolenfassungen aus, allen voran die Umsetzung für das Sega Master System. Zeitgenössische Berichte beschrieben diese Versionen als gleichmäßiger im Bildlauf und insgesamt geschmeidiger im Spielgefühl, was weniger auf höhere spielerische Komplexität als auf stabilere Animationen und eine auf Gamepads zugeschnittene Steuerung zurückzuführen war. Gerade Disziplinen wie BMX Cycling oder Roller Skating profitierten davon, wodurch die Konsolenversionen vielfach als direkter und flotter wahrgenommen wurden als manche Heimcomputerfassungen.

Beim Marktstart des Atari Lynx im September 1989 wurde California Games als Bundle-Titel zusammen mit der neuen Hardware ausgeliefert. Die Wahl dieses Spiels war eng mit der Geschichte des Systems verknüpft, da der Lynx ursprünglich bei Epyx als Projekt „Handy“ entwickelt worden war. California Games eignete sich ideal, um die Stärken des neuen Handhelds zu demonstrieren: farbige Grafik, flüssige Animationen und kurze, zugängliche Disziplinen. Hinzu kam die Möglichkeit, über das ComLynx-Kabel bis zu vier Lynx-Konsolen miteinander zu verbinden, was das Spiel zu einem frühen Beispiel für mobiles Mehrspieler-Gaming machte.

Zeitgenössische Magazine bewerteten California Games überwiegend positiv, betonten jedoch nahezu durchgängig die erheblichen Unterschiede zwischen den Plattformen. In der britischen ZZap!64 (September 1987) erhielt die Commodore-64-Version eine Gesamtwertung von 97 Prozent, begleitet vom Fazit: „California Games is quite simply the apex of computer sports gaming at the present time. Recommending it is a formality.“ („California Games ist ganz schlicht der Gipfel des Computersportspiels zurzeit. Eine Empfehlung ist reine Formsache.“) Auch The Games Machine (Oktober 1987) vergab für die C64-Version 92 Prozent. In Deutschland zeichnete die ASM die C64-Fassung in Ausgabe 10/87 mit dem Prädikat ASM HIT aus. Die Atari-2600-Version wurde in der ASM 10/88 deutlich niedriger bewertet, während die Sega-Master-System-Fassung in der ASM 5/89 wieder klar positiv beurteilt wurde.

Preislich positionierte sich California Games bei Erscheinen als klarer Vollpreistitel. In Großbritannien kosteten Kassettenversionen 8,99 Pfund, Diskettenfassungen 14,99 Pfund, was inflationsbereinigt etwa 33–35 Euro beziehungsweise 55–58 Euro entspricht. In Deutschland lag der Preis der C64-Version bei 59 DM, inflationsbereinigt rund 55–60 Euro. Spätere Budget-Neuauflagen, etwa unter dem Label Kixx, sorgten dafür, dass das Spiel über Jahre hinweg präsent blieb.

Rückblickend steht California Games exemplarisch für eine Phase der Videospielgeschichte, in der Atmosphäre, Musik und unmittelbare Zugänglichkeit wichtiger waren als sportliche Präzision. Die Fähigkeit des Spiels, auf Heimcomputern, Konsolen und als Bundle-Titel eines neuen Handhelds zu funktionieren, erklärt seinen anhaltenden Ruf. California Games ist weniger ein präzises Sportspiel als ein kulturelles Zeitdokument – und genau darin liegt sein bleibender Reiz.

Verfügbar für:
Commodore 64, ZX Spectrum, MSX, Amstrad CPC, Apple II, Apple IIgs, Amiga, Atari ST, Atari 2600, Atari Lynx, Sega Master System, NES, Mega Drive/Genesis, DOS, Windows, Wii, J2ME, Antstream

Kategorie-Archiv: Software

Lunar Lander (1969–1979): Vom PDP-8 zur Atari-Arcade

Adventureland (1978) – Der Moment, in dem Abenteuer nach Hause kamen

Vom QDOS zu MS-DOS: Wie ein improvisiertes Betriebssystem zur Grundlage der PC-Ära wurde

688 Attack Sub (1989): U-Boot-Simulation im Kalten Krieg

688 Attack Sub

F-29 Retaliator (1989) – Amiga-Flugsimulation zwischen Action und Anspruch

f29

Super Cars 2 – 1990 by Magnetic Fields / Gremlin Graphics

Super Cars 2

Crystal Raider (1986) – Mastertronics kompromissloses Logik-Plattformspiel für Atari 8-Bit

Bombuzal (1989) – 250 Level Puzzleklassiker | MansionManiax

Spy Hunter (1983) – Straßenkrieg, Agentenfantasie und das Arcade-Gefühl der Kontrolle

Spy Hunter

California Games (1987) – Epyx und das kalifornische Lebensgefühl auf Diskette

California Games

California Games Intro C64