戰鬥幾何學：Hitbox、Hurtbox 與 Pushbox
在電子遊戲的戰鬥系統中，玩家螢幕上看到的畫面極少直接對應底層物理引擎的計算結果。具有數萬個多邊形面數、複雜布料擺動和獨立手指關節的高精度角色模型，在即時物理計算中極其消耗資源。現代遊戲引擎將視覺渲染與幾何碰撞徹底解耦，在後台構建一套肉眼不可見的簡易幾何邊界，用以判定攻擊是否命中、角色是否承受傷害以及如何在空間中佔據物理實體。
為了清晰管理戰鬥機制，遊戲引擎通常將角色碰撞體積劃分為三種獨立的功能性幾何體：
+-------------------------------------------------------------------------+
| 戰鬥碰撞三元組 |
+-------------------------------------------------------------------------+
| 1. HITBOX（攻擊判定框 / 主動觸發體積） |
| - 僅在攻擊、法術或投擲物的有效判定幀內激活生成 |
| - 主動檢測場景中與其相交的易傷目標 |
| - 觸發傷害結算、受擊硬直（Hitstop）及擊退衝量 |
+-------------------------------------------------------------------------+
| 2. HURTBOX（受擊判定框 / 被動易傷體積） |
| - 綁定至角色骨骼關鍵節點（頭部、軀幹、四肢） |
| - 隨動作姿態變換即時刷新空間座標與旋轉矩陣 |
| - 被動接收體：當被外部 Hitbox 侵入或重疊時觸發受擊邏輯 |
+-------------------------------------------------------------------------+
| 3. PUSHBOX / 環境碰撞體（實體物理阻擋體積） |
| - 通常為垂直膠囊體、圓柱體或簡化立方形 |
| - 負責解析與環境幾何（地面、牆壁、斜坡、障礙）的接觸阻擋 |
| - 防止角色彼此重疊或穿透地形邊界 |
+-------------------------------------------------------------------------+
空間隔離的架構必然性
如果遊戲將角色的所有互動綁定在一個統一的碰撞體上，戰鬥機制將瞬間失衡：
- 若直接使用環境碰撞膠囊體結算傷害，玩家伸出手臂或揮刀時的空隙將全部判定為空氣挨打，造成極其荒謬的判定外溢。
- 若武器與角色實體物理共享阻擋判定，大劍在砍向敵人時會在觸碰到對方外層物理包圍盒時瞬間被彈開，無法順暢穿過肉身造成揮砍傷害。
- 透過解耦 Hitbox（攻擊體）、Hurtbox（受擊體）和 Pushbox（阻擋體），引擎可以為不同通道設定獨立的碰撞響應通道（Collision Response Channels），對特定通道產生重疊回調（Overlap），對其他通道則維持阻擋（Block）。
兩階段碰撞流水線：寬相（Broad Phase）與窄相（Narrow Phase）
在同時存在數十個角色、彈道法術和動態環境物件的大型動作場景中，若每一幀都讓場景中的所有碰撞體兩兩進行幾何相交檢測，計算量將呈現 $O(N^2)$ 指數級膨脹。場景中若有 100 個可碰撞實體，樸素演算法每幀需要執行：
$$\frac{100 \times 99}{2} = 4,950 \text{ 次成對交叉測試}$$
為了在 60Hz 甚至 144Hz 的物理更新率下保持毫秒級的幀生成時間，主流物理引擎（如 PhysX、Chaos、Havok）均將空間碰撞查詢嚴格劃分為兩個階段：
[ 場景中所有動態與靜態實體 ]
|
v
+-----------------------------------------------------------+
| 寬相階段（Broad Phase）：粗粒度空間劃分 |
| - 統一使用軸對齊包圍盒（AABB） |
| - 遍歷層次包圍盒（BVH）、八元樹或掃掠修剪演算法 |
| - 高速剔除 95% - 99% 完全不可能接觸的實體對 |
+-----------------------------------------------------------+
|
|（僅傳遞潛在重疊的候選對）
v
+-----------------------------------------------------------+
| 窄相階段（Narrow Phase）：高精度幾何相交求解 |
| - 針對候選對測試具體圖元（球體、膠囊體、有向包圍盒 OBB） |
| - 運行分離軸定理（SAT）或 GJK 距離演算法 |
| - 精確計算接觸點座標、法線方向與穿透深度 |
+-----------------------------------------------------------+
|
v
[ 分發遊戲邏輯事件：扣除血量、施加擊退力、播放受擊特效 ]
1. 寬相階段的空間加速劃分
寬相階段完全忽略角色複雜的肢體網格，而是將每個物件直接封裝在一個**軸對齊包圍盒（Axis-Aligned Bounding Box, AABB）**中。AABB 的邊始終平行於世界座標軸 $(X, Y, Z)$，其重疊判斷僅需比對最小與最大純量值：
$$\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）或掃掠修剪（Sweep and Prune）**等空間資料結構，引擎將空間鄰近的物件歸納到樹狀層級中。如果玩家揮刀動作的包圍盒未與遠處敵人群體的父節點包圍盒產生交集，引擎在一個時鐘週期內即可跳過數十個潛在實體的比對，將計算複雜度從 $O(N^2)$ 壓縮至 $O(N \log N)$ 乃至近乎 $O(N)$。
2. 窄相階段的高精度幾何解算
通過寬相篩選出的重疊候選對，將送入窄相階段進行精確的幾何代數解算：
- 球體 vs 球體：三維中最快的碰撞測試，僅需比較球心距離平方與半徑之和的平方 $(|C_1 - C_2|^2 \le (R_1 + R_2)^2)$。
- 膠囊體 vs 膠囊體：求解兩條內部骨骼線段之間的最短歐氏距離，再與半徑之和比對。由於人類肢體形態天然契合圓柱兩端封蓋半球的膠囊幾何，膠囊體是角色肢體 Hurtbox 最主要的基準圖元。
- 有向包圍盒（OBB）與凸包（Convex Hull）：採用**分離軸定理（Separating Axis Theorem, SAT）**或 GJK 演算法（Gilbert-Johnson-Keerthi）。如果在兩個凸體之間能找到一條投影不發生重疊的分離軸或分離超平面，則兩者互不接觸。
在動態戰鬥中，引擎堅決避免使用逐多邊形三角形網格（Per-Polygon Mesh）進行打擊判定。在角色複雜的骨骼蒙皮動畫下，讓兩個數萬面的變形網格即時計算三角形相交，會瞬間耗盡 CPU 物理線程，引發嚴重的卡頓掉幀。
離散碰撞與連續碰撞檢測（CCD）：高速穿模（Tunneling）成因
動作遊戲中最常見的判定缺陷莫過於「穿模空擊」（Tunneling，玩家常稱之為「揮刀穿透」、「子彈穿人」）。穿模的本質是高初速物件在兩個物理幀之間直接跨越了目標，導致物理系統未曾捕獲到任何接觸。
穿模的數學物理機制
絕大多數物理引擎預設運行離散碰撞檢測（Discrete Collision Detection）。在離散模式下，物理系統僅在離散的時間步長 $t, t + \Delta t$ 處取樣物件空間位置：
幀 N（時間 = t）： 幀 N+1（時間 = t + dt）：
[ 子彈 / 刀刃 ] --- 速度 v ---> [ 子彈 / 刀刃 ]
o o
(位於 x=10) (位於 x=60)
| 目標護盾 / 角色 |
| [x=30..35] |
當物件以速度 $v$ 高速位移時，單個物理步長內的位移量為：
$$\Delta x = v \cdot \Delta t$$
如果目標判定體積的厚度 $W_{\text{target}}$ 加上飛行物本身的碰撞直徑 $D_{\text{proj}}$ 小於該單幀位移量：
$$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]）與接觸點法線 |
| - 局限：計算開銷極其昂貴，多物件互動時易導致物理線程過載 |
+----------------------------------------------------------------------------+
| 2. 推測式 CCD（Speculative CCD / 預測膨脹包圍盒） |
| - 根據預期運動速度，在寬相階段將物件的 AABB 包圍盒向前膨脹延伸 |
| - 在發生實際物理接觸前提前建立接觸約束條件，限制其穿透速度 |
| - 優勢：計算消耗遠低於掃掠式求解，對 CPU 極為友好 |
| - 局限：物件突發變向時可能出現「空氣撞牆」（Ghost Collision）誤判 |
+----------------------------------------------------------------------------+
在快節奏射擊遊戲中，開發者通常徹底放棄讓子彈作為帶有物理實體的剛體飛行，而是改用射線投射（Line Trace / Raycast）。在武器開火瞬間，系統以槍口為起點、目標朝向為向量直接投射一條數學線段，沿途立即捕捉穿過的 Hurtbox，以極低的系統開銷實現絕對不穿模的即時命中（Hitscan）判定。
視覺模型與物理判定脫節的根源
玩家常常困惑於「明明砍中了模型卻沒有傷害」，或是「離敵人身體還有半米遠就被擊中」。這種體驗斷層源自視覺渲染與物理幾何之間的固有矛盾。
1. 簡易膠囊體與複雜人體外形的貼合差異
視覺模型具備逼真的肌肉起伏、鎧甲護肩與外掛披風，而負責接收傷害的 Hurtbox 通常僅由若干掛載在骨骼上的膠囊體拼合而成。
開發團隊在配置膠囊體時必須做出權衡：
- 收緊型 Hurtbox（小於視覺模型）：保護邊緣免受不合理判定侵擾，但會導致擊中披風、鎧甲尖刺或刀鞘邊緣時出現「穿模卻未命中」的視覺違和。
- 寬容型 Hurtbox（大於視覺模型）：確保擦過身體的攻擊必定能造成傷害，但玩家在近距離閃避時容易被明顯的「空氣刀」劃傷。
2. 動畫混合與根骨骼位移（Root Motion）的微步脫節
現代角色動作依賴複雜的動畫混合樹（Blend Tree）。當角色從蓄力攻擊強行接入閃避翻滾時，GPU 頂點著色器在數百毫秒內平滑插值過渡兩個動作的網格形變。
然而，Hurtbox 往往隨骨骼插槽變換矩陣離散刷新。如果動作過渡曲線與底層物理位移速度不同步，或者根骨骼位移在網路或幀率波動時出現微小延遲，螢幕上渲染的視覺角色可能會短暫偏離真實的碰撞膠囊體。
3. 外擴判定（Disjoint Hitbox）與判定幀滯後（Linger Frames）
在動作與格鬥遊戲中，開發者經常特意設計「脫節判定」（Disjoint Hitbox）——攻擊 Hitbox 的有效範圍故意延伸超出武器刀刃前端；或者在武器揮砍動作已經收招的數幀內，依然保留傷害判定（滯後判定幀）。
這種非寫實的設計往往是刻意為之：它能補償人類神經反應延遲，確保空中下劈能穩定命中低矮受擊面，並賦予重型武器十足的打擊壓制力。雖然從靜止畫面上看顯得「判定崩壞」，但在動態操作中它能帶來更爽快的交互反饋。
4. 純裝飾性特效（VFX）不具備物理實體
重武器揮舞時的耀眼刀光、火焰法術的拖尾粒子、槍口爆裂的火花均屬於 GPU 渲染管線中的特效通道。特效貼圖本身完全不包含任何碰撞資訊。如果刀光延伸三米遠而特效對應範圍未單獨掛載 Hitbox，僅用刀身本體攻擊的目標在特效範圍內自然不會受到任何傷害。
核心碰撞檢測模式對比矩陣
下表系統梳理了主流遊戲物理引擎中四種判定機制的第一線技術特性與權衡取捨：
| 碰撞檢測模式 | 計算資源開銷 | 穿透靜態地形風險 | 穿透動態角色風險 | 典型應用場景 | 關鍵權衡與失效缺陷 |
|---|---|---|---|---|---|
| 離散檢測（Discrete） | 極低（單幀靜態圖元比對） | 高速時必然穿透 | 高速時必然穿透 | 普通角色行走跑動、場景大型建築、低速怪物 | 幀率下降時穿模加劇；超薄障礙物易被直接穿透 |
| 掃掠式 CCD（Sweep-based） | 高（連續時空軌跡代數求解） | 完全消除 | 雙方均開啟時完全消除 | 高速冷兵器揮砍刃尖、擲矛投擲物、高速載具碰撞 | 多個高速物體同時碰撞時 CPU 計算暴增，引發卡頓 |
| 推測式 CCD（Speculative） | 中等（預先膨脹預測包圍盒） | 大幅降低 | 大幅降低 | 角色布娃娃物理（Ragdoll）、散落物理碎片 | 軌跡突變時可能在接觸前發生空氣彈開（幽靈碰撞） |
| 射線投射（Line Trace / Raycast） | 低（$O(1)$ 空間線段求交） | 路徑上完全消除 | 路徑上完全消除 | 槍械即時命中彈道、地面貼合吸附檢測、視線判定 | 無三維物理體積；若穿過相鄰膠囊體的微小縫隙可能漏檢 |
引擎內置碰撞診斷與實機排查
無論是獨立遊戲開發者調校手感、Mod 創作者調整武器打擊感，還是競技玩家定位判定疑慮，單純依賴錄像眼球判斷極易產生誤區。玩家與開發者可以透過引擎控制台直觀呈現底層的真實幾何碰撞。
1. 控制台幾何視覺化指令
虛幻引擎（Unreal Engine 4 / 5）
在開啟控制台的測試構建或特定遊戲中按下 ~ 鍵，輸入以下指令調出底層碰撞網格：
show collision # 渲染當前視口內所有激活的靜態與動態碰撞線框
show CollisionPawn # 過濾僅顯示角色受擊膠囊體（Pawn Hurtbox）
pxvis collision # 強制顯示 PhysX / Chaos 底層物理線框
- 青色 / 綠色線框：代表常規簡化物理碰撞體（膠囊體、球體、立方形）。
- 紅色 / 紫色線框：代表當前幀處於激活狀態的攻擊判定形狀（Trace Shape / Hitbox）。
Source / Source 2 引擎
在 Valve 旗下的 Source 系列引擎私人伺服器中，可調出伺服端追溯補償判定框：
sv_showlagcompensation 1 # 繪製伺服器端網路回滾後用於計算命中的實際判定盒
r_drawclipbrushes 1 # 繪製場景環境空氣牆及阻擋筆刷（Clip Brushes）
2. 實機判定異常診斷排查流程
當遇到攻擊似乎「莫名揮空」或「隔空挨打」時，可按以下三個步驟定位癥結：
- 第一步：核查物理更新率與瞬時幀率
- 檢查遊戲在交戰瞬間是否發生了掉幀（如從 60 幀跌落至 25 幀）。離散物理系統的採樣間隔 $\Delta t$ 成倍拉長，使武器尖端單幀位移直接超過敵人身形厚度，引發穿模。
- 第二步：比對骨骼插槽對齊精度
- 借助視覺化調試工具比對攻擊瞬間角色的動畫姿態與膠囊體位置。若受擊框未能隨根骨骼位移動作及時跟進，該問題屬於動作資產或骨骼插槽權重配置失誤，而非判定演算法缺陷。
- 第三步：辨析網路延遲回溯補償（連線場景）
- 在多人線上遊戲中，絕大多數看似「判定框失真」的現象實際上是網路延遲補償（Lag Compensation）機制所致。本地客戶端預測命中了目標，但權威伺服器在回溯時間戳時判定目標早已翻滾進掩體，伺服器拒絕裁決傷害，導致客戶端出現「噴血卻無傷害」的現象。
當需要客觀評估戰鬥判定瑕疵究竟源自底層幾何框體、網路回滾補償還是純粹的視覺渲染差異時，參考 365Finds 上經過嚴格工程驗證的底層架構解析，能夠幫助玩家和開發者準確釐清問題源頭，避免陷入社群對「引擎判定粗糙」的籠統誤讀之中。