Collision detection answers questions such as “which shapes might overlap?”, “are they actually touching?” and “will a fast-moving object hit during this step?” A complete game-physics solution may also calculate contact points, solve constraints and update motion, but those are separate responsibilities.
The right design depends on shape, speed, object count, movement distribution and gameplay tolerance. A precise algorithm applied to every pair is usually wasteful; an aggressive approximation without a narrow phase can produce false hits. Modern engines therefore combine filtering, broad-phase candidate generation and narrow-phase tests.
Choose representations for gameplay
Collision geometry does not need to reproduce every visible triangle. Prefer the simplest shape that supports the interaction:
- circle or sphere: cheap and rotation-independent;
- axis-aligned bounding box: useful for broad-phase bounds and axis-aligned games;
- capsule: often suitable for characters and elongated objects;
- oriented box: tighter than an AABB but more involved to test;
- convex polygon or hull: supports detailed solid shapes with robust algorithms; and
- segments, chains or tile geometry: useful for boundaries and terrain under engine-specific rules.
Complex concave objects are commonly decomposed into convex pieces or represented as a static mesh supported by the engine. Verify one-sided-edge, internal-edge and winding rules. Keep render and collision assets under version control with scale and coordinate assumptions documented.
An AABB is not a precise rotated-box test. It encloses the object along world axes and can grow when the object rotates. That makes it excellent for conservative candidate generation but potentially loose as final collision geometry.
Filter before testing pairs
Layers, categories, masks and group rules exclude pairs that can never interact. A projectile may collide with enemies and world geometry while ignoring its owner. A trigger or sensor may report overlap without producing a physical response.
Treat filters as data with tests. A single matrix should document which categories collide, overlap or ignore. Avoid scattered conditional code that disagrees with the physics engine. Validate network-supplied or modded category values before they influence authoritative gameplay.
Filtering reduces work and prevents unintended interactions, but it is not an access-control boundary. A hostile client must not decide that its authoritative hitbox ignores damage.
Broad phase: find plausible pairs
Testing every object against every other object grows quadratically. The broad phase maintains conservative bounds and returns a smaller set of candidate pairs. Common structures include:
- uniform grids or spatial hashes;
- sweep and prune along one or more axes;
- bounding-volume hierarchies; and
- dynamic AABB trees.
No structure wins for every distribution. A uniform grid can work well when objects have similar sizes and occupy space evenly, but large objects or dense clusters can overload cells. A tree handles varied placement but has update and traversal costs. Measure the actual distribution, motion and query mix.
Box2D uses a dynamic bounding-volume tree for broad-phase organisation and exposes overlap, ray-cast and shape-cast queries. Its documentation describes “fat” AABBs and category bits that support efficient conservative queries (Box2D — Collision). Do not assume an engine's internal tree behaves like a custom implementation; use its supported APIs and profiler.
Narrow phase: test actual shapes
The narrow phase applies shape-specific algorithms to candidates and may calculate a contact manifold. Examples include closest-point tests for circles and capsules and separating-axis tests for convex polygons.
The Separating Axis Theorem applies to convex shapes: if an axis exists on which the projected intervals do not overlap, the shapes do not intersect. Concave shapes require decomposition or another representation. Test degeneracy, touching boundaries, very small shapes and floating-point tolerances; a textbook formula can become unstable near zero-length edges.
Define whether touching counts as collision and whether coordinates use closed or open intervals. This matters for tile movement, grounded checks and deterministic regression fixtures. Centralise tolerances rather than introducing arbitrary epsilon values in every call.
Continuous collision detection for fast motion
Discrete detection checks positions at simulation steps. A projectile can pass through a thin wall between two checks. Continuous collision detection (CCD), shape casts or time-of-impact queries examine motion over an interval and can reduce tunnelling.
CCD costs more and has engine-specific limitations. Apply it to objects whose speed, size and consequences justify it rather than enabling an expensive mode blindly. A hitscan weapon may use a ray or shape query instead of a simulated high-speed body. A fast character may need a capsule cast and controlled resolution.
Box2D documents continuous collision for fast bodies and shape casts; Rapier exposes CCD controls and collision-pipeline queries. Use the precise version's supported combinations and test moving-versus-moving cases (Box2D — Simulation, Rapier — Advanced collision detection).
Separate detection from response
Detection says a contact or overlap exists. Response decides what it means: block movement, bounce, apply damage, collect an item or enter a zone. Keep gameplay effects idempotent when callbacks can repeat across steps.
Physics engines may deliver begin, persist and end events, or require polling. Confirm ordering and lifetime. Do not delete bodies or mutate the world in a callback unless the engine explicitly supports it; queue a command for a safe phase where necessary.
For grounded characters, one contact flag is often insufficient. Check surface normal, separation, slope and recent support state according to the controller design. Sensors can help, but they need filtering and edge-case tests.
Build a reproducible collision suite
Create deterministic fixtures for:
- separated, touching and overlapping shapes;
- rotated convex shapes and degenerate input;
- high-speed thin targets;
- sensors and category filters;
- objects spanning several broad-phase cells;
- dense clusters and widely dispersed scenes;
- creation, removal and teleportation; and
- fixed-step replay across supported platforms.
Record false positive candidates, narrow-phase calls, query time, contact count and high-percentile physics-step time. Profile realistic object-size and movement distributions; a benchmark containing identical static boxes can favour a structure that performs poorly in the actual level.
Visualise collision shapes, bounds, candidate pairs, normals and casts in a debug build. Keep the display out of release builds unless it is intentionally supported. Compare a recorded expected event sequence, not only a screenshot.
For help designing a collision test harness or selecting a physics integration, see Ozlin Info's game-development services or contact Ozlin Info.
Related reading: Choosing a 2D physics engine with a reproducible benchmark.
General-information disclaimer
This article provides general technical information. Collision accuracy, determinism and performance depend on the exact engine, version, shapes, step configuration and target hardware; no universal algorithm or outcome is guaranteed.
AI-assistance disclosure
AI tools assisted with source discovery, outlining and copyediting. A human reviewer must verify algorithms, tolerances, engine behaviour and benchmark results against the actual project before publication or implementation.
Primary sources checked
Source access date: 29 August 2026.
Leave a Reply