Godot-KI-Spielentwicklung

Definieren Sie die Projektgrenze vor Änderungen

Beginnen Sie mit einem eigenen Projektverzeichnis und einer schriftlichen Liste zulässiger Änderungen. Inventarisieren Sie vorhandene Szenen, Skripte, Assets und Plugins, damit der Agent die aktuelle Struktur erweitert, statt eine zweite Implementierung anzulegen. Halten Sie den Anfangszustand wiederherstellbar und erfassen Sie, welche Engine-Binary ihn öffnet.

Wählen Sie einen überschaubaren spielbaren Ausschnitt mit expliziten Übergängen. Ein Titelscreen, der zu einem Raum und über Sieg oder Niederlage zurückführt, liefert beispielsweise einen wiederholbaren Test. Entscheiden Sie, wer visuelle Gestaltung und Steuerung prüft, denn weder ein erfolgreiches Parsing noch die Abschlussmeldung eines Modells belegt, dass sich die Erfahrung stimmig anfühlt.

Identifizieren Sie Executable und unterstützte Argumente

Godots stabile CLI-Dokumentation liefert die folgenden Befehle. GODOT_BIN und PROJECT sind für dieses Beispiel gewählte Shell-Variablen und keine Godot-Einstellungen; ersetzen Sie ihre Platzhalterpfade durch vorhandene Executable und Projekt. Der Projektpfad muss project.godot enthalten.

Erfassen Sie Version und Hilfeausgabe, bevor Sie zusätzliche Flags skripten. So vermeiden Sie die Annahme, ein Befehl aus der aktuellen Online-Dokumentation existiere in Ihrem installierten Build. Bewahren Sie die Binary-Identität mit späteren Testergebnissen auf und halten Sie sie bei der Fehlersuche stabil. Diese beispielhaften Befehle verwenden die dokumentierten CLI-Formen.

GODOT_BIN="/absolute/path/to/godot"
PROJECT="/absolute/path/to/project"
"$GODOT_BIN" --version
"$GODOT_BIN" --help
"$GODOT_BIN" --headless --path "$PROJECT" --import

Trennen Sie Import, Parsing und echtes Spiel

Ein Headless-Import prüft eine Asset-Verarbeitungsgrenze. Eine Parserprüfung untersucht ein Skript. Ein normaler Start erreicht das Spiel und kann Szenenverdrahtung und Laufzeitprobleme sichtbar machen. Halten Sie diese Ergebnisse im Prüfdatensatz getrennt, statt alle drei als bestandene Tests zusammenzufassen.

Der folgende beispielhafte Skriptpfad muss in Ihrem Projekt bereits existieren. Eine Parserprüfung ist bewusst eng: Sie kann funktionierende Kollisionen, reaktionsfähige Eingabe oder korrekte Persistenz nicht belegen. Wiederholen Sie nach einer Änderung das Verhalten, das sie verändert, sowie den unmittelbar davor und danach liegenden Übergang. Das ist oft informativer, als zahlreiche isolierte Prüfungen für generierte Hilfsfunktionen zu erstellen.

"$GODOT_BIN" --headless --path "$PROJECT" \
  --script res://scripts/player.gd --check-only
"$GODOT_BIN" --path "$PROJECT" --debug

Wählen Sie CLI-Tools oder MCP bewusst

Ein Shell-fähiger Agent kann eine geprüfte CLI-Sequenz bedienen. Godot MCP ist eine zusätzliche, projektgepflegte Tool-Schnittstelle; die Einrichtung wird auf einer eigenen Seite behandelt. In beiden Fällen sollte der Bediener das Zielprojekt kennen, bevor er Schreibvorgang oder Prozessstart freigibt.

Halten Sie Modellanbieter-Einstellungen des Agenten getrennt von Engine-Tools. Eine funktionierende lokale Verbindung belegt weder die Verfügbarkeit eines bestimmten Modells noch die Unterstützung jeder Funktion eines kompatiblen Gateways. Etablieren Sie zuerst den kleinsten zulässigen Lesevorgang, dann eine umkehrbare Szenenänderung und erst danach einen vollständigen Gameplay-Zyklus in einem autorisierten Experiment.

Geben Sie Fehlern genügend Szenenkontext

Wenn eine Interaktion fehlschlägt, erfassen Sie relevanten Szenenbaum, Skript, Eingabeaktion und ersten aussagekräftigen Laufzeitfehler. Erklären Sie erwarteten Übergang und beobachteten Zustand. Ein Bericht, dass sich der Spieler nicht bewegen kann, sollte angeben, ob das Spiel fokussiert ist, Eingabe erkannt wird und sich die Position des Spielers ändert.

Verlangen Sie eine kleine vorgeschlagene Korrektur mit Erklärung, die an diese Belege gebunden ist. Wiederholen Sie nach der Anwendung dieselbe Aktion und prüfen Sie Regressionen bei Neustart und Szenenübergängen. Akzeptieren Sie eine Reparatur nicht allein deshalb, weil der Fehler verschwunden ist; das Deaktivieren der betroffenen Funktion kann einen Fehler entfernen, während die ursprüngliche Anforderung unerfüllt bleibt.

Bereiten Sie Exportvoraussetzungen ausdrücklich vor

Ein Export benötigt ein passendes Preset und installierte Exportvorlagen. Prüfen Sie export_presets.cfg und Ressourceneinbindung vor dem Build. Halten Sie Exportzugangsdaten privat. Der Presetname im Beispiel ist illustrativ und muss zu Ihrem Projekt passen; das Ausgabeverzeichnis muss bereits existieren.

Behandeln Sie eine fehlende Vorlage oder ein fehlendes Preset als Umgebungsproblem und nicht als Beleg dafür, dass die generierte Spiellogik falsch ist. Bewahren Sie Exportlogs und Artefakt-Hash auf, damit Zielplattformbefunde auf einen bestimmten Build verweisen. Ein erfolgreicher Export ist ein wichtiger Prüfschritt, belegt aber nicht, dass der gelieferte Player startet oder eine Runde abschließt.

"$GODOT_BIN" --headless --path "$PROJECT" \
  --export-release "Windows Desktop" "/absolute/existing-build-dir/game.exe"

Führen Sie einen Auslieferungs-Miniflow auf dem Ziel aus

Starten Sie das exportierte Spiel in dem Betriebssystem, das Sie unterstützen möchten. Testen Sie Start, Eingabe, vollständige Runde, Neustart, Einstellungen und Persistenz nach erneutem Start. Bewahren Sie für jedes Ergebnis Artefaktidentität, Gerätekontext und beobachtetes Ergebnis auf. Ein auf macOS erstellter Export verifiziert Windows-Verhalten nicht selbst.

Prüfen Sie bei einem Webziel zusätzlich Browser-Laden und Laufzeitfehler und bedienen Sie den Canvas mit echter Eingabe. Verifizieren Sie, dass Inhalte sichtbar sind und sich gegebenenfalls bewegen. Testen Sie die vorgesehene Hosting-Konfiguration und nehmen Sie nicht an, ein lokaler Editorlauf decke Browser-Ressourcenladen und Plattformbeschränkungen ab.

Ein Quellprojekt und native Aufnahme zur Prüfung

Das lokale Switchyard-Beispiel bietet ein Godot-Rätsel mit drei Räumen, automatisierte Gameplay-Prüfungen, Tests zum erneuten Öffnen des Speicherstands, Rohlogs, ein Source-ZIP und eine Godot-PCK. Seine nativen Aufnahmen zeigen das tatsächlich laufende Projekt in zwei Viewport-Größen. Die dokumentierten Befehle zu wiederholen ist ein stärkerer Test, als das Projekt allein anhand eines Screenshots zu beurteilen.

Das Projekt verwendete Godot 4.5.1 in einem Codex-Lauf, dessen exaktes Generierungsmodell nicht verifiziert wurde. Es demonstriert daher einen lokalen Engine-Workflow und keinen Astra-Benchmark. Browserexport war wegen fehlender Exportvorlagen blockiert, und die PCK ist keine eigenständige Windows-Datei. Diese Grenzen sind bei der Quelle dokumentiert, damit der nächste Entwickler weiß, was noch geprüft werden muss.

Schließen Sie die Schleife mit einer prüfbaren Übergabe

Die Übergabe sollte spielbaren Umfang, Quellenidentität, Engine- und Vorlagenversionen, Buildanweisungen, akzeptierte Ergebnisse und offene Fehler benennen. Fügen Sie echte Aufnahmen des getesteten Artefakts und die Herkunft ausgelieferter Assets hinzu. Bewahren Sie Reparaturversuche und manuelle Eingriffe auf, statt nur einen finalen generierten Code-Dump zu präsentieren.

Wenn die Basisschleife akzeptiert ist, fügen Sie Assets und Lokalisierung über eigene Import- und Gameplay-Prüfungen hinzu, bevor Sie eine Plattformeinreichung erwägen. Dieser Leitfaden basiert auf Engine-Dokumentation. Wenden Sie ihn auf Ihre installierte Version an und bewahren Sie tatsächliche Ergebnisse auf. Führen Sie eine kurze Liste offener Punkte mit Reproduktionsschritten, damit die nächste Entwicklungssitzung vom selben bekannten Zustand beginnt.

Häufige Fragen