The question behind every hit
When a bullet strikes an enemy, a player lands on a platform, or a car bumps a fence, the game has to answer one question: are these two things touching? That sounds trivial, but the game does not see objects the way you do. It sees numbers: positions, sizes and shapes. Collision detection is the process of comparing those numbers to decide whether two objects overlap.
The hard part is not any single check. It is doing thousands of them every frame, on shapes that are far more detailed than the game can afford to compare exactly.
Simple shapes stand in for real ones
A character model might be made of thousands of triangles, but the game almost never tests those against each other. Instead, each object gets a much simpler invisible shape, often called a hitbox or collider. Common choices include:
- Rectangles or boxes, aligned to the screen or world axes, which are the cheapest to test.
- Circles or spheres, which are cheap and work well for round things and for characters that should slide around corners.
- Capsules, a rounded pill shape often used for standing characters, since it handles stairs and slopes smoothly.
- Convex shapes, which are more precise but cost more to test.
The simplicity is a deliberate trade. A player may hit an enemy that looks close but is technically outside the visible outline, or miss one that looks overlapping. Designers tune hitboxes to what feels fair, and they are often smaller or larger than the artwork. In many action games the player’s hitbox is smaller than the visible character, which tends to feel forgiving.
A worked example with circles
Testing two circles is a good way to see the idea. Two circles overlap when the distance between their centers is no greater than the sum of their radii.
Suppose circle A has its center at (0, 0) with a radius of 3, and circle B has its center at (3, 4) with a radius of 2. The horizontal gap is 3 and the vertical gap is 4. The distance between centers is the square root of 3 squared plus 4 squared, which is the square root of 25, or 5. The sum of the radii is 3 + 2 = 5. Because the distance equals the sum, the circles are exactly touching. If B moved slightly closer, they would overlap.
Games often skip the square root to save time, comparing 25 against 5 squared (also 25) instead. The answer is the same, and the calculation is cheaper.
Too many pairs to check
If a level holds 1,000 objects and the game compares every one with every other, that is roughly half a million pairs per frame (1,000 times 999, divided by 2, is 499,500). Most of those pairs are nowhere near each other. Checking them all would waste the tiny time budget each frame allows.
So collision systems work in two stages.
Broad phase. A cheap first pass throws away pairs that obviously cannot touch. A common method divides the world into a grid. If the world is 1,000 units wide and each cell is 100 units, there are 10 columns, and an object only needs to be compared with others in its own cell or neighboring cells. Other approaches sort objects along an axis or arrange them in tree structures. The goal is the same: find candidate pairs quickly.
Narrow phase. For the few pairs that survive, the game runs a more careful test using the actual collider shapes. Only here does it compute things such as exactly where the contact happened and how deep the overlap is.
Detecting is not the same as responding
Knowing that two objects touch is only half the job. What happens next is the response. A solid wall might push the player back out along the direction of overlap. A pickup might disappear and add to a score. A hazard might reduce health. Many engines separate these cleanly: the detection system reports a contact, and game code decides the consequences. Some objects, called triggers, detect overlap but never push anything, which is how invisible zones that start a cutscene or a checkpoint work.
Why fast objects slip through
One well-known problem is tunneling. A game checks positions only once per frame. If a small object moves fast enough, it can be on one side of a thin wall in one frame and on the other side in the next, never overlapping at any checked moment. The collision is simply missed.
There are a few typical remedies:
- Make thin walls thicker than the distance fast objects travel per frame.
- Break a fast movement into several smaller steps and test each one.
- Use a sweep test, which checks the whole path between two positions instead of only the end point.
Which approach is appropriate depends on the game. A slow-walking character rarely needs any of them, while a fast projectile often does.
Common symptoms in play
Many everyday glitches trace back to collision choices.
- Getting stuck on a corner often comes from box-shaped colliders catching on edges. Rounded colliders reduce this.
- Falling through the floor can happen after a very long frame, when the game moves objects by a large step. Long frames can come from the issues described in how a main loop budgets its time.
- Hits that feel unfair usually reflect hitboxes that do not match what the player sees, or a mismatch between what a server and a client believe in online play.
Choosing the right level of detail
There is no single best method. A grid-based puzzle game may only check whether two cells match, while a physics-heavy game needs precise shapes. Most engines include collision tools, but understanding them helps, since the fix is nearly always to adjust a shape, a size or a step.