There's a little project I'm pencilling on a pad at the moment which is currently a nice 2D grid, but which I think may work better as a hextile grid. There's a couple of ways of storing a hextile map, but is there an absolutely one-for-all correct way of approaching it?
A* pathfinding is going to happen on it, which I can also see the way to do (in my head, not pencilled that part just yet). Does this affect how I should think about it?
I have to admit, after years and years of pure XY 2D grid thinking, I'm facing a little bit of a mental block.
Internally, an hexgrid is nothing but a square grid that you can move in a restricted set of directions. (edit: my mistake)
It's really when you draw it on the screen that there's a difference.
I have never liked any hextile games so I can't really say but there must be some info on this somewhere.
I would assume the proper way is to treat them as actual 2d polygons but you could also simplify the maths using a square grid and then some maths to 'cut' the current square up, as gosse suggested.
These links should rock your world:
http://www.gamedev.net/reference/articles/article747.asphttp://www.gamedev.net/reference/articles/article748.aspand there's a ton of more links here:
http://www.gamedev.net/reference/list.asp?categoryid=44#198If you need a book, try Isometric Game Programming with DirectX 7.0, by Ernest Pazera
ISBN: 0-7615-3089-4
Be aware that some things, like checking line-of-sight, has some inherent problems when you use hexes.
If you haven't been here yet, you should:
http://www-cs-students.stanford.edu/~amitp/gameprog.html#hex Thanks guys. I've bookmarked those links and had a quick look through. Some useful and interesting stuff.