2010

# Hexgrid coordinates

Blue Max and my own game, Momentum, are both played on a hex grid. Working with a hex grid raises some problems not present in a square grid, not the least of which is how do you identify a particular hex in the grid when they do not line up neatly into rows and columns.

The coordinates I use in Blue Max is a three axis system. Each axis runs through the centers of opposite sides of the hexagon. The positive directions of each axis are adjacent. On a clock face the positive axis directions are found at 12, 2 and 4. The negative axis run in the opposite direction at 6, 8 and 10.

Coordinates are then represented by a set of three numbers, one for each axis. I write these coordinates in square brackets as that is the syntax for arrays in both Javascript and PHP, my scripting languages of choice.

When you start assigning coordinates to a hex grid in this system you soon discover the same hex can be represented with more than one set of coordinates. For example [1,0,1] is the same as [0,1,0].

The later of those two coordinates is the simpler, it involves one direction and less movement. Reducing a set of coordinates to its simplest state is called*normalisation*.

By using three coordinates to represent six directions there is some normalisation to start with. The next step of normalisation is to take travel in non-adjacent directions and convert it to travel in the direction between the two. In the above example travel in the X and Z directions is converted to travel in the Y direction. If the two non-adjacent directions are not equal convert as much as possible and leave the rest – effectively reducing one of the non-adjacent coordinates to zero.

In the end a normalised coordinate can contain at most two non-zero values, and those two values must be for adjacent directions.

When coordinates are normalised in this way hexes have one unique coordinate each.

This is the system I am use in Blue Max. I have implemented a series of functions for it in Javascript as a jQuery plugin and in PHP.

**Pros**

- This coordinate system works well for getting the distance and direction between two discrete hexes.

**Cons**

- Coordinates are not easily human readable.
- Areas of hexes cannot be easily described.
- There are “holes” in the coordinate system – not all combinations of coordinates are valid.

### An alternate 2 coordinate system

This system uses two of the three directions described above. For the ease of conversion between the systems directions X and Y are used. This coordinate system places all hexes on two oblique axises.

To convert from two to three coordinates, a Z value of zero is added.

[1,2] = [1,2,0]

The resulting three coordinates would then need to be normalised as described above.

To convert three coordinates to two coordinates the Z value needs to be converted to an X,Y equivalent. In this case:

[0,0,1] = [-1,1]

[0,0,-1] = [1,-1]

So

[0,1,2] = [(0-2), (1+2)] = [-2,3]

**Pros**

- Coordinates are normalised by their very nature, there can be no ambiguity.
- All coordinate combinations are valid, there are no holes.

**Cons**

- Because of the oblique axises of the system two hexes can be closer together or further apart then a simple inspection of their coordinates would imply.

hey dude!

Hope ya had a good new year. I like this idea about how to do hex games on a computer database. I was wondering how you and youplay.it did this. Eacing would be handled in a like fashion I take it?

Racing could be handled. One of the advantages of Blue Max is that there is no collisions with terrain or other planes. In a racing game you would have to test for both. Why do you ask? Do you have a game idea?

A long, long time ago I was working on a BattleTech-ish game, and ran across the same problem. I decided on the 2 axis approach, and never did get around to writing all the code. Glad to see I was on the right track. Thanks for the explanation.

Actually I ment facing. What direction the place was going. There used to be an old Avalon Hill game about Formula One racing but I never played it. So i really cant say much about it. While I’m learning to program and have played lots of games I never got into the idea of creating a game. I’ll help but I’m getting th impression you’re over my head. 🙂

Very interesting. Can’t help thinking you’d be better off using the second system since…

a) It can be easily explained and understood by people, especially since it’s just a non-rectangular version of x and y cartesian co-ordinates that most people have used at school. Very intuitive system.

b) No awkward verification of valid hexes would be needed.

c) A height axis could be easily introduced with 3 axes for 3 dimensions as most people would expect.

d) You said yourself, “Areas of hexes cannot be easily described” for the first system. Not so for the second.

In short, with the second system coding would be much simpler and easier to ‘jiggle’ if you need to change the rules, say to check for proximity for some reason. So much so I wonder if perhaps you chose the first as it was a more interesting and challenging problem. But these are often the kind of problems that never get solved in a timely fashion…