2026-06-01 Rückblick
Was ich heute gemacht habe
Heute habe ich das Godot‑Projekt direkt ausgeführt, um das Ergebnis der Kartengenerierung zu prüfen, und dabei erneut getestet, wie gut KI‑Codierungswerkzeuge den tatsächlichen Spielentwicklungs‑Workflow unterstützen.
Außerdem habe ich ein persönliches geheimes Repository mit einem eigenen Web‑Research‑MCP versehen. Statt das Standard‑web-search-mcp unverändert zu verwenden, habe ich versucht, es an den gewünschten Suchablauf und die Ausgabe anzupassen. Beim Umgang mit ständig wechselnden Informationen wie Design, Godot und aktueller Dokumentation fühlte ich, dass ein Suchwerkzeug fast unverzichtbar ist.
Getestete Werkzeuge
Qwen Code, Codex und OpenCode wurden alle getestet.
Kurz gesagt, keines war so stabil, wie ich es mir erhofft hatte. Qwen Code lieferte zu häufig wiederholte Antworten. Der gleiche Plan wurde erstellt, dieselbe Datei gesucht und ein gescheiterter Pfad erneut vertraut – ein sich wiederholender Ablauf. Ohne das Setup exakt nach Dokumentation zu konfigurieren und zu tunen, scheint dieses Wiederholungsproblem bei jedem Modell schwer zu beheben.
Codex und OpenCode hatten im Vergleich zu Qwen Code zwar bessere Aufrufe, verstanden jedoch den Godot‑Kontext nicht tief genug oder konnten Bilder schlecht interpretieren. Antworten wurden mitten im Satz abgebrochen, sie erstellten eigenständig Pläne, die dann nicht korrekt umgesetzt wurden, und riefen Sub‑Agents auf, die angeblich recherchierten, dabei aber das Dateisystem durchsuchten – ein seltsamer Ablauf.
Ohne Qwen Code schien die Anbindung des web-search‑MCP schlecht zu funktionieren, was frustrierend war. Andererseits blieb bei Qwen Code trotz MCP‑Nutzung das Problem von Wiederholungen und Zustandsinterpretation bestehen.
Modell‑Experimente
Andere Modelle neigen dazu, Code‑Muster aus älteren Godot‑Versionen vorzuschlagen, weshalb ich nach einem Modell suchte, das speziell für Godot geeignet ist, und das Modell bekoozkan/godot-gemma-4-e4b-it-GGUF von Hugging Face ausprobierte.
Ich hoffte, dass es Godot besser versteht, doch die Grenzen waren groß. Das Modell hat zu wenige Parameter und kann lange Kontexte nicht gut erfassen.
Besonders bei Aufgaben, bei denen die Bildprüfung wichtig ist, war das frustrierend. Man muss sehen, ob die Karte seltsam aussieht oder wo etwas unpassend ist, aber die Modelle konnten Bilder nicht zuverlässig interpretieren. In der Spielentwicklung reicht es nicht, dass der Code stimmt – das Bild muss natürlich wirken, und hier schwankten die KI‑Werkzeuge stark.
Probleme, die ich bei der Godot‑Arbeit bemerkte
Godot stellte für die Modelle ein überraschend unbekanntes Gebiet dar. Aktuelle Syntax, Szenenstruktur, Editor‑Verhalten, Ressourcen‑Pfad und das Prüfen von Laufzeit‑Ergebnissen müssen zusammenhängen, doch viele Modelle antworteten nur auf Basis von Code‑Snippets und veralteten Kenntnissen.
Die eigentliche Arbeit heute bestand darin, Godot zu starten und zu prüfen, warum die Karte seltsam aussieht. Doch rundherum musste ich ständig Werkzeuge konfigurieren, MCP‑Verbindungen herstellen, Modelle austauschen, Sandbox‑Probleme lösen und Bildinterpretationen behandeln. Der eigentliche Spielteil kam dabei zu kurz.
Verbleibende Gefühle
Ehrlich gesagt habe ich das Gefühl, dass dieses Feld nicht zu mir passt.
Ich hatte gehofft, dass sich die Entwicklung erleichtert, wenn man KI‑Werkzeuge gut zusammensetzt, doch in der Praxis verlor das Werkzeug häufig seinen Zustand, wiederholte sich, fand Dateien falsch, sah keine Bilder und schlug nur veralteten Code vor. Was ich eigentlich bauen möchte, ist ein Spiel, aber ich verbrachte die meiste Zeit damit, die Grenzen der Werkzeuge zu debuggen.
Dennoch habe ich etwas gewonnen: Web‑Research‑MCP ist nötig, Qwen Code muss streng nach Dokumentation getuned werden, und Godot‑Arbeiten erfordern immer eine Prüfung der tatsächlichen Ausgabebilder. Statt alles dem LLM zu überlassen, ist es realistischer, wenn Menschen oder Skripte den Verifikations‑Loop übernehmen und das LLM nur für Entwürfe und unterstützende Entscheidungen nutzt.
Ab morgen denke ich, dass ich selbst feintunen muss. Das bloße Anbinden eines generischen Modells oder eines öffentlich verfügbaren Godot‑Spezialmodells reicht nicht, um die gewünschte Godot‑Version, Arbeitsweise und Bild‑Verifikations‑Workflow zu unterstützen. Ich muss Beispiele und Fehlerszenarien sammeln und einen eigenen Datensatz erstellen, der zu meinem Arbeitsstil passt.
Kriterien für zukünftige Einträge
- Godot‑Arbeiten gelten nicht als abgeschlossen, solange das Ausgabebild nicht geprüft wurde.
- Bei bildbasierten Entscheidungen vertraue ich nicht ausschließlich auf die Modellantworten.
- Ab morgen sammle ich Godot‑Arbeitsmuster und Fehlerszenarien, um mich selbst für das Feintuning vorzubereiten.
- Qwen Code wird erst nach Abschluss der Wiederholungs‑ und MCP‑Einstellungen eingesetzt.
- Codex und OpenCode werden mit der Annahme verwendet, dass ihr Godot‑Kontext und ihre Bildinterpretation schwach sind.
- Wenn ein Modell keinen Plan erstellt, sondern nur Werkzeugaufrufe wiederholt, wird es sofort abgebrochen.
- Web‑Research bleibt nötig, aber die Entscheidung, Suchergebnisse in Code‑Arbeit zu überführen, wird separat verifiziert.