This guide will cover various ways to make hexagonal grids, the relationships between different approaches, and common formulas and algorithms. Hexagonal grids aren't as common as square grids. I've been collecting hex grid resources^{[1]} for over 20 years, and wrote this guide to the most elegant approaches that lead to the simplest code, largely based on the guides by Charles Fu^{[2]} and Clark Verbrugge^{[3]}. Most parts of this page are interactive.

- Angles, size, spacing
- Coordinate systems
- Conversions
- Neighbors
- Distances
- Line drawing
- Range
- Rotation
- Rings
- Field of view
- Hex to pixel
- Pixel to hex
- Rounding
- Map storage
- Wraparound maps
- Pathfinding
- More reading

The code samples on this page are written in pseudo-code; they're meant to be easy to read and understand. The implementation guide has code in C++, Javascript, C#, Python, Java, Typescript, and more.

## Geometry#

### Angles#

## Coordinate Systems#

Now let's assemble hexagons into a grid. With square grids, there's one obvious way to do it. With hexagons, there are multiple approaches. I like cube coordinates for algorithms and axial or doubled for storage.

### Offset coordinates#

The most common approach is to offset every other column or row. Columns are named `col`

(`q`

). Rows are named `row`

(`r`

). You can either offset the odd or the even column/rows, so the horizontal and vertical hexagons each have two variants.

### Cube coordinates#

Another way to look at hexagonal grids is to see that there are *three* primary axes, unlike the *two* we have for square grids. There's an elegant symmetry with these.

Let's take a cube grid and **slice** out a diagonal plane at `x + y + z = 0`

. This is a *weird* idea but it helps us make hex grid algorithms simpler. In particular, we can reuse standard operations from cartesian coordinates: adding coordinates, subtracting coordinates, multiplying or dividing by a scalar, and distances.

Sometimes we don't have obvious algorithms for hex grids, but we do have algorithms for cube grids. Using cube coordinates allows us to adapt cube grid algorithms to work on hex grids. To use the algorithms with another coordinate system, we can convert to cube coordinates, run the algorithm, and convert back.

Study how the cube coordinates work on the hex grid. Selecting the hexes will highlight the cube coordinates corresponding to the three axes.

- Each direction on the cube grid corresponds to a
*line*on the hex grid. Try highlighting a hex with`z`

at 0, 1, 2, 3 to see how these are related. The row is marked in blue. Try the same for`x`

(green) and`y`

(purple). - Each direction on the hex grid is a combination of
*two*directions on the cube grid. For example, northwest on the hex grid lies between the`+y`

and`-z`

, so every step northwest involves adding 1 to`y`

and subtracting 1 from`z`

. We'll use this property in the neighbors section.

The cube coordinates are a reasonable choice for a hex grid coordinate system. The constraint is that `x + y + z = 0`

so the algorithms must preserve that. The constraint also ensures that there's a canonical coordinate for each hex.

There are *many* different valid cube hex coordinate systems. Some of them have constraints other than `x + y + z = 0`

. I've shown only one of the many systems. You can also construct cube coordinates with `x-y, y-z, z-x`

, and that has its own set of interesting properties, which I don't explore here.

"But Amit!" you say, "I don't want to store 3 numbers for coordinates. I don't know how to store a map that way."

### Axial coordinates#

The axial coordinate system, sometimes called “trapezoidal” or “oblique” or “skewed”, is built by taking two of the three coordinates from a cube coordinate system. Since we have a constraint `x + y + z = 0`

, there's some redundancy, and we don't need to store all three coordinates. This diagram is the same as the previous one, except I don't show `y`

:

There are many choices of cube coordinate system, and many choices of axial coordinate system. I'm not going to show all of the combinations in this guide. I've chosen `q`

for "column" = `x`

and `r`

as "row" = `z`

. This choice is arbitary, as you can rotate and flip the diagrams to make many different assignments of ±x,±y,±z to q,r.

The advantage of this system over offset grids is that the algorithms are cleaner when you can use add, subtract, multiply, and divide on hex coordinates. The disadvantage of this system is that storing a rectangular map is a little weird; see the map storage section for ways to handle that. In my projects, I name the axes `q`

, `r`

, `s`

so that I have the constraint `q + r + s = 0`

, and then I can calculate `s = -q - r`

when I need the third coordinate for algorithms that work better with cube coordinates.

### Doubled coordinates#

Although I recommend axial/cube coordinates, if you are sticking to offset coordinates, consider the doubled variant. It makes many of the algorithms easier to implement. Instead of alternation, the doubled coordinates *double* either the horizontal or vertical step size. It has a constraint `(col + row) % 2 == 0`

. In the horizontal (pointy top hex) layout it increases the column by 2 each hex; in the vertical (flat top hex) layout it increases the row by 2 each hex. This allows the in-between values for the hexes that are halfway in between:

I haven't found much information about this system — tri-bit.com called it interlaced^{[5]}, rot.js calls it double width^{[6]}, and this paper^{[7]} calls it rectangular. Other possible names: brick or checkerboard. I'm not sure what to call it. Tamás Kenéz sent me the core algorithms (neighbors, distances, etc.). If you have any references, please send them to me.

### Comparison#

What do I recommend?

Offset | Doubled | Axial | Cube | |
---|---|---|---|---|

Pointy rotation | evenr, oddr | doublewidth | axial | cube |

Flat rotation | evenq, oddq | doubleheight | ||

Other rotations | no | yes | ||

Vector operations (add, subtract, scale) | no | yes | yes | yes |

Array storage | rectangular | no^{*} | rhombus^{*} | no^{*} |

Hash storage | any shape | any shape | ||

Hexagonal symmetry | no | no | no | yes |

Easy algorithms | few | some | most | all |

^{*} rectangular maps require an adapter, shown in the map storage section

My recommendation: if you are only going to use rectangular maps, and never rotate the map, consider the doubled or offset coordinates, as they will line up with your map better than axial or cube. In all other cases, use axial as the primary system, and calculate the third cube coordinate only for those algorithms where cube is easier to work with.

## Coordinate conversion#

It is likely that you will use axial or offset coordinates in your project, but many algorithms are simpler to express in cube coordinates. Therefore you need to be able to convert back and forth.

### Axial coordinates#

### Offset coordinates#

### Doubled coordinates#

function doubleheight_to_cube(hex): var x = hex.col var z = (hex.row - hex.col) / 2 var y = -x-z return Cube(x, y, z) function cube_to_doubleheight(cube): var col = cube.x var row = 2 * cube.z + cube.x return DoubledCoord(col, row) function doublewidth_to_cube(hex): var x = (hex.col - hex.row) / 2 var z = hex.row var y = -x-z return Cube(x, y, z) function cube_to_doublewidth(cube): var col = 2 * cube.x + cube.z var row = cube.z return DoubledCoord(col, row)

It may also be useful to define conversion to/from offset coordinates.

## Neighbors#

Given a hex, which 6 hexes are neighboring it? As you might expect, the answer is simplest with cube coordinates, still pretty simple with axial coordinates, and slightly trickier with offset coordinates. We might also want to calculate the 6 “diagonal” hexes.

### Cube coordinates#

### Axial coordinates#

### Offset coordinates#

With offset coordinates, the change depends on where in the grid we are. If we're on an offset column/row then the rule is different than if we're on a non-offset column/row.

As above, we'll build a table of the numbers we need to add to `col`

and `row`

. However offset coordinates can't be safely added and subtracted. Instead, the results are different for odd and even columns/rows, so we will need two separate lists of neighbors. Look at `(1,1)`

on the grid map above and see how `col`

and `row`

change as you move in each of the six directions. Then do this again for `(2,2)`

. The tables and code are different for each of the four offset grid types, so **pick a grid type** to see the corresponding code.

Using the above lookup tables is the easiest way to to calculate neighbors. It's also possible to derive these numbers, for those of you who are curious.

### Doubled coordinates#

Unlike offset coordinates, the neighbors for doubled coordinates do *not* depend on which column/row we're on. They're the same everywhere, like axial and cube coordinates. Also unlike offset coordinates, we can safely add and subtract doubled coordinates, which makes them easier to work with than offset coordinates.

### Diagonals#

## Distances#

### Cube coordinates#

In the cube coordinate system, each hexagon is a cube in 3d space. Adjacent hexagons are distance 1 apart in the hex grid but distance 2 apart in the cube grid. This makes distances simple. In a square grid, Manhattan distances are `abs(dx) + abs(dy)`

. In a cube grid, Manhattan distances are `abs(dx) + abs(dy) + abs(dz)`

. The distance on a hex grid is half that:

function cube_distance(a, b): return (abs(a.x - b.x) + abs(a.y - b.y) + abs(a.z - b.z)) / 2

An equivalent way to write this is by noting that one of the three coordinates must be the sum of the other two, then picking that one as the distance. You may prefer the “divide by two” form above, or the “max” form here, but they give the same result:

function cube_distance(a, b): return max(abs(a.x - b.x), abs(a.y - b.y), abs(a.z - b.z))

The maximum of the three coordinates is the distance. You can also use the max of ```
abs(dx-dy), abs(dy-dz),
abs(dz-dx)
```

to figure out which of the 6 “wedges” a hex is in; see diagrams here.

Xiangguo Li's paper *Storage and addressing scheme for practical hexagonal image processing.*^{[10]} (DOI^{[11]}) gives a formula for Euclidean distance, which can be adapted to axial coordinates: `sqrt(dq² + dr² + dq*dr)`

.

### Axial coordinates#

In the axial system, the third coordinate is implicit. Let's convert axial to cube to calculate distance:

function hex_distance(a, b): var ac = axial_to_cube(a) var bc = axial_to_cube(b) return cube_distance(ac, bc)

If your compiler inlines `axial_to_cube`

and `cube_distance`

, it will generate this code:

function hex_distance(a, b): return (abs(a.q - b.q) + abs(a.q + a.r - b.q - b.r) + abs(a.r - b.r)) / 2

There are lots of different ways to write hex distance in axial coordinates, but no matter which way you write it, *axial hex distance is derived from the Mahattan distance on cubes*. For example, the “difference of differences” described here^{[12]} results from writing `a.q + a.r - b.q - b.r`

as `a.q - b.q + a.r - b.r`

, and using “max” form instead of the “divide by two” form of `cube_distance`

. They're all equivalent once you see the connection to cube coordinates.

### Offset coordinates#

As with axial coordinates, we'll convert offset coordinates to cube coordinates, then use cube distance.

function offset_distance(a, b): var ac = offset_to_cube(a) var bc = offset_to_cube(b) return cube_distance(ac, bc)

We'll use the same pattern for many of the algorithms: convert hex to cube, run the cube version of the algorithm, and convert any cube results back to hex coordinates (whether axial or offset). There are also more direct formulas for distances; see the rot.js manual^{[13]} for a formula in the "Odd shift" section.

### Doubled coordinates#

Although converting doubled coordinates to cube coordinates works, there's also a direct formula for distances, from the rot.js manual^{[14]}:

function doublewidth_distance(a, b): var dx = abs(a.col - b.col) var dy = abs(a.row - b.row) return dy + max(0, (dx-dy)/2) function doubleheight_distance(a, b): var dx = abs(a.col - b.col) var dy = abs(a.row - b.row) return dx + max(0, (dy−dx)/2)

## Line drawing#

## Movement Range#

### Coordinate range#

Given a hex `center`

and a range N, which hexes are within N steps from it?

We can work backwards from the hex distance formula, `distance = max(abs(x), abs(y), abs(z))`

. To find all hexes within N steps, we need `max(abs(x), abs(y), abs(z)) ≤ N`

. This means we need *all* three to be true: `abs(x) ≤ N`

and `abs(y) ≤ N`

and `abs(z) ≤ N`

. Removing absolute value, we get `-N ≤ x ≤ +N`

and `-N ≤ y ≤ +N`

and `-N ≤ z ≤ +N`

. In code it's a nested loop:

var results = [] for each -N ≤ x ≤ +N: for each -N ≤ y ≤ +N: for each -N ≤ z ≤ +N: if x + y + z = 0: results.append(cube_add(center, Cube(x, y, z)))

This loop will work but it's somewhat inefficient. Of all the values of `z`

we loop over, only one of them actually satisfies the `x + y + z = 0`

constraint on cubes. Instead, let's directly calculate the value of `z`

that satisfies the constraint:

var results = [] for each -N ≤ x ≤ +N: for each max(-N, -x-N) ≤ y ≤ min(+N, -x+N): var z = -x-y results.append(cube_add(center, Cube(x, y, z)))

This loop iterates over exactly the needed coordinates. In the diagram, each range is a pair of lines. Each line is an inequality (a half-plane^{[19]}). We pick all the hexes that satisfy all six inequalities.

### Intersecting ranges#

If you need to find hexes that are in more than one range, you can intersect the ranges before generating a list of hexes.

You can either think of this problem algebraically or geometrically. Algebraically, each hexagonally-shaped region is expressed as inequality constraints of the form `-N ≤ dx ≤ +N`

, and we're going to solve for the intersection of those constraints. Geometrically, each region is a cube in 3D space, and we're going to intersect two cubes in 3D space to form a cuboid^{[20]} in 3D space, then project back to the x + y + z = 0 plane to get hexes. I'm going to solve it algebraically:

First, we rewrite constraint `-N ≤ dx ≤ +N`

into a more general form, `x`

, and set _{min} ≤ x ≤
x_{max}`x`

and _{min} = center.x
- N`x`

. We'll do the same for _{max} = center.x + N`y`

and `z`

, and end up with this generalization of the code from the previous section:

var results = [] for each x_{min}≤ x ≤ x_{max}: for each max(y_{min}, -x-z_{max}) ≤ y ≤ min(y_{max}, -x-z_{min}): var z = -x-y results.append(Cube(x, y, z))

The intersection of two ranges `a ≤ x ≤ b`

and `c ≤ x ≤ d`

is ```
max(a, c) ≤ x ≤ min(b,
d)
```

. Since a hex region is expressed as ranges over x, y, z, we can separately intersect each of the x, y, z ranges then use the nested loop to generate a list of hexes in the intersection. For one hex region we set `x`

and _{min} = H.x - N`x`

and likewise for _{max} = H.x + N`y`

and `z`

. For intersecting two hex regions we set `x`

and _{min} = max(H_{1}.x -
N, H_{2}.x - N)`x`

, and likewise for _{max} =
min(H_{1}.x + N, H_{2}.x + N)`y`

and `z`

. The same pattern works for intersecting three or more regions, and can generalize to other shapes^{[21]} (triangles, trapezoids, rhombuses, non-regular hexagons).

### Obstacles#

If there are obstacles, the simplest thing to do is a distance-limited flood fill (breadth first search). In this diagram, the limit is set to moves. In the code, `fringes[k]`

is an array of all hexes that can be reached in `k`

steps. Each time through the main loop, we expand level `k-1`

into level `k`

. This works equally well with any of the hex coordinate systems (cube, axial, offset, doubled).

function hex_reachable(start, movement): var visited = set() # set of hexes add start to visited var fringes = [] # array of arrays of hexes fringes.append([start]) for each 1 < k ≤ movement: fringes.append([]) for each hex in fringes[k-1]: for each 0 ≤ dir < 6: var neighbor = hex_neighbor(hex, dir) if neighbor not in visited and not blocked: add neighbor to visited fringes[k].append(neighbor) return visited

## Rotation#

Given a hex vector (difference between one hex and another), we might want to rotate it to point to a different hex. This is simple with cube coordinates if we stick with rotations of 1/6th of a circle.

A rotation 60° right shoves each coordinate one slot to the right:

[ x, y, z] to [-z, -x, -y] to [y, z, x]

A rotation 60° left shoves each coordinate one slot to the left:

[ x, y, z] to [-y, -z, -x] to [ z, x, y]

As you play with diagram, notice that each 60° rotation *flips* the signs and also physically “rotates” the coordinates. Take a look at the axis legend on the bottom left to see how this works. After a 120° rotation the signs are flipped back to where they were. A 180° rotation flips the signs but the coordinates have rotated back to where they originally were.

Here's the full recipe for rotating a position P around a center position C to result in a new position R:

- Convert positions P and C to cube coordinates.
- Calculate a vector by subtracting the center:
`P_from_C = P - C = Cube(P.x - C.x, P.y - C.y, P.z - C.z)`

. - Rotate the vector
`P_from_C`

as described above, and call the resulting vector`R_from_C`

. - Convert the vector back to a position by adding the center:
`R = R_from_C + C = Cube(R_from_C.x + C.x, R_from_C.y + C.y, R_from_C.z + C.z)`

. - Convert the cube position R back to to your preferred coordinate system.

It's several conversion steps but each step is simple. You can shortcut some of these steps by defining rotation directly on axial coordinates, but hex vectors don't work for offset coordinates and I don't know a shortcut for offset coordinates. Also see this stackexchange discussion^{[22]} for other ways to calculate rotation.

## Rings#

### Single ring#

To find out whether a given hex is on a ring of a given `radius`

, calculate the distance from that hex to the center and see if it's `radius`

. To get a list of all such hexes, take `radius`

steps away from the center, then follow the rotated vectors in a path around the ring.

function cube_ring(center, radius): var results = [] # this code doesn't work for radius == 0; can you see why? var cube = cube_add(center, cube_scale(cube_direction(4), radius)) for each 0 ≤ i < 6: for each 0 ≤ j < radius: results.append(cube) cube = cube_neighbor(cube, i) return results

In this code, `cube`

starts out on the ring, shown by the large arrow from the center to the corner in the diagram. I chose corner 4 to start with because it lines up the way my direction numbers work but you may need a different starting corner. At each step of the inner loop, `cube`

moves one hex along the ring. After `6 * radius`

steps it ends up back where it started.

The scale, add, and neighbor operations also work on axial and doubled coordinates, so the same algorithm can be used. For offset coordinates, convert to one of the other formats, generate the ring, and convert back.

### Spiral rings#

Traversing the rings one by one in a spiral pattern, we can fill in the interior:

function cube_spiral(center, radius): var results = [center] for each 1 ≤ k ≤ radius: results = results + cube_ring(center, k) return results

The area of the larger hexagon will be the sum of the circumferences, plus 1 for the center; use this formula^{[23]} to help you calculate the area.

Visiting the hexes this way can also be used to calculate movement range.

## Field of view#

Given a location and a distance, what is visible from that location, not blocked by obstacles? The simplest way to do this is to draw a line to every hex that's in range. If the line doesn't hit any walls, then you can see the hex. Mouse over a hex to see the line being drawn to that hex, and which walls it hits.

This algorithm can be slow for large areas but it's so easy to implement that it's what I recommend starting with.

There are many different ways to define what's "visible". Do you want to be able to see the center of the other hex from the center of the starting hex? Do you want to see any part of the other hex from the center of the starting point? Maybe any part of the other hex from any part of the starting point? Are there obstacles that occupy less than a complete hex? Field of view turns out to be trickier and more varied than it might seem at first. Start with the simplest algorithm, but expect that it may not compute exactly the answer you want for your project. There are even situations where the simple algorithm produces results that are illogical.

Clark Verbrugge's guide^{[24]} describes a “start at center and move outwards” algorithm to calculate field of view. Also see the Duelo^{[25]} project, which has an an online demo of directional field of view^{[26]} and code on Github. Also see my article on 2d visibility calculation for an algorithm that works on polygons, including hexagons. For grids, the roguelike community has a nice set of algorithms for square grids (see this^{[27]} and this^{[28]} and this^{[29]}); some of them might be adapted for hex grids.

## Hex to pixel#

For hex to pixel, it's useful to review the size and spacing diagram at the top of the page.

### Axial coordinates#

### Offset coordinates#

### Doubled coordinates#

Doubled makes many algorithms simpler than offset.

function doublewidth_to_pixel(hex): var x = size * sqrt(3)/2 * hex.col var y = size * 3/2 * hex.row return Point(x, y) function doubleheight_to_pixel(hex): var x = size * 3/2 * hex.col var y = size * sqrt(3)/2 * hex.row return Point(x, y)

## Pixel to Hex#

## Rounding to nearest hex#

Sometimes we'll end up with a *floating-point* cube coordinate `(x, y, z)`

, and we'll want to know which hex it should be in. This comes up in line drawing and pixel to hex. Converting a floating point value to an integer value is called *rounding* so I call this algorithm `cube_round`

.

With cube coordinates, `x + y + z = 0`

, even with floating point cube coordinates. So let's round each component to the nearest integer, `(rx, ry, rz)`

. However, although `x + y + z = 0`

, after rounding we do *not* have a guarantee that `rx + ry + rz = 0`

. So we *reset* the component with the largest change back to what the constraint `rx + ry + rz = 0`

requires. For example, if the y-change `abs(ry-y)`

is larger than `abs(rx-x)`

and `abs(rz-z)`

, then we reset `ry = -rx-rz`

. This guarantees that `rx + ry + rz = 0`

. Here's the algorithm:

function cube_round(cube): var rx = round(cube.x) var ry = round(cube.y) var rz = round(cube.z) var x_diff = abs(rx - cube.x) var y_diff = abs(ry - cube.y) var z_diff = abs(rz - cube.z) if x_diff > y_diff and x_diff > z_diff: rx = -ry-rz else if y_diff > z_diff: ry = -rx-rz else: rz = -rx-ry return Cube(rx, ry, rz)

For non-cube coordinates, the simplest thing to do is to convert to cube coordinates, use the rounding algorithm, then convert back:

function hex_round(hex): return cube_to_axial(cube_round(axial_to_cube(hex)))

The same would work if you have `oddr`

, `evenr`

, `oddq`

, or `evenq`

instead of `axial`

.

Implementation note: `cube_round`

and `hex_round`

take *float* coordinates instead of *int* coordinates. If you've written a Cube and Hex class, they'll work fine in dynamically typed languages where you can pass in floats instead of ints, and they'll also work fine in statically typed languages with a unified number type. However, in most statically typed languages, you'll need a separate class/struct type for float coordinates, and `cube_round`

will have type `FloatCube → Cube`

. If you also need `hex_round`

, it will be `FloatHex → Hex`

, using helper function `floatcube_to_floathex`

instead of `cube_to_hex`

. In languages with parameterized types (C++, Haskell, etc.) you might define `Cube<T>`

where `T`

is either `int`

or `float`

. Alternatively, you could write `cube_round`

to take three floats as inputs instead of defining a new type just for this function.

Patrick Surry has a visualization showing why the rounding algorithm works^{[32]}.

## Map storage in axial coordinates#

One of the common complaints about the axial coordinate system is that it leads to wasted space when using a rectangular map; that's one reason to favor an offset coordinate system. However all the hex coordinate systems lead to wasted space when using a triangular or hexagonal map. We can use the same strategies for storing all of them.

Notice in the diagram that the wasted space is on the left and right sides of each row (except for rhombus maps) This gives us three strategies for storing the map:

- Use a
**2D Array**. Use nulls or some other sentinel at the unused spaces. Store`Hex(q, r)`

at`array[r][q]`

. At most there's a factor of two for these common shapes; it may not be worth using a more complicated solution. - Use a
**hash table**instead of dense array. This allows arbitrarily shaped maps, including ones with holes. Store`Hex(q, r)`

in`hash_table(hash(q,r))`

. - Use an
**array of arrays**by sliding row to the left, and shrinking the rows to the minimum size. For pointy-topped hexes, store`Hex(q, r)`

in`array[r - first_row][q - first_column(r)]`

. Some examples for the map shapes above:**Rectangle**. Store`Hex(q, r)`

at`array[r][q + floor(r/2)]`

. Each row has the same length. This is equivalent to odd-r offset.**Hexagon**. Store`Hex(q, r)`

at`array[r][q - max(0, N-r)]`

. Row r size is`2*N+1 - abs(N-r)`

.**Rhombus**. Conveniently,`first_row`

and`first_column(r)`

are both 0. Store`Hex(q, r)`

at`array[r][q]`

. All rows are the same length.**Down-triangle**. Store`Hex(q, r)`

at`array[r][q]`

. Row r has size`N+1-r`

.**Up-triangle**. Store`Hex(q, r)`

at`array[r][q - N+1+r]`

. Row r has size`1+r`

.

`array[q - first_column][r - first_row(q)]`

.

Encapsulate access into the getter/setter in a map class so that the rest of the game doesn't need to know about the map storage. Your maps may not look exactly like these, so you will have to adapt one of these approaches.

## Wraparound maps#

In some games you want the map to “wrap” around the edges. In a square map, you can either wrap around the x-axis only (roughly corresponding to a sphere) or both x- and y-axes (roughly corresponding to a torus). Wraparound depends on the map shape, not the tile shape. To wrap around a rectangular map is easy with offset coordinates. I'll show how to wrap around a hexagon-shaped map with cube coordinates.

Corresponding to the center of the map, there are six “mirror” centers. When you go off the map, you subtract the mirror center closest to you until you are back on the main map. In the diagram, try exiting the center map, and watch one of the mirrors enter the map on the opposite side.

The simplest implementation is to precompute the answers. Make a lookup table storing, for each hex just off the map, the corresponding cube on the other side. For each of the six mirror centers `M`

, and each of the locations on the map `L`

, store `mirror_table[cube_add(M, L)] = L`

. Then any time you calculate a hex that's in the mirror table, replace it by the unmirrored version. See stackoverflow^{[33]} for another approach.

For a hexagonal shaped map with radius `N`

, the mirror centers will be `Cube(2*N+1, -N, -N-1)`

and its six rotations.

Related: Sander Evers has a nice explanation of how to combine small hexagons into a grid of large hexagons^{[34]} and also a coordinate system to represent small hexagons within a larger one^{[35]}.

## Pathfinding#

If you're using graph-based pathfinding such as A* or Dijkstra's algorithm or Floyd-Warshall, pathfinding on hex grids isn't different from pathfinding on square grids. The explanations and code from my pathfinding tutorial^{[36]} will work equally well on hexagonal grids.

Mouse overTouch a hex in the diagram to see the path to it. Click or drag to toggle walls.

**Neighbors**. The sample code I provide in the pathfinding tutorial calls`graph.neighbors`

to get the neighbors of a location. Use the function in the neighbors section for this. Filter out the neighbors that are impassable.**Heuristic**. The sample code for A* uses a`heuristic`

function that gives a distance between two locations. Use the distance formula, scaled to match the movement costs. For example if your movement cost is 5 per hex, then multiply the distance by 5.

## More#

I have an **guide to implementing your own hex grid library**, including sample code in C++, Java, C#, Javascript, Haxe, and Python.

- The best early guide I saw to the axial coordinate system was Clark Verbrugge's guide
^{[37]}, written in 1996. - The first time I saw the cube coordinate system was from Charles Fu's posting to rec.games.programmer
^{[38]}in 1994. - DevMag has a nice visual overview of hex math
^{[39]}including how to represent areas such as half-planes, triangles, and quadrangles. There's a PDF version here^{[40]}that goes into more detail.**Highly recommended**! The GameLogic Grids^{[41]}library implements these and many other grid types in Unity. - In my Guide to Grids
^{[42]}, I cover axial coordinate systems to address square, triangle, and hexagon sides and corners, and algorithms for the relationships among tiles, sides, and corners. I also show how square and hex grids are related. - James McNeill has a nice visual explanation of grid transformations
^{[43]}. - Overview of hex coordinate types
^{[44]}: staggered (offset), interlaced, 3d (cube), and trapezoidal (axial). - The Rot.js library
^{[45]}has a list of hex coordinate systems: non-orthogonal (axial), odd shift (offset), double width (interlaced), cube. - Range for cube coordinates
^{[46]}: given a distance, which hexagons are that distance from the given one? - Distances on hex grids
^{[47]}using cube coordinates, and reasons to use cube coordinates instead of offset. - Convert cube hex coordinates to pixel coordinates
^{[48]}. - This thread
^{[49]}explains how to generate rings. - The HexPart
^{[50]}system uses both hexes and rectangles to make some of the algorithms easier to work with. - Are there pros and cons of “pointy topped” and “flat topped” hexagons
^{[51]}? - Line of sight in a hex grid
^{[52]}with offset coordinates, splitting hexes into triangles - Hexnet explains how the correspondence between hexagons and cubes
^{[53]}goes much deeper than what I described on this page, generalizing to higher dimensions. - I used the PDF hex grids from this page
^{[54]}while working out some of the algorithms. - Generalized Balanced Ternary for hex coordinates
^{[55]}seems interesting; I haven't studied it. - Hexagonal Image Processing
^{[56]}(DOI^{[57]}) is an entire book that uses a hierarchical hexagonal coordinate system. - Hex-Grid Utilities
^{[58]}is a C# library for hex grid math, with neighbors, grids, range finding, path finding, field of view. Open source, MIT license. - This is the oldest reference I can find for axial grids: Luczak, E. and Rosenfeld, A.,
*Distance on a Hexagonal Grid*. IEEE Transactions on Computers (1976) (DOI^{[59]}) It calls the axial system*oblique coordinates*and the offset systems*pseudohexagonal grids*. - Snyder, Qi, Sander's paper
*Coordinate system for hexagonal pixels*(DOI^{[60]}) describes gradients, diffusion, and map storage for axial coordinates. Mersereau's paper*The processing of hexagonally sampled two-dimensional signals*(DOI^{[61]}) describes signal processing on axial coordinates. - There's a paper that calls cube coordinates
**R3 coordinates*: Her, I.,*Geometric transformations on the hexagonal grid*, IEEE Transactions on Image Processing (1995) (DOI^{[62]}) It covers coordinates, correspondence to cube coordinates, rounding, reflections, scaling, shearing, and rotation. A paper from the same author (DOI^{[63]}) covers distances. - The Reddit discussion
^{[64]}and Hacker News discussion^{[65]}and MetaFilter discussion^{[66]}have more comments and links.

The code that powers this page is partially procedurally generated! The core algorithms are in lib.js, generated from my guide to implementation. There are a few more algorithms in hex-algorithms.js. The interactive diagrams are in diagrams.js and index.js, using Vue.js to inject into the templates in index.bxml (xhtml I feed into a preprocessor).

There are more things I want to do for this guide. I'm keeping a list on Trello^{[67]}. Do you have suggestions for things to change or add? Comment below.