Previous posts on this topic:

* * *

It took me a while of contemplating a Robik’s cube and thinking about 3D coordinates before I came across a system of cell/tile notation that would fit my purposes. So, here is the story.

Two orthogonal axes are not good for hexagonal cells, because cell coordinates will not be integer numbers (look at figure 1).

Figure 1. Orthogonal coordinates

Two non-orthogonal axes can have integer number coordinates, like in figure 2, but calculating distances between cells is not straight-forward, so they are not good either.

Figure 2. Two non-orthogonal coordinates

If two coordinates don’t do, then what? Three coordinates???

First consideration. A square belongs to a vertical file and a horizontal file, which is exactly why Cartesian coordinates perfectly fit for both easy numbering and easy distance calculation. A hexagon belongs to three files at the same time: a horizontal file (from “West” to “East”), a file going from NNE to SSW, and a file going from NNW to SSE. Thus, one could pick a cell, number it (0;0;0), and number all other cells depending on how many files to, say, South, ENE and WNW they are with respect to the origin.

Figure 3. Three coordinates

I’ll try to add a better illustration and a bit of explanation later. So far, I want to mention two important things:

  • Somehow the values of all three coordinates always sum up to 0. This sounds strange and irrelevant, but it has an explanation and it has important implications.
  • There are both positive and negative values. Negative values are a bit annoying and look unnatural.
  • The distance between any two cells is calculated by formula \sqrt{(x_1 - x_0)^2 + (y_1-y_0)^2 + (z_1-z_0)^2}. The distance between two adjacent cells is equal to \sqrt{2}, but we can always normalise it by dividing to formula above by this number.

So far, we obtained a nice system of coordinates where (1) all cells are numbered using three integers, and (2) all distances are calculated by the same formula irrespective of the direction. The last thing I wanted to do was to get rid of negative numbers.

I recalled reading somewhere that a hexagon can be thought of as a projection of a cube on a plane. This way, we can think of hex grid as a Rubik’s cube made of many little cubes. Because the tiles of our grid do not overlap we need to take only those small cubes that lay in the same plane, i.e. laying edge to edge to each other. This plane crosses the faces of the big cube (Rubik’s cube, the grid in 3D) at 45 degrees and thus can be described by a simple equation x + y + z = a, where ‘a’ is some constant. If a = 0 we have the system of coordinates described above. We need to take ‘a’ large enough to make all values within our grid positive, but not unnecessarily too large. ‘a’ is deternimed very simply: count all files (1) from N to S, (2) from ENE to WSW, and (3) from WNW to ESE, then pick up the largest of the three. Done.

Preliminarily, the grid itself will represent a large hexagon, with one side equal to 32 cells. This means there will be 63 files in any direction. So all values of coordinates will be comprised between 0 and 63.

* * *

Followup posts on the game progress:

Leave a Reply