godot-genre-action-rpg

絶対に避けること（エキスパート向けのアンチパターン）

戦闘と進行

• 進行に線形のダメージスケーリングを絶対に使用しないでください。パワーファンタジーを維持するため、必ず指数曲線（例：base * pow(1.15, level)）を使用してください。
• 防御ステータスが線形に積み重なって100％に達することを絶対に許可しないでください。無敵状態を防ぐため、必ず逓減効果の式（例：armor / (armor + 100.0)）を使用してください。
• ヒットリカバリー（ひるみ）を絶対に省略しないでください。戦闘が「ふわふわ」した印象になるのを防ぐため、大きな攻撃を受けた際に短いひるみ状態（0.2秒～0.5秒）を必ず実装してください。
• 重要なステータスをプレイヤーに絶対に隠さないでください。理論構築に役立つ詳細なキャラクターシート（クリティカル率、耐性など）を必ず用意してください。
• 戦利品のドロップを見た目で絶対に区別できないようにしないでください。レアリティごとに色分けされたビーム（紫／金）と異なる効果音で、必ず区別してください。
• ヒットボックス、ノックバック、戦闘中の移動を_process()で絶対に計算しないでください。決定論的な結果を得るため、必ず_physics_process()を使用してください。
• 戦闘のしきい値に対して、浮動小数点数の完全一致（==）を絶対に評価しないでください。必ずis_equal_approx()を使用してください。
• AnimationTree の Advance Condition 式で !（NOT）演算子を絶対に使用しないでください。明示的なブール値の比較（is_walking == false）を必ず使用してください。

技術とアーキテクチャ

• キャラクターのステータスや大規模なインベントリを Node として絶対に保存しないでください。メモリ使用量を抑えるため、必ずResource ベースのデータコンテナーを使用してください。
• 共有 Resource に対するduplicate()の呼び出しを絶対に忘れないでください。1体のゴブリンのステータスを変更しても、ほかのすべてのインスタンスに影響しないようにしてください。
• 戦闘の検出を特定のクラスに絶対に厳密に結合しないでください。相互作用には必ずダックタイピング（例：if body.has_method(&"take_damage")）を使用してください。
• インベントリの信頼できる情報源として、UI の SceneTree に絶対に依存しないでください。データロジックと表示処理は必ず分離してください。
• 毎フレーム、ステータスを絶対に再計算しないでください。装備変更時またはレベルアップ時にのみ再計算を実行してください。
• 大規模な RPG セーブファイルを同期的に絶対に解析しないでください。重い解析処理は必ずWorkerThreadPoolに委ねてください。
• 複雑な Resource 型をネットワーク経由で絶対に同期しないでください。変更をプリミティブ型の Dictionary または PackedByteArray に必ずシリアライズしてください。
• 子ノードを親ノードの存在に結び付けて、キャラクターの状態を絶対に管理しないでください。疎結合を保つため、必ずシグナルを使用してください（「Signal Up, Call Down」）。
• 高頻度で使う AI 状態識別子に標準の String を絶対に使用しないでください。ハッシュ比較を最適化するため、必ずStringNameを使用してください。

パフォーマンスと AI

• 毎秒数百個のオブジェクト（弾丸、ダメージ表示など）を生成・破棄することを絶対にしないでください。必ずオブジェクトプーリングを使用してください。
• 戦闘中のエンティティをfree()で絶対に削除しないでください。安全に遅延破棄するため、必ずqueue_free()を使用してください。
• 複雑な戦利品ドロップの計算や、終盤の大規模なインベントリの解析をメインスレッドで絶対に行わないでください。重い乱数処理や配列の反復処理は、必ずWorkerThreadPoolに委ねてください。
• 複雑なボス AI に入れ子の if/elif ブロックを絶対に使用しないでください。必ずモジュール式のStateMachineまたはパターンマッチングを使用してください。
• グローバルな状態変更のために SceneTree を反復処理することを絶対にしないでください。必ずシグナルグループ（call_group()）を使用してください。
• 動的なキャラクターにアタッチされたOccluderInstance3Dノードを絶対に移動しないでください。CPU による BVH 再構築で処理が停止する原因になります。

---

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

必須：CombatController／RPGStats のチュートリアルをインラインで作成する前に、以下の判断に関わるスクリプトを読んでください。 ピアジャンルのスキル（プラットフォーマー、レーシングなど）や、インベントリ／アビリティの詳細全般は、スキルチェーンの行で必要とされない限り読み込まないでください。ARPG の戦闘／戦利品／進行の範囲にとどめてください。

戦闘と命中処理

• hitbox_component.gd — 必須 Area ヒットボックスの有効化／無効化と多重ヒット防止。
• duck_typed_hitbox.gd — 必須 has_method(&"take_damage") による結合。
• health_component.gd — 子コンポーネントとして HP／死亡シグナルを管理します。
• aoe_physics_query.gd — 必須 PhysicsServer による AoE（爆発ごとに Node を生成しません）。
• aoe_group_broadcaster.gd — 陣営／AoE 向けのグループ一斉通知。
• combat_event_bus.gd / signal_combat_decoupler.gd / combat_log_connector.gd — 疎結合な戦闘バス／ログ。
• damage_label_manager.gd — 必須 プールされた浮遊ダメージ数値。
• stat_reduction_solver.gd — 逓減する防御力／耐性の計算。

ステータスと成長

• base_stat_resource.gd / character_stats_resource.gd — Resource を中心とした属性管理。
• deep_stat_duplicator.gd / entity_stat_duplicator.gd — 出現時の 必須 duplicate(true)。
• leveling_table.gd — XP／レベル曲線。
• cooldown_coroutine.gd — アビリティのクールダウン待機。

AI／アニメーション／インベントリのパフォーマンス

• telegraphed_enemy.gd — 必須 ソウルライクな予備動作／AoE の予兆。
• hierarchical_state_base.gd — ボス／プレイヤーの戦闘 FSM 基底クラス。
• animation_condition_sync.gd — ! を使わずに AnimationTree の Advance Conditions を設定します。
• high_speed_aggro_broadcaster.gd — グループを利用した局所的な敵視通知。
• threaded_inventory_loader.gd — 必須 WorkerThreadPool によるインベントリの解析。
• typed_inventory_storage.gd — 型付きアイテム辞書ストレージ。
• combat_damage_calculator.gd — 逓減するダメージとクリティカル判定。
• loot_generator.gd — ティアに応じたレア度の重み付けと接辞数。
• enemy_area_scaler.gd — 出現時のエリアレベルに応じたステータス／XP 倍率。

---

コアループ

戦闘 → 戦利品 → レベルアップ → 戦力強化 → より難しいコンテンツに挑戦 → 繰り返し

スキルチェーン

godot-project-foundations → godot-characterbody-2d → godot-combat-system → godot-rpg-stats → godot-inventory-system → godot-ability-system → godot-quest-system → godot-economy-system → godot-save-load-systems → godot-monte-carlo-balancer

判断ツリー（クラスの羅列なし）

問題	判断	スクリプト／関連項目
近接攻撃／飛び道具の接触判定	_physics_process 内で Area ヒットボックスを有効にする	hitbox_component + duck_typed_hitbox
防御力の重ねがけがうまく機能しない	線形の％ではなく、逓減を使う	stat_reduction_solver
ダメージ数値の表示で引っかかる	ラベルをプールする	damage_label_manager
共有されたゴブリンの HP を変更すると全員に影響する	インスタンス生成時に Resource をディープコピーする	deep/entity_stat_duplicator
ボスのネストした if/elif	階層型 FSM + 予兆	hierarchical_state_base + telegraphed_enemy
AoE のコストが高すぎる	PhysicsServer のクエリ／グループを使う	aoe_physics_query / aoe_group_broadcaster
エンドゲームのバッグ解析で引っかかる	WorkerThreadPool を使う	threaded_inventory_loader
AnimationTree が頻繁に切り替わる	明示的な bool の Advance Conditions を使う	animation_condition_sync
戦利品の接辞一式／バッグ UI	ここでは再度説明しません	godot-inventory-system
ホットバーのアビリティ／マナ	ここでは再度説明しません	godot-ability-system
モディファイアの重ねがけ／曲線	ここでは再度説明しません	godot-rpg-stats

アーキテクチャ概要（コンポジション）

BaseEnemy の継承よりも、Health／Hitbox の子コンポーネント（godot-composition）を優先してください。UI はシグナルを監視し、インベントリの真実はリソースにあります。HUD ツリーを真実の情報源にしてはいけません。

よくある落とし穴（簡易版）

• 戦闘が浮ついた感触になる → ヒットリアクション／よろめきを追加します。
• 戦利品がどれも同じに見える → レアリティビームと効果音を追加します（RenderingServer のインスタンスごとのパラメーターで問題ありません）。
• フレームレート依存の戦闘 → ヒット判定の解決には _physics_process のみを使用します。

戦闘／戦利品／装備／エリアスケーリングについて、意思決定ツリーを超える詳細が必要な場合は、必ず arpg-subsystems-deep.md を参照してください。初回のヒットボックスとステータスの配線では読み込まないでください。上記のスクリプトを使用してください。

高度な ARPG メタシステム

1. パラゴン／無限スケーリングリソース

上限到達後のパワーは複製したリソースに保持し、レベル変更時に emit_changed() を発行します。キャッシュ済みのテンプレートは変更しないでください。

2. シェーダーベースの戦利品ビーム

共有シェーダーに RenderingServer.instance_geometry_set_shader_parameter でレアリティカラーを渡します。マテリアルの duplicate() が大量に発生するのは避けてください。

3. ステータススナップショットによる戦闘ログ

Dictionary のスナップショットをバッファリングし、定期的に user:// にフラッシュします（res:// は使用しないでください）。

参考資料

段階的な情報開示： 実装する API（Resources、Area／物理クエリ、シグナル／グループ、AnimationTree、WorkerThreadPool、セーブ）に関する公式ドキュメントのみをざっと確認してください。戦闘、ステータス、インベントリ、アビリティ、バランスを配線する際は、関連スキルを開いてください。関連スキル一式を事前に読み込まないでください。

公式ドキュメント

• リソース — ARPG のステータス、戦利品の付与効果、レベルアップテーブル、装備テンプレートは Resource アセットにまとめることで、デザイナーは戦闘コードを書き換えずに .tres データを作成できます。
• Resource — 共有のステータス／戦利品テンプレートは、スポーン時に必ず duplicate(true) してください。そうしないと、あるゴブリンの HP やインベントリの変更が、すべてのインスタンスの .tres に反映されてしまいます。
• GDScript のエクスポート — @export と型付き Dictionary を使うと、インスペクターで調整できるダメージ、耐性、XP 曲線、装備スロットを設定でき、スクリプトを再コンパイルせずにバランス調整できます。
• Area2D の使用 — ヒットボックスとハートボックスの重なりを検出するシグナルは、リアルタイムの近接攻撃や投射物の接触判定におけるエンジンの基本機能です。
• レイキャスティング — 直接のスペース状態に対する形状／レイクエリを使えば、爆発ごとにノードを生成することなく、大量のエンティティに対する AoE や射線のチェックを行えます。
• アイドル処理と物理処理 — 固定デルタで戦闘を決定論的に処理するため、ヒットボックス、ノックバック、予告表示、追跡の更新は _physics_process で処理してください。
• シグナルの使用 — 戦闘ログ、XP の付与、ボスフェーズ、HUD のダメージ表示は、戦闘キャラクターを直接参照するのではなく、シグナルを購読してください。
• グループ — 陣営の敵対判定や AoE ダメージには、毎フレーム SceneTree を走査するのではなく、call_group ／ call_group_flags を使ってください。
• シーンの構成 — 「シグナルは上へ、呼び出しは下へ」を徹底してください。親ノード／UI は戦闘を監視し、マネージャーはヒットボックスや状態ノードを呼び出します。HUD をインベントリの正しい状態を示すものとして扱ってはいけません。
• AnimationTree の使用 — 攻撃／移動の Advance Condition は、明示的なブール値で同期してください（式に ! を使わないでください）。そうすることで、コンボとひるみの状態を確実に維持できます。
• WorkerThreadPool — 終盤の大規模なインベントリ、戦利品の抽選、セーブデータはメインスレッド外で解析し、戦闘を 60 FPS で維持してください。
• ゲームの保存 — レベル、装備、スキルランク、クールダウン終了時刻を、ほかの進行状況とともに保存してください。実行時ログを res:// に書き込んではいけません。

関連スキル

前提条件

• godot-project-foundations — ARPG の戦闘、インベントリ、セーブシステムを追加する前に、オートロード、フォルダー構成、入力／プロジェクト設定を整えておく必要があります。
• godot-characterbody-2d — プレイヤー／敵の移動と move_and_slide は、被弾後の硬直、追跡、攻撃の予備動作を支える移動の基盤です。
• godot-resource-data-patterns — ステータス、付与効果、レベルアップ曲線は Resource を優先して設計します。ノードだらけのキャラクターシートを作る前に、こちらを読み込んでください。
• godot-signal-architecture — 戦闘バス、health_changed、戦利品の取得イベントではシグナルの所有者を明確にし、UI／ログが戦闘の正しい状態を管理しないようにする必要があります。

補完

• godot-combat-system — ダメージ処理、被弾リアクション、ターゲット選択では、このジャンル別スキルがビルドと戦利品の仕組みに組み込むヒットボックス／ハートボックスのイベントを利用します。
• godot-rpg-stats — 指数関数的なダメージ曲線、逓減する防御力、モディファイアのスタックには、専用のステータス／モディファイアレイヤーが必要です。
• godot-inventory-system — 装備スロット、レアリティ階層、接辞の抽選は、SceneTree の HUD とは別のインベントリデータで管理します。
• godot-ability-system — クールダウン、マナコスト、スキルツリーによる付与は、ホットバーを備えた ARPG の戦闘時のヒット判定と組み合わせられます。
• godot-composition — モジュール式の RPG ユニットでは、BaseEnemy を深く継承するのではなく、HealthComponent／HitboxComponent の子ノードを優先してください。
• godot-state-machine-advanced — ボスの予備動作、よろめき、詠唱／チャネリング状態には、入れ子の if/elif AI ではなく階層型 FSM を使用します。

下流／利用側

• godot-monte-carlo-balancer — ダメージ曲線、戦利品のレアリティ、アビリティコストを調整可能にした後、モンテカルロによる装備構成のシミュレーションで、リリース前に DPS／TTK の範囲を検証します。
• godot-quest-system — 敵の討伐、アイテム収集、ボスのフェーズに関する目標は、このジャンルのゲームループが出力する同じ戦闘イベントとインベントリイベントを利用します。
• godot-economy-system — ドロップが安定した後、ベンダーの価格設定や通貨の流入／流出ループは、戦利品のレアリティやクラフトの上に構築されます。
• godot-save-load-systems — 長時間の ARPG セッションに対応するため、キャラクターのビルド、装備、スキルランクを永続性のあるセーブスキーマで保存・復元できるようにする必要があります。

マスター

• godot-master — ライブラリのルーターおよびミラー化されたモジュールのエントリです。関連するスキルを見つけたり、Domain Skill の編集後に共有スクリプトのミラーを同期したりする際に使用します。