戦闘の幾何学：Hitbox、Hurtbox、Pushbox
ビデオゲームの戦闘システムにおいて、プレイヤーが画面上で目にする映像表現は、物理エンジンが内部で解算しているデータと完全に一致しているわけではありません。数万ポリゴンにおよぶ精細なメッシュ、揺れる布地、細かく動く指関節を持つリアルなキャラクターモデルを、毎フレームそのまま物理演算に投入することは、計算リソースの観点から到底不可能です。現代のゲームエンジンは「視覚レンダリング」と「幾何学的衝突判定」を完全に切り離し、不可視の単純化された境界ボリュームを構築することで、攻撃の命中、ダメージの発生、キャラクター同士の押し合いを判定しています。
戦闘メカニクスを破綻なく制御するため、ゲームエンジンは衝突ボリュームを主に3つの機能的要素に分割しています。
+-------------------------------------------------------------------------+
| 戦闘衝突判定の三要素 |
+-------------------------------------------------------------------------+
| 1. HITBOX（攻撃判定ボリューム） |
| - 剣のひと振り、拳、銃弾など、攻撃の有効フレーム（発生フレーム）のみ生成 |
| - 空間内を走査し、接触した被ダメージ対象を探索 |
| - ダメージ計算、ヒットストップ、ノックバック衝撃値をトリガー |
+-------------------------------------------------------------------------+
| 2. HURTBOX（被弾・やられ判定ボリューム） |
| - キャラクターの骨格ボーン（頭部、胴体、四肢）にペアレント設定 |
| - モーションの骨格追従に合わせ、位置・回転マトリクスをリアルタイム更新|
| - パッシブな受容体：外部の Hitbox が重なった瞬間にダメージイベントを受領|
+-------------------------------------------------------------------------+
| 3. PUSHBOX / 環境コライダー（物理的ソリッド遮蔽ボリューム） |
| - 直立カプセル（Capsule）、円柱、直方体などの単純立体 |
| - 地形メッシュ（地面、壁、傾斜地）との侵入禁止・接地処理を担当 |
| - キャラクター同士のモデル突き抜けや地形へのめり込みを防止 |
+-------------------------------------------------------------------------+
空間的分離がもたらす構造的必然性
もしゲームが単一の衝突コライダーのみですべての判定を処理しようとすれば、戦闘は成立しなくなります。
- 環境移動用のカプセルコライダーでそのままダメージを判定した場合、腕を横に広げた瞬間や振りかぶった動作の隙間の空気部分にまで被弾判定が生じ、理不尽なヒットが発生します。
- 武器にキャラクターのソリッドな押し合い判定を持たせると、大剣を振った際に敵の外周境界ボックスに当たった瞬間物理的に弾かれ、敵の肉体を切り抜けるダイナミックなアクションが描けません。
- Hitbox（攻撃）、Hurtbox（被弾）、Pushbox（押し合い）を分離することで、エンジンは衝突応答チャンネル（Collision Response Channels）を個別に定義し、特定の属性には重なり検知（Overlap）を返し、地形には遮蔽（Block）を維持することが可能になります。
2段階衝突パイプライン：ブロードフェーズとナローフェーズ
複数の敵、飛び交う魔法エフェクト、物理小道具が同時に存在するアクションゲームにおいて、シーン内の全コライダーを総当たりで交差判定すると、計算量は $O(N^2)$ で爆発します。シーン内に100個の物理オブジェクトが存在する場合、単純計算では毎フレーム次の回数のテストが必要になります。
$$\frac{100 \times 99}{2} = 4,950 \text{ 回のペア総当たり交差判定}$$
60Hz や 144Hz といった高リフレッシュレートの物理ループを維持するため、主要な物理エンジン（PhysX、Chaos、Havok など）は空間判定を2つの連続したフェーズに分割して処理しています。
[ シーン内の全アクティブエンティティ ]
|
v
+-----------------------------------------------------------+
| ブロードフェーズ（Broad Phase）：大まかな空間分割 |
| - 軸平行境界ボックス（AABB）による一括スクリーニング |
| - BVH（境界ボリューム階層）や八分木（Octree）の走査 |
| - 接触の可能性が皆無なペアの 95%〜99% を即座に破棄 |
+-----------------------------------------------------------+
|
|（重なりの疑いがある候補ペアのみ抽出）
v
+-----------------------------------------------------------+
| ナローフェーズ（Narrow Phase）：精密な幾何代数解算 |
| - 抽出された候補に対して基本形状（球、カプセル、OBB）をテスト|
| - 分離軸定理（SAT）や GJK 距離アルゴリズムの適用 |
| - 正確な衝突点座標、法線ベクトル、めり込み深度を算出 |
+-----------------------------------------------------------+
|
v
[ ゲームロジックへのイベント送出：ダメージ付与、衝撃力印加 ]
1. ブロードフェーズによる空間枝刈り
ブロードフェーズでは、キャラクターの精緻なメッシュ形状は完全に無視されます。すべてのオブジェクトは、ワールド座標軸 $(X, Y, Z)$ に平行な**軸平行境界ボックス（Axis-Aligned Bounding Box, AABB）**で囲まれます。AABB 同士の重なり判定は、スカラーの最小値・最大値を比較するだけで完結します。
$$\text{Overlap} \iff (A_{\min}^x \le B_{\max}^x \land A_{\max}^x \ge B_{\min}^x) \land (A_{\min}^y \le B_{\max}^y \land A_{\max}^y \ge B_{\min}^y) \land (A_{\min}^z \le B_{\max}^z \land A_{\max}^z \ge B_{\min}^z)$$
**BVH（境界ボリューム階層）や八分木（Octree）**などの空間ツリー構造を用いることで、エンジンは空間的に近いオブジェクトを木構造のノードにまとめます。プレイヤーの剣撃ボリュームが遠方の敵グループの親ノードボックスと交差していなければ、配下の多数のオブジェクトとの判定処理を1サイクルでスキップでき、計算量を $O(N^2)$ から $O(N \log N)$ あるいはほぼ線形 $O(N)$ にまで削減します。
2. ナローフェーズによる厳密な幾何解算
ブロードフェーズを通過した候補ペアに対してのみ、形状ごとの精密な数学的テストが実行されます。
- 球 vs 球：中心間距離の2乗と半径の和の2乗を比較するだけで完了する最速の3次元判定 $(|C_1 - C_2|^2 \le (R_1 + R_2)^2)$。
- カプセル vs カプセル：2つの内部線分間の最短ユークリッド距離を求め、半径の和と比較。人間の四肢は円柱の両端を半球で塞いだカプセル形状に酷似しているため、キャラクターの Hurtbox に最も多用されます。
- 有向境界ボックス（OBB）や凸包（Convex Hull）：**分離軸定理（Separating Axis Theorem, SAT）**や GJK アルゴリズムを使用。立体間に投影が重ならない分離超平面を1つでも発見できれば、非接触と判定されます。
動的な戦闘シーンにおいて、数万ポリゴンの変形三角形メッシュ同士を直接判定する「ポリゴン単位のメッシュ衝突（Per-Polygon Mesh）」は原則として採用されません。アニメーション変形を伴うメッシュ同士の交差判定は CPU スレッドを圧迫し、激しいフレームレート低下を引き起こすためです。
離散的衝突判定と連続的衝突判定（CCD）：すり抜け（Tunneling）の発生構造
アクションゲームにおいて最もフラストレーションを生む不具合が**すり抜け（Tunneling、弾抜け、めり込み抜け）**です。高速で移動するオブジェクトが、標的のコライダーを一瞬で飛び越えてしまい、判定が一度も検知されない現象を指します。
すり抜けの力学的メカニズム
一般的な物理演算は**離散的衝突判定（Discrete Collision Detection）**を採用しています。離散シミュレーションでは、時間刻み幅 $\Delta t$ のスナップショット時点でのみ位置を評価します。
フレーム N（時刻 = t）： フレーム N+1（時刻 = t + dt）：
[ 弾丸 / 剣先 ] --- 速度 v ---> [ 弾丸 / 剣先 ]
o o
(位置 x=10) (位置 x=60)
| 標的の盾 / 敵本体 |
| [x=30..35] |
速度 $v$ で移動するオブジェクトの1フレームあたりの移動量は次式で表されます。
$$\Delta x = v \cdot \Delta t$$
もし標的の厚み $W_{\text{target}}$ と飛翔体の衝突直径 $D_{\text{proj}}$ の合計が、この1フレームの移動量よりも小さい場合：
$$W_{\text{target}} + D_{\text{proj}} < v \cdot \Delta t$$
フレーム $N$ では飛翔体は標的の手前にあり、次のフレーム $N+1$ では標的の背後に完全に突き抜けています。離散判定はサンプリング時点の空間重なりしか見ないため、どちらのサンプリング時点でもコライダー同士は交差していません。結果として、弾丸や剣撃は標的を幽霊のようにすり抜けてしまいます。
連続的衝突判定（CCD）のエンジニアリング
極めて初速の速い弾丸、投げ槍、あるいは高速に振り抜かれる武器の先端ですり抜けを防ぐため、物理エンジンは**連続的衝突判定（Continuous Collision Detection, CCD）**を実装しています。
+----------------------------------------------------------------------------+
| CCD 実装方式 |
+----------------------------------------------------------------------------+
| 1. スイープ型 CCD（Sweep-based CCD / 形状押し出し法） |
| - 移動ベクトルに沿って図元を時間軸方向に押し出し（Swept Volume）を形成 |
| - 時間区間 [0, dt] 内で障害物と交差する厳密な代数方程式を解く |
| - 衝突時刻（Time of Impact, TOI ∈ [0, 1]）と接触面法線を正確に算出 |
| - 課題：CPU の計算負荷が非常に高く、多体衝突時にフレームレートを圧迫する |
+----------------------------------------------------------------------------+
| 2. 投機的 CCD（Speculative CCD / 予測的膨張ボリューム） |
| - 予想速度に基づき、ブロードフェーズで AABB ボリュームを進行方向へ拡張 |
| - 物理的接触が生じる前に予測拘束を生成し、法線方向の速度をあらかじめ制限 |
| - 利点：スイープ型に比べて計算負荷が格段に低く、挙動が安定しやすい |
| - 課題：急激な軌道変更時に接触前の空間で弾かれる（ゴースト衝突）リスク |
+----------------------------------------------------------------------------+
高速なシューター作品では、銃弾の剛体物理シミュレーションを避け、**ラインスキャン／レイキャスト（Line Trace / Raycast）**による即時着弾（Hitscan）判定が多く採用されます。発射瞬間に銃口から目標ベクトルへ無限小の数学的線分を飛ばし、通過した Hurtbox を瞬時に検出することで、負荷を最小限に抑えつつ確実な命中判定を実現しています。
視覚モデルと物理判定のズレが生じる根本的理由
「明らかに相手の体に当たっているのに無効化された」「何もない空間を振られたのに被弾した」というプレイヤーの不満は、グラフィックス描画と物理判定の根本的な性質の違いに起因しています。
1. カプセル近似と複雑な生体輪郭の乖離
キャラクターの視覚モデルには、筋肉の起伏、厚手の鎧、揺れるマントが存在しますが、受撃判定用の Hurtbox はボーンにアタッチされた数本のカプセルコライダーの組み合わせに過ぎません。
開発者は次の二者択一を迫られます。
- タイトな判定（モデルより小さめ）：不当な外周被弾を防げる一方、マントの端や肩当てをかすめた際に「当たっているのに抜けた」という違和感が生じる。
- ルーズな判定（モデルより大きめ）：かすり傷を確実に拾える一方、至近距離での回避行動時に目に見える「空気判定」で被弾する。
2. アニメーションブレンドとルートモーションの微小な非同期
現代のキャラクター制御はブレンドツリー（Blend Tree）を駆使しています。強攻撃の溜め動作からステップ回避へ移行する際、GPU の頂点シェーダーは数百ミリ秒をかけて複数のモーションクリップ間を滑らかに補間します。
しかし、Hurtbox の座標更新はボーンソケットの行列に依存します。アニメーション遷移の補間速度と物理移動速度にズレが生じたり、ルートモーションの同期が乱れた場合、画面上のキャラクター描画と内部の衝突カプセルが数フレームにわたり位置ズレを起こすことがあります。
3. 外れ判定（Disjoint Hitbox）と判定残留フレーム（Linger Frames）
格闘ゲームやアクションゲームにおいて、開発者は意図的に**外れ判定（Disjoint Hitbox）**を設けることがあります。剣先よりも前方数センチまで攻撃判定を拡大したり、武器を振り切ったあとのフォロースルー動作中も数フレーム判定を残す設計です。
これはプレイヤーの反射神経の遅れを補正し、ジャンプ攻撃が屈んだ敵に安定して届くようにするための配慮であり、操作の爽快感を生み出すために意図的に組み込まれたゲームデザインです。
4. 装飾用エフェクト（VFX）には物理実体が存在しない
大剣を振った際の光の軌跡、炎のパーティクル、銃口の閃光は、すべて GPU の描画パイプラインで描かれる視覚効果に過ぎません。エフェクト自体には物理データは含まれておらず、プログラマーが明示的にエフェクト範囲へ追従する判定ボリュームを紐付けていない限り、エフェクトの端に触れてもダメージは発生しません。
衝突判定モード比較マトリクス
主要な衝突判定方式の特性とトレードオフを以下に整理します。
| 衝突検出モード | 計算コスト | 静的オブジェクトのすり抜け防止 | 動的オブジェクトのすり抜け防止 | 代表的な適用箇所 | 主な弱点・不具合リスク |
|---|---|---|---|---|---|
| 離散判定（Discrete） | 最小（単一フレームの単純交差） | 高速移動時にすり抜け発生 | 高速移動時にすり抜け発生 | キャラクター歩行、背景大型建築、低速な敵 | 処理落ち時のすり抜け悪化；極薄の壁を突き抜ける |
| スイープ型 CCD（Sweep-based） | 最大（連続時空の幾何代数計算） | 完全に防止可能 | 双方有効時に完全防止可能 | 近接武器の刃先、投擲槍、高速ビークル衝突 | 衝突対象が増加すると CPU 負荷が跳ね上がり処理落ちの原因となる |
| 投機的 CCD（Speculative） | 中程度（AABB の前方拡張） | 大幅に抑制 | 大幅に抑制 | ラグドール物理、破壊された瓦礫オブジェクト | 急激な方向転換時に空間で跳ね返る（ゴースト衝突） |
| レイキャスト（Line Trace / Raycast） | 低（$O(1)$ の線分交差） | 経路上のすり抜けを完全防止 | 経路上のすり抜けを完全防止 | ヒットスキャン射撃、接地判定、視線チェック | 太さを持たないため、隣り合うカプセルの極小の隙間をすり抜ける |
エンジン組み込みの診断機能と実機切り分け手法
アクションの判定に違和感を覚えた際、映像の印象だけで判断すると本質を見誤ります。開発環境やコンソールが開放されているタイトルでは、内部の衝突ボリュームを直接可視化して検証できます。
1. エンジンコンソールによる幾何ボリューム可視化
Unreal Engine（UE4 / UE5）
コンソール（~ キーなど）で以下のコマンドを実行し、物理メッシュを描画します。
show collision # 有効化されている全静的・動的コライダーを表示
show CollisionPawn # キャラクターの Hurtbox カプセルのみに絞り込んで表示
pxvis collision # PhysX / Chaos の低レベル物理ワイヤーフレームを強制描画
- シアン / 緑色のワイヤーフレーム：基本形状（カプセル、球、ボックス）。
- 赤 / 紫色のワイヤーフレーム：そのフレームで攻撃判定を行っているトレース形状（Hitbox）。
Source / Source 2 Engine
Valve の Source 系列エンジンを用いた専用サーバー等では、巻き戻し判定ボックスを表示可能です。
sv_showlagcompensation 1 # サーバー側がヒット計算時に巻き戻した実際の判定ボックスを描画
r_drawclipbrushes 1 # マップ内の不可視の壁（クリップブラシ）を描画
2. 判定異常の3ステップ切り分けフロー
攻撃の空振りに遭遇した際は、次の手順で要因を特定します。
- ステップ1：物理フレームレートの低下を確認する
- 乱戦時にフレームレートが急落（60FPS から 25FPS 等）していないか確認。サンプリング間隔 $\Delta t$ が拡大し、剣先が1フレームで敵の体を飛び越えてすり抜けが発生しやすくなります。
- ステップ2：ボーンとコライダーの同期を確認する
- 攻撃モーションの瞬間、Hurtbox カプセルがモデルの動きに追従しているかを確認。追従遅延が起きている場合、物理演算の欠陥ではなくアニメーションのルートモーション設定の問題です。
- ステップ3：ネットワークの遅延補償を疑う（マルチプレイ環境）
- オンライン対戦での「判定がおかしい」と感じる現象の大半は、ネットワークのラグ補償（Lag Compensation）が原因です。手元の画面では命中していても、サーバーが発砲時刻へワールド状態を巻き戻した結果、敵が既に遮蔽物に隠れていたと判定されれば、ダメージは無効化されます。
戦闘における判定の違和感が、根本的な幾何学ボリュームの設計によるものか、ネットワークのロールバック処理によるものか、あるいは単なる描画のズレであるかを正確に見極めるには、365Finds の検証済み技術アーキテクチャ解説を参照することで、コミュニティの主観的な誤解に惑わされることなく、真の原因を特定できます。