I have been using @amitp's excellent guide (and javascript library) to create a hexagonal grid system https://www.redblobgames.com/grids/hexagons/. I'm using flat-top, inverse-y cubic/axial system. However, I have elements that are located on the vertices, rather than "within" a tile. How would I refer to their position? I have considered using the index of the corner, but then the question is which tile do I use as my base? I would also like to extend the concept so that I could precisely position an element anywhere within a tile. I am thinking of something relating to the Ordnance Survey's method of sub-division within the British National Grid (OSGB 1936) but I cannot get my head around how this relates to a cubic/axial coordinate system.

  • 1
    \$\begingroup\$ Maybe not the most elegant way, but if you refer the coordinate as a tripled of the 3 tiles, you dont have the problem of deciding which one is the base tile and you always can refer to the corner. For the side you just need to refer two tiles, for within a single tile with the offset \$\endgroup\$
    – Zibelas
    Feb 13 '20 at 9:28
  • 1
    \$\begingroup\$ An interesting idea but effectively that results in a fairly complex and inconsistent data storage: [q,r,s] for centre of tile; [[q,r,s],[q,r,s]] for edge; [[q,r,s],[q,r,s],[q,r,s]] for vertex. And I'm still none the wise how to do the offset within a tile. And as for calculating distances between these... \$\endgroup\$ Feb 13 '20 at 9:54
  • \$\begingroup\$ Possible duplicate: gamedev.stackexchange.com/questions/167628/… \$\endgroup\$
    – Max
    Feb 13 '20 at 21:15

Only regarding your first question

but then the question is which tile do I use as my base?

ANY as long as you use a consistent scheme. For example ALWAYS find the leftmost tile (you need phantom extra ones for the edge of your map), and then (if applicable) the topmost of the two possible ones.

And then you only have one line (with a bent) on which to place any objects


An answer depends on a couple of facts: Can your elements only rest on vertices? If not can they move from a vertex of a hex to the center of that hex?

My first thought on this question was to set each vertex's coordinates to the average of the coordinates of the 3 hex' surrounding it, for instance, if a unit was on the vertex between the three tiles [0, 0], [0, -1] and [+1, -1] it would have the coordinate [0.5, -1].

But this results in two issues: one the vertex coordinates aren't unique when compared to the hex coordinates (There is a [-2, +1] tile and its rightmost vertex is also [-2, +1]) and two, referring back to my questions, if the elements can move from vertices to hex center's then when working out the distance becomes weird. Basically the distance from a vertex to an adjacent vertex is 1, from a vertex to one of the connected hexes' centers is also 1 and from a vertex to another vertex that is 2 vertices away (i.e. with flat top hexes from the left most vertex to the top right vertex) is a distance of 1.5 .

In other words the distance from hex to hex becomes equal to that from vertex to vertex with a couple twists.

Hopefully this helps, if you need images to show what I'm describing I can create them but I would rather wait for you to ask for them first.

  • 2
    \$\begingroup\$ While exploring other questions I came across this link also on @amitp 's bog. If you scroll down to Hexagon Grids he gives an example of a hexagonal coordinate system with vertices \$\endgroup\$
    – Ironcanon
    Feb 14 '20 at 12:45
  • \$\begingroup\$ Isn't the average in your first example (⅓, -⅔), not (0.5, -1)? If you calculate it this way, the coordinates are indeed unique at the vertices, and the distances are actually uniform. I think the technique shown at the link you shared would be worth summarizing in an answer. \$\endgroup\$
    – DMGregory
    Jul 13 '20 at 10:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.