Hexagonal Tle Mapboard Mathematics and Calculations

For those who want to develop historical strategy simulations with Monogame using hexagonal tile map-boards, I have found an excellent resource to help you get started with some of the mathematical calculations required to determine which hex tile has been selected on the map.

You may review the article and download the working code from the link below…


Please note that this piece does not include calculations for scrolling map boards.

Please also note that I will be publishing a short piece on my own TECH NOTES site in the next week or so, which demonstrates how to use a mouse for scrolling a tiled map board in all four directions. This will not demonstrate the use of scroll-bars since they seem to be rather difficult to implement and most such games do not appear to be using them anymore.due to their difficulties in implementation.

If anyone has any questions or wants to discuss such development with me, I can be reached at blackfalconsoftware@outlook.com (Steve)

I am senior software engineer with the .NET development environment and can help you with C#, VB.NET, and database implementations.

I did all of this stuff and probably more in xna. If you need help just ask.

The below is actually a zoomed out hexmap.


1 Like


Thank you very much for your offer.

You should write a book on your work with hexagonal maps. There is such a lack of information on this work that even after all these years, developing strategy simulations is still very much a “black art” that needs some good documentation for those that are interested in such game development.

This is why I am offering all of my work on this forum. It is not as advanced as your work clearly is but at least it is something… :slight_smile:

Hex maps in general can be treated very similarly to regular grid maps in most cases. Though this might not be obvious at first. To make this a little more obvious consider simply taking a grid and moving every odd column up by 1/2 of a grids height. Moving these back down essentially makes it a grid again.

Numbering these in grid space with a single number 0 , 1 , 2 , 3 ect… from left to right top down then turning it back into hex map space is akin to 1d array that represents a 2d image.
This shows that essentially you can simply convert from one system to the other at will to use most formulas. Only when traversing on a hex by hex basis must you apply special rules for movement depending on if you begin on a odd or even location. Simply moving in X +1 is moving up then down in y over odd even as you move right that repeats over and over.
Finding a position a (x , y) index from a 1d representation or the reverse in grid space then becomes fairly trivial. To say just consider the non overlapping parts of a hexmap as a grid.

I found that the more difficult part is mapping using actual adjoining tiles.

I did write a little bit about the use of logically ordered tiles in a sprite-sheet which i call tilesets in the second post on this site here long ago. http://www.panzercentral.com/forum/viewtopic.php?f=132&t=48705&p=702379#p702379 Though its a bit specific to a game. It might be interesting to glance over.


Thank you again for your informative response. I apologize for not responding sooner but I have been very busy in the past two weeks rebuilding two machines, which have taken a lot of effort.

I believe I have already implemented a bit of what you are suggesting as it regards hexagonal tile offsets. Nonetheless, I am already working on the set of algorithms to determine the selection of a specific hexagonal tile. Should begin testing these routines in the next day or so.

I believe the code-base I am using for the basis of these routines also has algorithms for determining the neighbors to a specific hex tile but I will have to research this code further.

However, before I get into developing these complexities I am need to spend a little time with refactoring my code into a simpler and easier to understand hierarchy… :slight_smile: