Startseite » MS-DOS

Omnicron Conspiracy (1989): First Stars verspätetes Science-Fiction-Adventure

Manchmal erkennt man einem Spiel an, dass es aus der falschen Zeit stammt. Nicht, weil seine Ideen schlecht gewesen wären — sondern weil sich der Markt während der Entwicklung schneller verändert hat als das Projekt selbst. Omnicron Conspiracy gehört genau in diese Kategorie. Als das Science-Fiction-Adventure 1989 schließlich für IBM-PC-Kompatible, Atari ST und Amiga erschien, wirkte vieles bereits leicht aus der Zeit gefallen: kleine Spielfiguren, große Interface-Rahmen, begrenzte Farbpaletten und eine Präsentation, die sich eher an späten EGA-Adventures orientierte als an den zunehmend filmischen Produktionen der frühen 90er. Doch gerade diese merkwürdige Mischung macht das Spiel heute historisch interessant.

Denn hinter Omnicron Conspiracy verbirgt sich offenbar ein Projekt, dessen Wurzeln deutlich weiter zurückreichen als das Veröffentlichungsjahr vermuten lässt.

Entwickelt wurde das Spiel von First Star Software, einem Studio, das damals vor allem durch Boulder Dash bekannt war. Entwickelt von First Star Software, erschien das Spiel in Nordamerika über Epyx, während in Europa häufig Image Works als Publisher beziehungsweise Vertriebspartner auftrat. Das allein macht die Existenz des Projekts bereits ungewöhnlich. Statt eines Arcade- oder Puzzletitels versuchte First Star plötzlich, ein umfangreiches Science-Fiction-Adventure mit Ermittlungen, Dialogen, Actionelementen und einer vergleichsweise offenen Spielstruktur zu erschaffen. Die ursprüngliche Idee stammte von Jim Nangano, während Jesse Taylor später Design und Programmierung übernahm. Für Story und Dialoge zeichnete Sheryl Knowles verantwortlich, während Chris Ebert und Christopher Grigg Musik und Soundeffekte beisteuerten. Das Titelbild der britischen Ausgabe entstand zudem durch Peter Andrew Jones, einen der bekanntesten Science-Fiction-Illustratoren der 70er und 80er Jahre.

Besonders spannend wurde die Geschichte des Spiels jedoch erst Jahrzehnte später durch Aussagen von Jim Nangano selbst. Auf der Archivseite Games That Weren’t erklärte er rückblickend:

“I began work on the engine that would theoretically become a game—The Omnicron Conspiracy.”
(„Ich begann mit der Arbeit an der Engine, aus der theoretisch einmal ein Spiel werden sollte — The Omnicron Conspiracy.“)

Damit wird deutlich, dass zunächst offenbar weniger ein fertiges Adventure als vielmehr eine flexible Adventure-Engine entstand. Genau das erklärt heute viele Eigenheiten des Spiels. Die stark modular aufgebauten Räume, die funktionale Menüstruktur, die großen Interfacebereiche und die vergleichsweise nüchterne Präsentation wirken plötzlich weniger wie gestalterische Schwächen, sondern eher wie die Architektur eines Systems, das ursprünglich als technisches Fundament gedacht war.

Noch aufschlussreicher fällt allerdings Nanganos Einschätzung zur späteren Entwicklung aus:

“That totally destroyed the game.”
(„Das hat das Spiel komplett zerstört.“)

Gemeint waren umfangreiche Änderungen und Verzögerungen während der Produktion. Laut Nangano befand sich das Spiel ursprünglich bereits in einer deutlich früheren Entwicklungsphase, ehe zusätzliche grafische Überarbeitungen verlangt wurden. Genau hier beginnt die eigentliche Tragik von Omnicron Conspiracy. Denn zwischen Mitte der 80er und dem finalen Release veränderte sich der Adventuremarkt drastisch.

Wäre das Spiel tatsächlich bereits 1986 oder 1987 erschienen, hätte es vermutlich wesentlich moderner gewirkt. Ein Science-Fiction-Adventure mit direkter Figurensteuerung, Ermittlungsstruktur, Actionelementen, Dialogsystemen und einer vergleichsweise offenen Welt war damals noch deutlich ungewöhnlicher. 1989 jedoch hatte sich die Konkurrenz massiv weiterentwickelt. Sierra experimentierte zunehmend mit komfortableren Interfaces, Lucasfilm Games setzte stärker auf filmische Präsentation, und Spieler erwarteten auf Amiga und PC immer häufiger größere Grafiken, weichere Animationen und aufwendigere audiovisuelle Inszenierungen.

Genau dieser Konflikt prägt Omnicron Conspiracy bis heute.

Das Spiel wirkt gleichzeitig ambitioniert und altmodisch.

Die Handlung folgt Captain Ace Powers, einem interstellaren Ermittler der Star Police. Sein Partner verschwindet während Untersuchungen gegen ein galaxieumspannendes Drogensyndikat und wird kurz darauf tot aufgefunden. Von diesem Moment an entwickelt sich die Geschichte zu einer Mischung aus Science-Fiction-Noir, Space Opera und satirischer Weltraumparodie. Statt familienfreundlicher Abenteuerkost setzt das Spiel auf Drogenringe, zwielichtige Wissenschaftler, korrupte Organisationen, Unterweltkontakte und paranoide Machtspiele. Bereits das Handbuch macht klar, dass hier keine klassische Hochglanz-Space-Opera erzählt werden soll. Dort beginnt die Geschichte mit einer absurd überzeichneten Szene zwischen Ace Powers und Lotsa Hotzi auf einem Asteroidenstrand, bevor das Manual das Spiel selbst als „a devastatingly clever odyssey involving pyramids, Top 40 tunes, giant artichokes, a BIG conspiracy, and the Universe“ beschreibt. („eine verheerend clevere Odyssee voller Pyramiden, Top-40-Hits, gigantischer Artischocken, einer GROSSEN Verschwörung und des gesamten Universums“).

Gerade dieser Humor unterscheidet Omnicron Conspiracy von vielen anderen Adventures seiner Zeit. Oberflächlich erinnert das Spiel zwar an Sierra-Titel wie Space Quest, tonal verfolgt es jedoch einen deutlich eigenständigeren Ansatz. Ace Powers ist kein liebenswerter Trottel wie Roger Wilco, sondern eher ein abgekämpfter Space-Cop mit deutlichen Film-Noir-Anleihen. Unterstützt wird er von PAL, seinem „Personal Automatic Link“, einem Roboterbegleiter, dessen Name bewusst mit dem englischen Begriff „pal“ spielt. Das gesamte Spiel schwankt ständig zwischen ernst gemeinter Science-Fiction und absurder Satire.

Selbst scheinbar nebensächliche Details zeigen, wie eigenartig die Welt von Omnicron Conspiracy angelegt ist. Auf dem Planeten Cron fliegt beispielsweise eine Superman-artige Figur durch die Häuserschluchten und geht dort alltäglichen Beschäftigungen nach — kein zentrales Storyelement, keine Pointe mit großem Payoff, sondern einfach eine absurde Hintergrundidee, die das Spiel völlig selbstverständlich in seine Science-Fiction-Welt integriert. Genau solche Momente verleihen Omnicron Conspiracy bis heute eine merkwürdige Mischung aus düsterer Zukunftsvision und fast schon anarchischem 80er-Humor.

Spielerisch kombiniert Omnicron Conspiracy mehrere Genres gleichzeitig. Räume werden untersucht, Gegenstände durchsucht, Bewohner befragt und Inventargegenstände verwaltet. Gleichzeitig integriert das Spiel ungewöhnliche Systeme wie Müdigkeit, Gesundheit und Waffenmodi. Ace Powers trägt ständig seinen ALSWELL-Blaster bei sich — eine „Automatic Laser System with Energy Light Load“ genannte Waffe, die zwischen Betäubungs- und Tötungsmodus umgeschaltet werden kann. Zusätzlich muss Ace schlafen, Verletzungen behandeln und auf chemische Substanzen achten, deren Auswirkungen sich direkt auf seine Lebens- und Erschöpfungsanzeigen auswirken. Das Handbuch warnt sogar ausdrücklich: „The Universe is a dangerous place“ („Das Universum ist ein gefährlicher Ort“). An anderer Stelle fordert das Spiel den Spieler beinahe esoterisch auf: „Trust your instincts. Flow.“ („Vertraue deinen Instinkten. Lass dich treiben.“) Rückblickend wirkt das stellenweise beinahe wie ein früher Vorläufer späterer Survival- oder Rollenspielmechaniken.

Optisch zeigt sich dagegen permanent die lange Entwicklungszeit des Projekts. Besonders die Amiga-Version nutzt die Möglichkeiten der Hardware nur sehr eingeschränkt. Viele Hintergründe arbeiten mit grobem Dithering, klaren Farbflächen und vergleichsweise wenigen Farbabstufungen. Obwohl der Amiga bereits 32 Farben gleichzeitig aus einer Palette von 4096 darstellen konnte, wirkt Omnicron Conspiracy häufig wie eine direkte Übernahme eines 16-Farben-Layouts. Historisch wäre das keineswegs ungewöhnlich gewesen. Zahlreiche Studios entwickelten Ende der 80er zunächst auf dem Atari ST und portierten ihre Grafiken anschließend nahezu unverändert auf den Amiga. Gerade deshalb erinnern viele Szenen stärker an klassische Atari-ST-Adventures als an typische späte Amiga-Produktionen.

Hinzu kam ein denkbar ungünstiger Veröffentlichungszeitpunkt. Publisher Epyx befand sich Ende der 80er bereits in einer schweren wirtschaftlichen Krise. Das Unternehmen, das wenige Jahre zuvor noch mit Titeln wie California Games, Impossible Mission oder Summer Games zu den bekanntesten Namen der Heimcomputerära gehörte, verlor zunehmend den Anschluss an den sich wandelnden Markt. 1989 kämpfte Epyx bereits mit massiven finanziellen Problemen und Lizenzgeschäften, ehe Teile des Unternehmens wenig später von Atari übernommen wurden. Omnicron Conspiracy erschien damit in einer Phase, in der Epyx kaum noch die Strahlkraft und Marktpräsenz früherer Jahre besaß — ein Umstand, der vermutlich ebenfalls dazu beitrug, dass das Spiel vergleichsweise schnell im Schatten größerer Adventureproduktionen verschwand.

Die zeitgenössische Presse reagierte entsprechend unterschiedlich. Die deutsche ASM lobte Atmosphäre, Handlung und die humorvollen Texte, stellte aber gleichzeitig fest: „THE OMNICRON CONSPIRACY gehört ganz gewiß nicht zu den bahnbrechenden Errungenschaften im Bereich Adventure.“ Der Amiga Joker reagierte deutlich härter und sprach bereits im Einstieg von einer „herben Enttäuschung“. Kritisiert wurden monotone Hintergründe, winzige Sichtfenster und die umständliche Menüführung. Die britische CU Amiga bewertete das Spiel dagegen wesentlich positiver und hob insbesondere Atmosphäre, Humor und Spielgefühl hervor. Gerade diese unterschiedlichen Reaktionen zeigen rückblickend sehr gut, woran Omnicron Conspiracy letztlich scheiterte: technisch wirkte es bereits konservativ, atmosphärisch und tonal dagegen häufig erstaunlich modern.

Preislich bewegte sich das Spiel damals keineswegs im Billigsegment. In den USA kosteten die DOS-, Atari-ST- und Amiga-Versionen zum Marktstart rund 39,95 US-Dollar, während britische Händler häufig etwa 24,99 bis 25,99 Pfund verlangten. Deutsche Magazine nannten je nach Zeitraum Preise zwischen etwa 84 und 120 D-Mark. Inflationsbereinigt entspricht das heute grob einer Kaufkraft von rund 80 bis 130 Euro — ein Bereich, in dem sich Omnicron Conspiracy direkt mit deutlich bekannteren Adventures seiner Zeit messen lassen musste.

Und genau darin liegt heute vermutlich seine eigentliche Bedeutung. Omnicron Conspiracy war kein großer Klassiker. Kein technischer Meilenstein. Kein Bestseller. Doch hinter seiner kantigen Oberfläche verbirgt sich möglicherweise eines der interessantesten Übergangsspiele seiner Zeit — ein Titel, dessen Design noch sichtbar aus der späten 8-Bit-Ära stammt, dessen Themenwelt aber bereits in Richtung jener düsteren Science-Fiction- und Cyberpunk-Abenteuer deutet, die wenige Jahre später deutlich populärer werden sollten.

Battle Command: Der spirituelle Nachfolger von Carrier Command (1990 by Realtime Software / Ocean)

Als Ocean Software 1990 gemeinsam mit Realtime Games Software Battle Command veröffentlichte, stand das Team vor einer heiklen Aufgabe. Nach dem Erfolg von Carrier Command erwarteten viele Spieler erneut eine komplexe Militärsimulation voller Strategie, Ressourcenverwaltung und taktischer Planung. Stattdessen rollte plötzlich der „Mauler“ auf den Bildschirm – ein futuristischer Kampfpanzer, der weniger an klassische Militärsimulationen erinnerte als an eine technische Machtdemonstration polygonaler 3D-Welten. Die deutsche Amiga Joker brachte es bereits 1990 auf den Punkt: „Nach dem Mega-Hit ‚Carrier Command‘ war es gut zwei Jahre eigenartig still um Realtime. In Wahrheit hat man aber schon emsig am Nachfolger gebastelt … Ergebnis: Die Welt hat einen neuen Klassiker!“

Realtime Games gehörte Ende der 80er zu den technisch auffälligsten britischen Entwicklerstudios. Während viele Konkurrenten noch auf Drahtgittergrafik setzten, experimentierte das Team bereits mit gefüllten Polygonflächen und weitläufigen 3D-Landschaften. Das Handbuch warb ausdrücklich damit, dass die Welt von Battle Command „in solid 3D“ dargestellt werde. Das Szenario entsprach der typischen „Near Future“-Militärästhetik jener Zeit: Seit über zehn Jahren befand sich die Welt in einem festgefahrenen Krieg zwischen Nord und Süd, große Offensiven galten als sinnlos, weshalb Spezialeinheiten und einzelne Hochleistungsfahrzeuge hinter den feindlichen Linien operierten.

Im Mittelpunkt stand der sogenannte „Mauler“, ein schwer bewaffneter Kampfpanzer, der laut Manual als „Armoured Fighting Machine capable of being fitted in and out of hostile territory by a fast Stealth Chopper“ beschrieben wurde. Bereits diese Formulierung zeigt, wie stark Battle Command zwischen realistischer Militärtechnik und fast comicartiger Zukunftsvision schwankte. Der Mauler verfügte über ein erstaunlich umfangreiches Arsenal aus infrarot- und radargelenkten Raketen, Phoenix-Luftabwehrsystemen, Dragonfly-Drahtlenkwaffen, Clusterbomben, Nachtsichtsystemen und Zielcomputern. Vor jeder Mission musste entschieden werden, welche Systeme tatsächlich mitgeführt wurden – ein taktischer Unterbau, der deutlich mehr Tiefe bot, als die reine Action-Optik zunächst vermuten ließ.

Die ASM erkannte diesen Hybridcharakter früh und schrieb 1991: „Ich habe lange mit mir gerungen, in welche Rubrik dieses Game, BATTLE COMMAND, eingeteilt werden soll.“ Wenige Absätze später folgte die treffende Zusammenfassung: „BATTLE COMMAND – gelungene Mischung aus Action und Simulation!“ Gleichzeitig kritisierte das Magazin, dass der Mauler unrealistisch viele Treffer einstecken könne und das Spiel dadurch stärker Richtung Action tendiere.

Genau darüber diskutierte damals praktisch die gesamte Fachpresse. Die Power Play bezeichnete Battle Command als „3D-Actionspiel“, das an Battlezone erinnere, lobte aber zugleich „die gelungene Kombination aus einfacher Handhabung und anspruchsvoller Gestaltung bei viel Spieltiefe“. Die Steuerung spielte dabei eine zentrale Rolle. Neben Radar, Schadenskontrolle und Zielsystemen bot der Mauler verschiedene Kameraansichten und taktische Anzeigen. Die Amiga Joker schwärmte von „Schwenkkontrollen, Zoomfunktionen – einfach alles, was das Herz begehrt.“

Die Versionen für Commodore Amiga und Atari ST galten als Lead-Systeme und boten die flüssigsten Polygonwelten. Besonders der Amiga profitierte von atmosphärischerem Sound und farbkräftigerer Darstellung. Die CU Amiga beschrieb Battle Command treffend als „fast, thinking man’s shoot ’em up“ („ein schnelles Shoot’em-up für Spieler, die mitdenken“).

Eine technische Kuriosität stellte dagegen die Cartridge-Version für den Commodore 64 dar. Anfang der 90er galten Steckmodule auf dem C64 bereits beinahe als Relikt früherer Jahre, doch Ocean nutzte das Format bewusst, um die Polygonengine schneller laden zu können. Commodore Power sprach von „real joystick-wrenching fun“, während Commodore Format den Titel als „extrem ambitionierten 3D-Blaster“ bezeichnete.

Besonders bemerkenswert blieb jedoch die Umsetzung für den Sinclair Research ZX Spectrum. Obwohl das System Anfang der 90er technisch längst als überholt galt, gelang Realtime Games eine erstaunlich flüssige Polygon-Darstellung. CRASH verlieh der Spectrum-Version das begehrte „Crash Smash“-Siegel und vergab 94 %, während Your Sinclair vor allem die Geschwindigkeit der Grafik hervorhob. Auch der Amstrad CPC erhielt eine eigene Umsetzung. Zwar wirkten die Landschaften dort gröber und reduzierter als auf den 16-Bit-Systemen, dennoch gelang es Realtime Games, den Eindruck schneller polygonaler Gefechte erstaunlich überzeugend auf die 8-Bit-Hardware zu übertragen.

Die PC-Version wiederum profitierte massiv von schnellerer Hardware. Die PC Joker bemerkte 1992: „auf einem Standard 286er ist der Mauler flott, auf einem 386er rast er förmlich dahin“. Gleichzeitig kritisierte das Magazin jedoch die schwachen Soundeffekte mit den Worten: „Was immer drinsteckt, Musik ist es nicht – und nur reichlich blecherne Effekte.“ Generell schwankten die Reaktionen der Presse zwischen Technikbegeisterung und Kritik an teilweise unfairen Missionen oder unübersichtlichen Gefechten.

Auch wirtschaftlich spiegelte Battle Command die Übergangszeit der frühen 90er wider. Die Vollpreisversionen für Amiga und Atari ST kosteten rund £24.95 beziehungsweise etwa 80 bis 90 DM in Deutschland, während ZX-Spectrum- und C64-Versionen günstiger auf Kassette oder Modul erschienen. Einige Jahre später wanderte das Spiel in Oceans Budgetreihe The Hit Squad und erschien zusätzlich in Compilations wie Wheels of Fire zusammen mit Titeln wie Hard Drivin' oder Chase H.Q. II. Damit positionierte Ocean Battle Command letztlich weniger als trockene Simulation, sondern vielmehr als spektakulären polygonalen Fahrzeug-Actiontitel.

Rocket Ranger – Ein Held, ein Raketenrucksack und ein Handbuch, das mit dem Tod droht

Was wäre, wenn der Zweite Weltkrieg nicht so ausgegangen wäre, wie wir ihn kennen? Wenn nicht Befreiung und Wiederaufbau folgten, sondern eine Welt, in der ein technologisch überlegener Gegner den Verlauf der Geschichte dauerhaft verändert hätte? Solche „What if“-Szenarien sind heute fest im kulturellen Gedächtnis verankert, doch bereits Ende der 1980er Jahre griff ein Studio diese Idee auf, das für seine besondere Verbindung aus Spiel und Inszenierung bekannt war: Cinemaware. Mit Rocket Ranger entstand 1988 ein Titel, der weniger wie ein klassisches Spiel wirkte, sondern eher wie ein interaktiver Abenteuerfilm – mit all seinen Stärken und Eigenheiten.

Die Handlung setzt im Jahr 1940 an, allerdings in einer alternativen Realität. Der Spieler übernimmt die Rolle eines amerikanischen Agenten, der mit einer außergewöhnlichen Situation konfrontiert wird: Wissenschaftler aus der Zukunft senden ihm einen Raketenrucksack und eine Strahlenwaffe, um den drohenden Sieg der Achsenmächte zu verhindern. Entscheidend ist dabei die Perspektive – man spielt keinen Zeitreisenden, sondern einen Mann seiner Zeit, der plötzlich Zugang zu Technologie erhält, die weit über das hinausgeht, was 1940 möglich wäre. Diese Prämisse verleiht dem Spiel eine eigene Dynamik und unterscheidet es klar von späteren Zeitreise-Erzählungen.

Spielerisch verbindet Rocket Ranger mehrere Ebenen. Auf einer strategischen Weltkarte werden Missionen geplant, Agenten eingesetzt und Ressourcen – insbesondere das seltene Lunarium – verwaltet. Diese strategische Komponente wird immer wieder durch actionreiche Sequenzen unterbrochen: Luftkämpfe gegen feindliche Jäger, Infiltrationen feindlicher Basen, Faustkämpfe oder das spektakuläre Starten des Raketenrucksacks. Gerade diese Mischung machte das Spiel reizvoll, aber auch fordernd. Viele Spieler scheiterten zunächst nicht an der Schwierigkeit, sondern daran, überhaupt zu verstehen, wie man eine Mission korrekt initiiert – ein Umstand, der dem Spiel bis heute einen gewissen Ruf der „Eigenwilligkeit“ eingebracht hat.

Technisch wurde das Spiel primär für den Commodore Amiga entwickelt und nutzt dessen Fähigkeiten konsequent aus. Die Kombination aus 16-Bit-CPU, Custom-Chips und Mehrkanal-Sound ermöglichte eine Präsentation, die sich stark an filmischen Vorbildern orientierte. Zwischensequenzen, Kamerafahrten und musikalische Untermalung erzeugten eine Atmosphäre, die sich deutlich von typischen Action- oder Strategiespielen abhob.

Erst im Vergleich der zahlreichen Umsetzungen wird jedoch deutlich, wie unterschiedlich sich dieses Konzept je nach Plattform entfaltet. Die Amiga-Version gilt als Referenz, da sie die visuelle und akustische Vision von Cinemaware am vollständigsten umsetzt. Die Umsetzung für den Atari ST wirkt im direkten Vergleich reduzierter, insbesondere durch die eingeschränkte Farbpalette, während frühe MS-DOS-Versionen zwar schärfere Darstellungen ermöglichen konnten, aber klanglich deutlich hinter dem Amiga zurückblieben.

Die Version für den Commodore 64 hingegen ist ein bemerkenswertes Beispiel technischer Anpassung. Ein ursprünglich für 16-Bit-Systeme konzipiertes Spiel wurde hier auf eine deutlich schwächere Hardware übertragen – mit sichtbaren Kompromissen, aber erstaunlicher Nähe zum Original. ZZAP!64 formulierte es treffend:

“The graphics, the sound, the presentation… just pushes the 64 right to the limit of its capabilities.”
(„Grafik, Sound und Präsentation bringen den C64 an die absoluten Grenzen seiner Möglichkeiten.“)

Die Nintendo Entertainment System-Version geht einen anderen Weg. Sie ist stärker vereinfacht, fokussiert sich mehr auf Action und reduziert die strategischen Elemente. Gleichzeitig wurden Inhalte angepasst, um den Richtlinien des Konsolenmarktes zu entsprechen.

Eine technisch besonders interessante Variante stellt die Umsetzung für den FM Towns dar. Dieses System ermöglichte durch CD-Technologie und erweiterte Multimedia-Fähigkeiten eine deutlich verbesserte Präsentation. Farben wirken satter, Audioelemente hochwertiger, und die cineastische Inszenierung kommt dem ursprünglichen Anspruch besonders nahe – in einigen Aspekten sogar stärker als auf den ursprünglichen Zielplattformen.

Auch auf Systemen wie Apple IIgs oder späteren PC-Konfigurationen zeigt sich, wie unterschiedlich das Spiel interpretiert wurde. Rocket Ranger ist damit kein einheitliches Erlebnis, sondern ein Titel, dessen Charakter sich je nach Plattform merklich verändert.

Ein besonders spannender Aspekt zeigt sich bei den internationalen Versionen. In Deutschland wurde das Spiel deutlich entschärft. Die nationalsozialistischen Gegner wurden durch außerirdische Invasoren ersetzt, die sogenannten „Leutonians“. Diese Anpassung entstand nicht zufällig, sondern aus der damaligen Praxis der Bundesprüfstelle für jugendgefährdende Medien, die Darstellungen des Dritten Reichs kritisch prüfte. Eine Indizierung hätte massive wirtschaftliche Folgen gehabt, da betroffene Spiele praktisch nicht mehr verkauft werden konnten.

Interessant ist dabei die Umsetzung dieser Zensur: Während Texte und Bezeichnungen geändert wurden, blieben die grafischen Darstellungen weitgehend unverändert. Zeppelin-Luftschiffe, Uniformen und Jagdflugzeuge entsprachen weiterhin klar historischen Vorbildern. Dadurch entstand eine bemerkenswerte Inkonsistenz: Eine angeblich technologisch überlegene Alienrasse griff mit Technik an, die eindeutig aus den 1930er und 1940er Jahren stammte. Gerade dieser Widerspruch verleiht der zensierten Version heute eine fast unfreiwillige Eigenart.

Ein oft unterschätzter Bestandteil des Spiels ist das Handbuch, das weit über eine klassische Anleitung hinausgeht. Es fungiert als erzählerischer Rahmen und vermittelt die düstere Ausgangslage bereits vor Spielbeginn:

“One hundred years ago, in 1940, the Nazis won World War II…”
(„Vor hundert Jahren, im Jahr 1940, haben die Nazis den Zweiten Weltkrieg gewonnen…“)

Im weiteren Verlauf wird die Situation drastischer geschildert:

“We live and work as virtual prisoners…”
(„Wir leben und arbeiten als Gefangene…“)

Selbst technische Hinweise sind in diesen Ton eingebettet:

“Reichlaw… under penalty of death.”
(„…bei Androhung der Todesstrafe.“)

Und schließlich endet die Einleitung abrupt:

“The Gestapo is at the door… goodbye and good luck!”
(„Die Gestapo steht vor der Tür…“)

Diese Mischung aus Science-Fiction, schwarzem Humor und beklemmender Atmosphäre verstärkt die Wirkung des Spiels erheblich und zeigt, wie bewusst Cinemaware auch außerhalb des eigentlichen Spiels an der Inszenierung arbeitete.

Die zeitgenössische Presse reagierte entsprechend vielschichtig. Während viele Magazine die audiovisuelle Präsentation hervorhoben, wurden Gameplay und Struktur differenzierter bewertet. Computer and Video Games schrieb:

“Rocket Ranger is without doubt Cinemaware’s best game to date…”
(„Rocket Ranger ist ohne Zweifel Cinemawares bestes Spiel bis dahin…“)

fügte jedoch hinzu:

“There is a certain inevitable amount of repetition involved…”
(„Es gibt eine gewisse unvermeidliche Wiederholung…“)

Die ASM formulierte es direkter:

„Grafik und Sound sind Spitzenklasse… hinter der tollen Aufmachung verbergen sich recht normale Action- und Taktik-Spielereien.“

Und die Power Play ergänzte kritisch:

„Hat man das Spiel einmal geschafft, ist die Motivation dahin.“

Dennoch lagen die Wertungen insgesamt auf hohem Niveau: rund 95 % bei ZZAP!64, etwa 86 % bei Computer and Video Games und sogar 97 % bei Amiga User International. Diese Spannbreite zeigt deutlich, wie stark das Spiel von der Perspektive des jeweiligen Testers abhing.

Preislich bewegte sich Rocket Ranger zur Veröffentlichung im oberen Segment. In Großbritannien lag der Preis bei etwa £24,95, was inflationsbereinigt heute ungefähr 80–90 Euro entspricht. Budget-Versionen – etwa über Labels wie Kixx oder ähnliche Reihen – senkten den Preis später deutlich und trugen dazu bei, dass das Spiel eine breitere Verbreitung fand.

In der Rückschau lässt sich Rocket Ranger weniger als klassisches Spiel im engeren Sinne verstehen, sondern als ein Experiment. Cinemaware versuchte, filmische Erzählweise, strategische Elemente und actionreiche Sequenzen zu verbinden. Nicht jede dieser Komponenten greift perfekt ineinander, doch gerade diese Mischung verleiht dem Titel seinen charakteristischen Platz in der Geschichte der Heimcomputer-Ära.

Space Quest III: Wie Sierra 1989 Humor, EGA-Grafik und klassische Adventure-Tradition auf die Spitze trieb

Source: Sierra On-Line / Microsoft, CC BY-SA 4.0

Space Quest III: The Pirates of Pestulon, veröffentlicht 1989 von Sierra On-Line, markiert innerhalb der Reihe einen deutlichen Entwicklungsschritt und steht exemplarisch für eine Übergangsphase im klassischen Adventure-Design. Noch basiert das Spiel auf dem bewährten Adventure Game Interpreter, einem System, das Sierra seit den frühen 1980er Jahren für seine Adventures einsetzte.

Der Adventure Game Interpreter kombiniert eine Skriptsprache mit einer vergleichsweise einfachen Grafikengine. Figuren bewegen sich in zweidimensionalen Räumen mit begrenzter Farbpalette, während ein Textparser die Eingaben interpretiert. Diese Architektur ermöglichte eine effiziente Portierung auf verschiedene Systeme, brachte jedoch klare Einschränkungen mit sich: begrenzte Farbvielfalt, eingeschränkte Animationen und eine stark hardwareabhängige Soundausgabe. Space Quest III nutzt diese Technik sichtbar bis an ihre Grenzen aus, während mit dem späteren SCI-System bereits eine deutlich leistungsfähigere Generation in Vorbereitung war.

Die Handlung setzt unmittelbar nach den Ereignissen von Space Quest II ein. Roger Wilco, einst Hausmeister und widerwilliger Retter der Galaxis, treibt in einer Rettungskapsel durchs All, bis er von einem gigantischen Müllfrachter eingesogen wird. Dieser Einstieg setzt bewusst einen Kontrapunkt zur klassischen Heldenfortsetzung: Statt Aufstieg folgt der erneute Absturz, statt Kontrolle Improvisation. Die Reise führt über Stationen wie Monolith Burger, den Wüstenplaneten Phleebhut und schließlich den Mond Pestulon, auf dem die Softwarefirma „ScumSoft“ residiert.

Im Zentrum steht die Rettung der „Two Guys from Andromeda“ – Scott Murphy und Mark Crowe –, die sich selbstironisch in die Handlung integriert sehen. Diese Form der Selbstreferenz ist charakteristisch für die Reihe und unterscheidet sie deutlich von anderen Sierra-Produktionen wie King's Quest oder Police Quest.

Technisch zeigt sich der Fortschritt vor allem in der visuellen Präsentation. Die EGA-Grafik wird deutlich differenzierter eingesetzt, Animationen wirken flüssiger, und Hintergründe gewinnen an Detailtiefe. Diese Entwicklung wurde auch in der zeitgenössischen Presse deutlich wahrgenommen. So stellte die Happy Computer (Special 7/1989, MS-DOS/EGA) fest:

„Space Quest III ist eine runde Sache. Allein die Eingangsszene zeigt, daß sich die ‚Two Guys from Andromeda‘ viel Mühe gegeben haben.“

Auch die Detailfülle wurde hervorgehoben:

„Das Spiel ist gespickt mit witzigen Details: Da liegt die Pilotenkonsole vom Millennium Falcon aus ‚Krieg der Sterne‘…“

Parallel dazu zeigt sich jedoch bereits eine differenzierte Bewertung einzelner Aspekte. Während die Grafik mit 85 % bewertet wurde, erhielt der Sound lediglich 52 %, was die noch vorhandenen technischen Grenzen widerspiegelt.

Ähnlich argumentiert der Aktueller Software Markt, der insbesondere die visuelle Gestaltung und Atmosphäre hervorhebt:

„Die Animationen sind herrlich, die Hintergrundgrafiken detaillierter und die Figuren wirken wie in einem guten Comic.“

Im Bewertungskasten ergibt sich hier ein klares Bild: Grafik (10) und Atmosphäre (9) stehen deutlich über Sound (5/10) sowie Parser und Steuerung (6/10). Auch hier zeigt sich, dass Präsentation und Stimmung im Vordergrund stehen, während spielmechanische Aspekte differenzierter betrachtet werden.

Internationale Tests bestätigen diese Einordnung. Die britische ZZap!64 vergab für die Amiga-Version 87 % Gesamtwertung und hob insbesondere die Mischung aus Action und Humor hervor:

„Here’s a game with plenty of excitement, and humour too.“

Gleichzeitig wurde der Puzzle-Anteil mit 67 % merklich niedriger bewertet. Ein weiterer englischsprachiger Test bescheinigte dem Spiel eine sehr hohe Atmosphäre (93 %), während die Langzeitmotivation mit 56 % deutlich zurückhaltender eingeschätzt wurde. Diese Unterschiede zeigen, dass die Präsentation nahezu einhellig überzeugt, während Struktur und Spieltiefe unterschiedlich wahrgenommen wurden.

Die Musik stammt unter anderem von Bob Siebenberg, bekannt als Schlagzeuger der Band Supertramp. Seine Beteiligung steht exemplarisch für die zunehmende Professionalisierung der Branche. Die tatsächliche Klangqualität bleibt jedoch stark von der eingesetzten Hardware abhängig – von einfachen PC-Speaker-Signalen bis hin zu deutlich differenzierteren Klangbildern auf Systemen wie der Roland MT-32.

Spielerisch bleibt Space Quest III fest in der klassischen Sierra-Tradition verankert. Der Parser verlangt präzise Eingaben, und Fortschritt entsteht durch Ausprobieren und Scheitern. In dieses System integriert das Spiel mit „Astro Chicken“ ein eigenständiges Minispiel, das nicht nur als humoristische Einlage dient, sondern auch spielerisch relevant wird. Diese Erweiterung der klassischen Struktur wurde nicht von allen Spielern gleichermaßen positiv aufgenommen und kann als bewusster Bruch mit etablierten Adventure-Konventionen verstanden werden.

Auch die Plattformvielfalt trägt zur Einordnung bei. Das Spiel erschien für MS-DOS, den Amiga, den Atari ST sowie für den Apple Macintosh. Die DOS-Version bietet die größte Bandbreite an Grafik- und Soundoptionen, während Amiga- und ST-Versionen trotz leistungsfähiger Hardware eng an die EGA-Vorlage gebunden bleiben. Die Macintosh-Version zeigt eine angepasste Darstellung und Bedienlogik.

Alle Versionen wurden auf Diskette ausgeliefert, wodurch Ladezeiten ein fester Bestandteil des Spielerlebnisses sind. Erst Festplatteninstallationen konnten diesen Umstand deutlich verbessern.

In der Gesamtschau ergibt sich ein konsistentes Bild: Space Quest III wurde von der zeitgenössischen Presse vor allem für Präsentation, Humor und visuelle Gestaltung geschätzt, während Sound und Rätseldesign differenzierter bewertet wurden. Gerade diese Mischung aus technischer Weiterentwicklung und bewusst beibehaltenen Designprinzipien verleiht dem Spiel seine besondere Stellung innerhalb der Adventure-Geschichte.

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.

Fujitsu FM R-70 (1987) – Fujitsus teurer Einstieg in die 32-Bit-PC-Klasse

Fujitsu FM R-70 (hier in einer museal dokumentierten Variante der FM-R-70-Serie), Foto: IPSJ Computer Museum

Im Spätsommer 1987, als Michael Jackson mit Bad weltweit Millionen Alben verkaufte und Popkultur zunehmend von globalen Maßstäben geprägt wurde, vollzog sich in der Computerwelt ein Wandel, der weit weniger sichtbar, aber nicht minder folgenreich war. Während Musik für wenige Dollar massenhaft verbreitet wurde, bewegten sich professionelle Computersysteme in ganz anderen Dimensionen: Rechner wie der Fujitsu FM R-70 kosteten bereits bei Markteinführung Summen, die inflationsbereinigt heute im Bereich von 15.000 bis 20.000 Euro Kaufkraft liegen. Das war kein Preis für Neugier oder Unterhaltung, sondern für Infrastruktur. Entsprechend war dieses System nicht als Consumer-PC gedacht, sondern als langlebiges Arbeitsmittel für Unternehmen, Verwaltungen und technische Abteilungen, in denen der Computer längst keine Option mehr war, sondern Voraussetzung.

In diesem Umfeld stellte Fujitsu im September 1987 den FM R-70 vor. Der Rechner war kein Prestigeobjekt und kein technisches Ausrufezeichen, sondern ein nüchtern konzipiertes Arbeitsgerät. Er richtete sich an Unternehmen und Institutionen, für die Stabilität, Standardisierung und langfristige Nutzbarkeit wichtiger waren als experimentelle Neuerungen.

Fujitsu verfügte zu diesem Zeitpunkt bereits über Erfahrung mit PC-kompatiblen Systemen, hatte jedoch bislang ausschließlich 16-Bit-Rechner im Programm. Diese orientierten sich am IBM-PC-Standard, blieben technisch jedoch im Rahmen der 8086- und 80286-Generation. Eine eigene 32-Bit-Linie existierte nicht. Der FM R-70 markierte daher weniger einen Strategiewechsel als den konsequenten Schritt in die nächste Leistungsstufe.

Als Teil der FM-R-Serie war der FM R-70 auf IBM-PC/AT-Kompatibilität ausgelegt. Ziel war es, internationale MS-DOS-Software ohne Anpassungen einsetzen zu können und zugleich die für Fujitsu typischen Stärken im professionellen Umfeld zu bewahren. Innerhalb der Serie nahm der FM R-70 die Rolle des leistungsstärksten Modells seiner Zeit ein.

Herzstück des Systems war ein Intel-80386-Prozessor mit 16 MHz, der erstmals eine durchgängige 32-Bit-Architektur ermöglichte. Optional konnte ein 80387-Coprocessor ergänzt werden, was den Rechner insbesondere für technische und wissenschaftliche Anwendungen aufwertete. Damit bewegte sich der FM R-70 klar oberhalb klassischer 80286-Systeme und bot spürbare Leistungsreserven für anspruchsvolle Aufgaben.

Die Speicherausstattung fiel für die späten 1980er-Jahre großzügig aus. Standardmäßig waren 2 MB RAM verbaut, erweiterbar auf bis zu 10 MB. Als Massenspeicher diente eine interne 40-MB-Festplatte, ergänzt durch Diskettenlaufwerke nach internationalem Standard. Optische Medien wie CD-ROM spielten zu diesem Zeitpunkt noch keine Rolle und waren eher Speziallösungen vorbehalten.

Grafisch setzte Fujitsu auf ein integriertes, PC-kompatibles Grafiksystem mit 512 KB Videospeicher. Die Lösung war auf zuverlässige Text- und 2D-Darstellung ausgelegt und nicht auf Multimedia oder Spiele. Eine feste Bindung an bestimmte Grafikstandards stand dabei weniger im Vordergrund als die problemlose Ausführung gängiger Business-Software.

Auch im Audiobereich folgte der FM R-70 der damaligen Praxis professioneller PCs. Eine dedizierte Soundhardware war nicht vorgesehen; akustische Ausgabe beschränkte sich auf einfache Systemtöne. Für den vorgesehenen Einsatzbereich spielte Audio keine Rolle.

Zur Anpassung an unterschiedliche Anforderungen bot der FM R-70 interne Erweiterungssteckplätze, über die zusätzliche Schnittstellen, Controller oder Spezialkarten installiert werden konnten. Diese Erweiterbarkeit orientierte sich am PC-AT-Umfeld und erlaubte eine projektbezogene Konfiguration, ohne den Charakter des Systems zu verändern.

Während seiner Marktzeit erschien der FM R-70 in mehreren Revisionen. Fujitsu passte das Modell schrittweise an, unter anderem durch leistungsstärkere 80386-Varianten mit höheren Taktraten. Der Rechner war damit weniger als einmaliges Produkt gedacht, sondern als ausbaufähige Plattform.

Im japanischen Markt positionierte sich der FM R-70 zwischen etablierten Lösungen wie der NEC PC-98-Reihe und stärker spezialisierten Systemen wie dem Sharp X68000. Er verzichtete bewusst auf Multimedia-Ambitionen und verstand sich klar als Arbeitsgerät für den professionellen Einsatz.

Wirtschaftlich war der FM R-70 im hochpreisigen Business-Segment angesiedelt und wurde häufig als projektspezifische Komplettlösung ausgeliefert. Er richtete sich nicht an den Massenmarkt, sondern an Anwender, die in langlebige, planbare Technik investierten.

Rückblickend ist der Fujitsu FM R-70 kein ikonischer Rechner, sondern ein typischer Vertreter seiner Zeit: sachlich, leistungsfähig und auf professionelle Anforderungen zugeschnitten. Seine Bedeutung liegt weniger in spektakulären Innovationen als darin, dass er Fujitsus Einstieg in die 32-Bit-PC-Klasse markierte – als solides Übergangssystem in einer Phase, in der der PC bereits unverzichtbar war, sich seine endgültige Form jedoch noch herausbildete.

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.

Bombuzal (1989) – 250 Level Puzzleklassiker | MansionManiax

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

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

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

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

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

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

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

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

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

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

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

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

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

Rampart (1990) – Burgenbau, Belagerung und Action im Arcade-Gewand

Anfang 1993 war die Lage eigentlich klar – auch wenn ich sie lange nicht wahrhaben wollte. Ich war ein eingefleischter Amiga-Fan, einer von denen, die ihrem Rechner die Treue hielten, selbst als die Zeichen der Zeit längst unübersehbar waren. Der Amiga hatte an Boden verloren und konnte sich nicht mehr unangefochten an der Spitze halten. Mit dem Super Nintendo und dem Mega Drive saß ihm die Konsolenkonkurrenz besonders bei Jump ’n Runs und Shoot ’em Ups im Nacken, während der PC in Simulationen und vielen anderen Genres mühelos davonzog. Diese Erkenntnis setzte sich im Freundeskreis – und auch bei mir selbst – nur zähneknirschend durch.

Und doch brachte ausgerechnet diese Übergangszeit noch einmal einen jener seltenen Momente hervor, in denen technische Ranglisten plötzlich bedeutungslos wurden. Mit Rampart erschien ein Spiel, das nicht auf Grafikgewalt oder bekannte Genreformeln setzte, sondern auf eine Idee, die sofort funktionierte.

Als Rampart 1990 in den Spielhallen auftauchte, war spürbar, dass Atari Games hier einen ungewöhnlichen Weg einschlug. Während viele Arcade-Titel klaren Genre-Grenzen folgten, verband Rampart Action, Strategie und Puzzlemechanik zu einem eigenständigen Konzept. Entwickelt wurde das Spiel bei Atari Games von John Salwitz und Dave Ralston. Rampart erschien zunächst als dedizierter Automat, der bis zu drei Spieler gleichzeitig zuließ – eine seltene Konstellation, die den kompetitiven Charakter von Beginn an unterstrich. Später folgte ein Conversion-Kit für bestehende Automaten, um die Verbreitung in den Spielhallen zu erhöhen.

Das Spielprinzip ist schnell erklärt, entfaltet aber eine erstaunliche Tiefe. Jede Runde gliedert sich in zwei Phasen. In der Kampfphase steuert der Spieler ein Fadenkreuz und feuert Kanonenkugeln auf anrückende Feinde oder die Burgen der Mitspieler. Die Geschosse fliegen in einem Bogen, was vorausschauendes Zielen erfordert. Nach Ablauf der Zeit beginnt die Bauphase, in der beschädigte Mauern mit zufällig erscheinenden Mauerstücken repariert werden müssen. Diese an Tetris erinnernden Formen zwingen den Spieler, unter hohem Zeitdruck räumlich zu denken. Nur vollständig geschlossene Mauerringe sichern Burgen und Kanonen; bleibt am Ende keine ummauerte Festung übrig, ist die Partie verloren. Gerade dieses Wechselspiel aus Zerstörung und Wiederaufbau verleiht Rampart seinen unverwechselbaren Rhythmus.

Technisch basierte Rampart auf einer 68000-basierten Arcade-Plattform von Atari Games. Für Grafik und Spielablauf sorgte ein klassischer 16-Bit-Prozessor, während die Audiowiedergabe über eine zeittypische Kombination aus Yamaha-FM-Synthese und einem OKI-Sample-Chip realisiert wurde. Diese Lösung war weniger auf komplexe Musikarrangements ausgelegt, bot jedoch klare Effekte und eine gute Durchsetzungsfähigkeit im lauten Spielhallenbetrieb. Ergänzt wurde das System durch Atari-spezifische Custom-Logik, wie sie bei vielen hauseigenen Arcade-Titeln jener Zeit üblich war.

Mit dem Erfolg in den Spielhallen folgten zahlreiche Umsetzungen für Heimcomputer und Konsolen. Besonders positiv wurde die Amiga-Version aufgenommen. Die Power Play schrieb unter der Überschrift „Die Mauer bebt“: „Während Electronic Arts die PC-Fassung des Atari-Automatenklassikers umsetzte, machten sich Domarks Designspezis an die Amiga-Version. Das Grundprinzip und die grafische Aufmachung ist geblieben.“ Weiter hieß es: „Unter dem Digidonner der Geschütze zerbröselte Burgmauern werden in einer zeitlich begrenzten Feuerpause mühsam mit Tetris-artigen Klötzchen wieder geflickt.“ Die Redaktion vergab 81 %, mit 62 % für die Grafik und 73 % für den Sound.

Auch die Super-Nintendo-Version wurde von der Power Play getestet. In der Rubrik „Kanonenkellerei“ beschrieb das Magazin das Spielprinzip treffend und merkte kritisch an, dass sich Rampart auf Nintendos Konsole „nicht so grandios wie das Spielhallen-Vorbild“ spiele, insbesondere aufgrund der Steuerung und der eingeschränkten Übersicht. Dennoch erhielt die SNES-Version 75 % und eine klare Empfehlung für Mehrspielerfreunde.

Eine der bemerkenswertesten Umsetzungen erschien auf dem Commodore 64. Das Magazin 64’er vergab im November 1993 9 von 10 Punkten und schrieb: „Die Umsetzung vom Automaten in der Spielhalle auf den C 64 ist gelungen und nach kurzer Zeit kommt man kaum noch von dem auch optisch sehr gelungenen Game los.“ Gerade angesichts der begrenzten 8-Bit-Hardware wurde Rampart hier als überraschend nahe am Arcade-Vorbild wahrgenommen.

Auch auf Segas Master System wusste Rampart zu überzeugen. Die Sega Force bewertete die Umsetzung Anfang 1992 mit 80 % und stellte fest, dass die Grafik „very close to the arcade“ sei, auch wenn Farbpalette und Soundleistung naturgemäß hinter dem Automaten zurückblieben. Hervorgehoben wurde vor allem der gelungene Zwei-Spieler-Modus, in dem der strategische Kern des Spiels vollständig erhalten blieb.

Rückblickend wird Rampart häufig als Vorläufer moderner Tower-Defense-Konzepte eingeordnet. Zwar fehlen feste Verteidigungstürme im späteren Sinne, doch der Wechsel aus Angriffswellen, Reparaturphasen und begrenzten Ressourcen ist klar erkennbar. Zeitgenössische Magazine beschrieben Rampart weniger theoretisch, aber nicht minder treffend: als Spiel, das vor allem im direkten Duell seine ganze Stärke entfaltet und dessen Mischung aus Kanonenfeuer und Mauerbau ungewöhnlich lange motiviert. Dass Rampart keinen direkten Nachfolger erhielt, verstärkt im Nachhinein sogar seinen Sonderstatus.

Rückblickend wirkt Rampart wie ein stiller Abschiedsgruß aus einer Übergangszeit. Anfang der 1990er-Jahre verschoben sich die Kräfteverhältnisse, Plattformen verloren an Bedeutung, andere übernahmen die Führung. Der Amiga war nicht mehr unangefochten, Konsolen und PCs drängten nach vorn – und doch zeigte Rampart, dass es nicht immer die stärkste Hardware oder das modernste System brauchte. Mauern bauen, Mauern einreißen, unter Zeitdruck improvisieren – das funktionierte auf nahezu jeder Plattform. Vielleicht liegt genau darin seine Stärke: Rampart war kein Symbol für ein bestimmtes System, sondern für eine Idee. Und diese Idee hat bis heute Bestand.

Starglider 1 – 1986 by Argonaut Software

Wie sehr der Angriff auf dem Eisplaneten Hoth in Star Wars – Das Imperium schlägt zurück eine ganze Generation beeindruckte, lässt sich heute kaum überschätzen. Der Anblick der riesigen AT-AT-Kampfläufer, der verzweifelten Verteidigung der Rebellen und der dynamischen Perspektive aus den Cockpits brannte sich bei vielen Jugendlichen tief ein. Als man Jahre später in den Spielhallen selbst in der legendären Star Wars-Arcade-Sequenz die gepanzerten Walker angreifen konnte, wurde diese Faszination erstmals interaktiv erlebbar. Es liegt nahe, dass auch ein junger Jez San von diesen Bildern geprägt war. Die Idee, schnelle Angriffe aus der Pilotensicht über eine Landschaft zu fliegen, in der eine feindliche Bodeninvasion im Gange ist, wirkt in Starglider jedenfalls wie eine spielerische Fortführung jener Eindrücke, die Science-Fiction-Kino und Arcade-Automaten Anfang der Achtziger hinterlassen hatten.

Jez San arbeitete Mitte der Achtziger bereits mit bemerkenswerter Zielstrebigkeit an dreidimensionaler Grafik, lange bevor er einen festen Publishing-Partner hatte. Noch als Teenager experimentierte er mit einer stark von Star Wars inspirierten 3D-Engine, die zunächst weniger als fertiges Spiel gedacht war, sondern als technische Machbarkeitsstudie. In dieser Phase bewegte sich San bereits in einem Umfeld professioneller Entwickler: Über seine Arbeit an Entwicklungswerkzeugen und frühen Projekten kam er mit David Braben und Ian Bell in Kontakt, die an Elite arbeiteten. Diese Begegnungen waren weniger formale Kooperationen als vielmehr frühe Berührungspunkte mit einer Szene, in der San nicht als Hobbyist, sondern als ernstzunehmender Techniker wahrgenommen wurde. In dieser Zeit entstand das Grundgerüst dessen, was später Starglider werden sollte – inklusive der Idee, schnelle Angriffe aus der Cockpit-Perspektive mit freier Bewegung über eine gekrümmte Landschaft zu verbinden.

Der entscheidende Schritt in Richtung professioneller Veröffentlichung erfolgte über die literarische Agentin Jacqui Lyons. San lernte sie über persönliche Kontakte kennen; bei einem gemeinsamen Dinner stellte er seine Arbeiten vor und gewann ihr Interesse. Lyons unterstützte ihn fortan als Agentin und öffnete ihm Türen in die britische Verlagslandschaft. Über dieses Umfeld kam schließlich der Kontakt zu Rainbird zustande. Erst durch diesen Vertrag wurde aus dem bestehenden Prototyp ein vollwertiges Spielprojekt mit klar definiertem Produktionsrahmen, Finanzierung und jener aufwendigen Präsentation, für die Rainbird Mitte der Achtziger bekannt war.

Veröffentlicht wurde Starglider schließlich 1986 von Rainbird als Premiumtitel für den Atari ST. Entwickelt von Argonaut Software unter Leitung von Jez San, setzte das Spiel auf farbige Drahtgittergrafik und weitläufige Landschaften, sichtbar inspiriert von der sogenannten „Tower“-Sequenz des Atari-Star-Wars-Arcadeautomaten. Der Spieler steuert ein veraltetes Angriffsfluggerät, das sogenannte AGAV, über dem Planeten Novenia, um die laufende Invasion der Egron-Streitkräfte zu bekämpfen. Der Schwerpunkt liegt dabei nicht auf klassischen Weltraumkämpfen, sondern auf präzisen Angriffen gegen feindliche Einheiten am Boden, Navigation und konsequentem Ressourcenmanagement.

Rainbird positionierte Starglider bewusst als hochwertigen Titel. Die Verpackung bestand aus einem stabilen blauen Karton und enthielt neben der Anleitung auch eine 64-seitige Science-Fiction-Novelle von James Follett, die dem Spiel einen erzählerischen Rahmen gab. Damit hob sich Starglider deutlich von der damals üblichen Actionkost ab und rechtfertigte seinen vergleichsweise hohen Verkaufspreis.

Technisch zeigen sich Atari-ST- und Amiga-Version sehr ähnlich. Beide bieten die charakteristische Cockpit-Perspektive über einer gekrümmten Drahtgitter-Landschaft, bevölkert von Panzern, Flugobjekten und zweibeinigen Kampfmaschinen mit klarer Science-Fiction-Anlehnung. Das Spieltempo ist hoch, die Steuerung direkt, und die Darstellung bleibt auch bei dichter Action übersichtlich. Auffällig ist das kurze, etwa fünfzehn Sekunden lange Musikstück im Hauptmenü mit Synthesizerklängen und gesprochener Zeile „Starglider… from Rainbird“, komponiert von David Lowe. Hinzu kommen zahlreiche Geräuscheffekte und kurze Sprachsamples der Rainbird-Sprecherin Clare Edgeley. Bereits 1986 bot Starglider ungewöhnlich viele Einstellmöglichkeiten zur Feinjustierung der Steuerung, darunter verschiedene Fadenkreuz-Modi und automatische Zentrierung. Auch eine optionale Maussteuerung war vorhanden – für ein Actionspiel dieser Zeit eine echte Besonderheit.

Die 8-Bit-Umsetzungen konnten dieses Niveau naturgemäß nicht erreichen. Als beste gilt allgemein die ZX-Spectrum-128K-Version, die durch vergleichsweise hohes Tempo, Sprachsamples, ein mehrstimmiges Titelstück sowie zusätzliche Missionen und Aufrüstungen überzeugte. Die 48K-Fassung verzichtete auf diese Erweiterungen. Die Amstrad-CPC-Version orientierte sich stark an der Spectrum-Umsetzung. Kritischer fiel die Rezeption der Commodore-64-Version aus, die durch langsame, ruckelige Vektorgrafik und eine insgesamt grobere Präsentation auffiel. Die MS-DOS-Version in CGA-Farben gilt rückblickend als schwächste Umsetzung, da Farbarmut, Flackern und unpräzise Steuerung den Spielfluss deutlich beeinträchtigten.

Spielerisch basiert Starglider auf einem einfachen, aber fordernden Prinzip. Gegnerwellen müssen unter konstantem Zeit- und Energiedruck bekämpft werden, während regelmäßig Reparaturbasen angeflogen werden müssen, um Schäden zu beheben und Raketen nachzuladen. Besonders das präzise Andocken an diese Basen gilt als anspruchsvoll. Ein weiteres markantes Element ist das Nachladen der Raketen, das in einer separaten Siloszene erfolgt, in der ein rotierender Tunnel exakt angesteuert werden muss. Insgesamt begegnet man einer Vielzahl unterschiedlicher Gegnertypen, darunter die titelgebenden Starglider als besonders widerstandsfähige Elitegegner.

Die zeitgenössische Presse reagierte ausgesprochen positiv. Crash bezeichnete Starglider als eines der besten Spiele, die je auf dem Spectrum erschienen seien, lobte Geschwindigkeit und Atmosphäre, kritisierte jedoch die zurückhaltende Musik. Auch in den USA erhielt die Atari-ST-Version Anerkennung für ihre flüssige Darstellung und das intensive Spielgefühl. Starglider wurde unter anderem mit dem Titel „Game of the Year 1986“ von Crash ausgezeichnet und fand auch in Sinclair User und Amstrad Action breite Anerkennung.

Jez San sprach später davon, dass sich Starglider rund 300.000 Mal verkauft habe, während andere zeitgenössische Schätzungen etwas darunter liegen. Unabhängig von der exakten Zahl gilt der Titel als außergewöhnlicher Erfolg für einen jungen Einzelentwickler. Der Erfolg führte 1988 zur Fortsetzung Starglider II, die mit ausgefüllter Polygon-Grafik einen weiteren Technologiesprung vollzog und Argonauts Ruf als Spezialist für dreidimensionale Spiele festigte.

Erst im Rückblick wird deutlich, welchen Weg San nach Starglider noch vor sich hatte. Die bei Argonaut entwickelte 3D-Expertise führte schließlich zu einer Zusammenarbeit mit Nintendo. San überzeugte das Unternehmen davon, dass echtes dreidimensionales Spielgefühl auf dem Super Nintendo nur mit zusätzlicher Hardware möglich sei. Nintendo stimmte zu, Argonaut entwickelte daraufhin den Super-FX-Chip – intern augenzwinkernd „MARIO“ genannt –, der dem SNES zu ungeahnter 3D-Leistung verhalf und in Spielen wie Star Fox zum Einsatz kam. Betrachtet man diesen späteren Erfolg, wirkt Starglider heute weniger wie ein isolierter Frühversuch, sondern vielmehr wie der Anfang eines Weges, der von den Eindrücken der Spielhalle über den Heimcomputer bis hin zur Konsolengeschichte führte.

Kurioserweise fand Starglider sogar Eingang in die britische Popkultur: In der TV-Kindersendung Get Fresh traten Spieler direkt im Spiel gegeneinander an. Heute wird Starglider vor allem als historisch bedeutsamer Titel erinnert – als frühes Beispiel dafür, wie technische Ambition, Eigenständigkeit und jugendlicher Wagemut den Heimcomputermarkt der Achtziger prägen konnten.