The Geometry of Combat: Hitboxes, Hurtboxes, and Pushboxes
In video game combat systems, what players see on screen is rarely what the underlying physics simulation evaluates. High-fidelity visual characters with tens of thousands of polygonal faces, flowing cloth, and articulated fingers are computationally impractical for real-time physics calculations. Instead, game engines decouple visual rendering from geometric collision, constructing invisible spatial boundaries to resolve whether an attack connects, whether an entity takes damage, and how characters occupy physical space.
To manage combat mechanics cleanly, game engines divide character collision into three distinct functional volumes:
+-------------------------------------------------------------------------+
| COMBAT COLLISION TRIAD |
+-------------------------------------------------------------------------+
| 1. HITBOX (Active Attacking Volume) |
| - Instantiated during active attack frames (swords, fists, bullets) |
| - Queries scene for intersecting damage-receptive targets |
| - Triggers damage events, hitstop, and knockback impulses |
+-------------------------------------------------------------------------+
| 2. HURTBOX (Vulnerability Volume) |
| - Bound to skeletal bones (head, torso, limbs) |
| - Constantly updates transform matrices alongside character motion |
| - Passive receiver: registers damage when penetrated by a Hitbox |
+-------------------------------------------------------------------------+
| 3. PUSHBOX / ENVIRONMENT COLLIDER (Solid Physics Volume) |
| - Usually an upright capsule, cylinder, or simplified box |
| - Resolves environmental contact (floors, walls, ramps, obstacles) |
| - Prevents entities from walking through one another or terrain |
+-------------------------------------------------------------------------+
The Architectural Necessity of Spatial Separation
If games relied on a single unified collider for a character, combat mechanics would collapse:
- If the environment collision capsule registered damage, attacks would trigger when striking empty air around outstretched arms or tucked heads.
- If weapons shared collision with character physics, swinging a broadsword against an enemy would stop the sword upon touching their outer physics boundary rather than slicing through the vulnerable torso.
- By separating Hitboxes (damage dealers), Hurtboxes (damage receivers), and Pushboxes (solid world boundaries), developers can dynamically configure distinct collision response channels, ignoring certain interactions while triggering bespoke gameplay callbacks on others.
The Two-Phase Collision Pipeline: Broad Phase vs. Narrow Phase
In modern action titles featuring dozens of simultaneous entities, spell effects, and environmental objects, testing every collision shape against every other shape every frame leads to an $O(N^2)$ computational explosion. If a scene contains 100 collidable actors, a naive loop requires:
$$\frac{100 \times 99}{2} = 4,950 \text{ pair-wise intersection tests per tick}$$
To maintain high frame rates (such as 60Hz or 144Hz physics loops), modern physics engines (such as PhysX, Chaos, and Havok) divide spatial collision queries into two consecutive phases:
[ All Game Entities in Scene ]
|
v
+-----------------------------------------------------------+
| BROAD PHASE: Coarse Spatial Partitioning |
| - Uses Axis-Aligned Bounding Boxes (AABBs) |
| - Evaluates Bounding Volume Hierarchies (BVH) or Octrees |
| - Swiftly rejects 95% - 99% of non-colliding pairs |
+-----------------------------------------------------------+
|
| (Candidate Overlap Pairs Only)
v
+-----------------------------------------------------------+
| NARROW PHASE: Precise Geometric Intersection |
| - Tests specific primitives (Spheres, Capsules, OBBs) |
| - Executes SAT (Separating Axis) or GJK Algorithms |
| - Calculates exact Contact Points, Normals, and Penetration|
+-----------------------------------------------------------+
|
v
[ Dispatched Gameplay Events: TakeDamage(), ApplyImpulse() ]
1. Broad-Phase Spatial Partitioning
The broad phase ignores intricate character shapes entirely. Instead, it encloses every object within an Axis-Aligned Bounding Box (AABB)—a box aligned strictly to world coordinate axes $(X, Y, Z)$ requiring only minimal min-max scalar comparisons:
$$\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)$$
Using spatial data structures such as Bounding Volume Hierarchies (BVH), Octrees, or Sweep-and-Prune (SAP), the engine groups spatially adjacent objects into hierarchical tree nodes. If the bounding volume of a player's sword attack does not overlap the parent bounding volume of an enemy cohort, the engine instantly skips dozens of potential checks in a single clock cycle, reducing complexity from $O(N^2)$ to roughly $O(N \log N)$ or $O(N)$.
2. Narrow-Phase Geometric Resolution
Once the broad phase yields a list of overlapping candidate pairs, the narrow phase executes exact mathematical intersection checks on the underlying collision primitives:
- Sphere vs. Sphere: The fastest test in 3D math. If the distance between two centers is less than the sum of their radii $(|C_1 - C_2|^2 \le (R_1 + R_2)^2)$, collision is confirmed.
- Capsule vs. Capsule: Evaluated by finding the shortest line segment between the two internal skeletal line segments and testing against the combined capsule radius. Because human limbs naturally map to capsules, this is the primary primitive used for character hurtboxes.
- Oriented Bounding Boxes (OBBs) & Convex Hulls: Evaluated using the Separating Axis Theorem (SAT) or the Gilbert-Johnson-Keerthi (GJK) distance algorithm. If a separating plane can be inserted between two convex shapes along any potential axis, the objects do not touch.
Per-polygon mesh collision (evaluating tens of thousands of animated triangle faces) is almost universally avoided for dynamic combat. The computational cost of testing dynamic deformed meshes against each other during complex animation states would stall CPU worker threads and cause severe frametime spikes.
Discrete Collision vs. Continuous Collision Detection (CCD): The Tunneling Problem
The most pervasive collision flaw in action games is tunneling (commonly referred to by players as "phasing", "ghost hits", or "clipping through"). Tunneling occurs when a fast-moving object passes completely through a target without the physics engine registering any contact.
The Mathematics of Tunneling
Standard physics simulation relies on Discrete Collision Detection. In a discrete simulation, the engine calculates positions only at fixed time intervals $\Delta t$:
Frame N (Time = t): Frame N+1 (Time = t + dt):
[ Bullet / Sword ] --- Speed v ---> [ Bullet / Sword ]
o o
(at x=10) (at x=60)
| Target Wall |
| [x=30..35] |
If an object travels at velocity $v$, its displacement over a single frame tick is:
$$\Delta x = v \cdot \Delta t$$
If the thickness of the target obstacle $W_{\text{target}}$ plus the diameter of the projectile $D_{\text{proj}}$ is less than the frame displacement:
$$W_{\text{target}} + D_{\text{proj}} < v \cdot \Delta t$$
The object was entirely on the front side of the obstacle at frame $N$, and entirely on the back side at frame $N+1$. Because the discrete engine only queries geometric overlap at the discrete sample points, it never detects an intersection. The bullet or sword phases through the target as though it were transparent.
Continuous Collision Detection (CCD) Architectures
To eliminate tunneling for high-velocity projectiles, melee weapon tips, and fast-moving player characters, game engines implement Continuous Collision Detection (CCD) through two primary methodologies:
+----------------------------------------------------------------------------+
| CCD IMPLEMENTATION MODES |
+----------------------------------------------------------------------------+
| 1. SWEEP-BASED CCD (Swept Volume / Extrusion) |
| - Extrudes primitive along its velocity vector: Volume = Shape x [0, dt]|
| - Solves continuous mathematical ray/capsule intersection over interval |
| - Computes exact Time of Impact (TOI in [0, 1]) and contact normal |
| - Cost: High CPU arithmetic overhead per dynamic actor |
+----------------------------------------------------------------------------+
| 2. SPECULATIVE CCD (Inflated Predictive Bounds) |
| - Expands broad-phase AABB along the expected movement vector |
| - Creates predictive contact constraints before actual overlap occurs |
| - Prevents penetration by constraining velocity along the surface normal|
| - Cost: Significantly lower CPU overhead than sweeping |
| - Risk: Can cause "ghost collisions" if trajectories change abruptly |
+----------------------------------------------------------------------------+
In high-performance shooter engines, developers frequently bypass physical CCD entirely for bullets by using instantaneous Line Traces (Raycasts) or multi-tick segmented raycasts. Instead of spawning physical rigid bodies that simulate air resistance and volume, a raycast traces a zero-width mathematical line between the projectile's previous position and its current position, immediately finding any intersected hurtboxes along the line segment.
The Disparity Between Visual Models and Combat Physics
Players frequently express frustration when visual feedback contradicts gameplay outcomes: an attack visibly clips through an opponent's body without registering, or an enemy strikes empty air two feet away and deals full damage. Understanding why these disparities occur requires examining the tension between visual fidelity and physics engineering.
1. Capsule Approximation vs. Skeletal Contours
Character art models feature intricate contours, clothing, capes, and varying armor thicknesses. In contrast, combat hurtboxes are composed of simplified geometric capsules parented to skeletal bones (e.g., Pelvis, Spine_02, UpperArm_L, Head).
Because a single capsule cannot match the curvature of an armored shoulder or leather vest, developers must choose between:
- Tight Hurtboxes: Smaller than the visual mesh, causing visual hits on armor edges, cloaks, and weapon sheaths to "whiff".
- Generous Hurtboxes: Larger than the visual mesh, allowing near-misses in empty air adjacent to the character to trigger hit registration.
2. Animation Blending and Root Motion Desync
Modern character movement relies on skeletal animation blend spaces. When a character transitions from a heavy attack windup into an evasive dodge, the graphics pipeline smoothly blends vertex positions across multiple animation clips over several hundred milliseconds.
However, hurtbox attachment points update discretely according to bone socket matrices. If an animation transition blends visual geometry faster or slower than bone transform updates, or if root motion physics desynchronizes from the animation graph, the rendered visual mesh can momentarily drift away from the underlying collision volumes.
3. Disjoint Hitboxes and Linger Frames
In many fighting games and character action titles, hitboxes are intentionally designed to be disjoint—the damaging volume extends significantly beyond the visual blade, or active damage frames remain enabled for several frames after the weapon model has completed its swing (known as "linger frames").
Developers implement disjoint hitboxes intentionally to compensate for human reaction latency, ensure directional attacks consistently hit crouching or aerial targets, and create a visceral sense of weapon weight. While visually inaccurate, these adjustments often create a more responsive and satisfying gameplay rhythm.
4. Cosmetic VFX Lack Collision Geometry
Weapon swings in modern games are accentuated by dynamic trail ribbons, particle bursts, lens flares, and screen-space distortion shaders. These visual effects exist exclusively within the graphics rendering pipeline (GPU vertex and fragment shaders) and contain zero physics data. A massive fire effect extending six feet past a blade does not possess collision unless the gameplay programmer explicitly attaches a corresponding spherical or conical hitbox to that effect.
Collision Matrix: Collision Detection Modes Compared
The following matrix compares how standard collision detection architectures balance computational cost, tunneling prevention, and typical gameplay applications:
| Collision Mode | Computational Cost | Static Geometry Tunneling | Dynamic Actor Tunneling | Typical Implementation | Primary Tradeoffs & Failure Modes |
|---|---|---|---|---|---|
| Discrete Detection | Very Low ($O(1)$ primitive test) | Vulnerable at high velocities | Vulnerable at high velocities | Default character walking, environment props, large slow monsters | Severe tunneling if frame rates drop or velocities spike; objects phase through thin walls |
| Sweep-Based CCD | High (Complex continuous geometry solver) | Completely Prevented | Prevented (if both bodies participate) | Fast melee weapon arcs, thrown spears, vehicle bumper collisions | Heavy CPU overhead when multiple actors collide; potential performance drops in crowded battles |
| Speculative CCD | Moderate (AABB predictive expansion) | Substantially Reduced | Substantially Reduced | Ragdolls, falling debris, secondary physics props | Prone to "ghost collisions" where objects bounce off walls before touching them |
| Line Trace / Raycast | Low ($O(1)$ line-plane intersection) | Prevented along path | Prevented along path | Hitscan sniper rifles, bullet ballistics, ground clamping checks | Zero physical volume; thin projectiles can slip through gaps between adjacent capsule colliders |
In-Engine Collision Diagnostics and Player Triage
When debugging combat registration inconsistencies—whether developing an indie project, modding an existing title, or diagnosing hit registration issues in competitive gaming—relying on visual cues alone leads to flawed conclusions. Gamers and developers can inspect the underlying collision pipeline using built-in engine visualization tools.
1. Visualizing Collision Geometry in Engine Consoles
Unreal Engine (UE4 / UE5)
In games built on Unreal Engine where developer console access is enabled, input the following commands to expose real-time physics volumes:
show collision # Renders all active static and dynamic collision primitives
show CollisionPawn # Restricts visualization exclusively to character hurtboxes and pawn capsules
pxvis collision # Exposes underlying PhysX/Chaos low-level collision wireframes
- Cyan / Green Wireframes: Indicate simple collision shapes (capsules, spheres, boxes).
- Red / Purple Wireframes: Indicate active damage-dealing trace shapes or complex mesh queries.
Source / Source 2 Engine
In titles running on Valve's Source architecture, developers and players in private local servers can inspect server-side versus client-side hitboxes:
sv_showlagcompensation 1 # Draws the server-rewound hitbox positions used to calculate hit registration
r_drawclipbrushes 1 # Visualizes environmental brush collision surfaces
2. Diagnostic Flowchart: Differentiating Engine vs. Network vs. Animation Issues
To identify why a combat action failed to connect as expected:
- Step 1: Check Frame Timing and Physics Rate
- If the game drops below its targeted physics tick rate (e.g., dropping to 20 FPS during heavy combat), discrete collision detection windows widen dramatically ($\Delta t$ triples from $16.6\text{ms}$ to $50\text{ms}$), making tunneling significantly more frequent.
- Step 2: Inspect Collision Volume Alignment
- Using debug overlays, confirm whether the character's skeletal capsules actually match the visual pose during the specific attack frame. If the hurtbox lagged behind the visual model due to root motion desync, the issue is an animation asset flaw rather than a hit registration bug.
- Step 3: Evaluate Network Reconciliation (In Multiplayer)
- In online titles, an apparent "hitbox issue" is almost always a latency compensation artifact. When a player fires, the local client predicts a hit, but the authoritative server rewinds world state to the timestamp of the shot. If the target moved behind cover during the transmission delay, the server rejects the hit, causing the client to display visual blood or sparks with zero damage applied.
When evaluating whether combat issues stem from underlying geometry, network reconciliation, or animation rendering quirks, consulting verified technical architecture breakdowns on 365Finds helps players and creators isolate root causes without falling victim to generalized community misconceptions about "broken engines".