Curious About Hex Numbering System

I'm not complaining, but I am curious as to the odd or even numbering in labelled hexagons. Is this a standard in hexagon systems on computer games and/or board games? I haven't played any Avalon Hill board wargames since the early 90s and a couple of decades before that for SPI, so I can't recall the hex numbering systems used in those games. When I used to make maps on hex paper for my D&D campaigns, I would use all numbers.  For example, A1, A2, A3, A4, A5, etc and B1, B2, B3, B4, B5, etc.  I found this easy as players could just count.  Counting by 2s for even numbers is easy, but I don't think it comes as naturally for odd numbers. Again, not complaining, I'm just curious as to why this convention was chosen.  Any comments would be appreciated.

That is pretty weird. I'd never had numbering on when using hexes so hadnt noticed this, but now i have, I am wondering why they'd choose this scheme too.

It has to do with the programming behind placing objects onto the map. Treat a&b as though they were the same row of a two dimensional array and it makes more sense. Article on the topic here . Similarly if you rotate the grid then it's every two columns that get treated as the same row in an array. Also consider the numbers in the hexes could instead be placed along the frame of the map, as is done in many road maps or atlases if there were two "1" columns it could be more confusing. Where column "2" is clearly between "1 & 3" and on odd lettered rows would fall between two hexes.

That's interesting. I would have thought thought that this shouldnt need to be exposed to the user? You can build the two dimensional array behind the scenes, and then should be able to have another calculation to create an array of hex names that is visible on the map.  They know how long the columns are so this should be fairly trivial. 

Seb_Romu said: It has to do with the programming behind placing objects onto the map. Treat a&b as though they were the same row of a two dimensional array and it makes more sense. Article on the topic here . Similarly if you rotate the grid then it's every two columns that get treated as the same row in an array. Also consider the numbers in the hexes could instead be placed along the frame of the map, as is done in many road maps or atlases if there were two "1" columns it could be more confusing. Where column "2" is clearly between "1 & 3" and on odd lettered rows would fall between two hexes. Thanks, Seb. I'm actually familiar with a lot of Clark Verbugge's work because in the early 2000s, I spent some time developing a wargames campaign manager which used offset squares instead of polygons.  I found Clark's articles on selecting areas of effect and other exercises with hexes to be very,very helpful back then when I was writing code.  While not exactly the same as hexagons, offset squares have a similar effect, albeit with some limitations.  For example, the longer the radius, the less an area of effect looked like a circle - it became more of a diamond. :) Thanks for your reply.

GiGs said: That's interesting. I would have thought thought that this shouldnt need to be exposed to the user? You can build the two dimensional array behind the scenes, and then should be able to have another calculation to create an array of hex names that is visible on the map.  They know how long the columns are so this should be fairly trivial.  Well, I'm glad I'm not the only one who finds it odd.  :)  I'm with you in what you say above, but I'm OK either way.  I'm not 100% I'll need to have the hex number on, but if so, I'll make sure the players know. Take care.