How Collision Detection Works in Arcade Games

When a game decides you hit an obstacle, it is almost never looking at pixels. It is comparing four numbers. Understanding which four explains a lot of otherwise mysterious moments - the death that looked like a miss, the coin you were sure you touched, and the landing that should not have worked.

Axis-aligned bounding boxes

The workhorse of arcade collision is the axis-aligned bounding box, usually shortened to AABB. Every object is treated as a rectangle described by an x, a y, a width and a height. Two rectangles overlap unless one of four things is true:

• A is entirely to the left of B
• A is entirely to the right of B
• A is entirely above B
• A is entirely below B

So the test is four comparisons, and if none of them separates the pair, they overlap. No square roots, no trigonometry, no geometry beyond subtraction. On a machine that can do hundreds of millions of comparisons a second, checking a cat against thirty obstacles is free.

"Axis-aligned" means the rectangles do not rotate. The moment an object can rotate, the cheap test stops working and you need something considerably more involved. Arcade games avoid this almost universally - and when a sprite appears to rotate, its collision box usually does not.

Why the box is smaller than the cat

Here is the part players notice without being able to name. The cat you see has ears, whiskers and a tail. The cat the collision system sees is a rectangle around its body, and it is deliberately smaller than the drawing.

The reason is that players judge collisions by the character's mass, not its outline. Nobody feels they hit a crate because a whisker brushed it. If the collision box covered the whiskers, the game would be technically correct and would feel broken, which is the worse outcome.

The same trick runs in the other direction for things you want to collect. Pickup boxes are usually slightly larger than the coin drawn on screen, so a near miss registers as a catch. Players never notice this either, which is exactly the point: both adjustments make the game agree with intuition rather than with geometry.

Circles, when rectangles are wrong

For round objects a rectangle is a poor fit - the corners of the box stick out well beyond the shape, and players die to empty space. The alternative is a circle test: two circles overlap when the distance between their centres is less than the sum of their radii.

The useful refinement is to compare squared distances rather than actual distances, which avoids a square root. If the sum of the squared differences in x and y is less than the square of the combined radii, they touch. It is barely more expensive than the rectangle test.

This is what Space Cat uses throughout: the saucer and the asteroids are all roughly circular, and a rectangle around a drifting asteroid would produce deaths that look plainly wrong.

Tunnelling: the bug that produces impossible deaths

Collision tests check where things are, not where they have been. If an object moves far enough in one frame, it can be on one side of a wall before the frame and on the other side after it, with no frame in which the two overlapped. The game sees no collision and the object passes straight through.

This is called tunnelling, and it is the cause of most "the game let me through the floor" bugs. It becomes likely in two situations: when speeds are high, and when a frame takes unusually long - which happens the moment you switch tabs and come back.

The standard defence is simple and is used by every game on this site: clamp the elapsed time. However long the browser says the frame took, the game never steps more than about a twentieth of a second at once. A long pause then produces a brief slow-motion catch-up rather than a teleport. It costs nothing and removes the entire class of bug.

Platform landings need more than overlap

Standing on a platform is not a collision question, it is a direction question. If a platformer used plain overlap, the cat would be stopped by a platform it jumped up through from below - which is wrong, because a one-way platform should be solid from above and passable from underneath.

The usual solution checks three things at once:

1. Is the cat moving downward? If it is rising, ignore the platform entirely.
2. Was the cat's feet position above the platform's surface at the start of this frame?
3. Is it at or below that surface now?

If all three hold, the cat crossed the surface during this frame from above, so it lands: snap the position to the surface and zero the vertical velocity. This is why you can jump up through a platform and land on it on the way down, and it is the whole of the one-way platform mechanic.

The solid-on-all-sides case in a hand-designed platformer is different again, and is worked through in how platform collision works.

Resolving one axis at a time

When a character can be blocked horizontally as well as vertically, moving both axes at once and then resolving produces ambiguity: the game cannot tell whether you hit the side of the platform or the top of it, and picks wrong often enough to be noticeable.

The fix is to move and resolve separately. Apply horizontal movement, check and resolve horizontal collisions, then apply vertical movement and resolve vertical collisions. Each resolution knows unambiguously which direction it is correcting, so a cat that runs into a wall stops, and a cat that lands on a ledge lands, and neither is confused for the other.

What this means when you are playing

A death that looked like a miss

The obstacle's box is probably slightly larger than its drawing, or you clipped it with part of the cat you did not think counted. Either way the geometry agreed with the game.

A catch you were sure you missed

Pickup boxes are deliberately generous. This is the system being kind to you rather than a bug.

A landing that should not have worked

Either coyote time gave you a grace window after leaving the ledge, or the landing snap pulled you up onto a surface you had just clipped.

Passing through something at high speed

That is tunnelling, and it is a defect rather than a feature. If you see it in one of our games, please report it.

Key Takeaways

• Arcade collision is four number comparisons between rectangles - no pixels are examined.
• The player's collision box is smaller than the drawing so near misses feel like misses; pickup boxes are larger so near misses count as catches.
• Circle tests suit round objects and cost barely more than rectangles if you compare squared distances.
• Tunnelling happens when an object moves past something inside a single frame; clamping the frame step prevents it.
• Platform landings check direction and crossing, not just overlap, and axes should be resolved one at a time.

Frequently Asked Questions

Do games compare actual pixels?

Very rarely. Per-pixel collision is far more expensive and, more importantly, produces deaths that feel unfair - a single whisker overlapping should not count.

Why did I die when I clearly jumped over it?

Most often the obstacle's box extends a little beyond its visible shape, or the cat's fall had begun sooner than it looked. Well-tuned games shrink the player's box precisely to reduce this.

What is a hitbox?

Informal shorthand for the collision shape attached to an object. It is usually invisible and usually a different size from the drawing.

Why do collectibles seem magnetic?

Their pickup area is larger than the icon. It is a deliberate generosity, because a missed coin that looked like a hit is annoying in a way a caught coin that looked like a miss is not.

Can collision detection be perfect?

Not in a discrete simulation. Positions are only known at frame boundaries, so anything between frames is inferred. The practical goal is not perfection but agreement with what the player believes happened.

Does collision detection slow games down?

Not at this scale. An arcade game checks a handful of nearby objects per frame, which is a trivial amount of work. Slowdowns almost always come from elsewhere.