In der Fortuna in Salzburg hab ich als Jugendlicher hunderte Schilling in einen einzigen Automaten geschoben. Pixelig, brutal schnell, gnadenlos schwer. Defender, Baujahr 1980, ist bis heute eines der am schwersten zu meisternden Arcade-Spiele überhaupt. Meine These: Genau diese Kombination aus Nostalgie und technischer Faszination macht Defender zum perfekten Testfall für Vibe Coding mit mehreren Claude-Modellen. Nach diesem Artikel weißt du, wie ein Modellwechsel innerhalb eines einzigen Projekts konkret abläuft, welche Rolle Fable 5 und Opus 5 dabei jeweils spielen, und warum ein 46 Jahre altes Arcade-Prinzip immer noch taugt, um moderne KI-Werkzeuge zu testen. Fangen wir bei der Spielhalle an, die es heute nicht mehr gibt.
Was war die Fortuna, und warum saß ich dort stundenlang vor Defender?
Wer aus der Generation X kommt, kennt das Bild noch: verrauchte Räume, blinkende Cabinets, der Geruch von warmem Plastik und Metallmünzen. Die Fortuna in Salzburg war für mich genau dieser Ort. Heute ist dort der Lux Club drin, das Gebäude steht noch, die Automaten sind längst verschrottet oder in Sammlerhänden. Ich hab dort einiges an Taschengeld verbrannt, und Defender war das Spiel, bei dem ich am längsten durchgehalten habe, bevor mich ein Lander erwischt hat.
Williams Electronics hat Defender 1980 herausgebracht, entwickelt unter der Leitung von Eugene Jarvis, der davor Pinball-Automaten programmiert hatte und mit Defender sein erstes Videospiel überhaupt ablieferte. Fünf Buttons plus ein zweiachsiger Joystick, für damalige Verhältnisse eine absurd komplexe Steuerung. Bei der Branchenmesse AMOA im November 1980 haben die meisten Besucher einen Bogen um den Automaten gemacht, zu einschüchternd. In den Spielhallen war es dann genau umgekehrt: Menschentrauben um das Cabinet, weil das Spiel so anders war als alles davor. Am Ende wurden über 55.000 Einheiten verkauft, mehr als eine Milliarde Dollar an Einnahmen, und laut dem National Museum of Play in Rochester zählt Defender bis heute zu den einflussreichsten Automatenspielen der Videospielgeschichte. Diese Details habe ich mir nicht ausgedacht, ich hab sie extra nachrecherchiert, weil meine eigene Erinnerung an „irgendwann Anfang der Achtziger“ zu ungenau war.
Was Defender damals besonders gemacht hat: Es gab zum ersten Mal eine Spielwelt, die größer war als der sichtbare Bildschirmausschnitt. Ein Radar oben zeigt, was rechts und links außerhalb deines Blickfelds passiert. Zehn Humanoide stehen auf der Planetenoberfläche, Lander greifen sie sich und tragen sie nach oben, erreicht ein Lander mit Humanoid den Bildschirmrand, wird er zum aggressiveren Mutanten. Rette den Humanoiden in der Luft, bekommst du 500 Punkte, setzt du ihn sicher ab, nochmal 500. Verlierst du alle zehn, explodiert der Planet, und du kämpfst gegen eine Welle voller Mutanten auf leerem Terrain. Genau dieses Spielprinzip habe ich für 2026 übernommen, fast eins zu eins.
Was ist Vibe Coding eigentlich, und was hat das mit einem Urlaub in Italien zu tun?
Vibe Coding heißt: Du beschreibst einer KI in normaler Sprache, was du bauen willst, und sie schreibt den Code. Du selbst tippst keine Zeile. Was du steuerst, sind Anforderungen, Feedback und die Entscheidung, wann ein Ergebnis wirklich gut genug ist. Ich hab darüber schon öfter geschrieben, unter anderem in meinem Erfahrungsbericht zum Umstieg vom BASIC-Zeiler auf den Vibe Coder, wo ich beschreibe, wie mein Weg vom Commodore VC 20 über C64 und Amiga 1000 mich heute im Umgang mit KI-Modellen anders arbeiten lässt als jemanden ohne diesen Hintergrund.
Die Idee zu Defender 2026 kam mir im Urlaub. Kein Laptop griffbereit, nur die Erinnerung an dieses eine Spiel und die Frage, wie es wohl aussehen würde, wenn man es heute mit adaptierter Grafik neu bauen würde. Zurück am Schreibtisch hab ich das Projekt tatsächlich durchgezogen.
Es geht mir nicht darum, ein Retro-Museum nachzubauen, sondern darum, den Spielfluss von 1980 mit heutigen Rendering-Möglichkeiten zu verbinden.
Genau das war auch die Vorgabe an die Modelle: die Pixelästhetik als Grundton behalten, aber mit Bloom, Tiefenschärfe und richtigem Licht arbeiten, das 1980 technisch schlicht unmöglich war.
Wie ich Defender 2026 tatsächlich gebaut habe: Fable 5 plant, Opus 5 baut
Der Ablauf war bewusst zweistufig, und das ist der Teil, der über das reine Nostalgieprojekt hinausgeht. Fable 5 hat den Plan gemacht: Spielmechanik, technische Architektur, welche Bibliotheken sinnvoll sind, wie die Weltgröße und die Wellen-Tabelle strukturiert werden. Danach hat Claude Opus 5 in zwei Iterationen das eigentliche Spiel als Browsergame umgesetzt. Diese Aufteilung, starkes Modell für Strategie und Grundsatzentscheidungen, ein anderes für die konkrete, urteilsintensive Umsetzung, ist kein Zufall, sondern eine Vorgehensweise, die ich in der Praxis inzwischen öfter einsetze. Ich hab die Details dazu bereits in meinem Artikel über den Modellwechsel mitten in einer Aufgabe beschrieben, dort auch mit der konkreten Aufteilung: Fable 5 für Strategie und Architektur, Opus 5 für anspruchsvolle Umsetzung, Sonnet 5 für Entwürfe und Varianten, Haiku 4.5 für Fleißarbeit in Serie.
Technisch steht Defender 2026 auf Three.js, Vanilla JavaScript in ES Modules, gebaut mit Vite. Reines Frontend, keine Server-Logik, keine externen Assets. Kein einziges Bild, keine Audiodatei liegt im Projekt. Alle Modelle sind aus Three.js-Primitiven zusammengesetzt, sämtliche Geräusche werden zur Laufzeit über die WebAudio API synthetisiert, Texturen entstehen live auf dem Canvas. Das war mir wichtig, weil es zeigt, wie weit man mit reiner Berechnung statt Asset-Bibliotheken kommt, wenn man die KI konsequent in diese Richtung lenkt.
Die Spielwelt ist eine Ringwelt mit 12.000 Einheiten Umfang, also rund 6,75 Bildschirmbreiten, die nahtlos umläuft, kein Rand, kein Reset. Die komplette Wrap-Mathematik dafür sitzt zentral in einer einzigen Datei, das war eine der ersten Architekturentscheidungen aus der Fable-5-Planungsphase, damit spätere Anpassungen nicht querbeet im Code verstreut sind. Die Game Loop läuft mit einem Fixed-Timestep von 60 Hz, unabhängig von der tatsächlichen Bildwiederholrate des Monitors, so bleibt das Spielgefühl konstant, egal ob jemand auf einem 60-Hz- oder einem 144-Hz-Bildschirm spielt. Das Gelände besteht aus drei prozedural erzeugten Bergketten in unterschiedlichen z-Ebenen, die Parallaxe entsteht rein durch die Kameraperspektive, ohne dass irgendetwas händisch verschoben wird.
Für den Bloom-Effekt, die Tonwertkorrektur, chromatische Aberration, die Vignette, Scanlines und das Filmkorn rendert der Composer in ein vierfach abgetastetes Render-Target. Ohne diesen Zwischenschritt wäre das Antialiasing wirkungslos gewesen und sämtliche Kanten wären hart geblieben, was besonders bei den Pixel-Ästhetik-Elementen sofort aufgefallen wäre. Performance war mir dabei nicht egal: Gemessen liegt der Frame bei rund 4,8 Millisekunden bei 168 gleichzeitigen Gegnern auf dem Bildschirm, also gut das Dreifache der Reserve, die für stabile 60 Bilder pro Sekunde nötig ist. Einzig der allererste gerenderte Frame nach dem Laden kostet einmalig etwa 50 Millisekunden, weil die Shader dann erst übersetzt werden. Geschosse, Partikel und Gegner laufen über Object Pooling, damit die Garbage Collection des Browsers nicht mitten im Gefecht für Ruckler sorgt.
Warum der Modellwechsel selbst die eigentliche Story ist
Ich hätte das ganze Spiel auch mit einem einzigen Modell durchziehen können. Hab ich aber bewusst nicht gemacht, und das war kein Zufall. Wenn ich Fable 5 direkt mit der Umsetzung beauftragt hätte, wäre der Plan wahrscheinlich in der Codebasis versickert, weil sich Architekturentscheidungen und Implementierungsdetail vermischt hätten. Getrennt durch einen bewussten Modellwechsel bleibt die Struktur oben sauber sichtbar, und Opus 5 konnte sich in der Umsetzungsphase voll auf konkrete Probleme konzentrieren: Wie synchronisiert man Radar-Anzeige und Weltposition, wie verhält sich ein Baiter, wenn eine Welle zu lange dauert, wie fühlt sich das Hyperspace-Risiko mit seinen rund 20 Prozent Absturzwahrscheinlichkeit tatsächlich an, wenn man es spielt.
Über Fable 5 selbst hab ich schon geschrieben, als Anthropic die Mythos-Klasse für alle geöffnet hat, mit Fable als Version mit aktiven Safeguards und Mythos als freigeschaltete Variante für Glasswing-Partner. Für ein Browsergame-Projekt wie Defender 2026 spielt dieser Unterschied praktisch keine Rolle, ich bin klar in dem Bereich, der bei über 95 Prozent der Sessions ohne jeden Fallback durchläuft. Was für mich zählt, ist die Qualität in der Planungsphase: lange Kontextfenster, saubere Architekturentscheidungen, Konsistenz über viele Dateien hinweg.
Ich muss ehrlich sagen, ich war selbst überrascht, wie deutlich der Unterschied in der Codequalität war, als ich das gleiche Projekt früher schon einmal mit einem einzigen Modell durchgezogen hatte. Das Bild hinkt leicht, aber es trifft den Kern: Es ist wie ein Architekt, der den Plan zeichnet, und ein Baumeister, der ihn nach Plan umsetzt, statt beides von derselben Person in derselben Rolle erledigen zu lassen.
Was ist vom Original geblieben, und was ist 2026 neu?
Die Spielregeln sind praktisch unangetastet aus 1980 übernommen. Zehn Humanoide, Lander, die sie stehlen, Mutanten bei Kontrollverlust, der Planetentod nach zehn verlorenen Humanoiden mit Regeneration nach drei Wellen. Wellenbonus mit 100 Punkten pro überlebendem Humanoid, multipliziert mit der Wellennummer. Alle 10.000 Punkte gibt es ein Extraleben und eine Smart Bomb, genau wie damals. Auch das Gegnerroster ist originalgetreu: Lander, Mutant, Bomber, Pod, der beim Ableben Swarmer freisetzt, Baiter als Zeitdruck-Mechanik, und die kleinen, fiesen Minen. Die komplette Balance, Geschwindigkeiten, Punktewerte, Wellentabelle, Gegnerverhalten, Weltgröße, sitzt zentral in einer einzigen Konfigurationsdatei, damit sich der Schwierigkeitsgrad justieren lässt, ohne die eigentliche Spiellogik anzufassen. Auch das war eine bewusste Entscheidung aus der Planungsphase, weil ich weiß, dass ich nach dem ersten Spielen sowieso an der Balance drehen wollen würde.
Neu ist die komplette Rendering-Ebene. 1980 gab es kein Bloom, keine chromatische Aberration, keine echte Tiefenschärfe. Die Steuerung liest heute über event.code, damit das Tastaturlayout, QWERTZ bei mir, QWERTY bei vielen anderen, keine Rolle spielt, alternativ funktioniert auch WASD. Neu ist auch die Bestenliste: Die besten zehn Ergebnisse liegen im localStorage des Browsers, samt Kürzel, erreichter Welle und Datum, mit der klassischen Drei-Buchstaben-Eingabe, die jeder aus der Arcade-Ära kennt. Bewusst pro Gerät und Browser, eine geräteübergreifende Rangliste hätte einen Server gebraucht, und das Spiel sollte konsequent rein statisch bleiben, kein PHP, keine Datenbank, kein Node auf dem Zielserver. Nur .html, .js und .css, die sich per FTP in einen beliebigen Ordner legen lassen und dort sofort laufen, weil Vite konsequent relative Pfade erzeugt.
Die klare Grenze: Desktop mit Tastatur, keine Touch-Steuerung, kein Gamepad, das war für dieses Projekt nicht das Ziel. Und der Ton startet erst nach dem ersten Tastendruck, weil die Autoplay-Regeln moderner Browser das schlicht verlangen, abgefangen über den Startbildschirm.
Warum du das auch ausprobieren solltest
Für mich ist Defender 2026 fertig. Ob dieses eine Spiel aus 1980 auch bei dir dieses Gefühl auslöst, weiß ich nicht, das ist Generation-X-Nostalgie, kein allgemeingültiges Rezept. Bei mir hat es funktioniert: Ich mag das Ergebnis, und ich spiel es tatsächlich wieder, so wie früher in der Fortuna, nur ohne Schillinge.
Und genau das ist der Punkt, den ich dir mitgeben will. Nimm dir irgendeine Idee, die du schon lange mit dir herumträgst, egal ob ein altes Lieblingsspiel, ein kleines Tool für den Alltag oder etwas, das dich einfach neugierig macht. Du brauchst dafür kein Informatikstudium und kein Entwicklerteam. Beschreib Claude, was du willst, lass planen, lass bauen, spiel mit dem Ergebnis, korrigier, wiederhol. Genau dieser Ablauf hat bei Defender 2026 funktioniert, und er funktioniert bei fast jedem abgegrenzten Projekt, das sich in klare Regeln und eine technische Umsetzung trennen lässt.
Was ich dir aus der Praxis mitgebe: Trau dich, für größere Vorhaben bewusst zwischen Modellen zu wechseln, so wie ich es mit Fable 5 für die Planung und Opus 5 für die Umsetzung gemacht habe. Und trau dich vor allem, überhaupt anzufangen. Der erste Prototyp muss nicht perfekt sein, er muss nur existieren, damit du weißt, woran du weiterarbeitest.
Ich bin gespannt, was du daraus machst. Bau dein eigenes Stück Nostalgie, oder bau etwas völlig Neues. Die Werkzeuge dafür liegen längst bereit.
Du willst auch mal Defender spielen? Dann klick doch einfach diesen Button:
