Collision detection for small games, without a physics engine

Physics engines are remarkable and entirely unnecessary for games with twenty moving objects. What these games need is a reliable answer to one question — did these two things touch? — and the standard shapes answer it in a few lines.

Two primitives cover almost everything

Axis-aligned bounding boxes handle rectangles and, with a slight overestimate, anything roughly box-shaped. Two boxes overlap when they overlap on both axes, which is four comparisons. Circles overlap when the distance between their centres is less than the sum of their radii, which is one square root or, better, a comparison of squared distances.

Choosing the right primitive is worth a moment of thought rather than reflex: a brick is a box, a ball and a serpent segment are circles, and a player character is usually a box that is deliberately smaller than its drawn sprite so that collisions feel forgiving rather than exact.

The problem with fast things

The classic failure is the fast ball that passes through a thin paddle. Collision is usually tested at discrete positions once per frame, so an object moving far enough in one frame can be on one side of a wall before the frame and the other side after it, with no frame in which they overlap.

There are two ways out. Sub-stepping divides the movement into several smaller steps and tests each one. A swept test instead asks whether the path travelled this frame crosses the obstacle, which is exact and cheap for boxes and circles. Games here use the swept approach where speed makes tunnelling possible — a breakout ball, a fast projectile — and plain overlap tests everywhere else, where the speeds are low enough that it cannot occur.

Grid games get their own rules

A game played on a grid does not need continuous collision at all. Positions are cells, movement happens between cells, and collision is a lookup: is the cell the serpent is about to enter occupied? This is faster and simpler than any geometry, and it makes the game's behaviour trivially predictable, which is exactly what a grid game should be.

Close enough is a feature

A game does not need physical accuracy. It needs collisions that agree with what the player believes they saw, and those are not the same thing. A paddle that is a few pixels more generous than it looks feels good; a paddle that is exactly its drawn size feels punishing, because players aim at the ball rather than at the geometry.

The same reasoning applies in reverse to hazards, which are often made slightly smaller than they appear. The general principle is that generosity toward the player is a design decision expressed in collision volumes, and it costs nothing to implement.

Broad-phase, but only when it earns its place

With thousands of objects, testing every pair becomes quadratic and a spatial grid — bucketing objects into cells and testing only neighbours — earns its complexity. With twenty objects, a full pairwise loop is faster than the bookkeeping required to avoid it. The right time to add a broad phase is when a measurement says so, not in anticipation of a catalogue that will never grow that large.