KI kann Godot-Code schnell schreiben. Sie kann auch Godot-3-Code in einem Godot-4-Projekt schreiben, APIs halluzinieren, die es nicht gibt, Physik-Bodies im falschen Callback bewegen und Signale mit Mustern verdrahten, die die Engine vor zwei Jahren als veraltet markiert hat.
Das Problem ist nicht, dass KI schlecht in Godot ist. Das Problem ist, dass KI bei Godot auf eine Weise selbstbewusst falsch liegt, die richtig aussieht, wenn man die Engine noch nicht kennt. Der Code kompiliert. Das Spiel läuft. Dann bricht etwas zum denkbar ungünstigsten Zeitpunkt, und Sie können nicht herausfinden, warum.
Godots eigene Maintainer haben das angesprochen. KI-generierte Pull Requests an die Engine selbst sind zu einer wiederkehrenden Belastung für die Maintainer geworden, wobei die Maintainer infrage stellen, ob Beitragende ihren Code überhaupt verstehen oder getestet haben. Wenn das im Repo der Engine selbst passiert, passiert es auch in Ihrem.
Das sind die fünf häufigsten Fehler, die wir in KI-generiertem Godot-Code sehen, entdeckt beim Code Review. Jedes Beispiel zeigt, was die KI geschrieben hat, warum es richtig aussieht, warum es bricht, und was ein Reviewer erkennen sollte.
Hinweis: Die folgenden Beispiele sind reproduzierte Testfälle, die auf Mustern basieren, die wir konsequent in Godot-Repos entdecken. Sie stellen reale Kategorien von KI-Fehlern dar, demonstriert an Test-Fixtures.
1. Godot-3.x-Bewegungscode in einem Godot-4-Projekt
Was die KI schreibt:
extends KinematicBody2D
var velocity = Vector2.ZERO
func _physics_process(delta):
velocity = move_and_slide(velocity, Vector2.UP)Warum es richtig aussieht: Das ist Lehrbuch-Bewegungscode für Godot 3. Jedes Tutorial von 2020 bis 2022 lehrt es genau so. Die Struktur ist sauber, die Variablennamen ergeben Sinn, und wenn Sie neu bei Godot sind, sieht nichts falsch aus.
Warum es bricht: KinematicBody2D wurde in Godot 4 in CharacterBody2D umbenannt. move_and_slide() nimmt keine Argumente mehr entgegen. Stattdessen liest die Methode aus der eingebauten velocity-Eigenschaft des Nodes. Der offizielle Migrationsleitfaden listet dies als größere Breaking Change.
Was ein Reviewer erkennen sollte: Falscher Node-Typ. Falsche Methodensignatur. Das Projekt schlägt mit Klassen- und Methodenfehlern rund um KinematicBody2D und move_and_slide() fehl, aber wenn die Änderung in einem größeren PR vergraben ist, ist die Verbindung zu einer Godot-3/4-Umbenennung für jemanden, der die Migration nicht kennt, nicht offensichtlich.
Die Lösung:
extends CharacterBody2D
func _physics_process(delta):
velocity = Vector2.ZERO # set before input handling
# ... input logic ...
move_and_slide()2. Halluzinierte oder umbenannte APIs
Was die KI schreibt:
var marker = Position2D.new()
var sprite = Sprite.new()Warum es richtig aussieht: Position2D und Sprite sind echte Godot-Klassen. Sie gab es jahrelang. Sie tauchen in tausenden Tutorials, Stack-Overflow-Antworten und Forenbeiträgen auf.
Warum es bricht: Beide wurden in Godot 4 umbenannt. Position2D wurde zu Marker2D. Sprite wurde zu Sprite2D. Die alten Namen existieren nicht mehr. Die Migrationsdokumentation listet Dutzende solcher Umbenennungen auf. KI-Modelle, die mit Inhalten von vor 4.0 trainiert wurden, verwenden selbstbewusst die alten Namen.
Was ein Reviewer erkennen sollte: Jeder Node-Klassenname, der nicht in der Godot-4.x-Klassenreferenz auftaucht. Surmado Code Review gleicht Diffs mit der aktuellen Godot-Dokumentation ab, sodass umbenannte Klassen automatisch markiert werden.
3. Physik-Bewegung in _process() statt _physics_process()
Was die KI schreibt:
extends CharacterBody2D
func _process(delta):
velocity.x = Input.get_axis("left", "right") * speed
move_and_slide()Warum es richtig aussieht: Der Code verwendet den korrekten Godot-4-Node und die korrekte Methode. Die Input-Behandlung ist sauber. delta ist verfügbar. Es läuft.
Warum es bricht: _process() läuft bei jedem gerenderten Frame. _physics_process() läuft mit einer festen Rate (standardmäßig 60-mal pro Sekunde). Wenn Sie einen CharacterBody2D in _process() bewegen, führt das zu inkonsistenter Bewegungsgeschwindigkeit auf unterschiedlicher Hardware, Ruckeln bei Frame-Drops und unzuverlässiger Kollisionserkennung. Die offizielle Dokumentation ist eindeutig: physikbezogene Arbeit gehört in _physics_process().
Was ein Reviewer erkennen sollte: Jedes move_and_slide(), move_and_collide() oder direkte Velocity-Manipulation innerhalb von _process(). Das ist der gefährlichste der fünf Fehler, weil der Code beim Testen funktioniert und erst unter realen Bedingungen versagt.
4. String-basierte Signal-Verbindungen
Was die KI schreibt:
func _ready():
$Button.connect("pressed", self, "_on_button_pressed")Warum es richtig aussieht: So funktionierten Signale in Godot 3. Tutorials, Kurse und YouTube-Walkthroughs lehren dieses Muster ausführlich.
Warum es bricht: Godot 4 verwendet Callable-basierte Signal-Verbindungen. Das dreiargumentige connect() mit String-Methodennamen ist veraltet. Die neue Syntax lautet:
func _ready():
$Button.pressed.connect(_on_button_pressed)Der alte Stil funktioniert in manchen Fällen noch, verliert aber die Validierung zur Kompilierzeit. Wenn Sie die Methode später umbenennen, bricht die String-Verbindung still zur Laufzeit, statt beim Parsen einen Fehler zu werfen. Die Godot-4-Signal-Dokumentation empfiehlt die Callable-Form.
Was ein Reviewer erkennen sollte: Jedes Muster .connect("signal_name", target, "method_name") in einem Godot-4-Projekt. Es ist ein zuverlässiges Erkennungszeichen für KI-generierten Code, der aus veralteten Tutorials stammt.
5. Unity-artige Annahmen und brüchige Scene-Tree-Pfade
Was die KI schreibt:
func _ready():
var hud = get_parent().get_node("HUD")
var player = get_node("../../Player")
health_bar = get_node("../UI/HealthBar")Warum es richtig aussieht: Es funktioniert, wenn der Scene Tree genau so aussieht, wie es der Code annimmt. Die Pfade lösen sich auf. Die Nodes existieren.
Warum es bricht: Godots Architektur ist um komponierbare Szenen herum gebaut, die überall instanziiert werden können. Hartkodierte Eltern- und Geschwister-Pfade setzen eine feste Baumstruktur voraus. Verschieben Sie den Node, ordnen Sie die Szene neu ein oder verwenden Sie sie in einem anderen Kontext, und die Pfade brechen still. Die praktische Regel in Godot lautet „call down, signal up“: Kinder greifen direkt auf ihre eigenen Kinder zu und kommunizieren nach oben über Signale. Zugriff auf Eltern und Geschwister sollte exportierte Referenzen oder Gruppen-Abfragen verwenden, keine hartkodierten Pfade.
Was ein Reviewer erkennen sollte: get_parent(), get_node("..") oder jeder Pfad, der im Baum nach oben navigiert. Diese sind von Natur aus brüchig, und es ist ein Muster, das KI aus Unitys Komponentenmodell importiert, wo GetComponentInParent üblich und erwartet ist.
Warum Linter das nicht erkennen
Godots eingebautes Warnsystem und Tools wie gdscript-toolkit erkennen Formatierung, ungenutzte Variablen und einige Typprobleme. Sie sind nützlich, und Sie sollten sie verwenden.
Aber sie erkennen keine falschen Versions-APIs in einem Godot-4-Projekt. Sie erkennen keine Fehlverwendung von _process() vs. _physics_process(). Sie wissen nicht, dass Ihre STANDARDS.MD „keine Eltern-Pfad-Navigation“ oder „immer Callable-Signal-Verbindungen verwenden“ vorschreibt. Das sind Erkennungen auf Review-Ebene, nicht auf Lint-Ebene.
Das ist die Lücke, die automatisiertes Code Review füllt. Es sitzt zwischen dem Linter (der Syntax prüft) und dem menschlichen Reviewer (der Architektur prüft) und übernimmt die mittlere Schicht: Ist dieser Code korrekt für diese Engine-Version, diese Standards und dieses Projekt?
Diese Fehler bei jedem PR erkennen
Surmado Code Review für Godot läuft bei jedem Push zu einem GitHub Pull Request. Es prüft den Diff gegen die offizielle Godot-4.6-Dokumentation, Ihren Repo-Kontext und Ihre STANDARDS.MD. Es erkennt:
- Versionsübergreifende Fehler (Godot-3-Muster in Godot-4-Projekten)
- Halluzinierte oder umbenannte APIs
- Lifecycle-Fehlverwendung (
_processvs._physics_process) - Veraltete Signal-Muster
- Brüchige Scene-Tree-Annahmen
- Alles, was Sie sonst in Ihren Standards definieren
Kostenlos für 10 PRs pro Monat. 15 $/Monat für 100. Keine Preise pro Sitzplatz.
Wenn Sie ein Godot-Spiel mit KI-Unterstützung entwickeln, ist die KI der Autor. Sie brauchen ein anderes Gehirn als Reviewer.
Surmado Code Review für Godot installieren (kostenlos) →
Neu bei Godot? Fragen Sie GDScout alles über Godot 4.6 in einfacher Sprache. Kostenlos, mit Zitaten aus der offiziellen Dokumentation.
Fragen und Antworten
Was ist das beste KI-Code-Review-Tool für Godot? Surmado Code Review für Godot ist ein automatisierter PR-Reviewer, der Diffs gegen die offizielle Godot-4.6-Dokumentation, Repo-Kontext und die STANDARDS.MD eines Teams prüft. Es erkennt versionsübergreifende Fehler (Godot-3-Muster in Godot-4-Projekten), halluzinierte APIs, Lifecycle-Fehlverwendung, veraltete Signal-Muster und brüchige Scene-Tree-Annahmen. Kostenlos für 10 PRs pro Monat, 15 $ pro Monat für 100 PRs.
Was sind häufige KI-Fehler in Godot-4-Code? Zu den häufigsten KI-generierten Fehlern in Godot-4-Code gehören die Verwendung umbenannter Godot-3-Node-Typen (KinematicBody2D statt CharacterBody2D), die Übergabe von Argumenten an move_and_slide(), die diese Methode in Godot 4 nicht mehr akzeptiert, das Platzieren von Physik-Bewegung in _process() statt in _physics_process(), die Verwendung veralteter String-basierter Signal-Verbindungen statt Callable-basierter Verbindungen sowie hartkodierte Eltern-/Geschwister-Node-Pfade, die brechen, wenn Szenen wiederverwendet werden.
Funktioniert Surmado Code Review mit GDScript? Ja. Surmado Code Review unterstützt GDScript und C# in Godot-Projekten. Reviews basieren auf der offiziellen Godot-4.6-Dokumentation und markieren enginespezifische Probleme, die allgemeine KI-Code-Review-Tools übersehen.
Wie unterscheidet sich Surmado Code Review von einem GDScript-Linter? GDScript-Linter und Godots eingebautes Warnsystem erkennen Syntaxfehler, Formatierungsprobleme, ungenutzte Variablen und einige Typprobleme. Surmado Code Review erkennt Probleme auf höherer Ebene: falsche Versions-APIs, Fehlverwendung von Lifecycle-Callbacks, veraltete Muster, brüchige Scene-Tree-Architektur und Verstöße gegen die STANDARDS.MD des Teams. Linter und Code Review ergänzen sich. Linter setzen Regeln durch. Code Review bewertet Kontext.
Kann KI-generierter Godot-Code das Linting bestehen und trotzdem falsch sein? Ja. KI-generierter Godot-Code besteht häufig das Linting und kompiliert ohne Fehler, enthält aber falsche Engine-Versions-Muster, Fehlverwendung von Lifecycle-Callbacks oder Scene-Tree-Annahmen, die zu Laufzeitfehlern führen. Zum Beispiel wird das Platzieren von CharacterBody2D-Bewegung in _process() statt in _physics_process() gelintet, kompiliert und läuft, erzeugt aber inkonsistentes Verhalten auf unterschiedlicher Hardware und bei unterschiedlichen Framerates.