godot-genre-battle-royale

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

ネットワークとスケール

• 毎フレーム、100人全員のプレイヤーを絶対に同期しないでください。厳密に**関連性システム（Relevancy System）**を使用し、約100m以内にいるプレイヤーに対してのみ高頻度データを同期してください。遠くにいるプレイヤーは約5Hzで同期します。
• 移動データにTRANSFER_MODE_RELIABLEを絶対に使用しないでください。パケットの滞留やネットワークの輻輳を防ぐため、厳密にUnreliableを使用してください。
• クライアント側のヒット判定に絶対に頼らないでください。厳密に**権威サーバーによる検証（Authoritative Server Validation）**を使用し、状態履歴に基づいてサーバーが「当たったか？」を確認してください。
• ゲーム状態についてクライアントを絶対に信用しないでください。すべての移動、アイテム収集、インベントリの変更を権威サーバー上でのみ厳密に検証してください。
• ビジュアルを有効にしたまま専用サーバーを絶対に実行しないでください。CPU/GPUリソースを大幅に節約するため、厳密にヘッドレスモード（--headless）またはダミードライバーを使用してください。
• 接続前にRPCを絶対に呼び出さないでください。同期処理を開始する前に、必ずconnected_to_serverシグナルを待ってください。

メカニクスとパフォーマンス

• 安全地帯の中心を完全にランダムに決めないでください。新しい円が現在の円に完全に収まる中心を厳密に選択してください。
• 「ストームのすり抜け（Storm Tunneling）」を絶対に許さないでください。低いティックレートでのすり抜けを防ぐため、単純な衝突範囲ではなく、厳密に中心までの距離を計算してください。
• オブジェクトプーリングなしでアイテムを絶対に生成しないでください。大量生成時のGCスパイクを避けるため、事前にインスタンス化し、表示状態と衝突を切り替えてください。
• VisibilityNotifier3Dを絶対に無視しないでください。監視者から見えないプレイヤーについては、厳密にAnimationPlayer、_process()、高負荷なAIロジックを無効にしてください。
• サーバーの高頻度ループ内で絶対に出力しないでください。コンソールI/Oはブロッキング処理であり、大人数の対戦ではサーバーのパフォーマンスを大幅に低下させるため、厳密にprint()を避けてください。

---

利用可能なスクリプト

必須：対応するパターンを実装する前に、適切なスクリプトを読んでください。

ゾーン／ストーム

storm_system.gd

ゾーン／ストームに関する作業では必須です。フェーズごとの半径、次の中心が現在の範囲内に収まる選択、すり抜け防止のための中心までの距離に基づくダメージを扱います。ゾーン管理のチュートリアルをインラインで貼り付けないでください。

ネットワークとマルチプレイヤー

kill_feed_bus.gd

マッチの統計追跡機能を備えた、グローバルな撃破シグナルバスです。

headless_branch_logic.gd

ヘッドレス実行かどうか、およびサーバー固有の機能フラグに応じてロジックを分岐する、エキスパート向けの専用サーバー初期化処理です。

enet_br_server.gd

UDP経由で100以上のピアを同時に処理できるよう最適化された、大人数対応のENetサーバー設定です。

state_replication_unreliable.gd

大規模なマッチでネットワークの輻輳を最小限に抑えるため、TRANSFER_MODE_UNRELIABLEを使用してプレイヤーのトランスフォームを同期するパターンです。

authoritative_looting.gd

チートによるアイテム収集や無限アイテム収集を防ぐ、権威サーバー側の検証ロジックです。

targeted_rpc_relay.gd

rpc_id()を使用して特定のピアを対象にし、無駄なパケットのブロードキャストを減らす最適化された通信パターンです。

server_state_buffer.gd

状態を順次バッファリングしてティック単位で並べ替え、ネットワークのジッターや順序が前後するUDPパケットに対処します。

パフォーマンスと最適化

rid_loot_spawner.gd

大量のアイテムを密集させるため、ノード階層を迂回します。RenderingServerを直接使用して、アイテムのドロップに伴うCPUオーバーヘッドを排除します。

async_map_loader.gd

ResourceLoaderのバックグラウンドスレッドを使用したノンブロッキングなマップセクターのストリーミングにより、シームレスなオープンワールド探索を実現します。

multimesh_vegetation.gd

MultiMeshInstance3Dを使用して、密集した葉や環境アセット（10万以上のインスタンス）を描画し、レンダリングパフォーマンスを最大化します。

threaded_ai_manager.gd

サーバー側のボットの挙動と経路探索ロジックをWorkerThreadPoolに移し、メインスレッドの停止を防ぎます。

ベースラインから復元

• lag_compensator.gd - サーバーのトランスフォーム履歴と、ヒット時刻を巻き戻して行う検証です。
• monster_synchronizer.gd - MultiplayerSynchronizerの差分／変更時レプリケーションの設定です。

バトルロイヤルで絶対にしてはいけないこと

• インターネット権限なしでモバイルクライアントをエクスポートしないでください — マニフェストにネットワーク権限がないと、Android/iOSで通信が気付かれないまま失敗します。
• 信頼できないデータにget_var(true)を使わないでください — 任意のオブジェクトをデシリアライズすると、攻撃者がサーバーまたは他のクライアントでリモートコードを実行できるようになります。
• ObjectまたはResource型をネットワーク経由で同期しないでください — MultiplayerSynchronizerは基本型（int、float、vec）に限定して使用してください。
• UNRELIABLEパケットが順番どおりに届くと思い込まないでください — 欠落または順序が入れ替わったティックに対応できるよう、状態補間を慎重に設計してください。
• 手動で呼び出さずにmultiplayer_pollをfalseのままにしないでください — カスタムスレッドを使用する場合、multiplayer.poll()を呼び出さないと、すべての通信が停止します。

---

コアループ

降下 → 戦利品を集める → ストームに合わせて移動 → 戦闘 → 最後まで生き残る。

スキルチェーン（GDSkillsピアのみ）

フェーズ	スキル	目的
1. ネットワーク	godot-multiplayer-networking	権威サーバー、関連性、RPC
2. マップ	godot-3d-world-building, godot-genre-open-world	地形のスケール、ストリーミング、HLOD
3. アイテム	godot-inventory-system	バックパック／アタッチメント／アーマー
4. 戦闘	godot-genre-shooter, godot-combat-system	ヒットスキャン／投射物とダメージ検証
5. ゾーン	必須 storm_system.gd	ストームのフェーズ／DPS／範囲内の中心
6. バランス調整	godot-monte-carlo-balancer	ゾーンのDPS、戦利品のレア度、TTKの範囲

---

判断ツリー（降下／戦利品／ゾーンのチュートリアルをインラインから削除）

ゾーン／ストーム

必要なもの	対応
フェーズ縮小、範囲内の中心、距離に応じたDPS	必須 storm_system.gd
ストーム壁のVFX	反転したSphereMeshと、ストームの半径に応じて制御する非シェーディングのcull_disabledシェーダー

戦利品

必要なもの	対応
高密度のドロップ	rid_loot_spawner.gdとプーリング
チート対策付きの拾得処理	必須 authoritative_looting.gd
テーブル／レア度	データリソースとピアのインベントリを使用してください。SKILL.mdでinstantiate()のループを使う方法は避けてください。

降下

必要なもの	対応
飛行機 → 自由落下 → パラシュート → 着地	プレイヤーコントローラーで有限状態を管理し、サーバーが着地時のインベントリを検証します
マップセクター	async_map_loader.gd

ネットワーキング

要件	対応
100人以上のピア	enet_br_server.gd + headless_branch_logic.gd
移動	state_replication_unreliable.gd
関連性	近距離は約20Hz以上、遠距離は約5Hz；replication_interval / 関心管理
対象を指定したメッセージ	targeted_rpc_relay.gd
ジッターバッファ	server_state_buffer.gd

---

高度な内容（エリート向けに保ち、デプロイ／戦利品の再説明はしない）

ラグ補償

サーバーはトランスフォームの履歴を保持し、巻き戻したポーズを基準にクライアントのヒット時刻を検証します（権威はサーバー側）。シューター／戦闘関連のピアと組み合わせます。

差分パッチ

MultiplayerSynchronizer + REPLICATION_MODE_ON_CHANGE を体力／インベントリに使用し、ホットなトランスフォームに限り ALWAYS を使用します。delta_interval で上限を設定します。

ゾーンビジュアライザー

storm_system.gd によってスケールされた、反転球体上のシェーディングなしの cull_disabled 空間シェーダーです。

よくある落とし穴

1. 戦利品が多すぎる → プール + RID スポーナー
2. キャンプ行為 → ストームによって移動を強制 (storm_system.gd)
3. クライアントがヒット判定の権威を持つ → 履歴を使ってサーバーが検証

必要に応じて参照するエキスパート向け知識

LLM の無知に関するルール： 一般的なエージェントが読む前に知らないような情報であれば、リファレンスを読み込んでください。エキスパート向けの差分は決して削除しないでください。

• expert-battle-royale-patterns.md — ベースラインの教育的説明を復元（アーキテクチャ、理由、実装の詳細）
• lag_compensator.gd
• monster_synchronizer.gd

リファレンス

段階的開示：特定の API を調査するときに限り公式ドキュメントのリンクを開き、関連スキルは隣接ドメインへ引き継ぐときに読み込みます。格子全体を事前に読み込まないでください。

公式ドキュメント

• ハイレベルマルチプレイヤー — 100 人のプレイヤーに対してフルメッシュのブロードキャストではなく関連性に応じた同期を実現する、RPC の権限、ピアのライフサイクル、可視性を考慮した同期パターン。
• ENetMultiplayerPeer — TCP のヘッドオブラインブロッキングを回避しながら、多数の同時参加者がいるマッチに対応する UDP ホスト／クライアントピア。
• MultiplayerPeer — 信頼性のある転送モードと、信頼性のない／順序保証のない転送モードを使い分け、移動スナップショットでチャネルが滞らないようにします。
• MultiplayerSynchronizer — プロパティのレプリケーション、replication_interval／変更時の差分、関心管理のためのピアごとの可視性フィルター。
• MultiplayerSpawner — プレイヤーや戦利品のドロップの生成／削除のレプリケーションと、途中参加時のシーングラフの整合性。
• コマンドラインチュートリアル — 専用マッチサーバー向けの --headless と複数インスタンスの CLI 起動。
• 専用サーバー向けのエクスポート — クライアント専用の描画／入力経路を除外するサーバー用エクスポートプリセットと機能タグ。
• オクルージョンカリング — 密集した建物群のオクルージョンをベイクし、大規模な BR マップを GPU で処理可能な状態に保ちます。
• メッシュの詳細度（LOD） — ドロップゾーン規模で描画コストの大半を占める地形の小物や構造物に対する距離ベースの LOD。
• MultiMesh による最適化 — フォリッジやデブリをインスタンスごとのノードではなく、MultiMesh の描画呼び出しにまとめます。
• サーバーを利用した最適化 — SceneTree ノードのオーバーヘッドを伴わずに、密集した戦利品を描画するための RenderingServer RID 経路。
• バックグラウンド読み込み — オープンワールドマップをブロックせずに読み込むための、スレッド化された ResourceLoader によるセクターのストリーミング。

関連スキル

前提条件

• godot-multiplayer-networking — BR の関連性管理とラグ補正の基盤となる、権威サーバーの RPC、転送モード、ロビー／ピアのライフサイクル。
• godot-project-foundations — ヘッドレス専用サーバービルドとクライアントビルドに必要な、自動読み込み、エクスポート機能フラグ、プロジェクト構成。
• godot-3d-world-building — ストーム規模のマップに必要な、大規模地形のチャンク分割、コリジョン生成、ワールドストリーミングの前提条件。

補完

• godot-adapt-single-to-multiplayer — BR 規模の関心管理を適用する前に、権限の分割、予測用シェル、スナップショット補間を扱います。
• godot-server-architecture — 権威型マッチシミュレーションで使用する、ヘッドレスホストの基盤と PhysicsServer/RID のパターンを扱います。
• godot-export-builds — 専用サーバーのプリセット、INTERNET 権限、複数インスタンスのマッチテスト向け CLI パッケージングを扱います。
• godot-inventory-system — 権威型の戦利品取得でサーバー側の検証が必要な、バックパック、アタッチメント、アーマーの状態を扱います。
• godot-performance-optimization — 戦利品の密度とピア数がマッチサーバー／クライアントに負荷をかける際の、LOD、プーリング、CPU 予算を扱います。
• godot-signal-architecture — RPC でピア間の撃破を伝達しつつ、ローカルに保つキルフィードやマッチイベントのバスを扱います。
• godot-genre-shooter — BR の交戦ループで使用する、ヒットスキャン／弾丸戦闘のパターンと、ラグ補償付きの検証を扱います。

下流／利用側

• godot-monte-carlo-balancer — ゾーンの DPS フェーズ、戦利品のレアリティテーブル、TTK の範囲をシミュレーションし、100 人参加のマッチでもストームや戦利品のペースを公平に保ちます。
• godot-ai-navigation — スレッド化されたサーバー側ボットでロビーを埋める際の、ボットの経路探索と関心範囲で絞り込んだ AI を扱います。

マスター

• godot-master — ライブラリーのルーターおよびミラーされたモジュールのエントリです。複数領域にまたがる BR の課題を担当するドメインスキルを調べる際に開いてください。