Hex Grid Distance: The Cube-Coordinate Trick

To find the distance between two hexes, give each one cube coordinates (q, r, s) where q + r + s = 0, subtract them, and compute (|Δq| + |Δr| + |Δs|) / 2. That single number is the minimum step count between the tiles. Our hex grid distance calculator does exactly this once you enter two coordinates.

It looks like overkill to use three numbers to address a flat, two-dimensional map. A chessboard gets by with two. But hexagons resist square-grid thinking, and the third axis is what makes hex math clean instead of a parity-riddled mess. This is the trick that powers Civilization, Catan-style boards, and half a century of tabletop wargames.

Why hexagons need three axes

On a square grid, every tile has eight neighbors, but they are not equal. The four orthogonal neighbors sit one unit away; the four diagonal neighbors sit √2 ≈ 1.414 units away. Games paper over this with the "diagonals cost the same as straight moves" fudge, which distorts geometry and lets units slip through cracks between obstacles.

Hexagons fix the geometry at the source. Every one of a hex's six neighbors is the same center-to-center distance away. There are no diagonals and no awkward corners where four tiles meet at a point. This equidistance is the whole reason strategy games adopted hexes: movement in any of the six directions can be treated identically in game logic.

The cost of that elegance is that hexes do not stack into tidy rows and columns. Each row is offset half a tile from the row above it, so a naive "column, row" address bends as you walk across the board. The clean solution is to stop pretending the grid is two-dimensional and embed it in three dimensions instead.

The cube-coordinate trick

Take an ordinary 3D grid of stacked cubes and slice out the diagonal plane where x + y + z = 0. The cubes that the plane passes through project down to a perfect hexagonal tiling. Red Blob Games, whose interactive guide is the canonical reference for this material, renames the axes q, r, and s to avoid confusion with screen coordinates, but the constraint is identical:

q + r + s = 0

The payoff is that (q, r, s) behaves like a real 3D vector. You can add two hex coordinates, subtract them, or multiply by a scalar, and the result is still a valid hex. A move of "two steps northeast," written (2, 0, -2), can be added componentwise to any starting tile and it just works. Decades of existing 3D algorithms for distance, rotation, reflection, and line-drawing transfer straight onto the hex grid for free.

Where the divide-by-two comes from

Because every coordinate sums to zero, a single step to an adjacent hex always changes exactly two of the three numbers: one goes up by 1 and another goes down by 1, leaving the sum at zero. So the raw total |Δq| + |Δr| + |Δs| counts each step twice. Halving it recovers the true number of steps. An equivalent shortcut gives the same answer with no division:

distance = (|Δq| + |Δr| + |Δs|) / 2
         = max(|Δq|, |Δr|, |Δs|)

Worked example: from (0, 0, 0) to (3, -1, -2), the differences are 3, -1, -2, absolute values 3, 1, 2, summing to 6. Divide by two and the distance is 3 — which also matches max(3, 1, 2) = 3. Both formulas always agree, which makes either one easy to sanity-check by hand.

Why this beats offset-coordinate math

Many games and editors store hexes in "offset" coordinates — plain column and row indices, with every other row or column nudged half a tile to make the grid fit a rectangular array. There are four flavors (even-q, odd-q, even-r, odd-r) depending on orientation and which rank gets pushed. Offset coordinates are wonderful for storage and screen layout and terrible for math.

The problem is that offset coordinates cannot be safely added or subtracted. Moving southeast from (0, 0) might land you at (0, 1), but moving southeast again from (0, 1) lands you at (1, 2) — the step vector itself changes depending on whether you sit on an even or odd row. Any distance formula written directly in offset space inherits this parity dependence and produces the classic symptom: it returns the right answer on some tiles and an off-by-one error on others, with the error flipping based on whether the row index is even or odd.

The fix is not to patch the offset formula but to abandon it. Convert offset coordinates to axial or cube first, then apply the cube distance formula. Axial coordinates are simply cube coordinates with the redundant s dropped, recovered on demand as s = -q - r. A correct axial distance reads:

distance = (|Δq| + |Δr| + |Δq + Δr|) / 2

A notorious buggy version computes the third term from the already-absolute-valued first two, like c = |a - b|, which throws away the sign information the third axis depends on. It compiles, it runs, and it quietly returns wrong distances for half the board.

The orientation bug: "my distance doesn't match the map"

The most common hex headache is a developer reporting that the formula says two tiles are 3 apart while the drawn map clearly shows 5. The cause is almost always an orientation mismatch. Hexes come in two layouts: pointy-top (a vertex points up) and flat-top (an edge faces up). The relationship between them is just a rotation — easiest to picture as a 90-degree turn, or equivalently a permutation that swaps the roles of the two axes.

If you draw the map in one orientation but your coordinate conversion assumes the other, your q and r axes are effectively swapped or negated relative to the picture. The arithmetic stays internally consistent, so it never throws an error; it just measures along axes that no longer line up with the tiles you can see. The convention to lock down: r-type offset layouts (odd-r, even-r) go with pointy-top hexes, and q-type layouts (odd-q, even-q) go with flat-top hexes. Match the offset variant to the actual orientation and the on-screen distance and the computed distance snap back into agreement.

A short history, and why hexes won

Recreational hex grids trace back to the dawn of board wargaming, though not quite to the moment most people assume. Charles S. Roberts designed Tactics in 1952 near Baltimore and, after failing to find a publisher, sold it himself by mail order from the Avalon neighborhood of Catonsville, Maryland — the operation that grew into Avalon Hill (formally incorporated in 1958). Tactics, often called the first commercially successful board wargame, actually ran on a square grid, not a hex one.

The hex grid arrived a few years later. The 1961 second edition of Avalon Hill's Gettysburg is generally credited as the first board wargame to use a hex map, and from there the format spread through wargaming and beyond — into The Settlers of Catan, the 1980s Dungeons & Dragons boxed sets, and science-fiction role-playing games that even used hexes to map interstellar space. Once players felt how cleanly units moved across six equal edges, the square grid never came back for serious tactical games.

The advantage is more than aesthetic. The hexagonal grid is the optimal sampling lattice for isotropically band-limited two-dimensional signals, delivering roughly a 13.4% efficiency gain over a square grid — a result from signal processing, not game design, that happens to explain why hexagons feel so natural for movement and area. Once you have the geometry, cube coordinates are what let you actually compute on it. Try a few pairs in the hex grid distance calculator and watch the (|Δq| + |Δr| + |Δs|) / 2 rule line up with the steps you count by hand.

Frequently Asked Questions