Kategorie-Archiv: Software

Hier befinden sich unsere vorgestellten Programme

Test Drive (1987): Als Ferrari und Lamborghini noch aus Autoquartettkarten kamen

1987 war die Welt der Supersportwagen für die meisten Jugendlichen ein ferner Traum aus Hochglanzprospekten, Autoquartettkarten und gelegentlichen Fernsehberichten über Reiche, die Dinge fuhren, deren Namen allein schon exotisch klangen. Ein Ferrari Testarossa, ein Lamborghini Countach oder ein Porsche 911 Turbo waren keine Fahrzeuge, die man im Alltag sah – sie waren Statussymbole einer anderen Welt, technische Fabelwesen auf Rädern, deren Leistungsdaten man auswendig lernte, obwohl man sie vermutlich nie aus der Nähe erleben würde. Auf Schulhöfen wurden Quartettkarten verglichen, diskutiert und verteidigt wie mittelalterliche Wappen; 309 km/h schlugen 290 km/h, zwölf Zylinder galten automatisch als besser als acht, und wer einen Countach in der Hand hielt, hatte ohnehin gewonnen.

Genau in dieses Spannungsfeld platzierte Test Drive seine Prämisse. Während andere Rennspiele den Spieler in generische Fantasiewagen oder auf abstrakte Rundkurse setzten, versprach Accolades Titel etwas deutlich Reizvolleres: Nicht bloß ein Rennen, sondern die Illusion, tatsächlich hinter dem Steuer jener automobilen Traumwagen zu sitzen, die man bislang nur aus Zeitschriften und Quartettkästen kannte. Plötzlich blickte man nicht mehr von außen auf einen Sprite, sondern durch ein Cockpit auf kurvige Bergstraßen, drehte den virtuellen Zündschlüssel und hörte einen digitalen Motor aufheulen, der wenigstens ein kleines bisschen nach Reichtum klang.

Als das Spiel 1987 für C64, den Apple II, MS-DOS, Atari ST und Amiga erschien, traf es damit einen Nerv. Denn Test Drive war nicht einfach nur ein weiteres Rennspiel – es war für viele Spieler die erste digitale Probefahrt in einer Welt, die bis dahin ausschließlich aus Fantasie bestanden hatte.

Entwickelt wurde Test Drive vom kanadischen Studio Distinctive Software, das Mitte der 1980er-Jahre zu den wichtigsten externen Partnern des US-Publishers Accolade zählte. Das von Donald A. Mattrick mitgegründete Studio hatte sich zunächst mit Portierungen und kleineren Auftragsarbeiten einen Namen gemacht, erhielt von Accolade jedoch zunehmend Freiheiten für eigene Projekte. Test Drive wurde zu jenem Titel, der Distinctive endgültig als kreativen Prestige-Entwickler etablierte und den Grundstein für weitere Rennspielproduktionen wie Grand Prix Circuit und Test Drive II legte.

Anstatt sich am üblichen Arcade-Muster zu orientieren und den Spieler über geschlossene Rundkurse zu schicken, verfolgte Distinctive einen deutlich atmosphärischeren Ansatz: Test Drive sollte das Gefühl vermitteln, einen exotischen Sportwagen tatsächlich im öffentlichen Straßenverkehr zu bewegen – schnell, riskant und mit dem latent schlechten Gewissen, dass die nächste Radarfalle bereits hinter der nächsten Kurve lauern könnte. Die Idee verschob den Fokus weg vom sportlichen Wettbewerb und hin zur Inszenierung des Fahrgefühls selbst.

Dass hinter dieser Herangehensweise echte Automobilbegeisterung stand, erscheint naheliegend. Donald Mattrick galt bereits in jungen Jahren als ausgesprochener Sportwagen-Enthusiast, und die Liebe zum Detail, mit der Test Drive seine Fahrzeuge inszenierte, spricht Bände. Jeder Wagen erhielt ein eigenes Cockpit mit individuell angeordneten Instrumenten, spezifischer Leistungsentfaltung und eigener Charakteristik. Die im Spiel dargestellten Beschleunigungs- und Höchstgeschwindigkeitswerte orientierten sich sichtbar an realen Vorbildern und verliehen jedem Fahrzeug ein eigenes Fahrprofil – soweit dies die damalige Hardware überhaupt zuließ.

Schon das Handbuch unterstrich diese Ausrichtung und inszenierte das Szenario als automobile Wunschfantasie: Der Spieler habe soeben seine erste Million verdient, betrete ein Luxus-Autohaus und dürfe nun endlich einen der „exotischsten Sportwagen der Welt“ Probefahren. Bereits die Fahrzeugwahl wurde somit als Erfüllung eines automobilen Lebenstraums dargestellt – ganz im Ton eines Spiels, das weniger Rennsimulation als interaktive Fantasie sein wollte.

Die anschließende Probefahrt führte über eine kurvige Bergstraße namens „The Rock“, auf der nicht nur Gegenverkehr und tückische Fahrbahnverhältnisse warteten, sondern auch Radarfallen und Highway Patrol. Wer Warnungen ignorierte oder einen Polizeiwagen rammte, wurde nicht bloß disqualifiziert, sondern – ganz im augenzwinkernden Ton des Spiels – direkt „ins Gefängnis geschickt“. Diese ungewöhnliche Mischung aus Fahrspiel, Lifestyle-Fantasie und leichter Gesetzesübertretung verlieh Test Drive bereits 1987 einen rebellischeren Charakter als den meisten Konkurrenten.

Spielerisch war Test Drive dabei weit mehr als bloß ein hübsch verpackter Grafikblender. Hinter der glamourösen Präsentation verbarg sich für 1987 ein erstaunlich anspruchsvolles Fahrspiel, das seine Fahrzeuge nicht nur optisch, sondern auch spielmechanisch differenzieren wollte. Jeder der fünf Wagen verfügte über eigene Beschleunigungswerte, unterschiedliche Endgeschwindigkeiten und ein individuelles Fahrverhalten, das zumindest innerhalb der technischen Grenzen der Zeit nachvollziehbar variierte. Der schwere Chevrolet Corvette wirkte träger und weniger agil, während Lamborghini Countach und Ferrari Testarossa aggressiver beschleunigten und nervöser reagierten – Unterschiede, die bereits zeitgenössische Tester hervorhoben.

Ungewöhnlich für das Genre war zudem der semi-simulative Ansatz bei der Fahrzeugbedienung. Test Drive verlangte vom Spieler manuelles Schalten, wobei falsches Hochschalten oder dauerhaftes Überdrehen des Motors mit Leistungsverlust oder Defekt quittiert werden konnte. Schlaglöcher, Ölflecken und Wasser auf der Fahrbahn beeinflussten zusätzlich das Fahrverhalten, während Gegenverkehr und enge Kurven präzise Lenkarbeit erforderten. Geschwindigkeit allein genügte dabei nicht: Ein auf der Sonnenblende montierter Radarwarner meldete Polizeikontrollen, und wer dauerhaft Vollgas gab, riskierte eine Verfolgung durch die Highway Patrol. Diese zusätzliche Spannungsebene hob das Spiel deutlich von Rundkurs-Racern wie Pole Position oder Arcade-Rasern wie Out Run ab.

Technisch beeindruckte insbesondere die Cockpitdarstellung. Statt den Wagen von außen zu zeigen, platzierte Test Drive den Spieler konsequent hinter das Lenkrad und spendierte jedem Fahrzeug ein eigenes, individuell gestaltetes Dashboard. Tachometer, Drehzahlmesser und Instrumente unterschieden sich sichtbar von Modell zu Modell und orientierten sich an realen Vorbildern – ein Detailgrad, der 1987 alles andere als selbstverständlich war. Zusammen mit den vorgelagerten Fahrzeugprofilen samt technischen Datenblättern wirkte das Spiel dadurch fast wie ein interaktiver digitaler Autokatalog für Spieler, die sich an solchen Informationen kaum sattsehen konnten.

Trotz aller technischen Ambitionen blieb der Umfang allerdings überschaubar. Gefahren wurde ausschließlich auf einer einzigen Strecke, deren fünf Abschnitte sich zwar durch steigende Schwierigkeit unterschieden, visuell jedoch kaum variierten.

Die zeitgenössische Presse reagierte entsprechend fasziniert, wenn auch nicht uneingeschränkt euphorisch. Nahezu alle Magazine waren sich einig, dass Test Drive 1987 etwas bot, das man in dieser Form kaum zuvor gesehen hatte: die glaubhafte Inszenierung einer automobilen Wunschfantasie. Besonders gelobt wurden die Cockpitperspektive, die detaillierten Fahrzeugdarstellungen und das allgemeine Fahrgefühl. Das britische Magazin ACE sprach von „sheer driveability“ und empfahl, sich schlicht „in das Leder sinken zu lassen“ und die Fahrbarkeit des Spiels zu genießen – ein Satz, der hervorragend illustriert, wie sehr Test Drive als luxuriöses Fahrerlebnis und nicht bloß als Rennspiel wahrgenommen wurde.

Auch internationale Magazine zeigten sich beeindruckt. Computer Gaming World lobte die „outstanding graphics“ und bescheinigte dem Titel das Potenzial, jeden Pole-Position-Fan zu begeistern, während Dragon Magazine stolze viereinhalb von fünf Sternen vergab. In Frankreich erreichte das Spiel bei Génération 4 sogar eine Wertung von 91 Prozent – ein ausgesprochen starker Wert für ein Rennspiel jener Zeit.

Gleichzeitig benannten viele Tester jedoch auch die Grenzen des Konzepts. The Games Machine kritisierte die geringe Langzeitmotivation und monierte, dass schlicht „nicht genug zu tun“ sei, sobald der erste technische Wow-Effekt verflogen war. Noch schärfer fiel die Analyse des britischen Motorjournalisten David Vivian in Amiga Computing aus, der das Spiel in einem ungewöhnlich ausführlichen Vergleich mit realen Supersportwagen prüfte. Zwar lobte er die sorgfältige Recherche und attestierte dem Spiel eine glaubhafte automobile Atmosphäre, urteilte letztlich jedoch: „A great idea, well researched. But lacks programming sparkle and substance.“

Gerade diese Kritik erwies sich rückblickend als bemerkenswert treffend. Denn so visionär Test Drive als Konzept war, so überschaubar blieb sein tatsächlicher Umfang. Die einzige Bergstrecke, die geringe Zahl spielerischer Variationen und das Fehlen weiterer Modi oder Gegner sorgten dafür, dass der Titel für viele Spieler eher eine intensive Kurzzeitfaszination als ein langfristiger Dauerbrenner war.

Dem kommerziellen Erfolg schadete dies allerdings kaum. Test Drive überschritt zunächst die Marke von 100.000 verkauften Exemplaren und erhielt dafür den Gold Award der American Software Publishers Association; spätere Branchenberichte sprachen bis Ende 1989 von mindestens 250.000 bis über 400.000 verkauften Einheiten. Damit avancierte das Spiel zu einem der erfolgreichsten Computer-Racer seiner Ära und etablierte sich endgültig als Accolades neue Prestige-Marke.

Auch preislich positionierte sich Test Drive klar als Premiumprodukt seiner Zeit. In den USA lag der Einführungspreis je nach Plattform meist bei rund 39,95 bis 49,95 US-Dollar, während die Heimcomputerfassungen im deutschsprachigen Raum häufig zwischen 79 und 99 DM gehandelt wurden – ein Betrag, der inflationsbereinigt heute grob einer Größenordnung von etwa 70 bis 100 Euro entspricht. Damit bewegte sich der Titel im oberen Segment des damaligen Softwaremarktes und unterstrich bereits über seinen Preis den Anspruch, kein gewöhnliches Budget-Rennspiel, sondern ein Prestigeprodukt für technikbegeisterte Autofans zu sein.

Auf dem Markt traf Test Drive dabei auf durchaus namhafte Konkurrenz, unterschied sich von dieser jedoch erheblich in seiner Ausrichtung. Segas Out Run dominierte 1986/87 weiterhin die Arcade-Hallen und setzte auf spektakuläre Geschwindigkeit, farbenfrohe Grafik und unmittelbaren Spielspaß, blieb spielerisch jedoch klar im Arcade-Lager. Titel wie Pole Position II oder diverse Formel-1-Umsetzungen wiederum orientierten sich stärker am klassischen Motorsportgedanken und boten Rundkurse statt Straßenverkehr. Test Drive besetzte damit eine Nische, die zu diesem Zeitpunkt kaum ein anderer Titel bediente: Es verkaufte keine Rennserie, keine Meisterschaft und kein Arcade-Spektakel, sondern den Traum einer illegal schnellen Spritztour im eigenen Supersportwagen.

Gerade diese Positionierung erwies sich als entscheidender Erfolgsfaktor. Wo andere Rennspiele den Wettbewerb in den Mittelpunkt stellten, verkaufte Test Drive ein Lebensgefühl – und traf damit exakt den Nerv einer Zielgruppe, die sich zwar keinen Ferrari leisten konnte, wohl aber einen Heimcomputer.

Rückblickend definierte Test Drive mehrere Grundelemente, die später zum Standard moderner Straßenrennspiele werden sollten: exotische Serienfahrzeuge, Cockpitperspektive, offene Straßen statt Rundkurse, Polizeidruck und eine stärker emotionale als motorsportliche Inszenierung. Als Distinctive Software 1991 von Electronic Arts übernommen wurde und Jahre später an The Need for Speed arbeitete, fanden sich viele dieser Ideen in technisch und spielerisch weiterentwickelter Form erneut wieder.

Auch innerhalb seiner eigenen Reihe legte der Titel den Grundstein für eines der langlebigsten Rennspiel-Franchises der Branche. Bereits 1989 folgte mit Test Drive II: The Duel ein deutlich ausgebauter Nachfolger, der das Grundkonzept um Gegnerfahrzeuge, mehrere Strecken und spätere Datadisks erweiterte. Über zahlreiche Iterationen hinweg sollte sich die Marke bis weit in die 2000er und darüber hinaus halten – ein bemerkenswerter Nachhall für ein Spiel, das ursprünglich lediglich die digitale Fantasie einer Spritztour im Supersportwagen erfüllen wollte.

So bleibt Test Drive heute vor allem als Meilenstein einer Übergangsphase in Erinnerung: als Titel, der Rennspiele aus der reinen Arcade-Ecke herausführte, ohne bereits echte Simulation zu sein; als Spiel, das mehr Atmosphäre als Umfang bot, aber damit einen Nerv traf; und als digitales Versprechen an eine Generation von Spielern, die Ferrari, Lamborghini und Porsche bis dahin meist nur aus Autoquartettkarten, Kinderzimmerpostern und den Träumen ihrer Jugend kannten.

 

 

West Bank (1985): Gremlins Western-Reaktionsspiel mit spanischen Wurzeln

Es gab eine Zeit, in der britische Heimcomputer-Spieler glaubten, die besten Spiele kämen zwangsläufig aus Sheffield, Liverpool oder London. Studios wie Ultimate Play the Game, Ocean Software oder eben Gremlin Graphics dominierten Mitte der 1980er das öffentliche Bild der europäischen Softwarelandschaft – doch während Großbritannien seine Heimcomputerstars feierte, entstand auf dem Kontinent längst eine zweite kreative Hochburg. Vor allem in Spanien entwickelte sich mit Studios wie Dinamic Software eine eigene, technisch ambitionierte und oft gnadenlos schwere Spieleszene, die später als „Goldene Ära spanischer Software“ in die Geschichte eingehen sollte. West Bank war eines jener Spiele, mit denen diese Entwicklung erstmals sichtbar über Spaniens Grenzen hinausstrahlte: ein hektischer Arcade-Shooter aus Madrid, veröffentlicht über Gremlin Graphics im Vereinigten Königreich und damit zugleich Spielhallen-Umsetzung, Lizenzprodukt und frühes Beispiel für die zunehmende Internationalisierung der europäischen Heimcomputerbranche.

Ursprünglich entstand West Bank bei Dinamic Software als spanische Heimcomputer-Adaption des Arcade-Erfolgs Bank Panic von Sega aus dem Jahr 1984 – klar erkennbar inspiriert von dessen Grundkonzept, jedoch mit eigenem Western-Setting, neuen Figuren und kleineren spielmechanischen Anpassungen versehen. Solche engen Genre- und Designanleihen waren in Europas 8-Bit-Markt jener Jahre keineswegs ungewöhnlich. Gremlin erkannte das Potential des Spiels früh, sicherte sich die Vertriebsrechte für den britischen Markt und veröffentlichte den Titel dort unter eigenem Label – ein Vorgehen, das exemplarisch für die damalige Zusammenarbeit britischer Publisher mit spanischen Studios stand.

Die Ursprungsfassung für den ZX Spectrum wurde von Álvaro Mateos bei Dinamic Software programmiert, einem der frühen Hausentwickler des Studios, der an mehreren prägenden Titeln der spanischen 8-Bit-Ära beteiligt war. Die markante Verpackungsillustration stammte vom legendären spanischen Künstler Alfonso Azpiri, dessen Airbrush-artige Covergemälde heute untrennbar mit der spanischen Heimcomputerszene verbunden sind und zahlreichen Dinamic-Veröffentlichungen ihren ikonischen Look verliehen. Für die Amstrad-CPC-Version adaptierte Dinamics internes Team die Spectrum-Fassung; die Ladegrafik wurde von Ignacio Ruiz Tejedor („Snatcho“) gestaltet.

Die Commodore-64-Version entstand hingegen nicht als bloße Portierung der spanischen Vorlage, sondern offenbar als eigenständige Parallelentwicklung mit ungewöhnlicher Vorgeschichte. Hauptverantwortlich war Richard J. Gibbs, dessen Autorenschaft heute durch mehrere Fachquellen und Entwicklerrekonstruktionen gut belegt ist. Besonders interessant: Gibbs arbeitete ursprünglich offenbar an einer direkten Heimcomputer-Umsetzung des Sega-Automaten Bank Panic für den britischen Publisher Elite Systems. Als daraus jedoch keine offizielle Veröffentlichung entstand, gelangte der bereits entwickelte Code mutmaßlich über Umwege zu Gremlin, wo er mit Dinamics West Bank-Lizenz zusammengeführt und schließlich als Commodore-64-Fassung des Spiels veröffentlicht wurde. Diese ungewöhnliche Entstehungsgeschichte erklärt, warum sich die C64-Version in mehreren Details vom spanischen Original unterscheidet und eher wie eine eigenständige Interpretation des Grundkonzepts wirkt als wie eine klassische Portierung. Für die musikalische Untermalung zeichnete Fred Gray verantwortlich, einer der profiliertesten SID-Komponisten seiner Epoche, später unter anderem bekannt für Arbeiten an Bionic Commando, The Last Ninja 2 und Hunter’s Moon.

Spielerisch gehört West Bank zu jener Sorte Titel, deren Konzept in wenigen Sekunden verstanden ist, deren Meisterung aber erheblich länger dauert. Der Spieler übernimmt die Rolle eines Bankwächters im Wilden Westen und muss zwölf Banktüren überwachen, von denen stets drei gleichzeitig sichtbar sind. Hinter jeder Tür kann sich ein harmloser Kunde, ein bewaffneter Bandit oder einer der Spezialgegner des Spiels verbergen. Aufgabe ist es, sämtliche zwölf Türen eines Tages erfolgreich „abzufertigen“, indem an jeder Position mindestens ein Kunde Geld einzahlt. Wer versehentlich Unschuldige erschießt, verliert ebenso ein Leben wie beim zu langsamen Reagieren auf Banditen.

Zusätzliche Würze erhielt das Konzept durch mehrere Gegnertypen mit unterschiedlichen Verhaltensmustern. Manche Revolverhelden durften erst erschossen werden, nachdem sie ihre Waffe sichtbar gezogen hatten – ein klassisches Western-Duell im Mikroformat. Andere Gegner mussten hingegen sofort eliminiert werden, noch bevor sie selbst feuern konnten. Besonders erinnerungswürdig war der kleine Zwerg „Bowie“, dessen gestapelter Hutturm zunächst wie eine skurrile Bonusfigur wirkte: Schoss man seine Hüte nacheinander herunter, verbarg sich darunter entweder ein Geldsack oder – zur wenig subtilen Bestrafung übermotivierter Spieler – eine Bombe. Zwischen den normalen Spielrunden traten zusätzlich schnelle Revolverduelle gegen mehrere Outlaws an, die bei Erfolg Bonusleben einbrachten und das Tempo weiter verschärften.

Weniger offensichtlich, aber spielmechanisch relevant war zudem die Progressionsstruktur: Eine vollständige Partie war in mehrere aufeinanderfolgende Tagesabschnitte gegliedert, deren spätere Phasen deutlich aggressiver wurden und den Spieler mit immer kürzeren Reaktionsfenstern konfrontierten. Dadurch erhielt das ansonsten klar auf Highscore ausgelegte Reaktionsspiel eine zusätzliche Ausdauerkomponente – wer hohe Wertungen erreichen wollte, musste nicht nur schnell, sondern über längere Zeit hochkonzentriert bleiben.

Gerade diese Mischung aus Reaktionsspiel, Mustererkennung und permanentem Entscheidungsdruck machte West Bank zu weit mehr als einem simplen Schießbudenspiel. Der Spieler musste nicht nur schnell sein, sondern binnen Sekundenbruchteilen Charaktermodelle erkennen, deren Verhalten einschätzen und entsprechend reagieren. Mit zunehmendem Spielfortschritt verkürzten sich die Reaktionsfenster drastisch, sodass spätere Runden beinahe nur noch instinktiv spielbar waren – ein Umstand, den zeitgenössische Magazine ausdrücklich hervorhoben.

Technisch unterschieden sich die einzelnen Fassungen durchaus spürbar, obwohl das grundlegende Spielprinzip überall identisch blieb. Die ZX-Spectrum-Version präsentierte sich kontrastreich und scharf gezeichnet, litt jedoch naturgemäß unter dem bekannten Attribute Clash, spielte sich dafür aber ausgesprochen direkt und schnell. Viele Retro-Fans betrachten sie bis heute als spielerisch „reinste“ Fassung, da ihre Geschwindigkeit und unmittelbare Steuerung das kompromisslose Reaktionsprinzip besonders gut transportieren.

Die Commodore-64-Version punktete im Gegenzug mit der insgesamt rundesten Präsentation. Dank Hardware-Sprites wirkten Animationen flüssiger, Figuren sauberer abgegrenzt und das gesamte Spielgeschehen optisch geschmeidiger. Hinzu kam Fred Grays markante musikalische Untermalung, die der C64-Fassung eine deutlich präsentere akustische Identität verlieh als vielen Konkurrenzversionen. Dass sich die C64-Version spielerisch und technisch leicht vom spanischen Original emanzipiert, überrascht rückblickend kaum – sie basierte offenbar nicht direkt auf Dinamics Quellcode, sondern auf einer separaten britischen Entwicklung.

Auf dem Amstrad CPC spielte West Bank seine typische Farbstärke aus und präsentierte sich in einer auffällig bunten, teils fast arcade-artigen Farbgebung, die manche Spieler bis heute als optisch attraktivste Version betrachten. Wie bei vielen CPC-Umsetzungen jener Jahre musste diese Farbpracht jedoch mit leicht geringerer Geschwindigkeit erkauft werden, wodurch das Spiel minimal träger wirkte als auf dem Spectrum. Die MSX-Fassung wiederum orientierte sich weitgehend an der Spectrum-Vorlage, wirkte jedoch technisch etwas nüchterner und wird in der Rückschau meist als unspektakulärste Umsetzung betrachtet.

Preislich positionierte Gremlin das Spiel bewusst aggressiv. Während viele Vollpreistitel Mitte der 1980er noch bei rund 7,95 Pfund lagen, erschien West Bank in Teilen seines Lebenszyklus bereits für nur 4,99 Pfund im britischen Handel – ein für damalige Verhältnisse auffallend günstiger Tarif für einen prominent vermarkteten Actiontitel. Frühere Rezensionen und Anzeigen nennen je nach Ausgabe auch noch den klassischen Vollpreisbereich von 7,95 Pfund, was darauf hindeutet, dass Gremlin das Spiel später in die eigene Budget- beziehungsweise Mid-Price-Schiene überführte. Damit wurde West Bank zu einem jener Titel, die durch starke Zugänglichkeit und impulsfreundliche Preisgestaltung zusätzlich von ihrer Arcade-artigen Sofortwirkung profitierten. Ein Preis von 4,99 Pfund entspräche inflationsbereinigt heute grob etwa 18 bis 22 Euro, während 7,95 Pfund eher im Bereich von 28 bis 35 Euro lägen.

Zeitgenössische Tester reagierten auf West Bank überwiegend positiv, auch wenn die Einschätzungen je nach persönlicher Vorliebe für reine Reaktionsspiele etwas schwankten. Besonders die unmittelbare Zugänglichkeit und das hohe Suchtpotenzial wurden immer wieder hervorgehoben. Computer + Video Games vergab der C64- und Spectrum-Version eine Höchstwertung von 5/5 und lobte: „Excellent fun and excellent value. Buy it and you won't be disappointed.“ Die Redaktion hob insbesondere die konstante Spannung hervor, die aus den zufällig öffnenden Türen und der Notwendigkeit blitzschneller Entscheidungen resultiere.

Die deutschsprachige ASM zeigte sich ähnlich angetan und beschrieb das Spiel als „auf recht einfache Weise in Szene gesetzt, dennoch aber von hohem Unterhaltungswert“. Weiter hieß es, West Bank verlange „ein außergewöhnlich gutes Reaktionsvermögen“, um Freund und Feind zuverlässig unterscheiden zu können. Die Schneider/CPC-Version erhielt starke Einzelwertungen von 9/10 für Grafik, 7/10 für Sound, 7/10 für Spielidee und 10/10 für Spielmotivation.

Amtix! schrieb über die CPC-Fassung sogar: „WEST BANK is one of the most addictive games I've played for a long time.“ Besonders die hohen Spielstufen, in denen Entscheidungen nur noch instinktiv getroffen werden könnten, wurden als Kern des Langzeitreizes hervorgehoben. Weniger euphorisch, aber dennoch positiv urteilte ZZAP!64, das zwar die Präsentation und den unmittelbaren Spielspaß lobte, zugleich aber auf die begrenzte spielerische Variation hinwies – ein nachvollziehbarer Kritikpunkt bei einem bewusst reduzierten Highscore-Spiel dieser Bauart.

Rückblickend nimmt West Bank innerhalb des Gremlin-Katalogs eine interessante Sonderrolle ein. Es war weder ein prestigeträchtiges Eigengewächs wie Monty on the Run noch ein technisch revolutionärer Showcase-Titel. Seine Bedeutung liegt vielmehr darin, exemplarisch zu zeigen, wie früh Gremlin internationale Entwicklungen und externe Kreativpartnerschaften in die eigene Strategie integrierte. Die Kooperation mit Dinamic Software half, spanische Entwickler erstmals einem breiteren britischen Publikum vorzustellen, und trug damit indirekt zur europäischen Vernetzung der Heimcomputerszene bei.

Für Dinamic wiederum war West Bank ein weiterer wichtiger Schritt hinaus auf den internationalen Markt. Gemeinsam mit anderen Exporttiteln wie Abu Simbel Profanation oder Phantomas trug das Spiel dazu bei, die Wahrnehmung spanischer Software außerhalb Spaniens nachhaltig zu stärken. Rückblickend markiert West Bank damit nicht nur einen gelungenen Reflexions-Shooter, sondern auch ein frühes Symbol jener Zeit, in der Europas Heimcomputerszene begann, über nationale Grenzen hinaus zusammenzuwachsen.

Spielerisch bleibt West Bank bis heute ein Paradebeispiel für die Philosophie „eine Idee, perfekt umgesetzt“. Kein unnötiger Ballast, keine künstliche Komplexität, keine überladenen Systeme – nur ein präzise gebautes Reaktionsspiel, das binnen Sekunden verstanden ist und dennoch lange fordert. Vielleicht gehört es deshalb nicht zu den ganz großen Ikonen der Ära. Aber es ist genau jene Sorte kompakter, ehrlicher Software, die den Geist der 8-Bit-Zeit oft besser einfängt als mancher vermeintlich größere Klassiker.

Monty on the Run (1985) – Der legendäre Monty-Mole-Klassiker im Rückblick

Es war das Jahr 1985, als Großbritanniens Heimcomputerlandschaft endgültig ihre erste Reifephase erreichte. Die wilden Frühjahre der simplen Arcade-Klone und hastig zusammengeschusterten Kassettenprogramme lagen zwar erst kurze Zeit zurück, doch die Ansprüche des Publikums waren inzwischen deutlich gestiegen. Spieler wollten mehr als ein paar springende Pixel auf monochromem Hintergrund – sie verlangten Charaktere, Wiedererkennungswert, technische Raffinesse und Spiele, die sich wie echte Ereignisse anfühlten. Genau in diese Phase platzte Monty on the Run, der dritte große Auftritt des mittlerweile etablierten Maulwurfs Monty Mole, und erhob eine bereits erfolgreiche britische Plattformserie endgültig in den Rang eines Heimcomputer-Klassikers.

Die Ursprünge der Figur lagen dabei tiefer, als es ihre cartoonhafte Erscheinung zunächst vermuten ließ. Schöpfer Peter Harrap, geboren 1964 und aufgewachsen in einer vom Bergbau geprägten Familie Nordenglands, kannte das Milieu, aus dem Monty entstand, aus unmittelbarer Anschauung. Mehrere Angehörige seiner Familie arbeiteten im Bergbau, sein Vater wurde in zeitgenössischen Berichten als Mine Safety Officer beschrieben – also als Sicherheitsverantwortlicher im Bergwerksbetrieb. Der erste Teil, Wanted: Monty Mole von 1984, war deshalb weit mehr als ein gewöhnliches Jump’n’Run: Er griff die Spannungen des britischen Bergarbeiterstreiks satirisch auf und verpackte sie in ein farbenfrohes Plattformspiel, dessen politischer Subtext seinerzeit von Presse und Öffentlichkeit sofort erkannt wurde. Im Zentrum dieser Anspielungen stand Arthur Scargill, Vorsitzender der National Union of Mineworkers (NUM) und während des Streiks eine der polarisierendsten Persönlichkeiten des Landes. Für seine Anhänger war er das kompromisslose Gesicht des Arbeiterwiderstands gegen Zechenschließungen; für seine Gegner ein radikaler Agitator, dessen konfrontative Haltung den Konflikt weiter verschärfte. Gerade weil Scargill zur Symbolfigur des Streiks geworden war, eignete er sich ideal als satirischer Gegenspieler einer Reihe, die den Kohlekonflikt bewusst in cartoonhafte Überzeichnung übersetzte. Dass zeitgenössische Fernsehberichte ihn offen als Antagonisten des Spiels bezeichneten, zeigt, wie unmittelbar diese Anspielung damals verstanden wurde.

Mit Monty on the Run trat dieser politische Kern zwar in den Hintergrund, verschwand jedoch nicht vollständig. Die Handlung knüpfte an die Vorgänger an und zeigte Monty weiterhin auf der Flucht vor dem Gesetz. Sein Ziel war nun die Flucht nach Frankreich – ein in der britischen Popkultur jener Jahre häufiger humoristischer Zufluchtsort für Exil- und Fluchtwitze. Der Fokus verlagerte sich damit stärker auf spielmechanische Finesse und technische Präsentation. Wo Wanted: Monty Mole noch deutlich von seiner politischen Satire lebte, wollte Monty on the Run vor allem als ausgereiftes Plattformspiel überzeugen.

Entwickelt wurde der Titel erneut von Peter Harrap, damals gerade einmal 19 beziehungsweise 20 Jahre alt. Harrap hatte sich seinen Weg in die Branche über die legendäre Sheffielder Computershop-Szene gebahnt, insbesondere über Just Micro, jenen Laden von Gremlin-Mitgründer Ian Stewart, der in den frühen 1980ern zugleich Verkaufsfläche, sozialer Treffpunkt und informelle Programmierschule war. Hier trafen sich junge Coder, zerlegten Routinen anderer Spiele, präsentierten Demos und tauschten Techniken aus – ein Umfeld, das für viele britische Entwickler dieser Ära prägender war als jede formale Ausbildung. Harrap selbst hatte zuvor mit Modifikationen bestehender Programme auf sich aufmerksam gemacht, ehe Stewart sein Talent erkannte und ihn in Gremlins junge Entwicklercrew holte.

Technisch entstand Monty on the Run unter Bedingungen, die aus heutiger Sicht beinahe absurd wirken. Harrap programmierte auf einem ZX Spectrum 48K, also direkt auf jener Maschine, für die das Spiel primär entstand. Speicherreserven für komfortable Entwicklungsumgebungen gab es nicht; der Code musste in Teilstücken geschrieben, ausgelagert und später zusammengesetzt werden, um überhaupt testbar zu bleiben. Harrap erinnerte sich später, dass allein diese Arbeitsweise die Entwicklung massiv erschwerte. Dennoch entstand das Spiel in ungefähr drei Monaten – ein Produktionstempo, das selbst für die hektische 8-Bit-Ära bemerkenswert war.

Spielerisch baute Monty on the Run das Grundprinzip der Vorgänger erheblich aus. Zwar blieb es bei der bewährten Mischung aus Plattformpassagen, Gegnerausweichmanövern und präzisen Sprüngen, doch Layout und Mechanik wirkten nun deutlich komplexer und dichter. Besonders berüchtigt wurde das sogenannte Freedom Kit: Zu Beginn musste der Spieler fünf Gegenstände auswählen, die Monty für seine Flucht benötigte. Nur eine ganz bestimmte Kombination machte das Spiel überhaupt lösbar. Wer falsch wählte, konnte oft minutenlang weiterspielen, bevor sich herausstellte, dass der gesamte Versuch von Anfang an zum Scheitern verurteilt war. Solche Vorab-Auswahlmechaniken waren in Actionspielen jener Zeit höchst ungewöhnlich und eher aus Adventures oder Strategiespielen bekannt. Die Designentscheidung galt schon damals als ausgesprochen kompromisslos – manche würden sagen sadistisch – und trug erheblich zum legendären Ruf des Spiels als Frustmaschine bei.

Nicht minder berüchtigt wurden die zahllosen Crusher-Fallen, zerquetschenden Kolben und pixelgenauen Sprungpassagen. Harrap selbst räumte Jahrzehnte später ein, dass manche dieser Hindernisse schlicht unfair seien – als junger Entwickler habe er es damals einfach lustig gefunden, Spieler scheitern zu sehen. Diese Mischung aus jugendlichem Übermut und kompromisslosem Designgeist prägt das Spiel bis heute.

Seinen größten Kultstatus verdankt Monty on the Run jedoch der Commodore-64-Version. Obwohl Peter Harrap als Schöpfer und Hauptarchitekt des Spiels gilt, wurde diese Fassung nicht von ihm selbst umgesetzt, sondern von Micro Projects Ltd., konkret durch Jason Perkins und Anthony Clarke. Erst diese Portierung machte aus dem bereits starken Plattformspiel einen audiovisuellen Meilenstein. Verantwortlich dafür war Rob Hubbard, einer der einflussreichsten Heimcomputer-Komponisten der 1980er Jahre, dessen Soundtrack bis heute als eines der berühmtesten Stücke für den SID-Soundchip des Commodore 64 gilt. Hubbard, bereits durch Werke wie Commando und International Karate etabliert, komponierte hier ein Stück, das den C64 beim Spielstart förmlich explodieren ließ. Computer and Video Games schrieb 1985 begeistert, das Spiel „explodes into life with the best sound we have yet encountered“ und lobte den treibenden Beat, zu dem selbst Monty im Titelbildschirm mitzuwippen schien. Die Inspiration durch „Devil’s Galop“, bekannt als Titelmusik der Radioserie Dick Barton – Special Agent, ist unverkennbar, doch Hubbard formte daraus ein SID-Stück, das längst ein Eigenleben entwickelt hat.

Die C64-Version gilt deshalb gemeinhin als die prestigeträchtigste Fassung des Spiels, auch wenn dies nicht bedeutet, dass die Spectrum-Version obsolet wäre. Gerade britische Spieler, die mit der Reihe auf dem Spectrum aufgewachsen waren, sahen in dieser nach wie vor die ursprünglichste und „authentischste“ Form des Spiels. Weitere Portierungen erschienen für Amstrad CPC, Commodore 16/Plus/4 und andere Systeme, doch keine erreichte denselben Kultstatus wie die C64-Fassung.

Zeitgenössische Magazine überschlugen sich beinahe vor Lob. Computer and Video Games vergab 39 von 40 Punkten und bezeichnete den Titel als „what Jet Set Willy II should have been“ – ein bemerkenswertes Kompliment, da Jet Set Willy zu den prägendsten britischen Plattformspielen der frühen 1980er zählte. ZZap!64 vergab 90 %, warnte jedoch zugleich davor, dass der hohe Schwierigkeitsgrad nicht jedermanns Sache sei. Your Spectrum kam ebenfalls auf 90 % und hob hervor, dass die Serie mit diesem Teil noch anspruchsvoller geworden sei. Die Presse war sich damit weitgehend einig: Monty on the Run gehörte 1985 zur Spitze des britischen Plattformgenres.

Auch wirtschaftlich war der Titel ein Erfolg. Genaue Verkaufszahlen sind zwar – wie bei vielen britischen Heimcomputerspielen der Ära – nicht überliefert, doch Chartplatzierungen und breite Portierungen sprechen klar für einen erheblichen kommerziellen Erfolg. Das Spiel erreichte Spitzenplätze der britischen All-Format-Charts, also jener Verkaufslisten, in denen Heimcomputerspiele plattformübergreifend gemeinsam gewertet wurden. Bereits der Vorgänger Wanted: Monty Mole hatte laut Gremlin binnen sechs Wochen rund 20.000 Käufer gefunden. Monty on the Run dürfte diese Reichweite mindestens erreicht und wahrscheinlich übertroffen haben, wodurch der Titel Gremlin Graphics’ Stellung als eines der führenden britischen Softwarehäuser der mittleren 1980er weiter festigte.

Rückblickend markiert Monty on the Run einen jener seltenen Momente, in denen nahezu alle Elemente eines Spiels zusammenfielen: ein erfahrener, aber noch hungriger junger Designer, ein technisch versierter Portierungspartner, ein Ausnahme-Komponist auf dem Höhepunkt seiner Kreativität und ein Markt, der genau bereit war für ein solches Werk. Das Ergebnis war kein perfektes Spiel – dafür war es zu unfair, zu gnadenlos, zu sehr Kind seiner Zeit. Aber gerade diese Ecken und Kanten machen seinen Charakter aus. Monty on the Run war kein Produkt moderner Komfortdesigns, sondern ein kompromissloses Stück britischer Heimcomputer-Kultur: laut, schwierig, kreativ, technisch ehrgeizig und mit jener leicht anarchischen Haltung, die die 8-Bit-Ära in Großbritannien so unverwechselbar machte.

Jupiter Probe (1987) – MicroDeals Shooter zwischen 8-Bit-Tradition und 16-Bit-Anspruch

Es ist das Jahr 1987, und die Erwartungen an Heimcomputer haben sich spürbar verschoben. Systeme wie der Atari ST und der Amiga versprechen nicht mehr nur bessere Grafik und Klang, sondern ein neues Niveau an Spieltiefe. Genau in diesem Moment erscheint mit Jupiter Probe ein Titel, der diese Entwicklung auf eine bemerkenswert konservative Weise interpretiert – und damit sowohl typisch für seine Herkunft als auch ein wenig aus der Zeit gefallen ist.

Veröffentlicht wurde das Spiel 1987 von MicroDeal, einem britischen Softwarehaus, das sich bereits in den frühen Tagen des Atari ST einen Namen gemacht hatte. Die Programmierung übernahm Steve Bak, während Chris Kew für die Grafik verantwortlich zeichnete. Für die Musik konnte man mit Rob Hubbard einen der bekanntesten Komponisten der 8-Bit-Ära gewinnen, dessen Arbeiten zuvor vor allem auf dem Commodore 64 Maßstäbe gesetzt hatten. Seine Beteiligung verleiht dem Spiel eine gewisse Gravitas, auch wenn sie nicht darüber hinwegtäuschen kann, dass Jupiter Probe spielerisch einen deutlich traditionelleren Weg einschlägt.

Inhaltlich bleibt das Spiel seiner Zeit treu – oder besser gesagt: der Arcade-Tradition. Der Spieler steuert ein Raumschiff über die Oberfläche des Planeten Jupiter, wo sich – wissenschaftliche Genauigkeit spielte in den 1980er Jahren bekanntermaßen eine untergeordnete Rolle – eine feindliche Alienrasse niedergelassen hat, die nichts Geringeres als die Zerstörung der Erde plant. Die offizielle Aufgabe besteht darin, fotografische Daten zu sammeln, doch in der Praxis reduziert sich das Geschehen auf das, was das Genre seit Jahren definiert: Ausweichen, Schießen und das sukzessive Auflösen gegnerischer Formationen.

Gerade diese Formationen sind es, die das eigentliche Rückgrat des Spiels bilden. Gegner erscheinen nicht zufällig, sondern in klar strukturierten, wiederkehrenden Mustern, die sich mit der Zeit einprägen lassen. Unterstützt wird dieses System durch eine ungewöhnliche Sprachausgabe, die Angriffswellen ankündigt – Begriffe wie „Formation“ oder „Mutation“ geben Hinweise darauf, welche Gegner als Nächstes erscheinen. Das verleiht dem Spiel eine gewisse Vorhersehbarkeit, die erfahrene Spieler zu ihrem Vorteil nutzen können. Es handelt sich also weniger um ein reflexbasiertes Chaos als vielmehr um ein System aus Erkennen, Lernen und Reagieren.

Ergänzt wird dieses Grundprinzip durch zwei zentrale Mechaniken: die sogenannten „Ultrasonics“, die als flächendeckende Angriffe dienen, sowie temporäre Schutzschilde, die das Schiff kurzzeitig unverwundbar machen. Beide sind limitiert und werden durch das Zerstören kompletter Gegnerformationen wieder aufgefüllt. Interessant ist dabei, dass diese Fähigkeiten nicht nur als Notfallwerkzeuge fungieren, sondern an bestimmten Stellen aktiv eingesetzt werden müssen, um besonders dichte Angriffswellen zu überstehen. Das Spiel verlangt also ein gewisses Maß an Ressourcenmanagement, bleibt dabei jedoch deutlich zugänglicher als viele seiner Genrekollegen.

Technisch präsentiert sich Jupiter Probe solide, ohne in irgendeiner Form herauszuragen. Das Scrolling ist flüssig, die Steuerung präzise, und die Unterstützung von Joystick, Tastatur und sogar Maus – letzteres für einen Shooter dieser Zeit keineswegs selbstverständlich – unterstreicht den Anspruch, ein möglichst breites Publikum anzusprechen. Visuell bleibt das Spiel funktional, ohne spektakuläre Effekte oder komplexe Hintergrundebenen. Hier zeigt sich deutlich die Nähe zur 8-Bit-Ära, in der klare Strukturen wichtiger waren als visuelle Opulenz.

Eine besondere Stellung nimmt hingegen die akustische Gestaltung ein. Trotz der vergleichsweise eingeschränkten Möglichkeiten des Atari-ST-Soundchips gelingt es Rob Hubbard, dem Spiel eine musikalische Identität zu verleihen, die in mehreren zeitgenössischen Tests ausdrücklich hervorgehoben wurde. Die französische Zeitschrift Tilt schrieb:

„Une bonne musique accompagne le jeu, à laquelle s'ajoutent des bruitages bien rendus de tir et d'explosion et une synthèse vocale qui signale quels types de vaisseaux vont apparaître.“

(„Eine gute Musik begleitet das Spiel, ergänzt durch gut umgesetzte Schuss- und Explosionseffekte sowie eine Sprachausgabe, die ankündigt, welche Schiffstypen erscheinen werden.“)

Auch die deutsche Fachpresse zeigte sich zumindest teilweise wohlwollend. Die ASM (Aktueller Software Markt) vergab 80 % und stellte insbesondere den Preis in den Vordergrund:

„Genug des defätistischen Geschwätzes … Es ist der günstige und vertretbare Preis von nur etwa 47 Mark. JUPITER PROBE ist also ein Goldrunner-Derivat, welches sich zu den ‚motivationsträchtigen‘ Ballerspielen zählen darf!“

Dieser Preis von rund 47 DM entspricht heute inflationsbereinigt etwa 45 bis 50 Euro und lag damit unter vielen vergleichbaren Titeln jener Zeit. Die wirtschaftliche Strategie von MicroDeal wird hier deutlich sichtbar: kein technologisches Prestigeprojekt, sondern ein kalkulierter Titel mit überschaubarem Risiko und attraktiver Preisgestaltung.

Doch nicht alle Magazine teilten diese Einschätzung. Die Happy Computer urteilte deutlich kritischer:

„Nach Goldrunner hätte ich mir wirklich mehr von den Programmierern erwartet … spielerisch leider nur Dutzendware.“

Noch schärfer fiel das Urteil der ST Action aus:

„The game lacks many features and becomes dull and repetitive after only a few sittings. I'm afraid I would not recommend it.“

(„Dem Spiel fehlen viele Funktionen, und es wird schon nach kurzer Zeit eintönig und repetitiv. Ich würde es nicht empfehlen.“)

Diese Spannbreite der Bewertungen lässt sich vor allem durch den historischen Kontext erklären. Während Jupiter Probe ein technisch sauberes und spielmechanisch funktionierendes Produkt darstellt, bewegt es sich konzeptionell klar im Fahrwasser früherer Shooter wie Xevious oder im direkten Umfeld von MicroDeals eigenem Goldrunner. Im Vergleich zu neueren Entwicklungen wie Slap Fight oder dem kurz darauf erscheinenden Xenon wirkt es jedoch bereits zum Zeitpunkt seiner Veröffentlichung zurückhaltend, fast vorsichtig.

Genau hier liegt die eigentliche Bedeutung des Spiels. Jupiter Probe ist kein misslungenes Projekt, sondern ein Beispiel für eine Übergangsphase, in der sich die Branche noch nicht vollständig von ihren Wurzeln gelöst hatte. Es zeigt, wie Entwickler versuchten, bewährte Konzepte auf neue Hardware zu übertragen, ohne dabei zwangsläufig neue Wege zu gehen. Für einige Spieler war das ausreichend – für andere ein Zeichen dafür, dass die Zeit dieser Art von Spielen langsam zu Ende ging.

Rückblickend lässt sich daher festhalten, dass Jupiter Probe weniger durch Innovation als durch Einordnung interessant ist. Es steht an der Schnittstelle zwischen zwei Generationen von Spieldesign und macht sichtbar, wie unterschiedlich Erwartungen und Realität in dieser Phase auseinandergehen konnten. Oder, nüchtern formuliert: kein Meilenstein – aber ein ausgesprochen ehrliches Produkt seiner Zeit.

 

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

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.