AI生成ゲームをデバッグする

修正を求める前に失敗を分類する

最初に失敗する段階を特定します。プロジェクトの検出、インポート、解析またはコンパイル、シーン起動、プレイヤー入力、ゲームプレイ状態、エクスポート、対象起動のいずれかです。後の症状は最初の失敗の結果かもしれません。エンジンのバージョン、プロジェクトのリビジョン、対象、正確な再現手順を一緒に保持します。

たとえば、シーンが起動しなければ、再開ボタンが動くかどうかは分かりません。ブラウザがゲームパッケージを取得できなければ、コントローラーをテストできません。コードを変える前にエラーを正しい境界へ送り、元の前提条件が壊れたまま修理ループに無関係なパッチが増えないようにします。

最初に意味のあるエンジンエラーを取得する

Godotではデバッガーパネルと関連する実行時出力を使います。Unityではコンパイルエラーと実行時エラーを分けて検査し、プレイ結果を解釈する前にエディタの準備が整うのを待ちます。失敗したスクリプトと、それを起動した操作を特定するスタックまたは位置情報を保持してください。

焦点を絞った抜粋と、関連するシーンまたはオブジェクトのコンテキストをエージェントへ送ります。最初のエラーが隠れる巨大で未整理のログは避けますが、後の検査に備えて完全な記録はローカルに保持します。認証情報と個人データを秘匿化してください。役立つ報告には、プレイヤーがしたこと、起こるべきこと、エンジンが実際に報告したことを記載します。

要件を変えずに再現を小さくする

復元可能なプロジェクト状態から始め、欠陥がなお現れる最小のシーンまたは操作を切り分けます。問題に関係する実際のコントローラー、衝突ルール、セーブ境界を保持します。失敗しているシステムを完全に削除すればクリーンに実行できても、直す必要があった動作を失う可能性があります。

以下のブリーフはオリジナルの診断テンプレートです。原因をモデルに仮定させるのではなく、観測した詳細を埋めます。一つの説明案と範囲を限定した変更を求めてください。テストが完了したら、完全なプレイヤー体験に戻り、局所的な修理で壊れたシーン遷移を隠していないことを確認します。

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.

空白画面を段階的に調べる

まずエンジンが起動し、意図したシーンが読み込まれたか確認します。次にカメラの選択、ビューポートの寸法、オブジェクトの可視性、位置、シーンを覆うオーバーレイを調べます。エンジン状態と実際のキャプチャを一緒に使ってください。画像だけでは、シーンが一時停止しているのか、カメラ外なのか、空なのか分からない場合があります。

何も表示されなくても入力し、状態が変わるか観測します。位置は変わるのに画像が変わらないなら、レンダリングまたはシーン参照に注目します。どちらも変わらないなら、アートを調整する前に起動と入力を調べます。各仮説を観測結果に結び付け、エージェントが両方のシステムを不必要に書き直さないようにします。

入力をゲームプレイ遷移まで追跡する

フォーカスとマッピングからハンドラーへ、そして変わるはずの状態へ、操作の経路をたどります。移動計算を疑う前に、一時停止状態とUIによる入力の横取りを確認します。再開に失敗する原因は、ハンドラーの欠落、古いシーン参照、リセットされていない状態かもしれません。

修理後は、関係する複数の状態から操作をテストします。初回起動、勝利後、該当する場合は敗北後です。繰り返しラウンドを行ったときだけ現れる重複ハンドラーや古いオブジェクトを確認します。小さく完全なミニフローなら、ボタンを単独で繰り返しテストするより、こうしたライフサイクルの欠陥を効果的に切り分けられます。

ブラウザの読み込みとゲームロジックを分ける

GodotのWebエクスポートでは、ゲームプレイコードを編集する前にブラウザのネットワークパネルとコンソールパネルを調べます。エクスポートしたHTML、JavaScript、WebAssembly、ゲームパッケージが意図した場所から読み込まれることを確認します。選択したスレッド設定の要件を含め、ホスティング設定を公式Webエクスポートドキュメントと比較してください。

エクスポートした補助ファイルの名前を一致させ、古いファイルと新しいファイルの混在ではなく成果物をテストします。誤ったプロジェクトが表示されたら、テストブラウザのサービスワーカーキャッシュを調べます。その後入力を行い、動くコンテンツを確認します。空でないキャンバスは初期レンダリングチェックであり、ゲームループが機能する証拠ではありません。

対象環境固有のエクスポート失敗を確認する

エディタは動くのに配布ビルドが失敗する場合は、起動シーンの選択、含まれるリソース、設定、対象ログを比較します。正確な成果物ハッシュを保持し、後の再エクスポートで再現記録が無効にならないようにします。既存のセーブやエディタキャッシュを頼る前に、クリーンな開始状態でテストしてください。

パッケージ化されたファイルの欠落を直すために、コアメカニクスを変更しないでください。パッケージ化の境界を修正し、対象ビルドで同じ受け入れ経路を再実行します。デスクトップ成果物には実際のOSを、ブラウザ成果物には意図したブラウザとホスティング設定を使います。別形式へエクスポートしただけでは対象動作は確定しません。

修理を前後の結果で完了させる

失敗した再現、範囲を限定した差分、期待した状態を生むようになった同じ操作を保持します。欠陥を生んだ境界に回帰チェックを追加し、周辺のゲームプレイループを再実行します。手動修正と、失敗した修理で消費したリクエストを記録してください。

ここでの例は診断手順であり、公開済みの失敗と修正のケースではありません。自分のプロジェクトから具体的な報告を作るために使います。同じ症状が提案を繰り返しても残る場合は、自動ループを停止し、証拠を増やさない広範な書き直しへ進むのではなく、不足している観測を集めます。

よくある質問