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.

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.