The Math of Collision Detection Algorithms

A video game is essentially a high-speed illusion. When Mario jumps and lands on a platform, it looks like a physical interaction. But underneath the graphics, there are no solid objects, no gravity, and no physical mass. There are only numbers stored in a computer's memory representing X and Y coordinates. The illusion of a solid world is maintained entirely by mathematical formulas known as collision detection algorithms. If these algorithms are written poorly, characters will fall through the floor, bullets will pass harmlessly through enemies, and the game will lag uncontrollably.

In HTML5 Canvas development, you don't have the luxury of dragging and dropping a built-in physics engine like you do in Unity or Unreal Engine (unless you import a heavy third-party library like Matter.js). Often, for lightweight web games, you have to write the physics yourself. Let's explore the fundamental math behind the most common collision algorithms and how to optimize them so they don't destroy your framerate.

AABB: Axis-Aligned Bounding Boxes

The simplest and most computationally cheap form of collision detection is AABB (Axis-Aligned Bounding Box). In this model, every entity in the game is enclosed in an invisible rectangle. "Axis-Aligned" simply means the box cannot be rotated; its edges are always perfectly parallel to the X and Y axes of the screen.

The math to check if two AABB boxes are intersecting is incredibly simple. It requires no complex trigonometry or square roots—just four basic logical comparisons. You check if Box A's right edge is past Box B's left edge, AND if Box A's left edge is past Box B's right edge, AND the same for the top and bottom edges. If all four statements are true, the boxes are overlapping.

Because the math is just basic addition and logic gates, a modern CPU can calculate thousands of AABB collisions in a fraction of a millisecond. This is why almost all 2D platformers and retro arcade games rely entirely on AABB. Even if the character sprite is highly detailed and irregular, the physics engine just treats them as a solid, unmoving rectangle.

Circle Collision: The Pythagorean Theorem

AABB is great for square platforms, but it is terrible for round objects like asteroids or balls in a game of pool. If you use a square hit-box on a circular asteroid, a spaceship might clip the empty corner of the square and explode, even though it visually missed the asteroid rock. This feels incredibly unfair to the player.

For these scenarios, developers use Circle Collision. The math here is beautiful because it relies on the Pythagorean theorem (A² + B² = C²) you learned in middle school. To check if two circles are overlapping, you calculate the distance between their center points using the distance formula. If that total distance is less than the sum of the two circles' radii, they have collided.

However, there is a catch. The distance formula requires a square root calculation (`Math.sqrt()`). Square roots are computationally expensive for a CPU. If you have 500 asteroids bouncing around, calculating 500 square roots every frame will cause lag. The optimization trick is to compare the squared distance instead. By comparing `distanceSquared < (radius1 + radius2) * (radius1 + radius2)`, you completely eliminate the need for the expensive square root operation, vastly increasing the engine's speed.

The N-Squared Problem

Knowing the math for AABB or Circle collision is only step one. Step two is solving the architectural nightmare known as the N-Squared problem. If you have a single player and 10 bullets, checking for collisions is easy: you loop through the 10 bullets once per frame. That's 10 math calculations. No problem.

But what if you have an asteroids game where 200 asteroids can all bounce off each other? To check if every asteroid is colliding with every other asteroid, Asteroid 1 has to check Asteroids 2 through 200. Then Asteroid 2 has to check Asteroids 3 through 200. The number of calculations required grows exponentially. For 200 objects, the CPU has to perform nearly 20,000 collision checks every single frame. At 60fps, that is 1.2 million checks per second. This will crash a browser instantly.

Broad Phase vs. Narrow Phase: Spatial Partitioning

To solve the N-Squared problem, professional physics engines separate collision detection into two phases: the Broad Phase and the Narrow Phase.

The Broad Phase acts as a highly aggressive filter. It doesn't do precise math; its only job is to quickly eliminate objects that are nowhere near each other. A common technique is a Spatial Hash Grid (or a QuadTree). The game world is divided into a massive invisible checkerboard. Every frame, objects register which grid cell they currently occupy. When checking for collisions, an object only bothers to do the math against other objects that are sitting in the exact same (or adjacent) grid cell. If Asteroid A is in cell [0,0] and Asteroid B is in cell [10,10], the engine completely ignores them.

Once the Broad Phase has quickly narrowed down a list of potential pairs that might be touching, it passes those specific pairs to the Narrow Phase. The Narrow Phase then executes the precise AABB or Circle math to confirm the exact pixel of impact.

Respecting the CPU

Writing a game in HTML5 Canvas forces a developer to become highly intimate with mathematical optimization. You cannot rely on raw hardware to brute-force poorly written code. By understanding the geometric simplicity of AABB, the optimized squared-distance trick for circles, and the absolute necessity of spatial partitioning to solve the N-Squared problem, you can architect web games that handle hundreds of physical entities with effortless, flawless performance.