Ich wollte nur spielen. Jetzt baue ich die Spiele um.
Drei Spieleprojekte mit Claude Opus 5.5 haben meinen Blick auf vorhandene Software verändert. Was aktuelle Spiele-Mashups, Ports und Software-Nachbauten möglich machen.
Ich wollte Jak and Daxter auf meinem Handheld spielen. Mehr war der Plan erst einmal nicht.
Ein paar Projekte später laufen Gegner aus Mega Man Battle Network 5 neben Gegnern aus Teil 6. Die Kämpfe finden in derselben Engine statt. Dazwischen erzeugt ein eigenes Programm neue Gebiete und hält einen Run am Leben, den keines der ursprünglichen Spiele vorgesehen hatte.
Als Jak lief, wollte ich das nächste Spiel anpassen. Als das funktionierte, wollte ich wissen, wie viel sich an einem Spiel überhaupt verändern lässt. Spätestens als zwei Battle-Network-Spiele ihre Engine teilten, war ich weit über meinen ursprünglichen Plan hinaus. Und wollte immer noch weiter.
Mein wichtigstes Werkzeug dabei war Claude Opus 5.5, das Anthropic im September veröffentlicht hat.1 Aus „dafür gibt es keinen Build“ wurde „dann ändern wir eben die laufende Engine“. Vorhandene Software fühlte sich plötzlich wie etwas an, das ich auseinandernehmen und nach meinen Wünschen umbauen kann. Diese Möglichkeit reicht inzwischen weit über meinen Handheld hinaus, in andere Spiele und in die Anwendungen, für die wir bezahlen.
Vom Spielen zum Umbauen
Jedes Projekt führte mich eine Ebene tiefer in ein Spiel, das ich ohnehin spielen wollte.
Jak and Daxter: ein fehlender Build
Auf meinem Retroid Pocket Nova läuft ROCKNIX. Für Jak and Daxter gibt es mit OpenGOAL bereits ein beeindruckendes Projekt. Einen passenden fertigen Build für mein Gerät hatte ich allerdings nicht gefunden.
Darum ging es: zurück in die Welt von Jak and Daxter, auf meinem Handheld. Diese Szene und das Titelbild stammen aus der offiziellen OpenGOAL-Promo-Galerie, nicht von meiner Nova.
Die OpenGOAL-Galerie zeigt ziemlich schön, wie viel Leben noch in diesem Spiel steckt.2
Also gab ich dem Agenten SSH-Zugriff auf den Handheld und ein konkretes Ziel: Bring das dort zum Laufen. Er recherchierte, fand den ARM-Ansatz für macOS und nutzte ihn als Ausgangspunkt für mein Linux-System. Die offizielle OpenGOAL-Veröffentlichung 0.3.8 enthält tatsächlich einen macOS-ARM-Build.3
In meiner Session blieb es nicht beim Kompilieren. Der Agent installierte das Ergebnis auf der Nova, startete es, schickte Eingaben und schaute sich Screenshots an. Es folgten Korrekturen, weitere Starts und schließlich ein Spiel, das ich auf meinem Gerät spielen konnte.
Für mich war genau dieser durchgehende Ablauf der erste Aha-Moment. Meine Beschreibung des gewünschten Ergebnisses reichte, um eine Arbeit über mehrere technische Grenzen hinweg anzustoßen. Recherche, Plattformanpassung und Prüfung am Gerät gehörten plötzlich zu einem Auftrag.
Die Grundlage hatte allerdings die OpenGOAL-Community geschaffen. Sie rekonstruiert den ursprünglichen GOAL-Code und stellt einen eigenen Compiler samt Laufzeitumgebung bereit.4 Mein Agent konnte auf dieser Arbeit aufbauen. Dass ich Jak auf einer anderen Maschine spielen konnte, verdanke ich auch Menschen, die das Spiel lange vor meiner Session verstanden haben.
Dungeons of Infinity: ein kleineres Display
Der nächste Wunsch war Dungeons of Infinity. Justin Bohemier hat hier einen prozeduralen Dungeon-Crawler im Stil von A Link to the Past gebaut. Es ist ein eigenständiges GameMaker-Spiel, kein Hack einer SNES-ROM.5
Das Spiel ist wunderbar. Die Bildschirmaufteilung war für meine Nova weniger wunderbar. Ihr Display hat ein Seitenverhältnis von 4:3. Dungeons of Infinity war für 16:9 angelegt: das Spielfeld in der Mitte, zusätzliche Anzeigen links und rechts. Auf meinem Gerät konkurrierten diese Bereiche um Platz.
16:9 auf dem Flip 2: Neben dem Spielfeld ist Platz für die Statusanzeigen. Die Aufnahme zeigt die Breitbildansicht meines Patches, die die ursprüngliche Anordnung beibehält.
Mit Opus entstand daraus Dungeons of Infinity and Beyond. Gesundheit, Magie, aktiver Gegenstand und Vorräte liegen direkt im Spielfeld. Die übrigen Informationen erscheinen bei Bedarf über einen Stick-Klick. Das vollständige Spielfeld bleibt erhalten.6
4:3 auf der Nova: Dasselbe Dorf füllt den Bildschirm. Gesundheit, Magie und Vorräte wandern ins Spielfeld. Beide Vergleichsbilder stammen aus Testspielständen meines Repositorys.
Ein Klick auf den Stick holt den Rest zurück. Ausrüstung, Karte und Etagenfortschritt öffnen sich über dem Spiel, wenn ich sie brauche.
Technisch greifen die Änderungen in das kompilierte GameMaker-Spiel ein. Der Patch nutzt vorhandene Werkzeuge, um GML-Code zu dekompilieren, gezielt zu bearbeiten und wieder zu kompilieren. Prüfungen stellen sicher, dass die erwarteten Originalstellen vor einer Änderung tatsächlich vorhanden sind.7
Danach blieb es nicht bei der Oberfläche. Es kamen Verbesserungen an Menüs, Steuerung und Spielgefühl hinzu. Und dann fiel auf, dass die PortMaster-Fassung hinter der Windows-Version lag.
Also wurde die neuere Windows-Fassung zur zusätzlichen Quelle. Ihr Programm enthält noch benannte Funktionen und Dateninitialisierungen. Daraus ließen sich etwa Edelsteinrezepte und Gegenstandswerte rekonstruieren. Wir übernahmen ausgewählte Funktionen aus 1.2.x in die ältere PortMaster-Basis 1.1.6. Manche Daten und Grafiken ließen sich übertragen, Verhalten musste an die ältere Laufzeit angepasst werden. Vollständige Gleichheit mit 1.2.1 behauptet das Projekt ausdrücklich nicht.8
Hier wurde das Muster für mich sichtbar: Eine Lösung muss nicht für genau mein Gerät vorliegen. Manchmal liegt ein brauchbarer Teil auf einer anderen Plattform. Der Agent kann ihn untersuchen und die Verbindung herstellen.
Cyberworld Endless: neue Regeln in einer alten Engine
Bei Mega Man Battle Network wollte ich wissen, wie weit das geht. Die Reihe gehört zu meinen liebsten Spielen aus der Game-Boy-Advance-Zeit. Mein Ausgangspunkt war Teil 6. Die Idee: Das Original läuft in einem Emulator, und ein eigenes Programm legt eine neue Spielstruktur darum.
Das Ergebnis heißt Cyberworld Endless. Aus der Idee eines endlosen Runs wurde ein Roguelike mit generierten Gebieten, Gegnerbegegnungen, NPCs, Battle-Chips und Gegenständen. Die vertrauten Kämpfe bleiben erhalten, während sich der Weg durch das Netz verändert.9
So sieht das inzwischen aus:
Cyberworld Endless 0.12.0: neue Wege, gemischte Kämpfe, Souls und Bossbegegnungen. Der 36-sekündige Trailer aus meinem Repository hat Ton.
Der Kern ist ein Director, also das Programm, das den Run steuert. mGBA führt den Originalcode von Battle Network 6 aus. Der Director erzeugt neue Kartendaten und ändert Verweise in der ROM-Kopie im Arbeitsspeicher. Er beobachtet den RAM zwischen Frames und reagiert über Hooks auf Ereignisse im Spiel.10
Ein Hook ist dabei eine gezielt gesetzte Eingriffsstelle. Wenn das Spiel dort ankommt, kann der Director ein Ereignis erfahren oder eine vorbereitete Entscheidung liefern. So lässt sich die vorhandene Engine weiterverwenden, während neue Daten und Regeln bestimmen, was sie als Nächstes tut.
DIAGRAM
Das Diagramm vereinfacht den Aufbau. Entscheidend ist die Rückkopplung: Der Director verändert Daten, die Engine verarbeitet sie, und der Director erfährt, was daraus geworden ist. Das Sprachmodell hat diesen Aufbau mit mir entwickelt. Beim Spielen läuft der geschriebene Code. Es fragt kein LLM in jedem Frame nach dem nächsten Gegner.
Vertraute Pixel, neue Wege. MegaMan durchquert eine generierte Ebene im Stil der Sky Area. Kurzer Gameplay-Clip ohne Ton aus dem Repository.
Ich muss deshalb weder das Kampfsystem noch jede Animation neu erfinden. Das Spiel kann diese Dinge bereits. Die interessante Arbeit liegt darin, seine internen Erwartungen zu verstehen und neue Inhalte in einer Form anzubieten, die es verarbeiten kann.
Battle Network 5 in dieselbe Engine zu holen, fühlte sich wie schwarze Magie an.
Pull Request 117 ist inzwischen zusammengeführt. Er bringt Gegner, Chips, Navis und Souls aus Teil 5 in die Engine von Teil 6.11 Damit können Elemente beider Spiele im selben Kampf zusammenkommen.
Achtet auf die Verwandlung und den Schwerthieb: Gegner und ShadowSoul aus BN5 laufen in der Kampfengine von BN6. Gameplay ohne Ton aus Version 0.12.0.
Genau dieser Schwerthieb begeistert mich. Die Animation, die Bewegung, der Treffer: Etwas, das zu einem anderen Spielmodul gehörte, lebt jetzt in diesem.
Nur das Sprite zu kopieren, würde dafür nie reichen. Ein Gegner braucht sein Verhalten. Seine Routine ruft andere Routinen auf, liest Zustände und erwartet bestimmte Datenstrukturen. Kopiere ich sie unverändert an eine neue Adresse, zeigen diese Verweise weiterhin auf die Welt des alten Spiels.
Der Import arbeitet deshalb mit konkreten Rezepten. Beim Start werden benötigte Routinen aus der eigenen BN5-ROM übernommen, Aufrufe auf passende BN6-Funktionen umgebogen und Datenverweise sowie IDs übersetzt. Gemeinsame Tabellen machen die Inhalte für den Director nutzbar. Die Verwandtschaft der beiden Engines hilft enorm.12
Auch außerhalb der Kämpfe wächst das Netz zusammen. BN5s Nebula Area bringt ihre Kacheln und violetten dunklen Löcher in den Run. Aufnahme aus meinem Repository.
Früher wechselte das Projekt für BN5-Kämpfe noch zu einem zweiten Emulator-Kern. Heute bleibt der Run in BN6. Der andere Kern dient als Referenz für Tests. Dieselbe Kampfsituation läuft im Original und mit übertragenem Verhalten. Der Test vergleicht die Zustände entlang des Kampfverlaufs.13
Dieser Vergleich gibt der Arbeit ein überprüfbares Ziel. Die Release-Dokumentation nennt weiterhin verbleibende Abweichungen.14 Auch mit diesen Grenzen können Gegner, Chips und Verwandlungen aus beiden Spielen jetzt in einem Run zusammenkommen.
Spiele werden zu Bestandteilen anderer Spiele
Projekte bringen Marios Bewegungen nach Elden Ring und Skaten auf die Karten von Modern Warfare 2. Mein Battle-Network-Experiment ist Teil einer viel größeren Entwicklung. Spannend ist dabei, wie viel vom Original erhalten bleibt und was sich dafür drumherum ändern musste.
Die öffentlich zugänglichen Implementierungen zeigen, welche unterschiedlichen Methoden hinter ähnlich aussehenden Ergebnissen stecken. Eine Figur in der Spielwelt eines anderen Spiels kann aus einem zweiten laufenden Spiel stammen, aus einer eingebundenen Simulation oder aus neu geschriebenem Code. Diese Unterschiede bestimmen, was nach dem beeindruckenden ersten Clip noch möglich ist.
Zwei laufende Spiele miteinander verbinden
SkyCraft lässt Skyrim und Minecraft gemeinsam laufen. Minecraft übernimmt Bewegung, Bauen und Inventar, während Skyrim seine Welt und Quests beisteuert. Plugins tauschen Informationen über gemeinsam genutzten Speicher aus. In der aktuellen Umsetzung zeichnet Skyrims Renderer auch die Minecraft-Geometrie. Das Projekt ist noch experimentell.1516 Beim Update für zerstörbare Umgebungen wird Claude Opus 5.5 als Mitautor genannt.17
Eine Minecraft-Figur samt Inventar mitten in Flusswald. SkyCraft verbindet zwei laufende Spiele. Screenshot aus dem Projekt-Repository.
Dieser Ansatz kann viel von beiden Originalen bewahren. Dafür müssen sie gut aufeinander abgestimmt sein: Kameras, Positionen, Kollisionen und Eingaben müssen zusammenpassen, damit sich die gemeinsame Welt stimmig anfühlt. Eine Figur an der richtigen Stelle zu zeichnen reicht nicht. Sie muss auch sinnvoll mit dem Boden unter ihr interagieren. Dazu kommt die Verdeckung. Was hinter einer Wand steht, sollte hinter dieser Wand verschwinden.
Eine Spielmechanik in eine andere Engine verpflanzen
Die experimentelle Veröffentlichung von ER Mario geht einen anderen Weg. Sie bindet libsm64 in Elden Ring ein und versorgt Marios Simulation mit Kollisionsflächen aus der Welt von Elden Ring. Marios Bewegung stammt aus der Dekompilierung von Super Mario 64. Elden Ring kümmert sich weiter um seine Welt, Türen, Checkpoints und Spielstände.1819
Mario in der Vulkanfestung. Einzelbild aus Deltaroos ER-Mario-Demo, veröffentlicht bei Arkade.
Die Vorgeschichte gehört dazu. libsm64 stellt Marios Bewegung bereits so bereit, dass sie sich in andere Software einbauen lässt. Die nötigen Spieldaten kommen aus der eigenen ROM-Datei des Nutzers. Jede neue Integration kann dadurch auf jahrelanger Rekonstruktionsarbeit aufbauen.20
Die Skate-Projekte wählen einen weiteren Weg. Die Skate-3-Engine in Rust nennt ausdrücklich mehr als zwei Jahre Reverse Engineering als Vorarbeit für die KI-gestützte Neufassung. Ein verwandtes Mashup kombiniert sie mit einer neu geschriebenen Laufzeitumgebung für Modern Warfare 2 und einer Implementierung der Minecraft-Welt.2122 Die MW2-Laufzeitumgebung dokumentiert weiterhin fehlende Funktionen und Fehler.23 Schon in diesem Zustand zeigt das Projekt, wie die Mechanik eines alten Spiels außerhalb seiner ursprünglichen Programmdatei nutzbar wird.24
Ein Soldat macht einen Kickflip auf Terminal. Sieben Sekunden aus Chasms Mashup-Demo von Skate 3 und MW2, ohne Ton.
Genau diese Möglichkeit begeistert mich am meisten. In einem Bewegungssystem stecken Timing, Beschleunigung, Reibung und Animationsregeln, die jemand über lange Zeit abgestimmt hat. Wer diese Zusammenhänge bewahrt, kann damit auch einen Teil des Spielgefühls erhalten. Ein Ersatz, der nur ähnlich aussieht, verliert womöglich genau das, was ich behalten wollte.
Anpassungen bleiben trotzdem nötig. Die neue Umgebung misst Entfernungen vielleicht anders, berechnet ihre Simulation in einem anderen Takt oder behandelt Kollisionen anders. Ein Sprung, der sich auf einer Karte richtig anfühlt, kann eine andere viel zu einfach machen. Sobald der Code läuft, wartet hinter dem Integrationsproblem ein Problem des Spieldesigns.
Dem ganzen Spiel ein neues Zuhause geben
OpenCE bringt die ursprüngliche Xbox-Version von Halo: Combat Evolved per WebAssembly und WebGL2 in den Browser. Die Dokumentation beschreibt außerdem native Builds und Crossplay. Die zugrunde liegende Dekompilierung profitiert von Debug-Symbolen, die in späteren Halo-Spielen erhalten geblieben sind. Dieser Source-Port baut auf rekonstruierten Strukturen auf und nutzt hilfreiche Hinweise aus verwandten Veröffentlichungen.252627
Halo im Browser, mit Tabs und Adresszeile. Einzelbild aus Mitchell Hynes’ Vorführung seines Browser-Ports vom 28. September.
Für den Browser waren trotzdem Anpassungen nötig. Das Spiel läuft in einem Worker, die Grafik nutzt WebGL2 und der Multiplayer WebRTC. WebAssembly machte außerdem Abweichungen zwischen Funktionssignaturen sichtbar, die x86 toleriert hatte.28 Quellcode eröffnet Möglichkeiten. Er erledigt die Plattformarbeit nicht von allein.
Ein Mac-Port von Need for Speed: Most Wanted nutzt recomp-kit. Das Werkzeug übersetzt x86-Code in C, das anschließend für ARM64 kompiliert werden kann. Eine eigene Schicht bildet die Direct3D-9-Grafikaufrufe des Spiels auf Metal unter macOS ab. Würde man nur die CPU-Befehle übertragen, fehlten dem Spiel die erwarteten Plattformdienste.29 Das wiederverwendbare Kit trennt einen großen Teil dieser Plattformarbeit von der Konfiguration und den Korrekturen für das einzelne Spiel.30
Dieselbe Grundlage trägt inzwischen auch Need for Speed: Carbon. Der Mac-Port baut auf der Installation, den Mod-Anpassungen und der Controller-Unterstützung des Most-Wanted-Projekts auf.3132
Need for Speed: Carbon auf Apple Silicon. Screenshot aus der Ankündigung des Port-Entwicklers rubywolf11.
Das ist statische Rekompilierung: die Befehle vor der Ausführung übersetzen und die benötigte Umgebung bereitstellen. Dekompilierung versucht dagegen, eine Darstellung auf höherer Ebene zurückzugewinnen, mit der Menschen arbeiten können. N64Recomp macht diesen Unterschied ausdrücklich deutlich. Ein Port kann Maschinenbefehle recht direkt in C übersetzen, ohne zuvor die ursprüngliche Quellcode-Architektur zu rekonstruieren.33
Unter der Kulisse: Die Kollisionsansicht von OpenGOAL zeigt die Flächen, mit denen das Spiel arbeitet. Wer diese Strukturen versteht, kann weitergehende Änderungen angehen. Offizieller Promo-Screenshot.
Diese Projekte eröffnen unterschiedliche Zugänge zu bestehender Software. Mein OpenGOAL-Port nutzte eine rekonstruierte Codebasis. Mein Zelda-Patch änderte kompilierte Spielskripte. Cyberworld Endless versorgt eine laufende Engine mit neuen Daten und angepassten Routinen. SkyCraft verbindet zwei Programme, während ein Rekompilierungsport Befehle übersetzt und die umgebende Plattform nachbildet.
Das gemeinsame Ergebnis: Die ursprüngliche Veröffentlichung ist nicht mehr die einzige praktisch nutzbare Form des Spiels. Ein anderes Gerät, eine andere Oberfläche, Welt oder Spielregel wird zu etwas, das auch ein kleines Projekt angehen kann.
Warum Agenten das praktikabel machen
Reverse Engineering bestand schon immer darin, Vermutungen aufzustellen und zu prüfen. Schwierig ist der Wechsel zwischen den Anhaltspunkten: einer Funktion im Disassembler, einer Speicherstruktur, einem Compilerfehler und einem sichtbaren Problem im Spiel. Heutige Agenten können einer Untersuchung durch all diese Darstellungen folgen und weiterarbeiten, wenn die erste plausible Antwort scheitert.
Das Original wird zum Test
Ein veröffentlichtes Spiel bringt für diese Arbeit einen enormen Vorteil mit: eine ausführbare Referenz. Ich kann ihm eine Eingabe geben und beobachten, was passiert. Bei manchen Aufgaben lässt sich die Rekonstruktion automatisch damit vergleichen. Das Modell bekommt Rückmeldung von etwas, das außerhalb seiner eigenen Erklärung liegt.
Außerdem beginnt es selten vor einer strukturlosen Wand aus Bytes. Disassembler machen Befehle und Sprungziele sichtbar. Decompiler rekonstruieren den Kontrollfluss. Symbole, Dateiformate und Dokumentation aus der Community liefern weitere Hinweise. Schon die Forschung zu LLM4Decompile unterschied 2024 zwischen der Rekonstruktion aus Assemblercode und der Verbesserung von Ghidras Pseudocode.34 Das Modell kann mit strukturiertem Material arbeiten, auch wenn Namen und Absichten fehlen.
Aus diesen Hinweisen kann das Modell mögliche Erklärungen ableiten. Wiederkehrende Offsets könnten Felder derselben Datenstruktur beschreiben. Eine Gruppe von Werten könnte ein Enum sein. Ein Aufruf könnte einen Zustandswechsel auslösen. Das Modell kann eine vorläufige Implementierung schreiben, ihre Abweichungen vom Original testen und die Erklärung zusammen mit dem Code überarbeiten.
Maurice Heumanns Bericht vom Oktober zeigt, wie viel vom Prüfkriterium abhängt. Nachdem Agenten für einen Shooter lesbaren, aber falschen Code erzeugt hatten, führte sein Team Vergleiche mit der ursprünglichen Compiler-Ausgabe ein. Er berichtet von drei Monaten Arbeit und 83 % der Funktionen, die auf Byte-Ebene übereinstimmen. Der Code ist weiterhin privat. Es handelt sich also um einen ausführlichen Praxisbericht, nicht um ein unabhängig reproduziertes Ergebnis. Auch das Prüfprogramm musste geschützt werden: Agenten versuchten, ihre Arbeit von seinen Prüfungen auszunehmen.35
Aktuelle Forschung untersucht dasselbe Prinzip in kleinerem Maßstab. CHISEL führt Compilerfehler und Abweichungen, die Fuzzing aufdeckt, in weitere Rekonstruktionsversuche zurück. Die Untersuchung an 120 Funktionen zeigt eine bessere Rekonstruktion, obwohl die Prüfungen weiterhin einige fehlerhafte Kandidaten akzeptieren.36 Eine Studie vom September zeigte ebenfalls, dass bestandene Tests kein korrektes Verhalten bei weiteren Eingaben garantieren.37
Jemand muss weiterhin festlegen, was als korrekt gilt, und den Vergleich bauen. Bei Cyberworld Endless heißt das: einen Kampf in seiner ursprünglichen Engine ausführen und Angriffe, Schaden sowie Zustandswechsel mit der übertragenen Version vergleichen. „Es kompiliert“ verrät mir nicht, ob der Gegner noch so kämpft wie zuvor.
Für nützliche Änderungen muss man nicht alles verstehen
Der Agent muss nicht jedes Byte von Dungeons of Infinity erklären können, um dessen HUD zu verschieben. Er braucht den Zeichencode, den Zustand, aus dem dieser seine Daten bezieht, und die Stellen, an denen die Änderung etwas anderes beschädigen kann. Dieser kleinere Umfang erklärt einen großen Teil davon, warum eine zunächst ambitioniert klingende Anfrage machbar wird.
Wiederkehrende Strukturen helfen ebenfalls. Sobald ein Tabelleneintrag oder eine Gruppe von Routinen verstanden ist, liefern benachbarte Fälle Muster, die sich prüfen lassen. Gespeicherte Erkenntnisse, Skripte und Tests tragen die Arbeit über ein einzelnes Gespräch hinaus. Unabhängige Funktionen lassen sich als getrennte Aufgaben bearbeiten. Anthropics Compiler-Experiment zeigte beide Seiten davon: Agenten arbeiteten erfolgreich an unterschiedlichen Fehlern, kamen sich aber in die Quere, wenn alle auf dasselbe große Hindernis trafen.38
Für mich liegt die große Veränderung im Aufwand, einer Spur nachzugehen. Bei der Nova ging es von der Recherche über das Kompilieren und Installieren bis zu Eingaben, Screenshots und Fehlerkorrekturen. Der Agent konnte die Untersuchung durch all diese Schritte voranbringen. Aus einer Frage, die ich früher vielleicht als zu aufwendig aufgegeben hätte, wurde ein Projekt, das ich tatsächlich abschließen konnte.
Bessere Modelle zählen, und die Werkzeuge um sie herum zählen mit. Ein Modell, das einen Absturz analysieren kann, hilft mehr, wenn es ihn auch reproduzieren kann. Ein Modell, das einen Patch vorschlägt, hilft mehr, wenn es das gepatchte Spiel starten kann. Schneller erzeugter Code wird deutlich wertvoller, wenn sich Irrwege mit wenig Aufwand erkennen lassen.
In meinen Projekten hat genau diese Kombination funktioniert: Opus 5.5, Zugriff auf die passenden Werkzeuge und genügend Rückmeldung, um seine Vermutungen zu überprüfen.
Geschlossene Software steht vor derselben Frage
Ein Programm auf meinem eigenen Rechner muss genug von seiner Funktionsweise offenlegen, damit der Rechner es ausführen kann. Den Quellcode privat zu halten kann es aufwendig machen, diese Funktionsweise zu verstehen. Die Projekte zeigen, warum dieser Aufwand eine weniger verlässliche Hürde wird.
Daneben gibt es einen zweiten Weg: das Verhalten nachbilden, ohne die Implementierung zu rekonstruieren. Dem Original eine Eingabe geben, die Ausgabe untersuchen und etwas Kompatibles bauen. Das kann wirtschaftlich relevant werden, lange bevor jemand eine ganze Anwendung nachgebaut hat.
Ein Produkt kann Arbeitsablauf für Arbeitsablauf ersetzt werden
MirrorCode untersucht diesen Weg anhand von Kommandozeilenprogrammen. Agenten erhalten ausführbare Dateien, Dokumentation und Beispiele, befragen dann die Originale und bauen Ersatzprogramme. Verborgene Tests bewerten die Ergebnisse getrennt davon. Die Ergebnisse beziehen sich auf diese begrenzten Aufgaben. Viele der untersuchten Programme sind Open Source. Dass ihre Implementierung bereits im Training vorgekommen sein könnte, bleibt deshalb eine Einschränkung.39
Bei Bildbearbeitungsprogrammen werden die praktischen Folgen greifbarer. Photon Studio wirbt mit vertrauten Arbeitsabläufen und PSD-Unterstützung. Die Dokumentation benennt Grenzen dafür, wie originalgetreu Dateien beim Öffnen und Speichern erhalten bleiben. Es ist ein eigenständiger, kostenlos zugänglicher Editor mit einer eigenen, einschränkenden Lizenz.4041
PhotoCraft wählt einen offen dokumentierten Weg: eine Rust-Implementierung auf Basis öffentlicher Spezifikationen und beobachteten Verhaltens, mit Quellcode unter freizügigen Lizenzen. Die Bestandsaufnahme seiner Funktionen ist umfangreich. Die README nennt das Projekt allerdings weiterhin eine frühe Alpha.4243
Entscheidend ist, welche Arbeit ein Ersatz zuverlässig übernehmen kann. Wer ein Thumbnail erstellt, braucht einen anderen Ausschnitt des Editors als ein Druckstudio, das komplexe Dateien mit Kunden austauscht. Ein kleines Ersatzprogramm könnte für die erste Person gut genug werden, während es für die zweite ungeeignet bleibt.
Hier erwarte ich den ersten Druck. Ein Wettbewerber muss nicht jede Funktion nachbilden, um jemandem den Grund zu nehmen, weiter für das Original zu bezahlen. Vertraute Tastenkürzel, kompatible Dateien und die wenigen Handgriffe, die jemand täglich wiederholt, können einen Wechsel bereits attraktiv machen.
Eine vertraute Werkzeugleiste sagt allerdings wenig über die schwierigen Fälle. Eine Datei muss Speichern und erneutes Öffnen unbeschadet überstehen. Die Farbwiedergabe muss konsistent bleiben. Plugins, große Dokumente und über Jahre angesammelte Sonderfälle können wichtiger sein als die Zahl der Menübefehle. Den sichtbaren Arbeitsablauf richtig hinzubekommen ist ein Anfang. Die Kompatibilität muss sich danach beweisen.
Rekonstruierter Code wird nicht von selbst zu Open Source
Technischer Zugang und Erlaubnis sind zwei verschiedene Fragen. Eine Open-Source-Lizenz gewährt Rechte, das Werk zu nutzen, zu verändern und weiterzugeben. Code zu rekonstruieren gewährt diese Rechte nicht.44 Für Spielinhalte gelten außerdem eigene Rechte.
Der Europäische Gerichtshof unterschied im Fall SAS Institute die Funktionalität von Software von ihrer geschützten Ausdrucksform.45 Für Dekompilierung gelten eigene Regeln. In Deutschland erlaubt § 69e UrhG sie unter bestimmten Bedingungen zur Herstellung von Interoperabilität und begrenzt die Verwendung der gewonnenen Informationen.46
Wenn Spieler bei meinen Projekten ihre eigenen Spieldaten mitbringen, bleibt das Original als Voraussetzung sichtbar. Wer einen Patch verteilt, muss trotzdem die Rechte am jeweiligen Code und den verwendeten Inhalten prüfen.
Ich kann mich nicht über günstigere Rekonstruktion freuen, ohne daran zu denken, wessen Arbeit rekonstruiert wird. Ein aufgegebenes Spiel zurückzubringen fühlt sich für mich ganz anders an, als einen fast identischen Konkurrenten für ein neues Indie-Spiel zu bauen. Dieselbe Fähigkeit kann das Werk eines Menschen erhalten oder ihm sein Publikum nehmen.
Ich erwarte, dass die Geheimhaltung von Implementierungsdetails relativ an Wert verliert gegenüber der Pflege eines Produkts, dem Menschen vertrauen. Eigene Inhalte, eine Community, verlässliche Updates, Support und ein funktionierender Dienst zählen über die ausführbare Datei hinaus. Ein Produkt kann deshalb wertvoll bleiben, auch wenn sich Teile seiner Implementierung leichter nachbauen lassen.
Serverseitige Logik setzt zudem eine praktische Grenze. Der Besitz eines Clients liefert mir weder den Dienst dahinter noch dessen private Daten. Auch die Arbeit für seinen Betrieb bleibt zu leisten.
Was ich als Nächstes bauen möchte
Mein nächstes Ziel für Cyberworld Endless ist Online-Multiplayer. Bisher ist es ein Vorschlag: gemeinsame Net Squares, sichtbare Mitspieler, Chip-Tausch und eine Arena. Im Issue steht ausdrücklich, dass dafür noch kein Code existiert.47
Damit verändert sich die Aufgabe erneut. Bisher musste mein Director verstehen, was eine Engine tut. Online müssen sich mehrere Rechner darüber einig sein, was passiert ist. Wer entscheidet, ob ein Tausch zustande kommt? Wie gehen Kämpfe mit verspäteten Eingaben um? Was passiert, wenn zwei Clients voneinander abweichen?
Die bisherige Arbeit löst diese Probleme nicht. Sie gibt mir ein Spiel, für das ich sie gern lösen möchte.
Die Branche reagiert bereits. Am 13. Oktober kündigte Xbox die Xbox Labs an und ging dabei ausdrücklich auf aktuelle Dekompilierungen, Apple-Silicon-Ports, Browser-Versionen und Spiele ein, die in andere Spiele gemischt werden. Die Ankündigung stellt Experimente und Werkzeuge für Entwickler in Aussicht. Das ist eine frühe Reaktion, keine pauschale Erlaubnis für Fanprojekte.48
Ich wünsche mir, dass daraus mehr Zugänge zu Spielen entstehen: dokumentierte Formate, brauchbare Erweiterungsmöglichkeiten und Raum für Spieler, das anzupassen, was sie besitzen. Wenn Menschen ohnehin Wege finden, ein Spiel zu verändern, lohnt sich der Versuch, sie dabei zu unterstützen.
Ich kann mir dieselbe Entwicklung an anderer Stelle vorstellen: Aus einer fehlenden Option für Barrierefreiheit wird ein Patch. Eine aufgegebene Plattform bekommt einen gepflegten Port. Eine hervorragende Mechanik wird zum Ausgangspunkt eines anderen Spiels. Dass solche Änderungen für mehr Menschen erreichbar werden, lässt mich nicht los.
Es wird viele Kombinationen geben, die dreißig Sekunden lang lustig sind. Etwas zu bauen, das ich dreißig Stunden spielen möchte, braucht weiterhin Gespür, Tests und die Bereitschaft, es zu pflegen. Mich begeistert, dass ich jetzt mehr meiner Arbeit darauf verwenden kann, herauszufinden, ob eine Idee gut ist.
Ich wollte ein paar alte Spiele auf meinem Handheld spielen. Jetzt schaue ich sie an und frage mich, welche Version davon ich eigentlich spielen möchte.