KI-generierte Spiele debuggen

Klassifizieren Sie den Fehler, bevor Sie eine Korrektur anfordern

Identifizieren Sie den frühesten fehlschlagenden Schritt: Projekterkennung, Import, Parsing oder Kompilierung, Szenenstart, Spielereingabe, Gameplay-Zustand, Export oder Zielstart. Spätere Symptome können Folgen dieses ersten Fehlers sein. Bewahren Sie Engine-Version, Projektrevision, Ziel und exakte Reproduktion gemeinsam auf.

Eine Szene, die nie startet, kann beispielsweise nicht zeigen, ob ihr Neustart-Button funktioniert. Ein Browser, der das Spielepaket nicht laden kann, kann den Controller nicht testen. Leiten Sie den Fehler an die richtige Grenze, bevor Sie Code ändern. So verhindert der Reparaturkreislauf, dass sich unabhängige Patches ansammeln, während die ursprüngliche Voraussetzung noch fehlt.

Erfassen Sie den ersten aussagekräftigen Engine-Fehler

Verwenden Sie in Godot das Debugger-Panel und die relevante Laufzeitausgabe. Prüfen Sie in Unity Kompilierungs- und Laufzeitfehler getrennt und warten Sie, bis der Editor bereit ist, bevor Sie Spielergebnisse interpretieren. Bewahren Sie Stack oder Position auf, die das fehlschlagende Skript und die auslösende Operation identifizieren.

Senden Sie dem Agenten einen fokussierten Auszug sowie relevanten Szenen- oder Objektkontext. Vermeiden Sie ein riesiges undifferenziertes Log, das den ersten Fehler verdeckt, bewahren Sie den vollständigen Datensatz aber lokal zur späteren Prüfung auf. Bereinigen Sie Zugangsdaten und personenbezogene Daten. Ein nützlicher Bericht sagt, was der Spieler getan hat, was geschehen sollte und was die Engine tatsächlich gemeldet hat.

Reduzieren Sie die Reproduktion, ohne die Anforderung zu ändern

Beginnen Sie mit einem wiederherstellbaren Projektzustand und isolieren Sie die kleinste Szene oder Aktion, die den Fehler weiterhin zeigt. Behalten Sie den tatsächlichen Controller, die Kollisionsregel oder die Speichergrenze bei, die am Problem beteiligt ist. Wenn Sie das fehlerhafte System vollständig entfernen, kann ein sauberer Lauf entstehen, während das zu reparierende Verhalten verloren geht.

Das folgende Briefing ist eine eigene Diagnostikvorlage. Füllen Sie es mit beobachteten Details und bitten Sie das Modell nicht, eine Ursache anzunehmen. Verlangen Sie eine vorgeschlagene Erklärung und eine eng begrenzte Änderung. Fügen Sie nach Abschluss des Tests die vollständige Spielerreise wieder hinzu, damit die lokale Reparatur keinen kaputten Szenenübergang verdeckt.

Project revision: <record actual revision>
Engine and target: <record actual environment>
Steps: launch -> start round -> perform the failing action
Expected state: <specific result>
Observed state: <specific result>
First engine error: <relevant error and location>
Inspect the referenced scene and script before editing.
Propose one cause, make a scoped fix, then repeat these steps.
Preserve the required behavior and report any remaining failure.

Untersuchen Sie einen leeren Bildschirm in Ebenen

Bestimmen Sie zuerst, ob die Engine gestartet und die vorgesehene Szene geladen wurde. Prüfen Sie anschließend Kameraauswahl, Viewport-Abmessungen, Objektsichtbarkeit, Positionen und ein Overlay, das die Szene verdecken könnte. Verwenden Sie Engine-Zustand und echte Aufnahme gemeinsam: Ein Bild allein zeigt möglicherweise nicht, ob die Szene pausiert, außerhalb der Kamera oder leer ist.

Geben Sie Eingaben ein und beobachten Sie, ob sich der Zustand ändert, auch wenn nichts sichtbar ist. Wenn sich die Position ändert, das Bild aber nicht, konzentrieren Sie sich auf Rendering oder Szenenreferenzen. Wenn sich beides nicht ändert, untersuchen Sie Start und Eingabe, bevor Sie die Gestaltung anpassen. Verknüpfen Sie jede Hypothese mit einer Beobachtung, damit der Agent nicht beide Systeme unnötig umschreibt.

Verfolgen Sie die Eingabe durch den Gameplay-Übergang

Verfolgen Sie die Aktion von Fokus und Zuordnung über ihren Handler bis zu dem Zustand, den sie ändern soll. Prüfen Sie Pausenzustand und UI-Abfangverhalten, bevor Sie die Bewegungsmathematik verantwortlich machen. Ein Neustartfehler kann durch einen fehlenden Handler, eine veraltete Szenenreferenz oder einen Zustand entstehen, der nie zurückgesetzt wurde.

Testen Sie die Aktion nach der Reparatur aus mehreren relevanten Zuständen: beim ersten Start, nach einem Sieg und nach einer Niederlage, sofern zutreffend. Prüfen Sie duplizierte Handler oder veraltete Objekte, die erst nach wiederholten Runden erscheinen. Ein kleiner vollständiger Miniflow kann diese Lebenszyklusfehler wirksamer lokalisieren, als den Button wiederholt isoliert zu testen.

Trennen Sie Browser-Ladevorgang von Spiellogik

Prüfen Sie bei einem Godot-Webexport zunächst Netzwerk- und Konsolen-Panel des Browsers, bevor Sie Gameplay-Code bearbeiten. Bestätigen Sie, dass exportiertes HTML, JavaScript, WebAssembly und Spielepaket am vorgesehenen Ort geladen werden. Vergleichen Sie Hosting-Einstellungen mit der offiziellen Webexport-Dokumentation einschließlich der Anforderungen der gewählten Thread-Konfiguration.

Halten Sie exportierte Begleitdateinamen konsistent und testen Sie das Artefakt und nicht eine Mischung aus alten und neuen Dateien. Wenn das falsche Projekt erscheint, prüfen Sie den Service-Worker-Cache im Testbrowser. Testen Sie anschließend die Eingabe und bestätigen Sie bewegte Inhalte. Ein nicht leerer Canvas ist eine erste Rendering-Prüfung und kein Beleg dafür, dass die Spielschleife funktioniert.

Prüfen Sie exportspezifische Fehler auf dem Ziel

Wenn der Editor funktioniert, aber der verteilte Build fehlschlägt, vergleichen Sie Startszene, enthaltene Ressourcen, Konfiguration und Ziellogs. Bewahren Sie den exakten Artefakt-Hash auf, damit ein späterer Re-Export die Reproduktionsaufzeichnung nicht ungültig macht. Testen Sie mit einem sauberen Ausgangszustand, bevor Sie sich auf vorhandene Spielstände oder Editor-Caches verlassen.

Ändern Sie die Kernmechanik nicht, um eine fehlende gepackte Datei zu lösen. Beheben Sie die Paketierungsgrenze und wiederholen Sie denselben Abnahmepfad im Ziel-Build. Verwenden Sie für Desktop-Artefakte das tatsächliche Betriebssystem und für Browser-Artefakte den vorgesehenen Browser und das Hosting-Setup. Ein Cross-Export allein belegt kein Zielverhalten.

Schließen Sie eine Reparatur mit Vorher-Nachher-Ergebnis ab

Bewahren Sie die fehlerhafte Reproduktion, den begrenzten Diff und die wiederholte Aktion auf, die nun den erwarteten Zustand erzeugt. Ergänzen Sie an der fehlerverursachenden Grenze einen Regressionstest und durchlaufen Sie anschließend die umgebende Spielschleife. Erfassen Sie manuelle Korrekturen und die für erfolglose Reparaturen verbrauchten Anfragen.

Die Beispiele hier sind Diagnoseverfahren und kein veröffentlichter Fehler-und-Korrektur-Fall. Verwenden Sie sie, um aus Ihrem Projekt einen konkreten Bericht zu erstellen. Wenn dasselbe Symptom nach wiederholten Vorschlägen bestehen bleibt, stoppen Sie die automatische Schleife und sammeln Sie die fehlende Beobachtung, statt ohne neue Belege eine umfassende Umschreibung zu beginnen.

Häufige Fragen