======================================================================== 描画最適化 (Rendering Optimization) ======================================================================== 1. 概要 (Overview) ------------------------------------------------------------------------ 1-1. 目的 PixiJSによるリアルタイム描画において，大人数・大マップでも60fpsを維持するための クライアント側の描画最適化手法をまとめる． 1-2. 主要な最適化手法 ・ビューポートカリング: 画面外のエンティティの描画をスキップする ・画面外プレイヤーの間引き更新: 不可視プレイヤーのtick頻度を削減する ・プレイヤー補間（LERP）: リモートプレイヤーの位置を滑らかに補間する ・フレームデルタクランプ: 異常なデルタタイムを制限する ・テクスチャキャッシュ: 同一アセットの重複ロードを防止する ・マップの差分描画: 変化セルのみを再描画する ・Bot JITウォームアップ: ゲーム開始前にV8 JITコンパイルを促進する 2. ビューポートカリング (Viewport Culling) ------------------------------------------------------------------------ 2-1. 仕組み カメラの表示範囲外にあるエンティティのvisibleプロパティをfalseに設定し， PixiJSの描画パイプラインから除外する． 2-2. カリング対象 ・プレイヤー（PlayerView） ・ボム（BombView） ・ハリケーン（HurricaneOverlayController） 2-3. 判定方法 ・円-矩形交差判定（isCircleIntersectingViewport）を使用する ・エンティティの半径円とビューポート矩形の交差を判定する 2-4. カリングマージン ・ビューポートをGRID_CELL_SIZE分だけ拡張する（expandWorldViewport） ・マージンにより画面端でのエンティティのポップイン（突然の出現）を防止する 2-5. 遅延描画 ・ハリケーンは可視状態に変化した瞬間のみrenderDisplayFromState()を呼び出す ・不可視→可視の遷移時のみ再描画し，可視継続中は通常のtick更新のみ行う 3. 画面外プレイヤーの間引き更新 (Offscreen Update Throttling) ------------------------------------------------------------------------ 3-1. 仕組み 画面外のリモートプレイヤーのtick処理を6フレームに1回に間引く． 3-2. 実装 ・フレームカウンタ: frameCount % 6 === 0 のフレームのみ画面外プレイヤーをtickする ・デルタタイム補正: 間引き時は deltaSeconds × 6 を渡し，位置精度を維持する ・画面内プレイヤー: 毎フレーム通常のdeltaSecondsでtickする 3-3. 効果 ・画面外プレイヤーの更新コストを約1/6に削減する ・デルタタイム補正により，画面内に戻った際の位置ずれを防止する 4. プレイヤー補間 (Player Interpolation) ------------------------------------------------------------------------ 4-1. リモートプレイヤーのLERP サーバーから受信した目標座標に向けて，フレームごとに滑らかに補間移動する． ■ 計算式 newPos = currentPos + (targetPos - currentPos) × LERP_SMOOTHNESS × deltaTime ・LERP_SMOOTHNESS: 設定値で補間速度を制御する ・deltaTimeを乗算し，フレームレートに依存しない一定速度の補間を実現する 4-2. スナップ閾値 ・現在位置と目標位置の距離がPLAYER_LERP_SNAP_THRESHOLDを下回る場合，即座に目標位置に移動する ・微小な揺れ（ジッター）を防止する 4-3. 効果 ・20Hz（50ms間隔）の位置更新でも60fpsで滑らかに見える ・サーバーからの位置が急に変わった場合もスムーズに追従する 5. フレームデルタクランプ (Frame Delta Clamping) ------------------------------------------------------------------------ 5-1. 問題 フレーム落ちやタブ非表示からの復帰時に，deltaTimeが異常に大きくなり 物理計算の暴走（プレイヤーが瞬間移動する等）が発生する． 5-2. 解決策 ・resolveFrameDelta()関数でdeltaTimeの上下限を制限する ・下限: 0（負の値やNaNを防止する） ・上限: FRAME_DELTA_MAX_MS（設定された最大値） 5-3. 適用範囲 ・プレイヤーの移動計算 ・LERP補間 ・ボム・ハリケーンの状態更新 ・全ての時間依存処理がこのクランプ済みデルタを使用する 6. テクスチャキャッシュ (Texture Caching) ------------------------------------------------------------------------ 6-1. モジュールレベルキャッシュ SVGアセットのテクスチャをモジュールスコープの変数にキャッシュし， 複数のインスタンスから参照しても1回だけロードする． ■ キャッシュパターン ・cachedTexture: ロード完了後のTexture参照を保持する ・texturePromise: ロード中のPromise参照を保持する ・初回呼び出し: Assets.load()でPromiseを生成し，texturePromiseに保存する ・2回目以降: 既存のPromiseをawaitする（追加のフェッチは発生しない） ・ロード完了後: cachedTextureから即座に返す 6-2. キャッシュ対象 ・爆発エフェクト（bakuhatueffe.svg）: RespawnEffectTextureCache ・ハリケーン（hurricane.svg）: HurricaneTextureCache ・ボム（Bomb.svg）: BombViewの静的テクスチャ 6-3. アセットプリロード ・preloadGameStartAssets()をゲーム開始前に呼び出す ・重いSVGアセットを事前にキャッシュし，初回出現時のフレーム落ちを防止する ・void（fire-and-forget）で呼び出し，ゲーム開始をブロックしない 7. マップの差分描画 (Differential Map Rendering) ------------------------------------------------------------------------ 7-1. セル単位の更新 ・GameMapViewはセルごとにGraphicsオブジェクトをコンストラクタで事前確保する ・renderCell(index, color)で変化したセルのみを再描画する ・全セルの再描画は行わない 7-2. 描画手順 1. 対象セルのGraphics.clear()で前回の描画を消去する 2. 新しい色でGraphics.fill()を適用する 3. 未塗装（-1）のセルは既定の背景色を使用する 7-3. リビジョン管理 ・GameMapModelがapplyUpdates()のたびにリビジョン番号をインクリメントする ・ミニマップ等のUI要素はリビジョン変化時のみ再描画する 8. 状態変化キャッシュ (State Change Caching) ------------------------------------------------------------------------ 8-1. ボムの描画スキップ ・BombViewが前回描画した状態（state, color, radiusGrid）を保持する ・状態が変化していない場合はrender()をスキップする ・armed状態のボムは毎フレーム位置更新のみ，外観は変化しない 8-2. ハリケーンの描画スキップ ・半径の変化が0.0001以下の場合はスプライトサイズの更新をスキップする ・画面外→画面内の遷移時のみrenderDisplayFromState()を実行する 8-3. ボムの重複チェック ・BombRepositoryがupsertBomb()時にisSameRenderPayload()で全フィールドを比較する ・同一ペイロードの場合はオブジェクトの破棄・再生成をスキップする 9. ゲームループのステップ分離 (Game Loop Step Architecture) ------------------------------------------------------------------------ 9-1. ステップ構成 GameLoopが毎フレーム以下の4ステップを順に実行する． 1. InputStep: ジョイスティック入力をPlayerControllerに適用する 2. SimulationStep: 自プレイヤーの移動 + リモートプレイヤーの補間 + カリング判定 3. BombStep: ボムの状態更新 + 爆発判定 + カリング適用 4. CameraStep: ワールドコンテナの位置を自プレイヤーに追従させる 9-2. 設計上の利点 ・各ステップが独立しており，個別に最適化できる ・共有のLoopFrameContext（deltaSeconds等）で一貫した時間管理を行う ・LoopFrameEffectsで移動状態をステップ間で受け渡す 10. リソース管理 (Resource Management) ------------------------------------------------------------------------ 10-1. DisposableRegistry ・ゲームシーンのリソース（イベントリスナー，PixiJSオブジェクト等）を登録する ・disposeAll()で登録の逆順に破棄し，依存関係のクラッシュを防止する ・シーン遷移時にメモリリークを防止する 10-2. プレイヤーの遅延テクスチャロード ・初期状態ではTexture.WHITE（1×1ピクセル）で描画を開始する ・非同期でプレイヤー画像をロードし，完了後にスプライトのテクスチャを差し替える ・ゲーム画面の初期表示をブロックしない 11. Bot JITウォームアップ (Bot JIT Warmup) ------------------------------------------------------------------------ 11-1. 問題 ゲーム開始直後の最初のティックでBot全員のdecide()が初めて呼ばれると， V8エンジンのJITコンパイルが集中し，ティック処理時間がスパイクする． 11-2. 解決策 ・ゲーム開始前の待機時間（GAME_START_DELAY_MS: 5000ms）を利用する ・warmUp()メソッドで全BotのbotTurnOrchestrator.decide()を1回ずつ空実行する ・V8がホットパスを事前にコンパイルし，初回ティックのスパイクを軽減する 11-3. ターゲット初期化の分散 ・各Botのインデックスに応じてchooseNextTarget()の呼び出し回数を分散する ・chainCount = (botIndex % 4) + 1 で1〜4回の初期化を割り当てる ・全Botが同一ティックで重い計算を行うことを回避する