Claude Code steuert Unity: Ein maßstabsgetreuer Sonnensystem-Simulator

Was es ist

Die Demo oben ist das fertige Ergebnis und läuft direkt im Browser. Ein Sonnensystem im echten Maßstab: eine Szeneneinheit entspricht 10.000 km, der Sonnenradius 69,6 Einheiten, die Neptunbahn 450.000 Einheiten, der äußere Rand der Oortschen Wolke 1,5 Milliarden Einheiten. Alle 36 Körper (Sonne, 8 Planeten, 18 große Monde, Pluto und 7 Zwergplaneten des Kuipergürtels, der Mond) werden aus J2000-Bahnelementen positioniert; Datum, Bahnneigungen und Exzentrizitäten sind real.

Ziehen zum Drehen, scrollen zum Zoomen, auf einen Namen klicken, um dorthin zu fliegen. Oben links stehen die physikalischen Daten des gewählten Körpers (NASA / JPL), unten die Regler für Zoom und Zeitgeschwindigkeit. Am Smartphone dreht ein Finger, zwei Finger zoomen.

Kurzfassung

• Es funktioniert. Ein KI-Agent hat ohne Mensch an der Tastatur den kompletten Kreislauf im Unity-Editor geschlossen: Code schreiben, kompilieren, Szene bauen, Play-Modus, per Screenshot prüfen, in git committen.
• Es ist nicht billig. Die Sitzung dauerte rund 12 Stunden mit 813 Modellaufrufen; die gewichtete Nutzung entspricht etwa 77 Millionen Eingabetokens.
• Der Engpass ist nicht das Modell, sondern die Werkzeugkette: modale Dialoge, Drosselung im Hintergrund, Sandbox-Rechte. Was ein Mensch sofort sieht, ist für einen Agenten auf der Kommandozeile eine Blackbox.

Anlass

Am 16. September 2026 veröffentlichte Unity ein offizielles Plugin für KI-Agenten (31 Skills) und die Unity CLI. Wir lasen einen Bericht darüber und wollten die Behauptung selbst prüfen. Also ließen wir Claude Code auf einem Windows-Rechner ohne Unity bei null anfangen.

Aufbau

Das Prinzip der Unity CLI ist einfach: Das Pipeline-Paket startet im Editor einen HTTP-Server, die CLI schickt Befehle, der Editor führt sie im Hauptthread aus und liefert das Ergebnis zurück. Am häufigsten nutzte der Agent eval_file (beliebiges C#), recompile, editor_play und capture_game_view.

Technischer Ansatz

Echter Maßstab. Zehn Größenordnungen; float würde zittern.

Schwebender Ursprung. Alle Positionen in double; der fokussierte Körper liegt immer im Weltursprung, alles andere relativ dazu. Beim Fokuswechsel wird die heliozentrische Kameraposition zuerst berechnet und im neuen Bezugssystem ausgedrückt, damit die Kamera nicht springt.

Beleuchtung. Das Intensitätsverhältnis Sonne–Neptun ist 900:1. Planeten und Ringe nutzen einen eigenen URP-Shader mit abstandsunabhängiger Lambert-Beleuchtung zur Sonne, deren Position C# jedes Frame in eine globale Shader-Variable schreibt.

Bahnen. Vollständige Kepler-Elemente, gelöst mit dem Newton-Verfahren; Mondbahnen zur Äquatorebene des jeweiligen Planeten geneigt: Saturn 28 Grad, Uranus seitlich bei 98, Triton rückläufig bei 130. Verifiziert über die Höhe jedes Körpers über der Ekliptik gegen NASA-Werte.

Kuipergürtel und Oortsche Wolke. Version eins mit 110.000 Punktsprites überforderte schwache GPUs. Ersetzt durch Volumenrendering: Raymarching in 40 Schritten mit gaußscher Dichte (Torus für den Gürtel, Schale für die Wolke). Nur 14.000 echte Punkte bleiben für die Körnung und schalten sich außerhalb der Reichweite ab.

Texturen. Planetenkarten von Solar System Scope (CC BY 4.0), 2K-Originale außerhalb des Projekts, 1K-Versionen im Projekt mit Crunch-Kompression. Alle Texturen unter 3 MB im Build. Monde und Zwergplaneten nutzen prozedural erzeugte Karten.

Browser-Build. Brotli mit JS-Fallback zur Dekompression, keine Server-Header nötig. WebGL2 hat kein Reversed-Z, daher folgen Near- und Far-Plane der Kameradistanz mit einem Verhältnis unter 10⁷. Insgesamt 12,9 MB.

Zeitleiste

Probleme und Lösungen

1. Die Store-Version der Unity CLI läuft in einer Sandbox. Das winget-Paket ist ein MSIX aus dem Microsoft Store. Es kann keine erhöhten Installer starten und den Lizenz-Client nicht erreichen. Lösung: den bereits heruntergeladenen Installer aus dem CLI-Cache mit Adminrechten still installieren; Lizenz manuell im Hub aktivieren. Beim WebGL-Modul dasselbe Problem, dieselbe Lösung.

2. Der Editor ignoriert Befehle im Hintergrund. Ohne Fokus liefen alle Hauptthread-Befehle in 30-Sekunden-Timeouts. set_autotick allein reichte nicht; erst der Interaction Mode „No Throttling“ löste es.

3. Das 5-Sekunden-Limit von eval. Der Szenenaufbau dauerte anfangs über 8 Sekunden. AssetDatabase.StartAssetEditing brachte ihn auf 1,5 Sekunden; lange Aufgaben laufen als --detach-Job mit job wait.

4. Ein modaler Dialog blockiert alles. Beim Speichern hielt der Editor die Datei für extern geändert und zeigte Reload / Ignore. Jeder Befehl lief in den Timeout, der Agent sieht keine Dialoge. Lösung: Fenster per Win32 aufzählen, Dialog finden, BM_CLICK senden; danach die Speicherreihenfolge ändern.

5. Ein Nullvektor verdarb das ganze Bild. Unitys Vector2.normalized liefert für winzige Vektoren null; im Shader wurde daraus NaN, das sich bei additiver Mischung über den Frame ausbreitete. Gefunden durch Ausschalten einzelner Objekte, behoben durch manuelle Normalisierung in double.

6. Neukompilieren im Play-Modus. Der Domain-Reload löschte das statische Singleton ohne erneutes Awake. Ersetzt durch verzögertes Nachschlagen.

7. Maus im Browser tot. Unity registriert im Browser ein Touchscreen-Gerät. Der Code prüfte die Anzahl der Touch-Slots (immer über null) statt gedrückter Finger und nahm jeden Frame den Touch-Zweig.

8. Nicht sehen können. Screenshots sind die einzigen Augen des Agenten. Jede CLI-Runde dauert etwa 2 Sekunden, eine Prüfung braucht 5 bis 8 Bilder; --source screen ist nötig, damit Post-Processing und UI enthalten sind.

9. Keine chinesische oder japanische Schrift im Browser. Die Desktop-Version leiht sich eine Systemschrift; im Browser gibt es keine, also musste die Oberfläche auf Englisch festgesetzt werden. Das vollständige Noto Sans CJK hat 16 MB. Der erste Versuch, die 368 benötigten Glyphen in einen statischen Atlas zu backen, scheiterte: Unitys IMGUI zeichnet mit einer statischen Schrift in jedes Label den zuletzt gerenderten Text. Lösung: die Schrift mit fontTools auf genau diese 368 Glyphen reduzieren (173 KB) und als dynamische Schrift mitliefern; ein Importskript leitet die Zeichenliste aus den Lokalisierungstabellen ab.

Verbrauch

Sitzung vom 2026-09-20 05:26 bis 17:19 UTC, inklusive Pausen.

Verteilung der gewichteten Nutzung: Codedateien lesen und schreiben 35 %, Systemanweisungen jede Runde neu lesen 26 %, Denken und Antworten 25 %, Shell (Unity CLI, git, node) 10 %, Rest 4 %. Werkzeugaufrufe: Edit 153, PowerShell 123, Read 109, Write 41, WebFetch 15, Browser 13, WebSearch 7. Keine Subagenten.

Einordnung. Cache-Lesen dominiert, weil jeder Aufruf das bisherige Gespräch mitführt, nach Cache-Treffer zu 0,1×. Wirklich neu erzeugt wurden 2,83 Millionen Ausgabetokens, etwa das 1.500-Fache dieses Artikels. Ein erfahrener Unity-Entwickler bräuchte für denselben Umfang etwa 3 bis 5 Arbeitstage.

Was gut lief

• Jeder Schritt per Screenshot geprüft.
• Feingranulare git-Commits, jederzeit zurückrollbar.
• Wiederkehrende Abläufe als Skript gekapselt.
• Fallen ins Gedächtnis geschrieben, kein Problem kostete zweimal Zeit.

Was schieflief

• Der erste Kuipergürtel mit 110.000 Punkten ohne Blick auf die Leistung.
• Die Touch-Bedingung war falsch und fiel erst nach der Veröffentlichung auf.
• Mehrfach während des Play-Modus des Nutzers neu kompiliert.

Als Nächstes

• Atmosphärisches Streulicht und Ringschatten.
• Zwei Agenten: einer plant und prüft, einer setzt um.
• Das Unity-CLI-Hilfsskript als wiederverwendbaren Skill aufbereiten.

---

Geschrieben von Claude Fable 5.1 aus dem vollständigen Protokoll dieser Sitzung; die Verbrauchszahlen stammen aus der direkten Auswertung des Sitzungslogs.