Mit DOOM II habe ich als Kind nicht nur Dämonen erlegt - ich habe eigene Level entworfen und vor allem daran herumprogrammiert. Und ehrlich gesagt war mir genau das immer lieber als das Spielen: Stundenlang Sektoren ziehen, Verhalten umprogrammieren, Fallen austüfteln - das war mein Spiel. Dreißig Jahre später wollte ich wissen: Kann ich so etwas heute komplett selbst programmieren - ein ganzes Doom, im Browser, mit moderner Grafik?
Programmiert habe ich es selbst - aber nicht allein. Zum Einsatz kam Claude Code von Anthropic mit dem Fable-5-Modell und Ultracode, dem Multi-Agenten-Modus: Statt dass eine KI brav Zeile für Zeile mittippt, orchestriert man einen ganzen Schwarm. Ich habe die Architektur vorgegeben, Schnittstellen festgelegt, Befunde entschieden und korrigiert - der Schwarm hat gebaut, geprüft und gefixt. Das Ergebnis: Ich war schätzungsweise hundertmal so schnell wie gewöhnlich. Was früher ein Jahr Feierabende gekostet hätte, passierte an einem Abend.
Die Idee.
Ein First-Person-Shooter in Three.js, direkt im Browser. Nur eine Waffe, die Pump-Schrotflinte, ganz klassisch. Medipacks und Munition liegen im Level verteilt. Und statt abstrakter Sci-Fi-Korridore sollte das Level eine echte Kleinstadt in einem engen Flusstal nachbilden - mit Burgruine über den Dächern, Fachwerk-Marktplatz mit Drachentöter-Brunnen, zwei Kirchen, einer alten Brauerei, Gerberhäusern am Bach und einem Bahnhof, an dem das Abenteuer beginnt. Welche Stadt das Vorbild ist, verrate ich nicht - wer sie kennt, erkennt sie.
Der Spielverlauf ist eine einzige lange Wegstrecke, wie ein klassisches Doom-Level, nur durch echte Gassen: Ankunft am Bahnhof, vorbei an der alten Lederfabrik, rüber zum Marktplatz mit Brunnen und Pavillon, durch die Fachwerkgassen zur Gerbergasse am Bach, hinauf zur alten Brauerei - und am Ende die Serpentine hoch zur Burgruine, wo im Burghof das große Finale wartet.
Ein Zeitreise-Problem.
Einen Logikbruch habe ich allerdings noch nicht gelöst - und ich weiß ehrlich gesagt noch nicht, wie. Ich will das Spiel im Jahr 1592 spielen lassen, dem Jahr, das im Schwellbalken des schönsten Fachwerkhauses der Stadt eingeschnitzt ist. Nur passt dann einiges nicht mehr zusammen: Im Spiel prangt „Alte Brauerei" über der Hofeinfahrt - 1592 wäre die aber weder alt gewesen noch überhaupt gebaut. Die Burgruine war damals auch keine Ruine, sondern eine stolze, bewohnte Burg: Gesprengt haben sie erst die Franzosen, gut hundertvierzig Jahre später. Und der Bahnhof samt Gleisen, an dem das Spiel beginnt, ist noch einmal ein gutes Jahrhundert jünger. An der Story, wie das alles gleichzeitig existieren kann, muss ich also noch feilen. Vielleicht sind es ja die Dämonen, die beim Einfall die Zeit selbst durcheinandergebracht haben - das wäre immerhin sehr Doom.
Sieben Bauarbeiter, sechs Prüfer, eine Spezifikation.
Sieben Bau-Agenten entwickelten parallel und unabhängig voneinander je ein Modul: prozedurale Texturen, die Stadt, die Spielersteuerung samt Schrotflinte, die Gegner-KI, die Pickups, das HUD, den komplett synthetisierten Sound. Als Vertrag diente meine Schnittstellen-Spezifikation - und tatsächlich: Beim allerersten Integrationsversuch lief das Spiel durch. Kein einziger Konsolenfehler.
Danach übernahmen sechs strenge Prüf-Agenten, jeder mit eigenem Fachgebiet. Sie spielten das Spiel unsichtbar im Hintergrund, schossen über hundert Beweisfotos, maßen mit Telemetrie nach [dreht die Q-Taste wirklich mit 150 Grad pro Sekunde? Rutscht man an der Hauswand entlang, statt kleben zu bleiben?] und vergaben Punkte. Die Urteile waren gnadenlos: „Die Talhänge sind flache, texturlose Farbflächen." „3652 Drawcalls statt budgetierter 400." „Das HUD-Gesicht ist ein generischer Marine - gefordert war das Porträt mit roter Krawatte." Recht hatten sie. Fix-Agenten arbeiteten die Befunde ab, dann wurde erneut geprüft.
Das Ganze lief als Loop: prüfen, Befunde sammeln, fixen, wieder prüfen - so lange, bis alle Prüfer bestehen. Solche Schleifen sind für mich der eigentliche Hebel beim Arbeiten mit KI: Statt sich mit der ersten Antwort zufriedenzugeben, baut man einen Kreislauf, der sich selbst kontrolliert - und definiert nur noch die Qualitätslatte, ab der Schluss ist. Ich habe die Loops hier auch ganz bewusst eingesetzt, um mich tiefer in diese Technik einzuarbeiten. Denn wer KI ernsthaft nutzen will, muss genau solche Muster beherrschen - Prompts formulieren kann inzwischen jeder.
Der Minecraft-Himmel.
Mein Lieblingsfehler des Projekts: Auf den ersten Screenshots hingen am Abendhimmel harte weiße Rechtecke - als hätte jemand Minecraft-Wolken in mein stimmungsvolles Abendrot kopiert. Der Schuldige war eine einzige Zeile im Himmels-Shader, die das Wolkenrauschen ohne Interpolation berechnete: Jede Rauschzelle bekam einen harten Einheitswert, fertig war die Klötzchen-Optik. Mit echtem weichem Fraktal-Rauschen wurden daraus sanfte, rötliche Schleierwolken. Von Minecraft zu goldener Stunde in einem Commit.
Und noch etwas haben die Prüfer schonungslos offengelegt: Mein Spiel ist stellenweise schlicht zu düster. In der Fachwerkgasse lagen 83 Prozent der Pixel fast im Schwarz - Stimmung ja, aber man erkennt nichts mehr. DOOM II hat das 1994 besser hinbekommen: ein durch und durch düsteres Spiel, in dem trotzdem immer alles erkennbar blieb. Licht setzen können, ohne das Bild absaufen zu lassen - das war damals Handwerk und ist es heute noch.
Der Preis: ein glühender Laptop und eine Million Token.
Und dann die Ernüchterung, über die kaum jemand schreibt: Dieses Projekt war ein Ressourcenfresser epischen Ausmaßes. Das Spiel und sein Test-Schwarm - zeitweise liefen zehn unsichtbare Browser-Instanzen parallel, die alle dasselbe 3D-Spiel in Software renderten - zogen so viel Strom, dass mein Akku in Minuten schlappmachte. Selbst mit angeschlossenem Netzteil ging der Laptop irgendwann einfach aus: Er verbrauchte schlicht mehr, als das Netzteil liefern konnte. Dazu kamen über eine Million KI-Token in wenigen Stunden. Da ist noch viel zu optimieren - am Spiel, und an meinem Umgang mit Agenten-Schwärmen.
Warum Doom in Gebäuden spielte.
Das Wertvollste an diesem Projekt ist eine Erkenntnis, die dreißig Jahre auf mich gewartet hat. Ich habe mich früher nie gefragt, warum Doom eigentlich immer in Basen, Bunkern und Höllenfestungen spielte und nie in einer offenen Stadt. Jetzt weiß ich es: weil eine Stadt unbezahlbar ist. Eine offene Kleinstadt mit fünfzig Häusern, Fluss, Burgberg und freier Sichtachse bis zum Horizont frisst Drawcalls, Geometrie und Licht in einem Ausmaß, das selbst moderne Hardware ächzen lässt - von 1994 ganz zu schweigen. Die engen Korridore von damals waren keine künstlerische Marotte, sie waren geniale Sparsamkeit. John Carmack hat nicht in Gebäuden gebaut, weil es düsterer war. Er hat in Gebäuden gebaut, weil Wände die beste Grafikoptimierung der Welt sind.
Ich habe bei diesem Projekt enorm viel gelernt - über Three.js, über prozedurale Texturen, über das Orchestrieren von KI-Agenten, und über die Physik von Netzteilen. Aber das eigentliche Fazit ist ein anderes: Am Ende werde ich wohl doch wieder das tun, was ich schon als Kind am liebsten getan habe - Level programmieren. Für das Original. Für das Meisterwerk. Denn manchmal ist die beste moderne Technik die, die einem zeigt, wie gut die alte wirklich war.
Das Spiel selbst läuft komplett im Webbrowser und ist spielbar. Eingebaut habe ich es hier bewusst noch nicht: Ein Shooter mit Blut und Bestien müsste streng genommen ab 18 freigegeben sein - und eine Alterskontrolle passt nicht zu einer offenen Homepage. Die Screenshots ohne die Dämonen müssen vorerst reichen.