Godot と Codex で 3 つの題材を試してみたら、初回出力の強さと人手確認の重さが見えてきた

# テーマ 1 セッション開始指示

このセッションでは、Godot の 2D アクション検証だけを扱ってください。
他テーマの内容は前提にせず、このテーマ単体の実装、検証、会話内での要約作成に集中してください。

## 開始時の前提

- 現在の作業ディレクトリには、まだ実ファイルが入っていないことがあります
- ディレクトリが空でも異常ではありません。このセッションでは、ここを検証用プロジェクトのルートとして使ってください
- まず、このディレクトリにベース候補を導入するか、必要なら最小構成を作成して作業を始めてください
- 対象の Godot バージョンは `Godot_v4.6.1-stable_win64` です
- 検証環境は Windows のみです
- このディレクトリには `godot` フォルダーが同梱されている前提です
- Godot をコマンドで起動するときは `./godot/Godot_v4.6.1-stable_win64_console.exe` を使ってください

## テーマの狙い

高速移動を伴う 2D アクションでは、単にキャラクターが移動できるだけでは不十分です。
入力受付、アニメーション遷移、カメラ追従、物理挙動の噛み合わせまで含めて、触ったときの気持ちよさが問われます。
この検証では、Codex が Godot らしい 2D アクション改修をどこまで破綻なく扱えるかを確認します。

## 対象

- テーマ: 高速移動を伴う 2D アクション
- ベース候補: `2D Platformer Demo`
- 出典: https://godotengine.org/asset-library/asset/2727
- ライセンス: MIT
- ベース候補が取得しにくい場合のみ、権利上問題のない最小構成を現在のディレクトリに自作してかまいません

## 初回実装で狙う要素

初回実装では、次の 5 要素を対象にしてください。

- dash
- wall slide / wall jump
- coyote time
- jump buffer
- 高速移動時のカメラ追従調整

必須要素は 4 つ以上でよいですが、今回は上の 5 つを優先してください。

## 想定される破綻

特に次を警戒してください。

- dash だけ追加されて全体の操作感が崩れる
- wall jump の判定が不安定になる
- coyote time と jump buffer が干渉して不自然なジャンプになる
- アニメーション状態と物理状態がずれる
- 高速移動時にカメラが追従しすぎて見づらくなる
- 壁抜け、めり込み、入力抜けが起きる

## このセッションで行うこと

1. このディレクトリにベースを導入し、Godot 4.6.1 で起動確認する
2. 上記 5 要素を実装する
3. 初回出力を手動検証する
4. 必要なら追加修正する
5. 会話内で最終要約をまとめる

## 手動検証で重視する観点

人間による確認では、少なくとも次を重視してください。

- 触って違和感がないか
- 壁際ジャンプや高速移動で挙動が不安定にならないか
- 入力受付が遅れたり抜けたりしないか
- 高速移動時にカメラが見づらくならないか
- 実装が場当たり的になっておらず、設定値や責務分離が保たれているか

## 最終要約に必ず含める内容

- ベース導入手順
- ベース選定理由
- 初回出力で成立した点
- 初回出力で破綻した点
- 追加指示の回数と要点
- 人間が見つけた違和感
- 修正後の状態
- 最終的に残った問題
- 更新した主要ファイル
- 記事に使えそうな観察結果

全体的には大きな破綻はない一方、細かい手触り感がまだかなりずさんな印象です。これらを修正してください。

## 実装に問題があると思われるもの

- 左に向いているとき毎フレーム身体が反転して前後両方を同時に向いているようになってしまいます。
- 壁張り付きの判定が失敗するケースがあります。最高到達点に達して状態が落下中に変わった状態で壁に張り付いた場合に壁張り付きにならないようです。一方、その場合でも壁キックができてしまうので、おそらく状態管理が変です。

## 私の感覚に依存するもの（遊ぶ人によっては違和感がないかもしれない）

- スピードアクションと指示した割にスピード感が感じられません。全体的に足が遅いです。ダッシュ時の距離も短く爽快感がありません。
- カメラの動きが気持ち悪いです。左に向いたときと右に向いたときでカメラが大きく揺れるので急激に方向転換を繰り返すと激しく揺れて酔います。
- 試験場の地形が適切ではありません。せっかく壁キックがあるのに、両側に高い壁があって登っていくような遊びが試せません。

# テーマ 2 セッション開始指示

このセッションでは、Godot の小規模対戦マルチプレイ検証だけを扱ってください。
他テーマの内容は前提にせず、このテーマ単体の実装、検証、会話内での要約作成に集中してください。

## 開始時の前提

- 現在の作業ディレクトリには、まだ実ファイルが入っていないことがあります
- ディレクトリが空でも異常ではありません。このセッションでは、ここを検証用プロジェクトのルートとして使ってください
- まず、このディレクトリにベース候補を導入して作業を始めてください
- 対象の Godot バージョンは `Godot_v4.6.1-stable_win64` です
- 検証環境は Windows のみです
- このディレクトリには `godot` フォルダーが同梱されている前提です
- Godot をコマンドで起動するときは `./godot/Godot_v4.6.1-stable_win64_console.exe` を使ってください

## テーマの狙い

この検証では、少人数の対戦マルチプレイにおいて、所有権、補間、同期ずれを Codex がどこまで扱えるかを確認します。
特に、見た目だけ同期している状態と、実際に遊べる状態の差を観察します。
対戦を優先する理由は、各フレームの挙動差が結果に直結し、破綻が観察されやすいためです。

## 対象

- テーマ: 小規模対戦マルチプレイ
- 第一候補: `Multiplayer Bomber Demo`
- 予備候補: `Pong Multiplayer Demo`
- 出典: https://godotengine.org/asset-library/asset/2797
- ライセンス: MIT

## 初回実装で狙う要素

初回実装では、次の 5 要素を対象にしてください。

- プレイヤー位置 / 移動の同期改善
- 爆弾や爆風の同期
- ownership の整理
- 接続 / 切断時の最低限の扱い
- 見た目の滑らかさ改善

必須要素は 3 つ以上でよいですが、今回は上の 5 つを優先してください。

## 想定される破綻

特に次を警戒してください。

- 移動は同期するが当たり判定がずれる
- 爆弾や攻撃オブジェクトの ownership が曖昧になる
- 片方から見ると当たっているのに、もう片方では当たっていない
- 切断や再接続で状態が壊れる
- 補間で見た目は滑らかでも内部状態は不整合になる

## このセッションで行うこと

1. このディレクトリにベースを導入し、ホスト / クライアントの起動確認を行う
2. 上記 5 要素を実装する
3. 初回出力を 2 インスタンスで検証する
4. 必要なら追加修正する
5. 会話内で最終要約をまとめる

## 手動検証で重視する観点

人間による確認では、少なくとも次を重視してください。

- 見た目上の同期だけで誤魔化されていないか
- 被弾や衝突判定が両視点で一致しているか
- ownership が曖昧で不正な挙動が出ていないか
- 切断や再接続の直後に状態が壊れないか
- 修正後も別の同期処理が壊れていないか

## 最終要約に必ず含める内容

- ベース導入手順
- ベース選定理由
- ホスト / クライアント確認手順
- 初回出力で成立した点
- 初回出力で破綻した点
- 追加指示の回数と要点
- 人間が見つけた視点差や違和感
- 修正後の状態
- 最終的に残った問題
- 更新した主要ファイル
- 記事に使えそうな観察結果

# テーマ 2 クラッシュ修正指示

`SESSION-INIT.md` の前提を維持したまま、このディレクトリ内だけで作業してください。

現状の問題は次です。

- Godot でプロジェクトを開くと、「このプロジェクトを最後に開いたのは 4.2 であり、4.6 として開くか」という旨のダイアログが出た
- そのまま許可して開いた
- デバッグで複数実行を有効にした
- Host と Join を行うと、エラーメッセージが出てクラッシュした

やってほしいことは次です。

1. Godot 4.6 環境で起きているクラッシュ原因を、このディレクトリ内のファイルだけから特定してください
2. まず、4.2 -> 4.6 移行に起因する問題か、今回の同期改修に起因する問題かを切り分けてください
3. `Host` と `Join` の直後に落ちる原因を、できるだけ最小の修正で直してください
4. 修正後は、少なくとも「プロジェクトを 4.6 で開く」「Host と Join を行う」までで落ちない状態にしてください
5. 変更後に、原因、直した内容、まだ未確認の点を会話内で要約してください

制約は次です。

- 現在のディレクトリ配下だけを対象にしてください
- 親ディレクトリは探索しないでください
- 既存の実装方針を全面的に作り直さず、まずはクラッシュ解消を優先してください
- 変更は必要最小限にしてください
- 最終要約はファイルへ書かず、会話内で返してください

補足です。

- 初回実装では `player.gd`、`bomb.gd`、`gamestate.gd`、`score.gd`、`player.tscn`、`bomb.tscn` を触っています
- 今回は「同期品質の改善」より先に、「4.6 で Host / Join すると落ちる」問題の解消を最優先にしてください
- 可能なら、クラッシュの直接原因になっているノード参照、RPC、同期設定、4.6 非互換 API を明示してください
- 可能なら、Godot 上に出たエラーメッセージ本文も前提として活用してください

# テーマ 3 セッション開始指示

このセッションでは、Godot のエディタ拡張 / 制作支援ツール検証だけを扱ってください。
他テーマの内容は前提にせず、このテーマ単体の実装、検証、会話内での要約作成に集中してください。

## 開始時の前提

- 現在の作業ディレクトリには、まだ実ファイルが入っていないことがあります
- ディレクトリが空でも異常ではありません。このセッションでは、ここを検証用プロジェクトのルートとして使ってください
- まず、このディレクトリに最小の Godot プロジェクトを作成して作業を始めてください
- 対象の Godot バージョンは `Godot_v4.6.1-stable_win64` です
- 検証環境は Windows のみです
- このディレクトリには `godot` フォルダーが同梱されている前提です
- Godot をコマンドで起動するときは `./godot/Godot_v4.6.1-stable_win64_console.exe` を使ってください

## テーマの狙い

この検証では、Godot の EditorPlugin を使った制作支援ツールを Codex がどこまで実用的に構築できるかを確認します。
要望は Unreal Engine のブループリントに近い体験ですが、Godot 4 系では前提が異なるため、用途を絞ったノード接続型ツールとして扱います。
ゲーム本体よりもツール作成の方が Codex と相性がよいかどうかも観察対象です。

## 対象

- テーマ: エディタ拡張 / 制作支援ツール
- 方針: `EditorPlugin` と `GraphEdit` を使ったノード接続型のイベント / 挙動設定ツール
- 補足: 汎用の視覚スクリプト言語ではなく、用途を絞った制作支援ツールとして実装してください

## 初回実装で狙う要素

初回実装では、次の要素を対象にしてください。

- ノード接続 UI の表示
- ノード配置
- 接続関係の保存 / 再読込
- ゲーム側からの利用
- EditorPlugin と明確に連携した導線

## 想定される破綻

特に次を警戒してください。

- UI はあるが、保存と再読込で接続情報が壊れる
- ノード定義とゲーム側の利用形式がずれる
- エディタ統合が浅く、ただの実行時 UI に留まる
- 少し仕様変更するとすぐ壊れる
- 継続利用しづらい雑な操作感になる

## このセッションで行うこと

1. このディレクトリに最小の Godot プロジェクトを作成する
2. `EditorPlugin` の有効化と最小表示を確認する
3. 上記の要素を持つツールを実装する
4. 初回出力を手動検証する
5. 必要なら追加修正する
6. 会話内で最終要約をまとめる

## 手動検証で重視する観点

人間による確認では、少なくとも次を重視してください。

- 制作支援ツールとして意味があるか
- ノード接続、保存、再読込が破綻していないか
- ゲーム側、またはランタイム側から利用できるか
- Godot の editor workflow に自然に馴染むか
- 継続利用したくなる程度の操作感があるか

## 最終要約に必ず含める内容

- 最小プロジェクト作成手順
- 採用したツール方針の理由
- 初回出力で成立した点
- 初回出力で破綻した点
- 追加指示の回数と要点
- 人間が見つけた使い勝手の違和感
- 修正後の状態
- 最終的に残った問題
- 更新した主要ファイル
- 記事に使えそうな観察結果

# テーマ 3 修正指示

`SESSION-INIT.md` の前提を維持したまま、このディレクトリ内だけで作業してください。

## この修正で重視すること

今回は機能追加より、まずグラフ編集ツールとしての安定性を上げてください。
特に次の 3 点を優先します。

- 接続情報が内部で壊れないこと
- 接続線の表示が安定すること
- 保存 / 再読込で同じ状態に戻ること

そのうえで、最低限の編集完結性として、ノードと connection を GUI から削除できるようにしてください。

## 現状で成立している点

次の点は現時点でも良好です。これらは壊さないでください。

- `EventGraphRunner` を選んだときだけ右 dock が出る
- マップの表示 / 非表示ができる
- 自動整列が使える
- グリッド表示 / 非表示ができる
- グリッドスナッピングが使える
- マウスミドルクリックでカメラ移動できる
- 操作感の方向性は類似ツールに近く、初見でも触り始めやすい

## 手動検証で見つかった問題

### 1. 接続線の表示が不安定

ノードを追加した直後、またはノードを接続した直後に、接続線がすべて見えなくなる場合があります。

- ミニマップ上では存在しているように見えます
- そのため、接続そのものが消えたというより、GraphEdit 側の表示更新か再構築処理が壊れている可能性があります

### 2. 内部の connection 数が見た目と一致しない

GUI 上の見た目と内部の connection 数が一致していません。

- 例として、見た目では `5 nodes / 6 connections` 程度に見える状態でも、status 表示が `Editing EventGraphRunner with 5 nodes / 21 connections` のようになります
- 同じ connection が内部で重複登録されている可能性があります

### 3. 保存 / 再読込が安定しない

`Save Graph` を押して再起動したあと、追加した connection が正しく復元される場合とされない場合があります。

- 接続線が見えなくなった状態で保存すると、再読込結果も安定しません
- `.tres` に重複や不正な connection が保存されている可能性があります

### 4. 削除の導線がない、または分かりにくい

追加したノードや connection を消す方法が分かりません。

- 何らかの方法があるとしても、GUI 上では案内されておらず直感的ではありません
- 制作支援ツールとしては、追加だけできて削除できない状態では不十分です

## 優先順位

次の順で直してください。

1. connection の重複登録を止める
2. 接続線が見えなくなる表示不具合を直す
3. 保存 / 再読込で常に同じ graph が戻るようにする
4. GUI から node と connection を削除できるようにする
5. 既存の良い操作感を壊していないことを確認する

## 切り分けてほしい観点

少なくとも次を確認してください。

- connection 追加時に同じ接続が重複登録されていないか
- `_rebuild_graph()` のたびに connection が積み上がっていないか
- `GraphEdit.connect_node()` と resource 側の配列が二重管理になっていないか
- ノード追加、接続追加、切断、保存の各操作後に表示更新が破綻していないか
- `.tres` 保存時に重複 connection がそのまま保存されていないか
- 再読込時に connection の復元順や再接続処理が不安定になっていないか
- node と connection の削除方法を GUI から自然に提供できているか

## 今回やってほしいこと

1. このディレクトリ内のファイルだけで上記の問題を修正してください
2. まず、connection 重複と表示不安定の直接原因を切り分けてください
3. 修正後は、少なくとも `ノード追加 -> 接続追加 -> Save Graph -> Godot 再起動 -> 再読込` を安定して通る状態にしてください
4. GUI から node と connection を削除できるようにしてください
5. 既存の良い操作機能が壊れていないことも確認してください
6. 最後に、原因、直した内容、まだ残る問題を会話内で要約してください

## 制約

- 現在のディレクトリ配下だけを対象にしてください
- 親ディレクトリは探索しないでください
- まずは安定性を優先してください
- 変更は必要最小限にしてください
- 最終要約はファイルへ書かず、会話内で返してください