Schlagwort-Archiv: Andrew Braybrook

Uridium (1986): Woran man einen Braybrook erkennt

Einen Van Gogh erkennen viele auch ohne Kunststudium: an der unruhigen Pinselführung und den kräftigen Farben, oft noch bevor Sonnenblumen oder Zypressen ins Bild kommen. Auch Andrew Braybrooks Spiele besaßen Mitte der achtziger Jahre eine erkennbare Handschrift. Metallische Oberflächen gewannen durch harte Schatten räumliche Tiefe, Fahrzeuge und Roboter wirkten wie Bauteile einer größeren Maschine.

Uridium zeigt diese Merkmale bereits auf dem ersten Bildschirm. Ein kleiner Raumjäger gleitet über die Oberseite eines gewaltigen Kriegsschiffs, vorbei an Landebahnen, Generatoren und technischen Aufbauten. Zeitgenössische Tester erkannten darin sofort den Stil von Paradroid. Commodore User verwies auf Braybrooks bekannte Metalloptik, Your Commodore sprach von „pseudo 3D metallic graphics“, Zzap!64 hob die Reliefwirkung der Schatten hervor.

Trotzdem wiederholte Braybrook seinen Vorgänger nicht. Paradroid verband Erkundung, Roboterklassen, Kämpfe und das Übernahmesystem. Uridium konzentrierte sich auf die Bewegung eines einzigen Fahrzeugs. Der vertraute Metallic Look blieb erhalten, während sich Grafik, Steuerung und Programmstruktur einem neuen Ziel unterordneten: Geschwindigkeit.

Die Zahl, die das Spiel bestimmte

Nach mehreren Dragon-32-Konvertierungen wechselte Braybrook zum Commodore 64, den er zunächst bei der Umsetzung von Steve Turners Lunattack kennenlernte. Mit Gribbly’s Day Out und Paradroid folgten eigene Spiele. Für Uridium setzte er sich ein klares technisches Ziel: 50 Bildschirmaktualisierungen pro Sekunde auf einem PAL-C64.

Gribbly’s Day Out hatte nach seiner späteren Erinnerung ungefähr 25 Bilder pro Sekunde erreicht, Paradroid etwa 17. Für das neue Spiel strich er Funktionen, die zu viel Rechenzeit beanspruchten, und hielt den Entwurf bewusst einfacher. Braybrook beschrieb die Manta später als Ferrari: Die hohe Geschwindigkeit sei vorhanden, der Spieler müsse sie aber nicht auf jeder Strecke ausnutzen.

Damit verlagerte sich der Anspruch. Paradroid verlangte den Überblick über mehrere miteinander verbundene Systeme. Uridium verlangte die Beherrschung eines ungewöhnlichen Fluggeräts und die genaue Kenntnis der gegnerischen Schiffe.

Ein Kriegsschiff als Spielfeld

Fünfzehn Super-Dreadnoughts umkreisen Planeten und entziehen ihnen Rohstoffe. Jeder verarbeitet ein anderes Metall. Der Spieler übernimmt einen Manta-Raumjäger und soll die Schiffe nacheinander zerstören.

Ein Dreadnought ist dabei kein einzelner Gegner. Das gesamte Level liegt auf seiner Oberseite. Mauern, Generatorfelder, Antennen und Landebahnen ziehen horizontal unter der Manta hindurch. Feindliche Jäger greifen in Formationen an, Generatoren setzen zielsuchende Minen frei. Kleine Ziele können beschossen werden, hohe Aufbauten müssen umflogen werden.

Die Manta steuert sich anders als das übliche Schiff eines horizontalen Shoot-’em-ups. Der Joystick regelt Flughöhe und Geschwindigkeit. Starkes Abbremsen löst eine Kehrtwende aus: Der Jäger steigt kurz an, rollt über die Seite und fliegt in der Gegenrichtung weiter. Mit gedrücktem Feuerknopf lässt er sich außerdem um 90 Grad auf die Seite legen, sodass seine schmalere Silhouette durch enge Passagen passt.

Wende und Seitenrolle verändern Richtung, Höhe und Kollisionsfläche. Beide benötigen Platz und müssen ebenso bewusst eingesetzt werden wie die Waffen. Wer an der falschen Stelle abbremst, kann nach dem Manöver unmittelbar vor dem nächsten Aufbau landen.

Sobald genügend Angriffswellen abgewehrt wurden, erscheint „Land Now“. Der Spieler setzt auf der Hauptlandebahn auf; danach folgt die Fuel Rod Chamber. Die Anleitung beschreibt diesen Abschnitt als Entfernung von Brennstäben aus dem Metallkonverter. Spielerisch funktioniert er wie die Risikofunktion eines britischen Geldspielautomaten: Der Bonus steigt, während der Spieler rechtzeitig „Quit“ wählen muss. Verpasst er den Ausstieg, verliert er ein Leben. Your Commodore verglich den Ablauf bereits 1986 mit dem „gamble feature on a fruit machine“.

Nach dem Bonusspiel hebt die Manta wieder ab, während sich der Dreadnought von hinten nach vorn auflöst. Der wiederkehrende Ablauf aus Luftkampf, Landung und Abflug gibt den vergleichsweise kurzen Levels eine klare Form.

Wie der C64 das Tempo hält

Hewson warb in der Anleitung mit 50 Bildschirmzyklen pro Sekunde, Einzelpixel-Scrolling sowie einer Verbindung aus Hardware- und Software-Sprites. Eine spätere Untersuchung des veröffentlichten Programms macht nachvollziehbar, wie diese Leistung erreicht wurde.

Der unter dem Pseudonym mwenge arbeitende Autor untersuchte die C64-Fassung mittels Reverse Engineering. Er disassemblierte den Maschinencode, identifizierte Routinen und Datenstrukturen und kommentierte den rekonstruierten 6510-Assemblercode. Es handelt sich um eine nachträgliche Rekonstruktion des ausgelieferten Programms, nicht um Braybrooks ursprünglichen Quelltext. Der Code lässt sich wieder zu einer lauffähigen Fassung assemblieren und erlaubt daher einen genauen Blick auf die tatsächlichen Abläufe.

Die Hauptschleife läuft synchron zum Rasterstrahl des Fernsehbildes. Der VIC-II baut das Bild Zeile für Zeile auf und löst an festgelegten Rasterpositionen Interrupts aus. Sobald der Rasterstrahl den unteren Bildschirmbereich erreicht, beginnt die nächste Runde der Spielberechnungen. Das Programm aktualisiert unter anderem Schüsse, Scrollposition, Oberfläche, Sterne, Gegner und Eingaben und wartet anschließend auf dieselbe Phase des nächsten Fernsehbildes. Auf einem PAL-C64 wiederholt sich dieser Takt 50-mal pro Sekunde. Weniger dringende Aufgaben werden über mehrere Durchläufe verteilt.

Die Dreadnoughts liegen nicht als vollständige Bilder im Speicher. Ihre Oberflächen bestehen aus Zeichengrafik, die Braybrook aus wiederverwendbaren Bauteilen zusammensetzt. Größere Verschiebungen erfolgen in ganzen Zeichenpositionen, die Pixel dazwischen bewegt das Feinscrolling des VIC-II. Der Prozessor muss deshalb nicht fortlaufend eine komplette Bitmap neu zeichnen.

Auch der Sternenhintergrund entsteht innerhalb dieser Zeichengrafik. Das Programm verschiebt die Pixel besonderer Sternzeichen entgegen der Scrollrichtung. Die Metallfläche zieht vorbei, während die Sterne scheinbar im Weltraum stehen bleiben. Eine zweite frei bewegliche Hintergrundebene ist dafür nicht erforderlich.

Manta, Schatten und Gegner verwenden Hardware-Sprites. Die Laserschüsse zeichnet das Programm dagegen in veränderbare Bildschirmzeichen. Nach jedem Bewegungsschritt stellt es den ursprünglichen Hintergrund wieder her und setzt den Schuss an seiner neuen Position ein. So bleiben die begrenzten Hardware-Sprites für größere Objekte frei. Gary Liddon erwähnte diese Softwaregeschosse bereits im damaligen Zzap!64-Test.

Der Schatten der Manta belegt einen eigenen Sprite und wird abhängig von der Flughöhe versetzt. Zwei flache Grafiken vermitteln dadurch Abstand zur Oberfläche. Steve Turner schrieb die dreistimmige Titelmusik und programmierte die Soundeffekte; während des Spiels bleibt der Klang auf kurze Schüsse, Explosionen und Signale konzentriert.

Wenn die Geschwindigkeit weiter reicht als der Bildschirm

Das schnelle Scrolling erzeugt zugleich die deutlichste Schwäche des Spiels. Bei hohem Tempo zeigt der sichtbare Ausschnitt nur wenig von der vorausliegenden Strecke. Mauern und enge Durchgänge erscheinen spät, viele Stellen lassen sich beim ersten Versuch kaum sicher einschätzen.

Zzap!64 nannte den kleinen Bildausschnitt als wesentlichen Kritikpunkt und betonte, dass die Karten der Dreadnoughts gelernt werden müssten. Die Tipps des Sinclair User zur späteren Spectrum-Fassung empfahlen ebenfalls, sich den Aufbau einzuprägen, um mit voller Geschwindigkeit fliegen zu können.

Aus einem zunächst hektischen Flug entsteht dadurch eine feste Folge gelernter Manöver: vor einem Aufbau abbremsen, während der Wende über eine Mine steigen und den nächsten Kanal in Seitenlage durchqueren. Diese Streckenkenntnis gibt den kurzen Schiffen mehr Substanz, bringt aber Wiederholungen mit sich.

Die zeitgenössische Presse bewertete die technische Ausführung deutlich höher als die Grundidee. Zzap!64 vergab 94 Prozent und erklärte Uridium zu einem der stärksten Arcade-Spiele des C64. Commodore User und Your Commodore sahen Einflüsse von Defender und Scramble, lobten jedoch die präzise Steuerung, das Tempo und Braybrooks metallische Grafik.

Auch die deutschen Tests hoben Scrolling, räumliche Wirkung und Klang hervor. Happy Computer stellte zugleich fest, dass Uridium weniger strategische Tiefe als Paradroid besaß. Die ASM vergab Höchstnoten für Grafik und Sound, bewertete Spielidee und Motivation niedriger. Die Magazine beschrieben damit dieselbe Spannung: eine vertraute Shooter-Grundlage, ausgeführt mit einer für den C64 außergewöhnlichen technischen Sicherheit.

Dominic Robinson baut Uridium für den Spectrum neu

Die Spectrum-Fassung stand vor einem grundsätzlichen Problem. Braybrook hatte das Original um die Fähigkeiten des C64 gebaut. Der ZX Spectrum besaß weder Hardware-Sprites noch einen vergleichbaren Grafikchip für Feinscrolling; seine blockweise Farbdarstellung erschwerte schnelle, farbige Objekte zusätzlich.

Dominic Robinson begann mit einer technischen Demonstration. Sie zeigte, dass sich eine an Uridium erinnernde Oberfläche auf dem Spectrum mit mindestens 25 Bildern pro Sekunde scrollen ließ. Andrew Hewson hielt das zunächst kaum für den Ausgangspunkt eines vollständigen Spiels, weil die Demo den Hintergrund mehrfach im Speicher hielt. Steve Turner zog den gegenteiligen Schluss und drängte darauf, Robinson zu verpflichten.

Für die fertige Umsetzung reduzierte Robinson die Farbigkeit der Dreadnoughts. Große Teile des Spielfelds blieben zweifarbig, wodurch die Konturen bei hoher Geschwindigkeit lesbar blieben und viele Attributkonflikte vermieden wurden. Der Klang fiel schlichter aus als auf dem C64.

Sinclair User lobte das schnelle und gleichmäßige Scrolling. Die dort genannten 17 Bilder pro Sekunde stammten ausdrücklich aus dem Werbematerial und waren keine unabhängige Messung. Das Magazin vergab fünf Sterne und die Auszeichnung „Sinclair User Classic“. CRASH kam auf 90 Prozent, vermerkte aber auch die schwächere Farbwirkung und eine weniger unmittelbare Reaktion der Manta beim Wenden.

Robinson übertrug damit nicht jede Eigenschaft gleichwertig. Er bewahrte jedoch den schnellen Flug über eine zusammenhängende Oberfläche, die Richtungswechsel, die engen Passagen und den Wechsel zwischen Angriff und Landung. Diese Elemente hielten Uridium auch auf einer sehr anderen Maschine zusammen.

Zwei Joystickstandards und ein erfundenes Element

Der ursprüngliche ZX Spectrum besaß keinen eingebauten Joystickanschluss. Viele Besitzer verwendeten ein externes Kempston-Interface, das Spiele über eine eigene Ein-/Ausgabeadresse abfragten. Sinclair nutzte für seine Joysticklösung ein anderes Verfahren. Der Spectrum 128K +2 besaß zwar zwei eingebaute Buchsen, verwendete softwareseitig aber den Sinclair-Standard.

Ein Programm mit Kempston-Unterstützung erkannte die Anschlüsse des +2 deshalb nicht automatisch. Genau daran scheiterte die erste Auflage von Uridium. Obwohl die Verpackung Kompatibilität versprach, funktionierten frühe Exemplare am +2 nur über die Tastatur. Sinclair User zitierte einen Hewson-Sprecher:

“There was a problem with early batches of the game but that's been sorted-out and the new version of the game is fully compatible with the 128K +2 joystick.”

„Bei den frühen Versionen des Spiels gab es ein Problem, das inzwischen behoben wurde. Die neue Version ist vollständig mit dem Joystick-Anschluss des 128K +2 kompatibel.“

Hewson bestätigte damit den Fehler und lieferte eine korrigierte Fassung. Welche Routinen geändert wurden, wäre nur durch einen Vergleich beider Versionen festzustellen.

Der Titel des Spiels geht auf Robert Orchard zurück, einen früheren Kollegen Braybrooks bei GEC. Orchard hielt „Uridium“ offenbar für ein reales Element oder verwechselte es mit Iridium. Die Überprüfung ergab, dass es den Begriff nicht gab, was ihn für Graftgold gerade brauchbar machte. Die Anleitung vermerkt:

“Name created by Robert ‘I thought it really existed’ Orchard”

„Der Name wurde von Robert ‚Ich dachte, das gäbe es wirklich‘ Orchard erfunden.“

Der erfundene Name passt zu einer Welt aus metallischen Kriegsschiffen, während die fünfzehn Dreadnoughts nach tatsächlichen Elementen benannt sind.

Uridium ist an seinen Metallflächen und Schatten sofort als Braybrook-Spiel zu erkennen. Geprägt wurde es jedoch von seinem technischen Ziel. Levelaufbau, Grafiktricks und Steuerung mussten mit dem Tempo des Scrollings zusammenarbeiten. Dominic Robinsons Spectrum-Fassung bestätigte später, dass genau diese Bewegung den Kern des Spiels bildete.

 

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)

U.F.O. – 1987 by Odin Computer Graphics / Firebird

U.F.O. - 1987 by Odin Computer Graphics / Firebird

ufo coverIm Jahr 1987 erschien im Rahmen von Firebirds berüchtigter „Silver Range“-Budgetserie ein Spiel, das auf den ersten Blick wie ein weiterer Space-Shooter wirkte, sich bei genauerem Hinsehen aber als technisches Kuriosum mit cleveren Detailideen entpuppte: U.F.O., entwickelt von Odin Computer Graphics für den Commodore 64, ein Spiel, das sich mit gerade einmal £1.99 in den Läden einsortierte, aber dennoch ein Stück Entwicklerhandwerk bewies, das über reines Massenfutter hinausragte – zumindest in der Theorie.

Der Spieler schlüpft in die Rolle eines Piloten des experimentellen Abfangjägers F21 "Condor" – einer Mischung aus Jet und Raumgleiter –, der in mehreren Wellen die Erde gegen anrückende Alienformationen verteidigen muss. Auf den ersten Blick handelt es sich um einen horizontal scrollenden Shooter im Stile von Defender oder Uridium, doch U.F.O. verzichtet auf freies Scrollen und setzt stattdessen auf einen Bildschirm-nach-Bildschirm-Wechsel mit festen Kampfzonen. Zwischen diesen Gefechten schaltet das Spiel in ein separates „Hypersonic Air Corridor“-Segment, in dem der Spieler seinen Gleiter durch einen engen Korridor voller Hindernisse manövrieren muss. Diese Sequenzen erinnern an eine Art Mini-Simulator in schnellerem Tempo, das Spieltempo zieht merklich an, die Steuerung wird trägheitsbasiert. Diese Tempowechsel bildeten das spielmechanische Rückgrat und sollten laut damaligen Entwicklern die monotone Repetition klassischer Budget-Shooter durchbrechen.

Eine auffällige Innovation lag im Waffenüberhitzungssystem: Die Bordkanone des Condors verfügte über eine Temperaturanzeige, die bei Dauerfeuer anstieg. Wurde die Schwelle überschritten, versagte die Waffe – der Spieler musste ausweichen oder notlanden. Außerdem besaß der Condor einen Energieschild, der nach Einsatz über Zeit wieder aufgeladen werden musste, was der actionlastigen Ballerei einen Hauch von Strategie mitgab. Für ein Spiel dieser Preisklasse war das ungewöhnlich.

Die Entwicklungsverantwortung lag bei Robert W. Tinman, der als Hauptprogrammierer agierte. Tinman war für Odin kein Unbekannter: Er hatte zuvor an Titeln wie Mission AD gearbeitet. Unterstützt wurde er im Grafikbereich von Andy Rixon, Andy Rowson und Martin Chatfield. Chatfield war später u.a. als Designer bei Spielefirmen wie Core Design und Probe tätig. Die Musik wurde von Keith Tinman komponiert, der ebenfalls für Odin arbeitete. Sein Soundtrack in U.F.O. nutzt die Möglichkeiten des SID-Chips effektiv aus, auch wenn er aus Platzgründen nur im Titelbild erklingt – das Spiel selbst bleibt weitgehend stumm.

u.f.o.Die Entwicklung fand unter knappen Budget- und Zeitrahmen statt. Laut einem nicht autorisierten Interview auf Spectrum Computing arbeitete das Team lediglich sechs Wochen an dem Titel. Eine geplante Version für den ZX Spectrum wurde verworfen – zu wenig Markt, zu hoher Portierungsaufwand für die dort fehlenden Hardwaresprites. Ursprünglich war U.F.O. als Teil einer Serie von Firebird-Budgettiteln geplant, die jeweils neue Spielmechaniken testen sollten. Ein Prototyp mit größerem Spielbereich und vertikaler Bewegung wurde zugunsten des Screen-by-Screen-Layouts gestrichen. Ebenso war eine Bosskampfsequenz in Planung, in der ein riesiges Mutterschiff über mehrere Bildschirme hinweg bekämpft werden sollte. Diese Phase wurde laut Entwicklernotizen aus Speichergründen verworfen – das Spiel nutzt nahezu die kompletten 64 KB des Commodore 64 aus.

Was die Vermarktung betrifft, so erschien U.F.O. lediglich in Europa. Eine geplante US-Version unter dem Arbeitstitel „Invaders '86“ wurde nie umgesetzt. Firebird bewarb das Spiel fast ausschließlich über Kleinanzeigen in Zeitschriften wie Commodore User und Zzap!64. Die Resonanz fiel nüchtern aus. Zzap!64 gab dem Spiel magere 19 %, kritisierte insbesondere die fehlende Originalität und das monotone Gameplay: „Klingt nach einer tollen Idee, aber wenn man’s spielt, sehnt man sich nach dem nächsten Tape-Seitensprung.“ Your Commodore vergab immerhin 4/10, lobte die Präsentation, monierte jedoch die steife Steuerung.

Der kommerzielle Erfolg war begrenzt. Schätzungen gehen von ca. 8.000 verkauften Einheiten in Großbritannien aus, was für ein Budgetspiel im unteren Mittelfeld lag. Andere Firebird-Titel wie Thrust oder Booty verkauften sich um ein Vielfaches besser. Auch eine Portierung für den Amstrad CPC wurde angedacht, aber nie realisiert. In Sammlerkreisen erzielt die Original-Kassette mit Inlay heute Preise zwischen £10 und £14, was inflationsbereinigt etwa £30–40 entspricht.

Interessante Trivia zum Spiel bietet der Code selbst: Eine kommentierte Version, die durch eine geleakte Source-Diskette von Odin im Jahr 2003 auftauchte, enthält Hinweise auf einen ursprünglich geplanten „Zweispieler-Modus“, bei dem abwechselnd zwei Spieler dieselben Level absolvieren sollten. Diese Funktion blieb jedoch unvollständig. Ebenfalls im Code findet sich der humorvolle Kommentar:

„If this overheats again, I’m buying a Speccy.“ (Wenn das wieder überhitzt, kaufe ich einen Speccy)

Offenbar ein interner Scherz zwischen den Entwicklern, der sich auf die zu diesem Zeitpunkt häufigen SID-Chip-Crashs bei Dauerklangwiedergabe bezog.

Auch die Namensgebung des Schiffs – „Condor F21“ – war kein Zufall. In frühen Konzeptzeichnungen hieß das Vehikel „Falcon“, wurde aber umbenannt, da Falcon Patrol von Virgin bereits existierte. Ein Testflug-Level mit Codenamen „Area G-9“ wurde gestrichen, da er thematisch zu nah an Uridium lag. Dies zeigt, wie sehr sich Entwickler damals auch innerhalb des engen Genres noch um Originalität bemühten.

Rückblickend ist U.F.O. ein Paradebeispiel für das, was Budgetspiele der späten 1980er-Jahre auf dem Commodore 64 oft waren: eine Mischung aus ambitionierter Mechanik, eingeschränkter Umsetzbarkeit und kommerziellem Pragmatismus. Es ist weder besonders erfolgreich noch besonders innovativ – aber gerade die kleinen Ideen, wie die Hitzemechanik oder der Hyperspace-Korridor, machen es zu einer charmanten Fußnote im großen Katalog von Firebird. Es ist ein Spiel, das mehr wollte, als es durfte, und damit vielleicht auch mehr ist, als es scheint.