godot-genre-fighting

絶対にしてはいけないこと（エキスパート向けアンチパターン）

フレームデータとロジック

• 可変フレームレートは絶対に使用しないでください。ロジックは決定論的な固定ループ（フレームカウンターを使った_physics_process）に厳密に固定し、テレポート時には**reset_physics_interpolation()**を呼び出してください。
• ヒット検出に標準の物理処理は絶対に使用しないでください。Area2Dのシグナルによる遅延を避け、**PhysicsDirectSpaceState.intersect_shape()**を使ってヒットボックスを即座に問い合わせてください。
• ダメージスケーリングを絶対に省略しないでください。無限コンボを防ぐため、コンボ中はヒットごとに必ず10％のダメージ軽減を適用してください。
• すべての技をガードされても隙のない技にしてはいけません。高リターンの技には、攻撃側が反撃を受けるリカバリーウィンドウを必ず設けてください。
• Area2D.get_overlapping_areas()には絶対に依存しないでください。即時かつフレーム単位で正確に解決するため、必ず**intersect_shape()**を使用してください。
• **ヒットボックスの近接（近接ガード）**を絶対に忘れないでください。ヒットが成立していなくても、ヒットボックスが近くのゾーンに入った時点で、必ずガード状態を発動してください。

キャラクターとアニメーション

• キャラクターの向きを反転する際、単純な親ノード設定（scale.x = -1）は絶対に使用しないでください。専用のVisualsノードを調整しつつ、ヒットボックスのオフセットをプログラムで管理してください。
• 文字列ベースのアニメーショントリガーは絶対に使用しないでください。フレーム同期再生には、必ずADVANCE_MANUALを使ったAnimationMixerを使用してください。
• フレーム単位の厳密なロジックにyieldやawaitは絶対に使用しないでください。リカバリーとスタートアップのウィンドウを正確に管理するため、ステートマシン内で必ず整数フレームカウントを使用してください。
• フレームデータを生のスクリプトに絶対に保存しないでください。ダメージスケーリング、キャンセル、コンボ状態の追跡を委譲するロジックとともに、必ず**Resourceファイル（.tres）**を使用してください。
• キャラクターのパーツに深いノード階層を絶対に使用しないでください。トランスフォーム処理の負荷を減らすため、スケルトンの階層は浅くしてください。

入力とネットワーク

• 入力バッファリングを絶対に省略しないでください。プレイヤーが寛容かつ応答性の高い操作を行えるよう、必ず5～10フレームのバッファを実装してください。
• Input.use_accumulated_inputを有効にしたままにしないでください。正確なコンボ連係のためのサブフレームタイミングを保てるよう、必ず無効にしてください。
• ネットプレイでクライアント側のヒット検出は絶対に使用しないでください。同期ずれを防ぐため、必ずロールバックネットコードまたはサーバー検証を使用してください。
• マルチプレイヤーで標準のTCPは絶対に使用しないでください。レイテンシーが急増した際のヘッドオブラインブロッキングを避けるため、必ずUDP/ENetを使用してください。
• ネットプレイでファイターのトランスフォームをSceneTreeに絶対に依存させないでください。位置は必ずシリアライズ可能なデータバッファで管理してください。

---

🛠 エキスパート向けコンポーネント（scripts/）

対応するシステムを実装する前に必ず読むこと：

1. fighting_input_buffer.gd — 入力バッファリング＋モーション（QCF/DP）
2. direct_hitbox_query.gd — 唯一のヒット解決経路（intersect_shape）
3. rollback_state_serializer.gd — ネットプレイ向けのスナップショット／復元

エキスパート向けの基本パターン

• fighting_input_buffer.gd - モーションコマンドのあいまい検索（QCF/DP）に対応した、フレーム固定の入力エンジン（60fps）。
• hitbox_component.gd - ヒットボックス／やられ判定のボリュームヘルパー（レイヤー：上段／下段／投げ）— Areaシグナルではなく、direct_hitbox_queryを介してヒットを解決します。

モジュール式コンポーネント

• deterministic_physics_loop.gd - フレーム単位でゲーム状態を正確に進行させるカスタムループパターンです。
• direct_hitbox_query.gd - PhysicsServer のシェイプキャストによる即時の衝突解決です。
• hit_stop_controller.gd - 「インパクト」感を演出する動的な時間スケール操作です。
• manual_animation_advancer.gd - 手動のデルタ処理による、フレームと同期したアニメーション制御です。
• rollback_state_serializer.gd - 離散的なゲーム状態のスナップショットを管理するシリアライズロジックです。
• bitwise_state_flags.gd - ファイターの状態追跡に使う、高速なビット演算フラグです。
• input_accumulation_control.gd - サブフレームのタイミング制御のため、Godot の入力蓄積を無効にする切り替え機能です。
• raw_byte_network_sync.gd - ネットプレイの効率化を目的とした、UDP ベースの状態同期です。
• string_name_optimization.gd - AI 状態でポインターレベルの StringName 比較を使うパターンです。
• round_timer_logic.gd - フレーム同期の試合タイマーとタイムアウト判定のロジックです。

ベースラインから復元（必要に応じて読み込み）

• attack_resource.gd - 起動／有効／硬直／有利フレームを定義する .tres フレームデータ Resource です。
• combo_tracker.gd - ダメージ補正（1ヒットあたり約10％）とコンボ状態を管理します。
• fighter_state_machine.gd - 整数の state_frame を使う IDLE／ATTACKING／HITSTUN 状態です。
• fight_game_state.gd - シリアライズ可能なロールバック用スナップショットの枠組みです（rollback_state_serializer.gd と組み合わせてください）。
• move_set_loader.gd - デザイナーによる反復作業向けの JSON 技リストローダーです。
• frame_advancer.gd - ヒットボックスの位置合わせに使う、@tool エディター用フレームスクラバーです。
• fighter_balance_profile.gd - ロスターごとのダメージ／移動／防御補正を定義する Resource です。

---

コアループ

ニュートラル → ヒット確認 → コンボ → 有利状況 → 繰り返し

判断ツリー（Area2D なし／システムのインライン表示なし）

フレームと固定ループ

必要なもの	対応
攻撃タイミング Resource	起動／有効／硬直／有利フレームを .tres で定義します。スクリプト定数は使いません
60fps のシミュレーションステップ	deterministic_physics_loop.gd
アニメーションとフレームの同期	manual_animation_advancer.gd（ADVANCE_MANUAL）

入力

必要なもの	対応
5～10f のバッファ＋QCF／DP	必須 fighting_input_buffer.gd
サブフレームのリンク	input_accumulation_control.gd — 入力の蓄積を無効にします

ヒットボックス

必要なもの	対応
フレーム単位で正確なヒット判定	必ずこれのみを使用 direct_hitbox_query.gd
判定領域の作成補助	形状／レイヤーには hitbox_component.gd を使います。判定処理に area_entered ／ get_overlapping_areas を使うことは絶対に避けてください
近接ガード	有効フレームが始まる前に、拡張した形状をクエリします

コンボ／キャンセル

必要なもの	対応
ダメージ補正（1ヒットあたり約10％）	コンボ状態で追跡し、キャンセルの階層を Attack Resource に保存します
状態	整数の state_frame を使った IDLE／ATTACKING／HITSTUN／BLOCKSTUN… — godot-state-machine-advanced を参照してください

ネットコード

必要な項目	対応
スナップショット	必須 rollback_state_serializer.gd
トランスポート	raw_byte_network_sync.gd を介した UDP/ENet；ピア：godot-multiplayer-networking

---

バランス調整のガイドライン

要素	ガイドライン
体力	約20秒のラウンドでは10,000～15,000
コンボダメージ	1回の接触につき体力の最大30～40％
最速技	発生3～5フレーム（ジャブ）
最遅技	20～40フレーム（スーパー技、オーバーヘッド）
投げの射程	短めでも安定して届くこと
ゲージ増加量	コンボを約2回受けるとゲージが最大までたまる

ロスター／マッチアップのシミュレーションには、godot-monte-carlo-balancer を使用してください。

よくある落とし穴

落とし穴	解決策
無限コンボ	ヒットスタンの減衰＋重力スケーリング
Area2Dのシグナルによるヒット判定	direct_hitbox_query.gd に置き換える
ラグによる入力の取りこぼし	8フレーム以上バッファする
デシンク	決定論的なループ＋ロールバックシリアライザー

専門知識（必要に応じて）

LLMの無知に関するルール： 一般的なエージェントが読む前には知らない知識は、参照資料を読み込んでください。専門知識による差分は決して削除しないでください。

• expert-fighting-patterns.md — 基礎となる教育内容を復元（アーキテクチャ、理由、実装の詳細）
• attack_resource.gd
• combo_tracker.gd
• fighter_state_machine.gd
• fight_game_state.gd
• move_set_loader.gd
• frame_advancer.gd
• fighter_balance_profile.gd

リファレンス

段階的開示：特定のAPIを調査するときに限り、公式ドキュメントへのリンクを開いてください。 作業を関連分野のピアに割り当てる際は、関連スキルを読み込んでください。関連分野の全体を事前に読み込まないでください。

公式ドキュメント

• アイドル処理と物理処理 — 対戦のロジックは、変動する _process の差分ではなく、固定された物理ティック（またはカスタムのフレームカウンター）で実行する必要があります。
• 入力 — use_accumulated_input を無効にし、フレームごとにアクションをサンプリングすることで、入力バッファーとモーションウィンドウの決定性を維持します。
• 入力の例 — 5〜10 フレームのバッファーやモーション検出を支えるアクションマップとイベント処理のパターンです。
• コントローラー、ゲームパッド、ジョイスティック — スティックのデッドゾーンとデジタルゲートのしきい値を設定し、QCF/DP の方向履歴を正確に記録します。
• Area2D の使用 — ヒットボックス／くらい判定の領域、monitoring と monitorable の違い、そしてフレーム単位の正確な相打ち判定ではシグナルの遅延が手遅れになりやすい理由を説明します。
• 物理の概要 — 頻繁に実行される処理で文字列グループを使う代わりに、衝突レイヤー／マスクで上段・下段・投げをフィルタリングします。
• PhysicsDirectSpaceState2D — Area2D の重複シグナルを待たずに、intersect_shape で即時にヒットを判定します。
• PhysicsShapeQueryParameters2D — 直接ヒットボックス判定のためのシェイプクエリ設定（マスク、除外、collide_with_areas）です。
• AnimationMixer — ADVANCE_MANUAL／コールバックモードを使い、攻撃アニメーションを整数フレームのデータと同期して進行させます。
• リソース — 起動・アクティブ・リカバリー、キャンセル、バランスプロファイルは、スクリプトに定数としてハードコードするのではなく、.tres データとして保存します。
• ハイレベルマルチプレイヤー — 決定論的なファイターシミュレーションにオンライン対戦を追加する際の、オーソリティ、RPC、ピアの役割について説明します。
• ENetMultiplayerPeer — TCP のヘッドオブラインブロッキングを避け、ロールバックに適した入力交換を行うための UDP/ENet トランスポートです。

関連スキル

前提条件

• godot-project-foundations — フレームデータシステムの決定性を維持するには、物理ティックレート、入力マップ、プロジェクトのデフォルト設定を事前に確定する必要があります。
• godot-input-handling — モーションコマンドやキャンセルに対応した、アクションのサンプリング、デバイスのマッピング、入力バッファーに適した入力処理の仕組みです。
• godot-2d-physics — レイヤー／マスクと直接のスペースクエリは、Area シグナルの遅延なしにヒットボックス／くらい判定を行う基盤です。
• godot-characterbody-2d — 純粋なヒット検出以外にも必要となる、接地状態での移動、向き、テレポート／reset_physics_interpolation の規約を扱います。

補完

• godot-combat-system — 共有の DamageData／ヒット確認パターン。格闘ゲームのフレームデータでは、これを発生・持続・硬直の各フレームに特化させます。
• godot-animation-player — 自由に動作するタイマーではなく、アニメーションで制御するヒットボックスの有効化トラック、キャンセル可能フレーム、硬直ロックです。
• godot-state-machine-advanced — await ベースの硬直ではなく、整数の state_frame カウンターを使う IDLE／ATTACKING／HITSTUN／BLOCKSTUN の FSM です。
• godot-resource-data-patterns — 技リスト、キャンセルテーブル、FighterBalanceProfile リソースを、各ファイターインスタンスごとに安全に複製します。
• godot-signal-architecture — シミュレーションループとプレゼンテーションノードを結合せずに、ヒット確認、ラウンド終了、HUD イベントを扱います。
• godot-multiplayer-networking — ロールバックまたは入力遅延型ネットコードにおける、ピア同期、RPC の規律、権威ある検証です。
• godot-adapt-single-to-multiplayer — ローカルのファイターをネットプレイ対応にする際の、予測、再同期、ロビー／途中参加のパターンです。

下流／利用側

• godot-monte-carlo-balancer — AFK からプロまでの PvE 帯域をもとに推測するのではなく、ロスター全体の対戦カード表、ダメージ補正、反撃可能時間をシミュレートします。

マスター

• godot-master — 対応する格闘ゲーム関連モジュールを見つけ、共有スクリプトのミラーを同期するための、ライブラリルーター兼ミラーモジュールのエントリーポイントです。