Hitboxes
Collision boundaries
Hitboxes define the invisible collision boundaries around game objects, determining when attacks connect, pickups are collected, and characters collide with the world.
Overview
What you see isn’t always what the game detects. Hitboxes are the simplified collision boundaries that determine interactions between game objects. A character sprite might be 32 pixels tall, but their vulnerable hitbox could be a small rectangle at chest height — making the game feel fair despite the simplification. Done well, hitboxes make a fighting game’s frame data, a platformer’s “this jump should make it” forgiveness, and a shooter’s “the bullet didn’t seem to hit” satisfaction.
The technique is alive and central to modern games — fighting-game frame data discussions on YouTube and Twitch (Street Fighter, Tekken, Smash Bros.) revolve around hitbox / hurtbox visualisations.
Fast facts
- Purpose: Collision detection boundaries.
- Shape: Usually rectangles (axis-aligned bounding boxes); circles, capsules, or hand-tuned polygons for higher precision.
- Visibility: Hidden from players in-game; visible in debug modes and frame-data analysis.
- Design goal: Feel fair and responsive.
Hitbox types
Modern games typically use multiple distinct box types per object:
| Type | Purpose | Example |
|---|---|---|
| Hurtbox | Where the character can be hit | Body, head — separate boxes per limb in fighters |
| Hitbox / attack box | Where an attack deals damage | Sword swing, punch, projectile body |
| Collision box / pushbox | Solid-world collision; characters can’t overlap | Player vs player, player vs wall |
| Trigger box | Event activation (no physical collision) | Door entry, area-of-effect, cutscene trigger |
| Grab box | Throw-attack range | Fighter grabs |
| Counter box | Active-during-counter window | Parry / counter mechanics |
| Block box | Blocking-attack registration | Shield raised states |
Different games have different needs — a platformer might just have collision and hurt; a fighting game has all of the above plus more.
Design considerations
| Factor | Approach |
|---|---|
| Fairness to player | Player hurtbox often smaller than sprite — gives a “felt fair” advantage on close calls |
| Hostile to player | Enemy hitboxes can be slightly larger than visuals to give attacks reach |
| Forgiveness on pickups | Generous trigger boxes — coin pickups feel snappy |
| Precision in skill games | Tight boxes that exactly match the visual (fighting games, bullet-hells) |
| Animation matching | Per-frame boxes that follow the sprite’s actual extension (a sword swing’s hitbox grows during the swing animation) |
The “player hurtbox smaller than sprite” rule is the secret behind why classic Nintendo games “felt good” — a tiny hurtbox at Mario’s centre means most close-call jumps barely-cleared rather than barely-failed.
Platform approaches
| Platform | Common method |
|---|---|
| NES / 8-bit | Bounding box comparison — single rect per object, simple AABB intersection |
| C64 | Same, plus optional hardware sprite-sprite collision register $D01E |
| Mega Drive / SNES | Multiple boxes per object; software AABB; sometimes hierarchical |
| Arcade fighters | Multiple boxes per character per frame; Street Fighter II introduced the per-frame approach |
| Modern engines | Hierarchical: broad-phase via spatial partition + narrow-phase via per-bone capsules / boxes |
Fighting game precision
Fighting games made hitboxes their own art form:
| Element | Implementation |
|---|---|
| Per-frame boxes | Different shapes each animation frame |
| Active frames | Attack only hits during specific frames of the animation |
| Recovery frames | Vulnerable hurtboxes during cooldown — punishable |
| Invincibility frames (i-frames) | No hurtbox during certain moves (dragon-punches, dodges) |
| Counter-hit window | Hitbox registers as “counter” only during specific opponent frames |
| Hurtbox extensions | Some attacks expose the attacker’s hurtbox during startup |
The Street Fighter II fighting-game tradition — startup, active, recovery — is now standard across genres. Modern fighting-game training modes show all boxes in real time so players can study frame data.
Common optimisations
| Technique | Benefit |
|---|---|
| Axis-aligned boxes (AABB) | Simplest overlap maths — 4 comparisons per pair |
| Hierarchical checks | Broad-phase (large box around the whole entity) before narrow-phase (per-limb boxes) |
| Spatial partitioning | Quadtree / grid bucketing — only check pairs that share a region |
| Sweep and prune | Sort objects by axis, only check pairs whose axes overlap |
| Frame skipping | Some checks can run every other frame for non-critical objects |
The broad-then-narrow approach is universal: an axis-aligned bounding box is cheap to test; per-bone capsules are expensive. Test the cheap one first, fall through to the expensive one only when the cheap one says “maybe.”
Visualising hitboxes
Modern fighting game communities have made hitbox visualisation a public discourse:
- Training mode toggles — Street Fighter, Tekken, Smash Bros training modes show boxes
- Mods / hacks — older fighting games have community mods to expose boxes
- Frame data sites — Dustloop, SuperCombo Wiki, Smash Wiki document boxes per frame
- Streamer culture — Maximilian Dood, Sajam, and others routinely overlay box data during analysis
This transparency is relatively recent; original game designers often guarded box layouts as design secrets.