Lokales LLM kämpft mit Unreal Engine Solitaire: Qwen 3.6-27B verbrennt 687k Tokens auf einer Karte

Ein Experiment eines Reddit-Nutzers mit lokalen LLMs für die Spieleentwicklung zeigt gravierende praktische Einschränkungen. Mit Qwen 3.6-27B, Zugriff auf unreal-mcpython, SearXNG und GitHub bestand die Aufgabe darin, ein Solitaire-Spiel in Unreal Engine zu erstellen. Nach einigen Stunden (viel Wartezeit auf Antworten des Nutzers auf Prompts) war das Ergebnis eine einzelne Karte mit korrekten Texturen, aber ohne Spiellogik, die ↑687k und ↓210k Tokens verbrauchte.

Erforderliche manuelle Eingriffe

• Manuelles Herunterladen von PNGs mit Kartenmotiven
• Erstellung eines Meshes mit 3 Materialien (Standardwürfel hat nur 1 Seitenmaterial)
• Ständiges Prompting wie „Hör auf, dir Dinge auszudenken, benutze eine verdammte Suche“
• Wiederholte Korrekturen: „Die Karte hat keine Textur“ oder „Die Karte hat Pik-Ass auf beiden Seiten“

Das Problem der zweiseitigen Karte verbrauchte die meiste Zeit und die meisten Tokens. Der Standardwürfel kann nur ein Material auf allen Seiten haben; ein benutzerdefiniertes Mesh mit 3 Materialien ist erforderlich. Gemini Flash 3.5 generierte die korrekte OBJ-Datei auf Anhieb, aber Qwen drehte sich stundenlang im Kreis, obwohl konkrete Codebeispiele gefunden wurden. Das Modell bestand darauf, Ebenen zu erstellen, zwei Ebenen mit einem Würfel zu kombinieren, das Substrat zu deaktivieren oder andere nicht funktionierende Ansätze zu verwenden. Der Nutzer musste schließlich das Mesh manuell bereitstellen.

Gemma 4-31B wurde getestet, konnte aber keinen sinnvollen MCP-Aufruf tätigen und wurde früh disqualifiziert.

Praktische Erkenntnis: Für Unreal Engine-Aufgaben mit benutzerdefinierter Geometrie benötigen lokale LLMs wie Qwen 3.6-27B weiterhin erhebliche manuelle Unterstützung. Token-Budgets explodieren schnell, und grundlegende Mesh-Operationen bleiben ein Stolperstein.