Schlagwort-Archiv: Apple II

Apple II: Als der Computer plötzlich Farbe bekam – und einen Platz auf dem Schreibtisch

FozzTexx, CC BY-SA 4.0 (Wikimedia Commons)

Ein leises Klicken von Steckkontakten, der Geruch erhitzten Lötzinns, ein Schaltplan, der über Stunden hinweg auf einem Zeichenbrett wächst – doch in diesem Moment ist es mehr als nur Technik. Es ist die Vorstellung eines Computers, der nicht hinter Glasscheiben in Laboren steht, sondern auf einem Schreibtisch, erreichbar, verständlich, unmittelbar. So beginnt die Geschichte des Apple II nicht als Produktidee, sondern als persönliche Obsession. Steve Wozniak war kein Unternehmer im klassischen Sinn, sondern ein Ingenieur, der sich seit seiner Jugend mit dem Entwurf eigener Computersysteme beschäftigte. Während andere Systeme der Mitte der 1970er Jahre aus Schaltern, Leuchtdioden und Frontpanels bestanden, verfolgte er eine andere Vorstellung: ein Rechner, den man direkt bedienen konnte, mit Tastatur, Bildschirm und einer Programmiersprache, die ohne Umwege reagierte.

Der erste greifbare Schritt in diese Richtung war der Apple I, ein handverdrahteter Rechner, den Wozniak im Umfeld des Homebrew Computer Club präsentierte. Dort zeigte sich jedoch schnell, dass das Interesse über die reine Bastlerszene hinausging. Wozniak selbst trat zurückhaltend auf; er brachte seine Geräte mit, stellte sie auf einen Tisch und ließ andere die Fragen stellen. Erst das Feedback von Gleichgesinnten bestätigte ihm, dass seine Ideen auch außerhalb seiner eigenen Werkbank Relevanz hatten. Parallel erkannte Steve Jobs, dass sich aus diesen Konstruktionen ein Geschäft entwickeln ließ. Die oft zitierte Episode um Paul Terrell markiert dabei einen entscheidenden Wendepunkt: Statt einzelner Platinen wollte der Händler vollständig aufgebaute Computer verkaufen.

Doch gerade in diesem Moment zeigte sich auch die Grenze des Apple I. Für Wozniak war er ein Zwischenschritt. Als er begann, mit Farbgrafik zu experimentieren, wurde deutlich, dass sich diese nicht sinnvoll in das bestehende Design integrieren ließ. Die Konsequenz war ein vollständiger Neuentwurf – ein Rechner, dessen Zentrum nicht der Prozessor, sondern die Videoerzeugung war.

Diese Entscheidung prägte den Apple II fundamental. Während konkurrierende Systeme wie der Commodore PET oder der TRS-80 Model I auf Monochromdarstellung setzten, nutzte der Apple II gezielt die Eigenschaften des NTSC-Signals zur Farberzeugung. Das sogenannte Artifact Coloring ermöglichte es, mit minimaler Hardware farbige Darstellung zu erreichen – ein Ansatz, der weniger auf zusätzliche Chips als auf präzises Timing setzte.

Ein Detail, das dabei oft übersehen wird, ist die enge Kopplung zwischen Systemtakt und Videoerzeugung. Der Apple II arbeitete mit einer MOS 6502 CPU, die mit etwa 1,023 MHz getaktet war – genauer gesagt ein Bruchteil der NTSC-Farbträgerfrequenz. Dieser Takt bestimmte nicht nur die Rechengeschwindigkeit, sondern auch die Videogenerierung und sogar Teile des Diskettenzugriffs.

Besonders bemerkenswert ist dabei die Rolle des Grafiksystems selbst. Der Apple II besaß keinen klassischen Grafikchip. Stattdessen war der Grafikgenerator so aufgebaut, dass er gleichzeitig den Refresh des dynamischen RAMs übernahm. Speicher und Bildausgabe waren damit untrennbar miteinander verbunden – eine Konstruktion, die Hardware sparte, aber höchste Präzision erforderte.

Was in der damaligen Außendarstellung oft nur am Rande erwähnt wurde, zeigt sich in technischen Dokumenten deutlich konkreter: Der Apple II war kein einheitlich konfiguriertes System, sondern eine Plattform, deren Leistungsfähigkeit stark von der jeweiligen Bestückung abhing. Bereits frühe Modelle konnten sowohl mit 4 KB als auch mit bis zu 48 KB RAM ausgeliefert werden.

Interessant ist dabei, dass Apple früh zwischen verschiedenen Speicherlösungen wechselte. Dynamischer RAM ermöglichte niedrigere Preise, erforderte jedoch zusätzliche Logik. Die Architektur blieb bewusst offen: Erweiterungsslots erlaubten es, Speicher, Schnittstellen oder Controllerkarten direkt zu integrieren.

Diese Ausrichtung blieb auch der Fachpresse nicht verborgen. BYTE Magazine beschrieb den Apple II als „one of the most complete microcomputer systems available“ („eines der vollständigsten Mikrocomputersysteme, die verfügbar sind“) – eine Einschätzung, die vor allem die ungewöhnliche Kombination aus Bedienbarkeit und Erweiterbarkeit widerspiegelt.

Was diese technische Eleganz im Alltag bedeutete, lässt sich in den Handbüchern der Zeit beinahe greifen. Das System startete ohne Umwege: Einschalten, ein kurzer Ton – und der Rechner ist bereit. „an asterisk (‘’) prompt character … and a flashing white square“ („ein Sternchen (‘’) als Eingabeaufforderung … und ein blinkendes weißes Quadrat“) erscheinen auf dem Bildschirm. Kein Bootmenü, kein Betriebssystem im heutigen Sinne – nur ein Cursor und die Erwartung, dass man etwas damit tut.

Die Tastatur war vollständig integriert, aber bewusst reduziert. Großbuchstaben, direkte Eingabe, unmittelbare Rückmeldung. „The Apple II has a built-in 52-key typewriter-like keyboard…“ („Der Apple II besitzt eine eingebaute, schreibmaschinenähnliche Tastatur mit 52 Tasten…“) beschreibt nüchtern, was in der Praxis ein entscheidender Unterschied war: Der Rechner wartete nicht – er reagierte.

Creative Computing brachte diesen Eindruck auf den Punkt: „Apple has produced a machine that is both powerful and easy to use.“ („Apple hat eine Maschine geschaffen, die sowohl leistungsfähig als auch einfach zu bedienen ist.“)

Auch der Textmodus blieb funktional. 24 Zeilen mit je 40 Zeichen, weiße Schrift auf schwarzem Hintergrund, keine Kleinbuchstaben – eine Einschränkung, die gleichzeitig Klarheit schuf. Erst spätere Modelle erweiterten diesen Bereich.

Die Grafik hingegen war der eigentliche Sprung nach vorn. Neben einfacher Farbdarstellung bot der Apple II hochauflösende Grafik mit 280×192 Pixeln. Die Farben entstanden nicht direkt, sondern durch die Position einzelner Bits im Videosignal. Aus technischer Sicht ein Kompromiss – aus praktischer Sicht ein Durchbruch.

Besonders deutlich wurde die physische Nähe zwischen Mensch und Maschine beim Umgang mit Speichermedien. Der Kassettenbetrieb war hörbar, spürbar, fehleranfällig. „the Apple II needs a signal of about 2 1/2 to 5 volts peak-to-peak“ („der Apple II benötigt ein Signal von etwa 2,5 bis 5 Volt Spitze-zu-Spitze“) – eine technische Angabe, die im Alltag bedeutete: Lautstärke einstellen, Band prüfen, hoffen, dass es funktioniert.

„Tape recorder head alignment is the most common source of tape recorder problems.“ („Die Ausrichtung des Tonbandkopfes ist die häufigste Ursache für Probleme mit Kassettenrekordern.“) – der Computer funktionierte nicht allein, er verlangte Aufmerksamkeit.

Vor diesem Hintergrund wurde das Disk-II-System zu einem Wendepunkt. Es war schneller, zuverlässiger und technisch ungewöhnlich elegant. Während andere Systeme komplexe Controller benötigten, verlagerte Wozniak große Teile der Logik in die Software. Die Kapazität lag bei etwa 143 Kilobyte pro Diskettenseite – ein Wert, der damals deutlich über vielen konkurrierenden Heimlösungen lag.

Die zugehörigen Schaltpläne zeigen eine reduzierte, fast minimalistische Architektur. Kilobaud Microcomputing brachte es treffend auf den Punkt: „a very sophisticated piece of engineering“ („ein sehr ausgeklügeltes Stück Ingenieurskunst“).

Ein Blick auf die Hauptplatine bestätigt diesen Eindruck. Funktionen greifen ineinander, statt getrennt zu sein. CPU, Speicher und Video sind Teil eines gemeinsamen Systems.

Die Erweiterbarkeit war dabei kein Detail, sondern ein Grundprinzip. Acht Steckplätze erlaubten Anpassungen, Erweiterungen, Experimente – gegen den ursprünglichen Widerstand von Jobs.

An dieser Stelle wird auch die Einordnung im Markt greifbar. Gemeinsam mit dem Commodore PET und dem TRS-80 Model I bildet der Apple II die sogenannte „1977 Trinity“.

Doch die Unterschiede waren entscheidend:
Der PET war geschlossen.
Der TRS-80 war günstig und funktional.
Der Apple II war offen.

Diese Offenheit machte ihn zu einer Plattform. Erweiterungskarten wie die Z80 SoftCard ermöglichten sogar den Betrieb von CP/M und damit Zugang zu professioneller Software wie WordStar oder dBASE.

Ein oft unterschätztes Detail ist das Fehlen komfortabler, standardisierter Timer- und Interrupt-Mechanismen im Grundsystem. Zwar konnten Interrupts über Erweiterungskarten realisiert werden, doch im Auslieferungszustand musste vieles exakt berechnet werden. Sound entstand durch präzises Schalten des Lautsprechers, Diskettenzugriffe durch exakt abgestimmte CPU-Zyklen.

Der Apple II war kein komfortables System – er war ein präzises.

Parallel zu dieser technischen und spielerischen Nutzung entwickelte sich jedoch eine Anwendung, die den Apple II in eine völlig neue Kategorie verschob. Mit VisiCalc erschien 1979 ein Programm, das rückblickend häufig als erste echte „Killerapplikation“ des Personal-Computer-Zeitalters bezeichnet wird.

VisiCalc war mehr als nur Software – es war ein Perspektivwechsel. Tabellenkalkulationen, die zuvor auf Papier, mit Taschenrechnern oder auf teuren Großrechnern erstellt wurden, konnten plötzlich direkt auf einem Personal Computer berechnet und verändert werden. Jede Eingabe wirkte sich sofort auf das gesamte Modell aus. Zahlen wurden nicht mehr nur festgehalten – sie wurden beweglich.

Für viele Anwender war dies der erste Moment, in dem ein Computer nicht als Maschine, sondern als Werkzeug erschien. Ein Werkzeug, das Denken beschleunigte. Ein Werkzeug, das Entscheidungen sichtbar machte.

Zeitgenössische Berichte sind in dieser Hinsicht eindeutig: Unternehmen kauften den Apple II nicht wegen seiner Grafikfähigkeiten, nicht wegen seiner Erweiterbarkeit und auch nicht wegen seiner technischen Eleganz – sie kauften ihn wegen VisiCalc. Der Rechner wurde zur Trägerplattform für eine Anwendung.

Damit kehrte sich das Verhältnis von Hardware und Software erstmals spürbar um. Nicht mehr der Computer bestimmte, welche Programme sinnvoll waren – sondern ein Programm bestimmte, welcher Computer gekauft wurde.

In diesem Zusammenhang entstand die bis heute zitierte Einschätzung, VisiCalc sei „the first killer application“ („die erste Killerapplikation“). Doch diese Bezeichnung greift fast zu kurz. VisiCalc war nicht nur ein Verkaufsargument – es war ein Beweis. Ein Beweis dafür, dass Personal Computer wirtschaftlich sinnvoll eingesetzt werden konnten.

Die Auswirkungen waren unmittelbar. Der Apple II fand seinen Weg in Büros, in Buchhaltungen, in Planungsabteilungen. Aufgaben, die zuvor Tage oder Wochen beanspruchten, ließen sich nun innerhalb von Minuten durchspielen. Szenarien konnten verändert, Zahlen angepasst, Konsequenzen sofort sichtbar gemacht werden.

In der Rückschau markiert VisiCalc damit einen Wendepunkt, der über das System selbst hinausgeht. Der Apple II wurde nicht einfach erfolgreicher – er wurde relevant. Oder anders formuliert: Zum ersten Mal wurde ein Computer nicht gekauft, weil man ihn haben wollte, sondern weil man ihn brauchte.

Doch gerade in diesem Moment zeigt sich eine zweite Dimension, die über die unmittelbare Wirkung von VisiCalc hinausgeht. Der Apple II war kein kurzlebiges Produkt einer frühen Experimentierphase, sondern entwickelte sich zu einer der langlebigsten Plattformen der gesamten Mikrocomputerära. Zwischen 1977 und 1993 blieb die Architektur – in verschiedenen Ausprägungen – im Markt präsent.

Der ursprüngliche Einführungspreis lag bei rund 1.298 US-Dollar, während stärker ausgebaute Systeme deutlich darüber lagen. Über die gesamte Baureihe hinweg wurden mehrere Millionen Geräte verkauft.

Noch greifbarer wird diese Entwicklung anhand typischer Systemkonfigurationen. Ein arbeitsfähiger Apple II bestand selten nur aus dem Rechner selbst.

Ein typisches Business-System um 1980 umfasste:
– Apple II / II+
– Diskettenlaufwerk
– VisiCalc (ca. 150 US-Dollar)

Ein solches System bewegte sich im Bereich von etwa 1.800 bis über 2.400 US-Dollar. Mit zunehmender Verbreitung kamen weitere Komponenten hinzu. Textverarbeitungssysteme wurden für rund 129,95 US-Dollar angeboten und erweiterten den Rechner zu einem vielseitigen Arbeitsgerät. Bis Anfang der 1980er Jahre entstand daraus ein vollständiger Arbeitsplatz mit Software, Erweiterungen und Peripherie – oft mit Gesamtpreisen von mehreren tausend US-Dollar. In Europa, insbesondere in Deutschland, verstärkten Importkosten diesen Effekt zusätzlich. Apple-II-Systeme kosteten häufig mehrere tausend D-Mark und wurden eher als Investition denn als Konsumprodukt wahrgenommen. Im Vergleich dazu stand der Commodore 64 für den Heimgebrauch, während der IBM PC sich im professionellen Umfeld etablierte. Der Apple II bewegte sich zwischen diesen Welten.

Doch bevor der Apple II zu einem Werkzeug wurde, war er bereits etwas anderes – ein Experimentierfeld. Ein Ort, an dem sich nicht nur Programme, sondern Ideen entwickeln konnten. In dieser Umgebung entstand etwas, das sich erst Jahre später vollständig greifen ließ: Der Apple II wurde zur Geburtsstätte ganzer Spielgenres. Ein besonders prägnantes Beispiel ist die Entstehung von Sierra On-Line. Ken Williams und Roberta Williams entwickelten mit Mystery House das erste Grafik-Adventure. Parallel dazu entstand mit Akalabeth: World of Doom ein früher Vertreter des Rollenspielgenres. Mit zunehmender Reife des Systems folgten Titel wie Wizardry, Lode Runner oder Karateka. Auch Castle Wolfenstein und The Oregon Trail erweiterten das Spektrum. Zeitgenössische Magazine beobachteten diese Entwicklung genau. In der ersten Ausgabe von Softline wird offen beschrieben, dass Computer in der Praxis vor allem für Spiele genutzt wurden – und dass gerade diese Programme entscheidend zur Weiterentwicklung von Benutzerfreundlichkeit und Grafik beitrugen. Spiele waren damit nicht nur Unterhaltung, sondern ein Experimentierfeld für neue Ideen.

Der Apple II bot dafür ideale Bedingungen. Direkter Zugriff auf Speicher, flexible Grafik und eine offene Architektur ermöglichten es Entwicklern, die Grenzen des Systems auszureizen.

Der Rechner bot keine Abstraktion – er verlangte Verständnis. Der Apple II war kein fertiges Produkt im heutigen Sinn. Er war ein Angebot. Ein System, das den Benutzer nicht abschirmte, sondern einbezog. Ein Computer, den man nicht nur benutzte, sondern verstand. Oder, wie Apple es selbst formulierte: „the first personal computer you’ll actually enjoy using.“ („der erste Personal Computer, den man tatsächlich gern benutzt.“)

Und vielleicht liegt genau darin sein eigentlicher Wendepunkt: Nicht darin, was er konnte – sondern darin, dass er es dem Benutzer zutraute, es herauszufinden.

 

Centipede: Wie Dona Bailey und Atari 1981 einen Arcade-Klassiker zwischen Trackball, Zufall und Pilzlabyrinth schufen

Ein leises Summen liegt in der Luft, irgendwo zwischen Neonlicht und dem metallischen Klang fallender Münzen. Anfang der 1980er Jahre war die Spielhalle kein Ort der Erklärungen, sondern der Erfahrung. Als Dona Bailey zum ersten Mal vor einem Automaten von Space Invaders stand, wusste sie nicht einmal, was ein Videospiel war. „I said what is a video game…“, erinnerte sie sich später, nur um wenige Augenblicke danach eine Entscheidung zu treffen, die rückblickend wie ein Wendepunkt wirkt: „I don’t want to program for GM anymore, I want to program for Atari.“ („Ich will nicht mehr für GM programmieren, ich will für Atari programmieren.“) Was als neugieriger Blick auf flackernde Pixel begann, führte direkt zur Mitarbeit an einem der einflussreichsten Titel der Arcade-Geschichte: Centipede.

Bailey brachte dabei kein vages Interesse, sondern handfeste technische Erfahrung mit. Bei General Motors hatte sie bereits mit dem MOS-6502-Prozessor gearbeitet – jenem Chip, der auch das Herz vieler Heimcomputer wie des Commodore 64 bilden sollte. Dort programmierte sie Systeme wie Tempomat- und Klimasteuerungen im Cadillac Seville. Der Wechsel zu Atari war damit weniger ein Sprung ins Unbekannte als eine Verschiebung des Einsatzfeldes: von Sensorik und Regeltechnik hin zu Bildpunkten und Spiellogik. Die Werkzeuge blieben jedoch ähnlich streng – und ebenso unerbittlich.

Denn die Entwicklung von Centipede war ein permanenter Balanceakt zwischen Idee und Limit. „I was always supposed to be counting my bytes and counting my cycle time“, erklärte Bailey. („Ich musste ständig meine Bytes und meine Taktzyklen mitzählen.“) Jeder Befehl, jede Routine war an exakte Zeitfenster gebunden. Wurde diese Grenze überschritten, hatte das unmittelbare Konsequenzen: „If you run over the amount of clock time there’s tearing on the screen.“ („Wenn man die verfügbare Taktzeit überschreitet, zerreißt das Bild.“) Programmieren bedeutete hier nicht nur Logik, sondern Timing im wortwörtlichen Sinne – eine direkte Verbindung zwischen Code und sichtbarem Ergebnis.

Auch der Arbeitsalltag im Atari-Arcade-Team wirkt aus heutiger Sicht fast fremd. Code wurde handschriftlich verfasst, in einen Korb gelegt, von spezialisierten Mitarbeiterinnen abgetippt, kompiliert und auf ein PROM gebrannt. Erst Stunden später ließ sich das Ergebnis im Entwicklungskabinett testen. „Here’s your cubicle, now make a game“, lautete die nüchterne Einweisung. („Hier ist deine Kabine, jetzt mach ein Spiel.“) Eine Struktur, die kaum Planung erlaubte, dafür aber Experiment begünstigte. „We had no idea what we were doing. We were just doing stuff.“ („Wir hatten keine Ahnung, was wir da taten. Wir haben einfach Dinge gemacht.“)

Die Grundidee von Centipede war schlicht: Ein segmentierter Gegner bewegt sich über das Spielfeld und wird vom Spieler beschossen. Doch die eigentliche Qualität entstand aus den Lösungen, die unterwegs gefunden wurden. Ein prägnantes Beispiel sind die Pilze. Lange Zeit wurden sie als ironische Anspielung interpretiert, doch Bailey widersprach dieser Deutung deutlich: „It was not my style to make a drug reference like that.“ („Es war nicht meine Art, einen solchen Drogenwitz zu machen.“) Stattdessen entstand ihre Funktion aus einem praktischen Problem. Bailey benötigte visuelle Marker, um die Bewegung und Drehpunkte des Tausendfüßers nachvollziehen zu können. Aus einfachen Testobjekten entwickelte sich schließlich der Pilz als grafisch funktionierende Form. „Putting the mushrooms on the screen made it a maze right away.“ („Die Pilze machten das Spielfeld sofort zu einem Labyrinth.“) Aus einer technischen Notwendigkeit wurde ein spielprägendes Element.

Ähnlich zentral war die Frage der Steuerung. Frühere Varianten mit Knöpfen oder Joystick erwiesen sich für Bailey als wenig überzeugend. Erst mit dem Einsatz eines Trackballs änderte sich das grundlegend. „It was when the track ball was tried out that it really became compelling for me to play“, erinnerte sie sich. („Erst mit dem Trackball wurde das Spiel für mich wirklich fesselnd.“) Die direkte, fließende Bewegung verlieh dem Spiel eine Präzision, die sich mit herkömmlichen Eingabegeräten kaum erreichen ließ. Bailey sah darin rückblickend auch einen möglichen Grund für die ungewöhnlich breite Spielerbasis: „I think the track ball was part of the reason that it was successful with girls and women.“ („Ich glaube, der Trackball war einer der Gründe für den Erfolg bei Frauen und Mädchen.“)

Technisch nutzte Centipede zudem einen hardwarebasierten Zufallsmechanismus, gekoppelt an den Atari-Pokey-Chip. Dadurch variierte das Spielfeld von Runde zu Runde – ein Ansatz, der sich deutlich von den festen Angriffsmustern früherer Titel wie Space Invaders oder Galaxian unterschied. Pilzverteilung, Gegnerbewegungen und Bedrohungslagen wirkten weniger berechenbar und gaben dem Spiel eine Dynamik, die über das reine Reaktionsspiel hinausging. Besonders die Spinne wurde so zu einem unberechenbaren Faktor, dessen Auftreten durch ein charakteristisches Geräusch angekündigt wurde – eine frühe Verbindung von Sound und Spielmechanik.

Auch visuell setzte Centipede eigene Akzente. Die leuchtenden, teilweise pastellartigen Farben entstanden zunächst aus technischen Umständen, wurden jedoch bewusst beibehalten. Bailey beschrieb ihre Reaktion darauf schlicht mit: „I just thought it was so beautiful.“ („Ich fand es einfach wunderschön.“) In der dunklen Umgebung der Spielhallen entwickelte das Spiel dadurch eine besondere Präsenz. „It would be the shimmering jewel across the room.“ („Es war quer durch den Raum ein schimmerndes Juwel.“) Damit wurde Centipede nicht nur ein Spiel, sondern auch ein visueller Anziehungspunkt.

Die zeitgenössische Presse bestätigte diese Wirkung, wenn auch nicht ohne Einschränkungen bei den Heimversionen. Die britische Commodore User schrieb über die VIC-20-Fassung: „All round, centipede is a good one or two player game with well-defined graphics and good clear sound.“ („Alles in allem ist Centipede ein gutes Ein- oder Zwei-Spieler-Spiel mit klar definierten Grafiken und gutem, deutlichem Sound.“) Das deutsche Magazin TeleMatch hob die Popularität des Originals hervor und beschrieb den Spielablauf treffend: „Reaktion ist alles!“ Gleichzeitig wurde jedoch auch kritisch angemerkt, dass die grafische Umsetzung nicht an die Arcade-Version heranreiche. Internationale Stimmen wie das Games Magazine bezeichneten die Atari-5200-Version als „faithful and satisfying adaptation“, während Bill Kunkel und Arnie Katz im Video Magazine auf die technischen Grenzen des Apple II verwiesen und die Steuerung als „sluggish“ beschrieben.

Mit dem Erfolg des Arcade-Originals begann eine breite Welle von Portierungen. Systeme wie das Atari 2600 reduzierten die Darstellung auf einfache Formen, bewahrten jedoch die Geschwindigkeit und damit den Kern des Spiels. Auf leistungsfähigeren Plattformen wie dem Atari 5200 oder den Atari-Heimcomputern näherte sich das Spiel stärker dem Original an, insbesondere wenn ein Trackball verwendet werden konnte. Umsetzungen für den Commodore 64 oder Systeme wie den ZX Spectrum zeigten jeweils eigene Interpretationen, während spätere Versionen etwa für den Game Boy durch das kleinere Display ein verändertes Spielgefühl erzeugten. Entscheidend blieb dabei stets die Steuerung: Ohne Trackball verlor Centipede einen Teil seiner charakteristischen Präzision.

Auch wirtschaftlich spiegelt das Spiel den Wandel der Branche wider. Ein Arcade-Automat kostete zur Veröffentlichung rund 2.000 bis 3.000 US-Dollar, was inflationsbereinigt etwa 7.000 bis 10.000 Euro entspricht. Heimversionen waren deutlich günstiger und machten das Spiel einem breiteren Publikum zugänglich, während spätere Budgetveröffentlichungen den Titel dauerhaft im Markt hielten.

Die Entwicklung von Centipede lag im Kern bei Ed Logg und Dona Bailey, deren Zusammenarbeit das Spiel maßgeblich prägte. Weitere Beiträge entstanden innerhalb des Atari-Teams, lassen sich jedoch nicht in allen Fällen eindeutig einzelnen Personen zuordnen.

Auffällig ist rückblickend auch, wie konzentriert Baileys Beitrag in der Spielegeschichte geblieben ist. Abgesehen von Centipede ist kein weiteres von ihr entwickeltes Spiel erschienen. Zwar arbeitete sie nach ihrer Zeit bei Atari und später unter anderem bei Activision an weiteren Projekten, doch keines davon erreichte den Markt. Diese Entwicklung ist weniger ungewöhnlich, als es aus heutiger Sicht erscheinen mag: Die frühe Spieleindustrie war geprägt von kurzen Karrieren, instabilen Strukturen und einem rasanten Wandel.

So bleibt Centipede nicht nur als Spiel in Erinnerung, sondern als Momentaufnahme einer Phase, in der sich das Medium noch in Bewegung befand. Zwischen handgeschriebenem Code, experimentellen Ideen und der unmittelbaren Rückmeldung aus der Spielhalle entstand ein Titel, dessen Prinzip sich als erstaunlich widerstandsfähig erwies. Dass er auf unterschiedlichsten Systemen funktionierte und bis heute nachvollziehbar bleibt, spricht weniger für technische Perfektion als für die Klarheit seines Entwurfs – und für eine Zeit, in der man, wie Bailey es formulierte, oft einfach begann, Dinge zu machen.

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Lode Runner – 1983 by Brøderbund Software

Lode Runner (1983) – Minimalismus, Spannung und 150 Wege in die Sucht

Lode Runner (1983) – Minimalismus, Spannung und 150 Wege in die Sucht

Als Anfang der Achtziger an amerikanischen Universitäten noch Lochkarten staubten und Großrechner im Neonflackern brummten, entstand ein Spiel, das mit radikaler Schlichtheit neue Maßstäbe setzte: Lode Runner. Seine Wurzeln liegen in ASCII-Prototypen wie Suicide auf dem Commodore PET, deren Engine bereits sauber getrennte Leveldaten nutzte. Auf einem Prime-550-Minicomputer entstand daraus das Spiel Kong, versteckt hinter dem Tarnbefehl graph. Zeitzeugen berichten, dass auf vielen Universitätsrechnern dieser Befehl zum inoffiziellen Geheimtipp wurde – eine kleine studentische Untergrundszene, die das Fundament legte. Douglas E. Smith übertrug das Konzept später auf den Apple II und entwickelte Miner, eine noch rohe Fassung mit ruckelnden Sprites und schwarz-weißer Optik. Doch das Fundament war gelegt: graben, fliehen, taktieren.

Smith schickte den Prototyp an mehrere Publisher. Broderbund bot den geringsten Vorschuss, aber die besten Royalties – eine Entscheidung, die sich später als Glücksgriff herausstellte. Der Verlag verlangte flüssige Animationen und 150 spielbare Levels. Mit dem eingebauten Editor gelang das nur, weil Freunde, Nachbarskinder und Studenten dutzende Bildschirme entwarfen; ein großer Teil der finalen Levels stammt aus dieser frühen „Volkswerkstatt“, lange bevor der Begriff „User Generated Content“ existierte.

Die Mechanik ist bis heute einzigartig reduziert und deshalb so klar: Der Spieler sammelt Gold, gräbt temporäre Löcher, trickst Wachen aus und nutzt sie manchmal als unfreiwillige Trittsteine. Feste Bildschirme, präzise Wege, missverständnisfrei lesbare Elemente – ein Baukasten, der wie Schach in Echtzeit funktioniert. Die Wachen agieren überraschend clever, sammeln sogar Gold ein, das sie beim Sturz in ein Loch wieder verlieren. Fehler im Timing können ein Level unlösbar machen, doch gerade diese Konsequenz macht den Reiz aus.

Die Apple-II-Version bleibt minimalistisch, einfarbig und beinahe asketisch. Der C64 fügt weichere Sprites und typischen SID-Sound hinzu, während der Atari-8-Bit technisch zwischen beiden liegt. CGA auf dem PC wirkt härter, aber spielmechanisch identisch. In Japan entstand eine zweite Identität: Hudson Softs Famicom-Version bot Scrollbewegungen, Musik, buntere Optik und einen funktionalen Editor, dessen Levels sich per Data Recorder speichern ließen. Irem brachte 1984 sogar eine Arcade-Fassung heraus – bemerkenswert, da hier eines der ersten amerikanischen Heimcomputerspiele zur Grundlage eines japanischen Arcade-Titels wurde.

Der Erfolg war unmittelbar und enorm. Lode Runner wurde schnell zu Broderbunds größtem Hit und verkaufte sich weltweit millionenfach, besonders in Japan. Für Smith bedeutete das hohe Royalties und den plötzlichen Sprung vom Studenten zum unerwartet wohlhabenden Designer eines minimalistischen Puzzle-Plattformers.

Zeitgenössische Magazine lobten die Mischung aus Denksport und Action. Softline nannte das Spiel 1983 „smooth, thoughtful, and quite addictive“ („flüssig, durchdacht und ziemlich süchtig machend“). Computer Gaming World bezeichnete es als „one of the few thinking men's arcade games“ („eines der wenigen Arcade-Spiele für denkende Spieler“). Zzap!64 attestierte der C64-Version: „graphically minuscule and aurally crude, the game's sheer addiction kept my eyes propped open until the owls went to bed“ („grafisch winzig und klanglich grob, aber so süchtig machend, dass ich wach blieb, bis die Eulen schlafen gingen“). Bei den 5th Arkie Awards wurde der Titel 1984 als „outstanding design“ und „irresistible“ ausgezeichnet. In späteren Rückblicken rangiert Lode Runner regelmäßig unter den wichtigsten Apple-II- und Puzzle-Spielen aller Zeiten.

In Deutschland lagen die Preise für die gängigen Heimcomputerfassungen typischerweise zwischen 39 und 59 DM, je nach Händler und System – inflationsbereinigt etwa 55–60 Euro. Spätere Ariolasoft-Budgetversionen („Hits!“) machten den Titel auch für Sparfüchse attraktiv, während die zahlreichen Ports und Varianten für eine beständige Präsenz in Regalen und Magazinen sorgten.

B.C.’s Quest for Tires – 1983 by Sydney Development Corp.

Von der Höhle auf den Bildschirm – Der Aufstieg des ersten kanadischen Videospielhits

BC's Quest for TiresB.C.’s Quest for Tires, entwickelt von Sydney Development Corporation und vertrieben durch Sierra On-Line, war eines jener Spiele, das im goldenen Zeitalter der Heimcomputer erschien und dabei etwas ganz Eigenes schuf. Basierend auf dem beliebten Zeitungscomic B.C. von Johnny Hart, versetzte das Spiel den Spieler in die Rolle des wortkargen Höhlenmenschen Thor, der auf einem Steinrad durch prähistorische Landschaften rollt, um seine Angebetete – „Cute Chick“ – aus den Fängen des Dinosauriers Gronk zu befreien. Die Handlung mag rudimentär wirken, doch der Witz, die stilisierte Grafik und das durchdachte Gameplay machten den Titel zu einem Klassiker jener frühen Homecomputer-Ära.

Thor bewegt sich auf seinem Stein-Einrad unaufhörlich von links nach rechts, und der Spieler muss im richtigen Moment springen, sich ducken oder auf fahrende Schildkröten springen, um die zahlreichen Hindernisse zu überwinden. Es gibt zehn Level, darunter auch ruhigere Abschnitte, in denen es auf das richtige Timing ankommt. Besonders auffällig war die farbenfrohe Grafik und der comicartige Zeichenstil, der dem Originalstrip erstaunlich treu blieb. Eine besondere Raffinesse bestand darin, dass der Spieler die Geschwindigkeit von Thors Gefährt selbst kontrollieren konnte, was nicht nur den Schwierigkeitsgrad, sondern auch die Punktwertung beeinflusste – ein damals innovatives Element.

Die Entstehung des Spiels war eng mit dem kanadischen Entwickler Michael Bate und dessen Gründung von Artech Studios verknüpft. Die Lizenz an Johnny Harts Comicstrips B.C. und The Wizard of Id wurde für 25.000 Dollar jährlich erworben – eine für damalige Verhältnisse beachtliche Summe. Ursprünglich war das Spiel als Werbung für das kanadische NABU-Netzwerk gedacht, wurde jedoch bald als eigenständiges Produkt weiterentwickelt. Die ColecoVision-Version war die erste technisch funktionstüchtige, da sowohl NABU als auch ColecoVision denselben Z80-Prozessor nutzten. Die Portierung war daher vergleichsweise unkompliziert, und auch der Vertrieb durch Sierra kam rasch zustande.

An der Programmierung waren mehrere später bekannte Entwickler beteiligt. Rick Banks, zusammen mit MaryLou O’Rourke, entwickelte die ColecoVision-Fassung. Chuck Benton, der später mit Leisure Suit Larry bekannt wurde, programmierte die Atari-8-Bit- und Commodore-64-Version. Justin Gray übernahm die Apple-II-Umsetzung, N. R. Dick war für die MSX-Version verantwortlich und Mike Davies für den ZX Spectrum. Ein dedizierter Komponist wurde nicht genannt – der Sound, der oft auf einfache Effektgeräusche reduziert war, wurde meist von den Programmierern selbst beigesteuert. Viele dieser Entwickler arbeiteten in späteren Jahren an weiteren bekannten Titeln, insbesondere im Umfeld von Sierra oder Artech.

Trotz der engen Produktionszeit – Michael Bate äußerte später, dass er nicht besonders stolz auf das Spiel sei, da es unter großem Zeitdruck entstanden sei – wurde B.C.’s Quest for Tires ein beachtlicher Erfolg. Es war das erste in Kanada entwickelte Videospiel, das auf Kassette erschien, und wurde zu einem Verkaufsschlager. Über eine Million Einheiten wurden verkauft – ein gewaltiger Erfolg für ein Computerspiel des Jahres 1983. Es erhielt Auszeichnungen wie „Best Game for Youngsters“ von Family Computing und lobende Erwähnungen für Grafik und Sound vom Billboard Magazine und dem Magazin Video Game Update.

Die internationale Rezeption war ebenfalls positiv. Die Atari-8-Bit-Version erhielt von Spielern im Durchschnitt 8,4 von 10 Punkten, die Commodore-64- und Spectrum-Fassungen bewegten sich meist im Bereich um 7,5. Die ColecoVision-Version wurde oft als die technisch gelungenste bezeichnet, während die ZX-Spectrum-Fassung in punkto Grafik durch das monochrome Design leichte Abstriche machte, aber flüssig lief. Die PC-Version hingegen wurde aufgrund der limitierten CGA-Grafik und des fehlenden Sounds als eher mittelmäßig bewertet.

Auch heute noch gibt es Diskussionen um Begriffe wie „Cute Chick“ und „Fat Broad“, die im Originalcomic verwendet wurden und später von der Familie Hart in „Grace“ und „Jane“ geändert wurden, da man sie als potenziell abwertend empfand. Diese Änderungen betrafen zwar den Strip selbst, warfen aber auch einen neuen Blick auf das Spiel, das diese Namen in seinem Originaltitel und Abspann übernahm.

Verworfene Inhalte sind kaum dokumentiert, doch es gibt Hinweise, dass ursprünglich weitere Level geplant waren, darunter eine Szene im Innern eines Vulkans mit seitlich rollender Lavakugel, die aus Speichergründen gestrichen wurde. Auch eine Variante mit Höhlenzeichnungen als Hintergrundgrafik wurde verworfen – der Speicherbedarf hätte den Rahmen der Module und Disketten überschritten.

Das Spiel wurde auf zahlreiche Systeme portiert: Neben ColecoVision, Atari 8-bit, Commodore 64, Apple II, MSX und IBM PC erschien es auch für das ZX Spectrum. Die technische Umsetzung variierte stark: Während ColecoVision und Apple II mit vergleichsweise hoher Bildwiederholrate glänzen konnten, litten einige Umsetzungen unter ruckeliger Steuerung. Unterschiede in Sound und Grafik waren systembedingt. Interessanterweise war B.C.’s Quest for Tires eines der wenigen Spiele jener Zeit, das sowohl in den USA als auch in Europa und Japan vertrieben wurde, oft mit lokal angepasstem Handbuch oder abgewandeltem Titelbild.

Ein interessantes Detail am Rande: Auf einem frühen Werbeflyer von Sierra ist die Heldin des Spiels blond dargestellt – im Comic jedoch ist sie rothaarig. Es wurde nie erklärt, ob dies ein Versehen oder eine bewusste künstlerische Entscheidung war. Ebenso kursieren bis heute unbestätigte Berichte, dass eine Version für den Intellivision-Prototyp entwickelt wurde, diese aber nie veröffentlicht wurde.

B.C.’s Quest for Tires mag heute wie ein kurioses Überbleibsel einer vergangenen Ära wirken, doch es war stilbildend für das Lizenzspiel-Genre der frühen 1980er und trug maßgeblich dazu bei, dass Spiele nicht nur abstrakte Herausforderungen sein mussten, sondern auch humorvolle Geschichten erzählen konnten. In einem Interview sagte Entwickler Rick Banks später: „Wir wollten einfach ein Spiel machen, das sich so anfühlt, als würde man einen Sonntagscomic durchblättern – nur eben spielbar.“ Und genau das war es: ein interaktiver Comicstrip auf einem Steinrad.

The Goonies – 1985 by Datasoft / U.S. Gold

The Goonies - 1985 by Datasoft / U.S. Gold

goonies coverThe Goonies, veröffentlicht 1985 in den USA von Datasoft und ein Jahr später in Europa von US Gold, war eine jener frühen Filmumsetzungen, die versuchten, das cineastische Abenteuerfeuerwerk ins pixelige 8‑Bit‑Universum zu übertragen – und das mit erstaunlich viel Charme, obwohl (oder gerade weil) man statt auf actionreiche Dauerballerei auf Puzzle-Kombinationen und Geschicklichkeit setzte. Das Spiel wurde von Scott Spanburg programmiert, der später noch durch Bruce Lee und Zorro auffiel, während Kelly Day die Grafik entwarf und Richard Mirsky (Apple II, Atari) sowie John A. Fitzpatrick (C64) sich um die Musik kümmerten – letztere teils mit eigenständigen Tape‑ und Diskettenversionen, was zur damaligen Zeit noch echte Unterschiede bedeutete.

Spielerisch begibt man sich in einem Mix aus Plattformspiel und Puzzler mit zwei Goonies gleichzeitig durch acht Level, die lose Szenen aus dem gleichnamigen Spielberg-Film aufgreifen. Im Solomodus kann man zwischen den Figuren hin- und herschalten, im Zwei-Spieler-Modus übernimmt jeder einen der Charaktere. Ziel in jedem Abschnitt: Schalter aktivieren, Schlüssel finden, Fallen vermeiden – und das möglichst synchron. Die grafische Umsetzung war je nach Plattform unterschiedlich detailreich, wobei besonders die C64- und Amstrad-Versionen sich durch etwas knackigere Farben und Musikuntermalung hervortaten, während die ZX Spectrum-Fassung mit spartanischer Darstellung auskommen musste, dafür aber flüssiger lief.

Der Entwicklungsprozess verlief vergleichsweise geordnet, wobei einige ursprünglich geplante Spielelemente und Level aus Speicherplatzgründen wieder gestrichen wurden. Laut Aussagen in späteren Entwicklerforen war unter anderem ein Level vorgesehen, in dem die Fratellis mit einer Lore durch das Bild rasten sollten – eine direkte Anspielung auf die dramatische Lorenfahrt aus dem Film. Auch experimentierte man mit einem Bildschirm, der bei bestimmten Aktionen zittern oder kollabieren sollte – eine Art primitiver Erdbebeneffekt, der durch flackernde Tiles und Soundeffekte simuliert werden sollte. Letztlich war die Technik auf den Zielplattformen dafür zu begrenzt, sodass man den Plan aufgab und das Ganze durch eher statische Levelbilder ersetzte. Ebenso wurden alternative Figuren wie Andy oder Brand als spielbare Charaktere verworfen, da die Zweierkonstellation mit Mikey & Mouth technisch am einfachsten zu realisieren war.

Was damals nur wenige wussten: Auf dem Amstrad CPC konnte man mit einem versteckten Tastendruck F5 tatsächlich das Startlevel ändern – eine Art inoffizieller Trainer-Modus, den man wohl ursprünglich zu Testzwecken eingebaut und nie entfernt hatte. Und in der CPC-Version startete man mit 8 Leben statt der üblichen 5 – möglicherweise ein Kompromiss an die damals als „etwas schwieriger“ geltende Tastensteuerung. In manchen Fassungen wie der Apple-II- und MSX-Version lassen sich beim Neustart sogar kleine Unterschiede im Levelverlauf und der Platzierung von Objekten feststellen – vermutlich bedingt durch leicht andere Portierungsbasen.

Besonders spannend ist der internationale Versionsvergleich: In Japan erschien 1986 bei Konami eine eigene Umsetzung für Famicom und MSX mit völlig anderem Spielprinzip, Musik und Mechanik. Diese Version wurde später mit dem bekannten The Goonies II auf dem NES fortgesetzt – viele europäische und US-Spieler gingen damals fälschlich davon aus, Goonies II wäre ein Sequel zur US Gold-Version, obwohl es sich um einen völlig anderen Ast der Lizenzgeschichte handelte.

Kritiken fielen meist positiv aus, wenn auch nicht euphorisch. Die C64-Version erhielt im Schnitt 68–75 % in Magazinen wie Zzap!64, der Spectrum pendelte um die 74 %, während der CPC immerhin auf respektable 70 % kam. Besonders gelobt wurde die Kombination aus Rätseldesign und Teamwork-Mechanik, aber man bemängelte die recht kurze Spieldauer und den manchmal frickeligen Schwierigkeitsgrad. Ein User-Kommentar aus dem Retro Gamer Forum brachte es auf den Punkt: „Ein Spiel, bei dem die Kooperation nicht hilft, sondern scheitert, wenn der zweite Spieler zu blöd ist – willkommen bei den echten Goonies!“

Kommerziell gesehen war The Goonies ein veritabler Erfolg. Während genaue Verkaufszahlen schwer greifbar sind, tauchte es in mehreren Compilations auf, etwa in US Golds Kixx-Reihe oder auf Tape-Zusammenstellungen wie Hit Pak. Die Tatsache, dass es auf beinahe allen 8-Bit-Systemen erschien – von Apple II über Atari 8-Bit bis hin zu Amstrad CPC, ZX Spectrum und MSX – spricht für eine gute Marktverbreitung. Sogar eine PC-88-Version wurde in Japan realisiert, mit leicht verändertem Grafikstil und japanisch lokalisiertem Text, was im Westen kaum bekannt war.

Heute ist The Goonies ein Liebling der Abandonware-Szene und Emulationsfreunde. Die C64-Version ist rund 170 kB groß, die Amstrad-Version knapp 128 kB, die Spectrum-Fassung nur rund 46 kB – und dennoch steckt in diesen paar Kilobyte jede Menge Liebe, Timing und Trial & Error. Besonders Sammler schätzen die Tape-Editionen mit alternativen Artworks, z. B. die grüne Kixx-Label-Kassette, die in UK später einen gewissen Kultstatus erlangte.

Was bleibt, ist ein Spiel, das filmische Nostalgie mit cleverem Spieldesign verband. Keine überbordende Grafikorgie, kein revolutionäres Gameplay – aber ein liebevoll umgesetzter Lizenztitel, der den Charme des Films in ein kompaktes, forderndes Puzzle-Erlebnis für zwei kleine Pixelhelden übersetzte. Für Freunde klassischer Movie Games bleibt The Goonies auch heute noch ein kleiner, blinkender Goldschatz im Labyrinth der Retrogeschichte.

2400 A.D. – 1987 by Origin Systems

2400 A.D. – 1988 by Origin Systems

314527 2400 ad dos front cover2400 A.D. von Origin Systems war eines dieser Spiele, das mit großen Ambitionen gestartet wurde – und mit einem leisen „bitte vergessen“ im Firmenarchiv endete. Entwickelt von Chuck Bueche, besser bekannt als „Chuckles“, der zuvor als Entwickler bei Ultima I–IV sowie Autoduel tätig war, erschien der Titel 1988 für den Apple II und MS-DOS – und hätte eine neue Sci-Fi-Rollenspielreihe einläuten sollen. Stattdessen wurde er zum Paradebeispiel für verpasste Chancen bei einem eigentlich hochinteressanten Cyberpunk-Konzept.

Das Spiel versetzt den Spieler in die dystopische Stadt Metropolis auf dem Planeten XK-120, wo eine Roboterdiktatur das tägliche Leben unterjocht. Als Mitglied des Widerstands sollte man durch Gespräche, kleinere Aktionen und gelegentliche Gewaltakte das Regime nach und nach destabilisieren. Vom Gameplay erinnerte vieles an Ultima IV: Top-down-Ansicht, Tastenkürzel für Aktionen, ein rudimentärer Parser für Gespräche und eine offene Spielwelt, die man erkunden konnte, sobald man eine Ahnung hatte, was überhaupt zu tun war. Der Humor blitzte gelegentlich durch – etwa durch Bewohner mit Namen wie „Sven the Janitor“, der völlig belangloses Zeug von sich gab. Wer sich jedoch eine epische Story oder moralische Entscheidungsfreiheit erhoffte, wurde enttäuscht. Der Plot plätscherte dahin, und die immer gleichen Roboter-Patrouillen nervten schneller, als einem lieb war.

Chuck Bueche hatte ursprünglich größere Pläne. In internen Konzeptzeichnungen, die später auf Messen kursierten, war von mehreren Städten, einem Bahnnetz, Außenmissionen und sogar städtischen Bezirksaufständen die Rede. Auch ein erweitertes Dialogsystem mit thematischen Auswahloptionen wurde getestet – fiel aber wegen mangelnder Speicherressourcen weg. Der Parser blieb also dumm wie ein Toaster: Wer das richtige Schlagwort nicht tippte, bekam „I don't understand“ als Antwort. Das machte viele Quests zu Rätseln mit der Methode „raten und hoffen“.

Produziert wurde das Spiel mit für Origin typischem Aufwand: Es lag eine faltbare Stadtkarte bei, ein dickes Handbuch und – tatsächlich – kleine Metall-Miniaturen von Robotern, als wolle man ein Tabletop-Spiel simulieren. Diese Aufmachung war vielleicht auch nötig, um den Preis von knapp 50 Dollar zu rechtfertigen, was inflationsbereinigt etwa 130 Euro heute entspricht. Richard Garriott, Mitbegründer von Origin, stand hinter der Veröffentlichung, hatte aber mit der Entwicklung selbst wenig zu tun. Die Promotion war dennoch typisch großspurig: In Anzeigen hieß es, 2400 A.D. sei „the next evolution in science fiction role playing“, eine neue Dimension sei erreicht worden – der damals übliche Werbe-Overkill.

Doch die Verkaufszahlen blieben weit hinter den Erwartungen zurück. Weder Apple-II- noch PC-Spieler wollten sich auf das experimentelle Setting einlassen. Viele kritisierten die langsame Performance auf älteren Maschinen, das belanglose Missionsdesign und die seelenlose Welt. In einem seltenen Interview sagte Chuck Bueche später: „Wir haben die Essenz eines RPGs genommen, aber dabei vergessen, den Spieler auch zu motivieren.“
Ein Spieletester der Computer Gaming World war noch direkter: „Wenn man sich bei 2400 A.D. langweilt, liegt das nicht an einem selbst – es liegt am Spiel.“

Eine Portierung auf den Commodore 64 war zwar intern mal Thema, wurde aber nie über das Planungsstadium hinausgeführt. Entgegen mancher Mythen war John Romero nicht an einer C64-Version beteiligt – auch wenn er zu der Zeit bei Origin arbeitete. Stattdessen wurde recht bald das bereits begonnene Sequel 2500 A.D. eingestellt, nachdem klar war, dass Teil eins kommerziell gefloppt war. Bueche verließ Origin kurz darauf und widmete sich dem Studium. Rückblickend war 2400 A.D. so etwas wie sein letzter großer Alleingang.

Einige interessante Details zur Produktion: Die Stadt Metropolis basierte laut Designer-Skizzen auf einer Mischung aus sowjetischen Stadtentwürfen der 1970er-Jahre und texanischen Einkaufszentren – kein Witz. Die Robotertypen hatten interne Codenamen wie „Smashbot“, „Zapbot“ und „Snitchbot“, letzterer war ein besonders nerviger Denunziant, der in jeder Gasse zu stehen schien. Es gab ursprünglich auch eine moralische Skala für den Spieler – bei zu brutaler Vorgehensweise hätten sogar Mitkämpfer das Vertrauen verloren. Auch das fiel dem Rotstift zum Opfer.

Die Kritiken waren – höflich gesagt – mittelmäßig. MobyGames listet keine internationalen Wertungen, aber Fanreviews pendeln zwischen „nette Idee, langweilige Umsetzung“ und „mehr als eine Tech-Demo ist das nicht“. Besonders heftig war das Urteil in einem Rückblick der Amiga Power, die (sinngemäß) meinten: „2400 A.D. sieht aus wie ein Ultima, spielt sich wie ein Schachspiel ohne Regeln.“
Ein Nutzer auf MyAbandonware schrieb trocken: „Ich wollte Widerstandskämpfer sein. Stattdessen habe ich Möbel umstellt und mit Robotern über Faxgeräte gesprochen.“

Komponisten oder Sounddesigner wurden im Abspann nicht genannt – ein weiteres Indiz dafür, dass Musik und Atmosphäre bei diesem Titel nicht Priorität hatten. Soundeffekte gab es, aber sie waren rudimentär, und auf vielen Systemen sogar deaktiviert, wenn der Arbeitsspeicher zu knapp wurde.

Heute ist 2400 A.D. ein kurioses Relikt – nicht wirklich gut, aber in seiner Mischung aus ambitioniertem Worldbuilding und blutleerem Gameplay irgendwie charmant. Es ist ein Beispiel dafür, wie sich große Ideen im Labyrinth der Limitierungen verlieren können. Und es ist der Beweis, dass selbst bei Origin Systems nicht alles Gold war, was auf Klappkarte gedruckt wurde.

Wer möchte, kann es über DOSBox spielen. Die DOS-Version umfasst knapp 200 kB und läuft sogar auf 8088-kompatiblen Maschinen mit CGA. Und vielleicht, nur vielleicht, entdeckt man beim nächsten Durchspielen etwas, das die damalige Rebellion doch noch rechtfertigt. Wahrscheinlich aber nicht.

 

Wings of Fury – 1988 by Brøderbund

Wings of Fury - 1988 by Brøderbund

Wings of Fury, von Brøderbund im Dezember 1987 veröffentlicht, war ein ungewöhnlicher, stilisierter Mix aus Shoot-'em-up und Simulation, der sich in der Ästhetik eher an Spielhallenklassiker anlehnte, inhaltlich jedoch überraschend ernst war. Entwickelt wurde das Spiel ursprünglich von Steve Waldo, einem der weniger bekannten, aber technisch versierten Designer, der zuvor an Tools und internen Konvertern für Brøderbund mitgearbeitet hatte. Die Musik und Sounds wurden von Kris Hatlelid beigesteuert, wobei die PC-Version mangels Sound-Hardware auf einfache Effekt-Cues beschränkt blieb. Die Amiga- und Apple-II-Versionen nutzten einfache Sampleeffekte und systemnahe Töne, boten aber keine musikalische Untermalung im eigentlichen Sinne.

Die Entstehungsgeschichte von Wings of Fury begann laut einer internen Brøderbund-Mitteilung bereits 1986, als Steve Waldo erste Prototypen entwickelte, die sich an Side-Scrolling-Flugspielen wie Choplifter oder Defender orientierten, aber eine realistische Physik und ballistische Berechnung einführen wollten. In einem seltenen Interview aus der Zeitschrift Compute! (Ausgabe Juni 1989) sagte Waldo: „Ich wollte ein Spiel, das so einfach zu bedienen ist wie ein Arcade-Shooter, aber die Ernsthaftigkeit des Zweiten Weltkriegs mit sich trägt. Kein Fantasiekrieg, sondern realistisch, direkt, ohne Filter.“ Der Produktionsprozess war relativ schlank: Innerhalb von etwa acht Monaten wurde die Kernversion für den Apple II fertiggestellt, wobei viele der Sprites handgezeichnet und pixelweise optimiert wurden. Die Entwickler testeten die Wirkung von Bomben auf animierte Soldaten in verschiedenen Variationen – ein Detail, das später für Kritik sorgte.

Das Spiel versetzt den Spieler in die Rolle eines US Navy-Piloten im Pazifikkrieg 1944. Als Pilot eines F6F Hellcat jagt man von einem Flugzeugträger aus japanische Flakstellungen, Nachschubtruppen, Landungsboote, Radaranlagen und Flugplätze. Gesteuert wird dabei aus einer seitlichen 2D-Perspektive. Die Steuerung kombiniert Flugphysik mit direkter Arcade-Steuerung: Geschwindigkeit, Fluglage und Flughöhe müssen koordiniert werden, um präzise Bombenabwürfe, Torpedoeinsätze oder Bordmaschinenangriffe auszuführen. Landungen auf dem eigenen Flugzeugträger – der sich ebenfalls in Bewegung befindet – gehören zu den schwierigsten, aber auch eindrucksvollsten Momenten. Munition ist begrenzt, Nachladen und Reparaturen erfordern präzises Landen.

Die Kombination aus realer Militärgeschichte, schwarzhumoriger Gewalt und Arcade-Mechanik sorgte für eine geteilte Rezeption. Die US-Presse lobte das Spiel nahezu durchweg – Compute! sprach von einem „komplexen, aber unterhaltsamen Kriegsspiel, das gleichzeitig pädagogisch und fesselnd“ sei. In Deutschland fiel die Berichterstattung zurückhaltender aus. Die Zeitschrift 64'er lobte 1989 die technische Umsetzung, merkte aber kritisch an, dass „die Darstellung von explodierenden Menschen in einem Spiel dieser Art unnötig martialisch“ wirke. Besonders auf dem C64, dessen Version vom Studio Cascade Games konvertiert wurde, sorgten die teils expliziten Animationen der sterbenden Soldaten für Diskussionen. In Frankreich wurde das Spiel aufgrund seiner Thematik teilweise zensiert vertrieben.

Wings of Fury erschien ursprünglich auf dem Apple II undMS-DOS, später folgten offizielle Portierungen für Commodore 64, Amiga, sowie eine japanische Version für den Sharp X68000, die nicht nur technisch, sondern auch inhaltlich stark verändert wurde. In der exklusiven X68000-Version übernimmt der Spieler nicht die Rolle eines amerikanischen Piloten, sondern steuert eine japanische Mitsubishi A6M Zero und kämpft gegen amerikanische Streitkräfte. Die Level, Menüs, Sounds und Animationen wurden neu gestaltet, um der japanischen Perspektive auf den Krieg zu entsprechen – eine komplette kulturelle Umkehrung des ursprünglichen Spiels. Damit war die X68000-Version keine reine Portierung, sondern eine vollständig lokalisierte Neuinterpretation mit hoher grafischer Qualität und historisch angepasstem Narrativ. Technisch war sie zudem deutlich anspruchsvoller: flüssigere Parallax-Scrolling-Effekte, detailliertere Explosionen und eine ausgefeiltere Kollisionslogik machten sie zu einer der hochwertigsten Fassungen überhaupt.

Insgesamt wurden weltweit schätzungsweise über 250.000 Einheiten verkauft, was angesichts der ernsten Thematik bemerkenswert war. Das Spiel wurde nie offiziell fortgesetzt, obwohl ein Prototyp mit dem Titel Wings of Fury II 1992 bei Brøderbund kursierte, später aber eingestellt wurde. 2001 erschien ein inoffizielles Remake für Windows-PCs, das Gameplay und Grafik modernisierte, aber ohne Lizenz durch kleinere Entwickler realisiert wurde.

Trivia: Die Figur des Piloten blieb namenlos, doch in einem Mockup für das Handbuch der Amiga-Version wurde er „Lt. J. R. Hayes“ genannt – ein Hinweis auf einen echten US-Piloten, der 1944 über Iwo Jima abgeschossen wurde. Entwickler Waldo sagte dazu nur: „Ich wollte keine Heldenromantik. Das war ein Krieg, kein Abenteuerfilm.“ Ein weiterer interessanter Aspekt: Die Gravity-Engine von Wings of Fury wurde später von Brøderbund intern bei Prince of Persia inspiriert übernommen – insbesondere das ballistische Verhalten der Fallbewegungen. Entwickler Jordan Mechner bestätigte später in seinen Notizen von 1989, dass Wings of Fury als eines von drei physikbasierten Vorbildern diente.

Apple III

Apple III

Apple IIIAls Apple im Mai 1980 den Apple III vorstellte, galt er als ambitioniertes Vorhaben, das den erfolgreichen Apple II beerben und das Unternehmen aus dem Heimcomputersegment in den lukrativeren Markt für Business-Computer führen sollte. Die Erwartungen waren immens, denn Apple hatte sich mit dem Apple II als führender Hersteller in der Bildungs- und Hobbyszene etabliert, doch um Unternehmen wie IBM und DEC herauszufordern, musste ein professionelleres Gerät entstehen – leistungsfähiger, robuster und mit echtem Betriebssystem. Der Apple III wurde somit von Anfang an als Business-Maschine positioniert, mit höherem Arbeitsspeicher, besseren Textdarstellungsfähigkeiten und einem professionelleren Gehäuse. Doch die Realität entwickelte sich anders: Der Apple III wurde später berüchtigt als eines der größten Technikdesaster der frühen Computerindustrie.

Im Kern des Apple III arbeitete ein Synertek 6502A-Prozessor mit 2 MHz, eine leicht übertaktete Variante des bekannten MOS 6502, der auch im Apple II, Commodore PET und später im Commodore 64 zu finden war. Der 6502 war ein 8-Bit-Prozessor mit 16-Bit-Adressraum und einfacher Architektur, die ihn für kostengünstige Systeme attraktiv machte. Er konnte mit sehr wenigen Transistoren arbeiten, was niedrige Produktionskosten und geringeren Stromverbrauch zur Folge hatte. Der 6502 verfügte über drei 8-Bit-Register (A, X, Y), einen 16-Bit-Program Counter, einen Stackpointer und einen Status-Register, was ihn sehr gut für kompakte Maschinenprogrammierung geeignet machte. Für den Apple III jedoch war dieser Prozessor ein Anachronismus: Während IBM für seinen 1981 vorgestellten PC auf einen 16-Bit-Prozessor (den Intel 8088) setzte, verblieb Apple bei 8-Bit-Technik, wenn auch mit cleverer Architektur. Der Apple III konnte über spezielle Speicherbankumschaltung bis zu 512 KB RAM adressieren, weit mehr als der Apple II. Dennoch wurde der Prozessor bald als Engpass empfunden.

Der Startpreis des Apple III betrug bei seiner Vorstellung 4.340 US-Dollar, was inflationsbereinigt im Jahr 2025 etwa 14.700 Euro entspricht. Für diese Summe erhielt man einen Rechner mit 128 KB RAM, eingebautem 5¼-Zoll-Diskettenlaufwerk, monochromem Textbildschirm mit 80×24 Zeichen und dem neuen Betriebssystem SOS – dem Sophisticated Operating System. Die Preise waren deutlich höher als beim Apple II, der zu dieser Zeit je nach Konfiguration zwischen 1.000 und 2.000 Dollar kostete. Apple wollte sich bewusst vom Heimcomputermarkt absetzen, doch das Preis-Leistungs-Verhältnis wurde von vielen Zeitgenossen als ungünstig kritisiert. In der InfoWorld vom Oktober 1981 hieß es: „Apple verlangt einen Premiumpreis für einen Computer, der in vielen Belangen kaum mehr bietet als sein Vorgänger.“

Ein zentrales Problem des Apple III war sein Aufbau: Steve Jobs bestand darauf, dass der Rechner keine Lüfter oder Lüftungsschlitze enthalten dürfe – aus ästhetischen Gründen. Dies führte zu massiven Hitzeproblemen. Die Chips überhitzten häufig, der integrierte Diskettencontroller löste sich buchstäblich aus dem Sockel, und das System wurde instabil. Apple musste bereits Ende 1980 die gesamte erste Produktionsreihe zurückrufen. Etwa 14.000 Geräte wurden überarbeitet oder ausgetauscht. Dies führte zu einem enormen Imageverlust. In einem internen Memo bezeichnete ein Apple-Manager das Gerät als „technisch zu früh geboren“. Spätere Revisionen des Apple III (etwa ab 1982, oft informell als „Apple III+“ bezeichnet) verbesserten die Situation durch geänderte Sockel, optionale Lüfter und überarbeitete Platinen Layouts, doch das Vertrauen war bereits verloren.

Als Massenspeicher verwendete der Apple III zunächst ein integriertes 143-KB-Diskettenlaufwerk (Apple Disk III), später auch das externe Apple ProFile-Festplattenlaufwerk mit 5 MB Kapazität – eines der ersten Festplattenlaufwerke im Personal-Computer-Bereich. Die Apple ProFile war allerdings teuer (über 3.000 Dollar) und nur über spezielle Karten ansteuerbar. Der Apple III verfügte über mehrere Erweiterungssteckplätze, einen Centronics-kompatiblen Drucker Port, einen seriellen Port (RS-232) und konnte über ein spezielles Interface auch mit AppleTalk-Netzen verbunden werden. Vorgesehen waren zudem Mausunterstützung, Farbmonitore, SCSI-Controller und externe Laufwerke, doch viele dieser Geräte erschienen verspätet oder gar nicht.

Der Bildschirm des Apple III war standardmäßig monochrom und zeigte 560×192 Pixel, wobei durch besondere Tricks auch Bitmapped-Grafik mit Farbanpassung möglich war – in Farbe war jedoch eine externe Grafikkarte nötig. Die Farbfähigkeiten waren theoretisch vorhanden, aber stark eingeschränkt. Der Rechner konnte maximal 16 Farben anzeigen, allerdings nicht simultan im Hochauflösungsmodus. Da jedoch kaum Programme die Farbmöglichkeiten unterstützten, blieb der Apple III faktisch ein monochromes System. Seine physischen Abmessungen lagen bei etwa 38×45×13 cm mit einem Gewicht von rund 10 kg – für damalige Verhältnisse ein sehr kompakter Businesscomputer. Als Soundchip kam keine dedizierte Lösung zum Einsatz, sondern der interne Speaker wurde direkt über den CPU-Takt gesteuert. Klanglich blieb der Apple III damit auf dem Niveau des Apple II, das heißt: einfache Piepser ohne Mehrstimmigkeit oder Musikfähigkeiten.

Das Betriebssystem SOS, das Apple eigens für den Apple III entwickelte, war der eigentliche technische Höhepunkt des Systems. Es unterstützte Dateien mit Metadaten, ein echtes Device Management, Benutzerverzeichnisse, feste Dateitypen und ein modulares Treibersystem – Konzepte, die später im Macintosh wiederkehren sollten. Die API war objektorientiert und systematisch dokumentiert, was Programmierer sehr schätzten. Leider war die Einstiegshürde hoch, und viele Entwickler scheuten die Umstellung. Außerdem war der Softwaremarkt für den Apple III schwach. Nur rund 200 Programme erschienen, meist Buchhaltungs- und Datenbanksoftware wie VisiCalc III, Apple III Pascal, Profile Pascal, Word Juggler oder Apple III BASIC. Spiele existierten kaum.

Die Hauptentwickler des Apple III waren unter anderem Wendell Sander, ein früher Apple-Ingenieur, der bereits am Apple II beteiligt war und als Hauptarchitekt des Apple III gilt. Sander war bekannt für seine detailverliebte Arbeit an Systembussen und Speicherzugriffen, doch sein technisches Design wurde durch die Designvorgaben von Jobs und durch Zeitdruck eingeschränkt. Auch Jef Raskin, später bekannt durch seine Rolle beim Macintosh-Projekt, war beteiligt, zog sich jedoch bald zurück. Rod Holt, der für die Stromversorgung beim Apple II bekannt war, war ebenfalls involviert, allerdings nicht federführend.
Der Apple III verkaufte sich über die gesamte Laufzeit hinweg nur etwa 65.000-mal – ein Bruchteil der über zwei Millionen verkauften Apple II-Modelle. Im April 1984 stellte Apple die Produktion endgültig ein, nachdem der Macintosh angekündigt worden war. Die meisten Einheiten wurden an US-Firmen verkauft, insbesondere an Universitäten und kleinere Buchhaltungsfirmen. In Europa blieb der Apple III weitgehend unbekannt.
Gegenüber seinem Vorgänger, dem Apple II, bot der Apple III einen professionelleren Gesamteindruck, mehr RAM, eine höhere Auflösung, ein echtes Betriebssystem und integrierte Massenspeicheroptionen. Doch der Preis, die Hitzeprobleme, der Mangel an Software und die geringe Entwicklerunterstützung ließen ihn als Fehlschlag gelten. Gegenüber der IBM-PC-Familie, die ab 1981 den Markt dominierte, fehlte dem Apple III schlicht die Rechenleistung und Standardkompatibilität. Der 8-Bit-Prozessor, das fehlende Betriebssystem-Ökosystem und die hohen Preise machten ihn unattraktiv. Selbst gegenüber dem CP/M-Markt oder frühen MS-DOS-PCs war der Apple III technologisch und wirtschaftlich unterlegen.

Ein Artikel in Byte Magazine von 1982 fasste es trocken zusammen: „Der Apple III ist wie ein Sportwagen, der ständig überhitzt, nicht richtig startet und nur auf bestimmten Straßen fahren kann. Schön, aber unpraktisch.“ Heute gilt der Apple III als Lehrstück in der Technikgeschichte – ein ambitioniertes Projekt, das an Designidealen, Zeitdruck und Marktverkennung scheiterte. Gleichzeitig bereitete es mit SOS und seiner Architektur den Boden für die Entwicklung des Macintosh, der später Apples wahre Antwort auf den Businessmarkt wurde.

Auch wenn der Apple III als Büromaschine entwickelt wurde, gab es einige Spiele für das System, beispielsweise Apple III Chess, das speziell für das Apple III entwickelt wurde und unter SOS lief. Es bot im Vergleich zu Apple II-Versionen ein ausgefeilteres Interface, eine höhere Bildschirmauflösung (Textmodus mit 80×24 Zeichen) und eine stärkere KI-Routine, die auf den erweiterten Arbeitsspeicher zugreifen konnte. Es war aber sehr langsam in höheren Schwierigkeitsstufen, da der 6502-Prozessor trotz doppelter Taktung (2 MHz) gegenüber dem 8088 des IBM PC schwächelte.

Mit Star Thief III portierte man ein erweitertes Action Game, dass exklusiv für das neue Flaggschiff angepasst wurde. Im Vergleich zur Apple II-Version hatte es eine bessere Steuerung über die numerische Tastatur, zusätzliche Level und leicht erweiterte Grafik. Es wurde in wenigen Apple-Händlerkatalogen erwähnt, war aber kommerziell unbedeutend.

Einige Hobbyisten und kleinere Entwicklerstudios veröffentlichten einfache Spiele, die speziell in Apple III Business BASIC oder SOS BASIC geschrieben wurden. Darunter befanden sich Spiele wie Hangman III, Treasure Cave oder Space Courier, die in Apple-Usergruppen oder über Diskettenversand vertrieben wurden. Diese Titel waren technisch einfach, nutzten aber gelegentlich die strukturierte Dateiverwaltung und die 80-Zeichen-Darstellung von SOS.

Apple hatte mit dem Apple III einen Rechner geschaffen, der keine Marktdurchdringung geschaffen hatte. Die technischen Probleme und die fehlende Spielkultur im Businessbereich taten ihr Übriges. Zudem war das SOS-Betriebssystem mit seiner anspruchsvollen API nicht attraktiv für Spieleentwickler, die lieber die große installierte Basis des Apple II nutzten. Eine Rückwärtskompatibilität zum Apple II war zwar theoretisch vorhanden – der Apple III konnte in einen Apple II-Modus booten – aber dieser war hardwareseitig unvollständig und fehleranfällig, sodass viele Apple II-Spiele dort nicht funktionierten.

Sid Meier’s Pirates! – 1987 by Microprose

Sid Meier's Pirates! - 1987 by Microprose

Sid Meier's Pirates! CoverSeien wir ehrlich, wie viele Spiele existierten in den 1980ern, die tatsächlich wahre Zeitfresser waren und das nicht aufgrund eines mörderischen Schwierigkeitsgrades? Es fallen Euch etliche Spiele ein? Schön, aber wie viele Eurer Titel haben eine Verbindung mit dem Schauspieler Robin Williams? Gut, Zelda gäbe es da noch, aber hier beschäftigen wir uns mit dem anderen großartigen Game. Für mich, wahrlich mit das Größte…

Sid Meier’s Pirates! erschien 1987 und markierte einen Wendepunkt in der Geschichte der Computerspiele. Es war das erste Spiel, das den Namen seines Designers im Titel trug – eine Entscheidung, die auf einen Vorschlag des Schauspielers Robin Williams zurückging. Williams empfahl bei einem Treffen mit MicroProse-Mitgründer Bill Stealey, Sid Meier als Star zu vermarkten: „Bill, du solltest Sids Namen auf ein paar dieser Schachteln setzen und ihn als Star promoten.“

Anfang 1986 wollten Sid Meier und sein Kollege Arnold Hendrick bei MicroProse ein Rollenspiel-Abenteuer entwickeln. Doch Meiers Geschäftspartner Bill Stealey stand dem Vorhaben skeptisch gegenüber – er hielt nicht viel von Spielen, die keine Fahrzeugsimulationen waren. Das Unternehmen hatte sich damit seit der Gründung hervorgetan und Bill Stealey, als ehemaliger Captain der US Air Force, setzte weiterhin seinen Fokus auf dieses Genre. Doch Sid Meier hatte sich in der Gaming Szene bereits einen Namen machen können, wieso also diesen nicht für Marketing Zwecke verwenden?

Daher entschied man sich, seinen Namen erstmals auf die Verpackung eines Spiels zu setzen – auch wenn es sich von den Kampfsimulatoren unterschied, mit denen Meier berühmt geworden war. Die Idee dazu soll von einem besonderen Treffen stammen: „Wir waren bei einem Abendessen während einer Tagung der Software Publishers Association, und die Hollywood Legende Robin Williams („Good Morning, Vietnam“, „Mork and Mindy“ oder „Mrs. Doubtfire“) war auch da“, erinnerte sich Stealey. „Er brachte uns zwei Stunden lang zum Lachen. Dann drehte er sich zu mir und sagte: 'Bill, du solltest Sids Namen auf ein paar dieser Schachteln drucken und ihn als Star promoten.'“

Das Spiel wurde hauptsächlich in Commodore BASIC geschrieben. Ursprünglich sollte es „Pirates of the Spanish Main!!“ heißen. Einige geplante Elemente, wie mehrere NPCs pro Stadt, detailliertere Seeschlachten und Handlungsstränge zu Religion und Adel, wurden vor der Veröffentlichung entfernt.

Die Entwicklung dauerte etwa acht Monate. Meier übernahm dabei fast alle Aufgaben selbst, mit Ausnahme der Grafik. Erst mit diesem Spiel wurden bei MicroProse spezialisierte Grafiker eingestellt, was Meier ermöglichte, sich auf Programmierung und Spieldesign zu konzentrieren. Zusätzlich ließ er sich bei der Entwicklung von einem technischen Trick inspirieren: „Einer unserer Programmierer hatte eine coole Methode entwickelt, Bilder zu erstellen, indem er sie in Schriftarten packte. Das ermöglichte es uns, sehr schnell neue Bilder einzufügen.“ Pirates! wurde hauptsächlich in Commodore BASIC geschrieben. Lediglich das Segeln im Hauptspiel wurde, um die Geschwindigkeit zu steigern, in Assembler verwirklicht.

Pirates! kombiniert Rollenspiel, Wirtschaftssimulation und Echtzeitstrategie. Der Spieler übernimmt die Rolle eines Kapitäns in der Karibik des 16. bis 18. Jahrhunderts und kann sich entscheiden, als Pirat, Freibeuter, Piratenjäger oder einfach nur als Händler zu agieren. Das Spiel bietet eine offene Welt mit Städten, Seegefechten, Duellen und Schatzsuchen. Meier betonte, dass das Spiel eher auf der Fantasie als auf historischer Genauigkeit basiere: „Pirates! wurde mehr um deine Fantasie von Piraten herum entworfen als um die tatsächliche Realität.“ und weiter: „Wir machen oft den Scherz, dass wir die Recherche erst nach der Fertigstellung des Spiels machen. Wenn ich zu viele Bücher lese, entwickle ich am Ende ein Spiel, das auf den Büchern basiert. Pirates! drehte sich um Piratenfilme, nicht um die historische Epoche“ Dennoch waren etliche Teile des Spiels akkurat dargestellt, etwa die Städte in den unterschiedlichen Epochen. Waren Städte im 16. Jahrhundert noch nicht vorhanden, konnten diese bereits hundert Jahre später blühende Metropolen darstellen. Darüber hinaus entwarf Sid eine gewisse Dynamik, die dem Spiel zugutekam: Die Plünderung von Städten durch den Spieler oder andere Piraten veränderte deren Zustand. Nach einem Beutezug war die Stadt militärisch geschwächt und konnte einer anderen Nation leicht in die Hand fallen. Auch existierten Schiffe, die nicht in jeder Epoche zugänglich waren, da sie zu jener Zeit noch nicht oder nicht mehr existierten.

Der Soundtrack wurde von Ken Lagace komponiert. Für die NES-Version, die 1991 von Rare entwickelt und von Ultra Games veröffentlicht wurde, komponierte David Wise die Musik. Wise ist bekannt für seine Arbeit an Spielen wie Donkey Kong Country. Pirates! wurde für zahlreiche Plattformen portiert, darunter Apple II, IBM PC, Amiga, Atari ST und NES. Die NES-Version ersetzte Tabak durch „Getreide“, um Nintendos familienfreundlichen Richtlinien zu entsprechen.

Das Spiel erhielt durchweg positive Kritiken. Das Magazin Dragon bewertete es 1988 mit 5 von 5 Sternen. Computer Gaming World nannte es einen „Durchbruch im Genre“ und verlieh ihm 1988 den Titel „Action Game of the Year“. Pirates! gewann auch zwei Origins Awards: „Best Fantasy or Science Fiction Computer Game of 1987“ und „Best Screen Graphics in a Home Computer Game of 1987“.  In Deutschland erhielt es vom Magazin Amiga Joker (01/1991) die Auszeichnung „Bestes Adventure Spiel 1990" und gehört, nach Meinung der GameStar 2013 zu den „zehn besten C-64 Spielen“.

Der Erfolg von Pirates! führte zu mehreren Neuauflagen. 1993 erschien Pirates! Gold mit verbesserten Grafiken. 2004 wurde ein umfassendes Remake für moderne Plattformen veröffentlicht. Mobile Versionen folgten in den Jahren danach.