Representing a Hex Map
Author
I''m sure a lot of you have built games where you have a hexagonal map before, I was wondering what you found to be the best way to represent it when programming?
As far as I can tell there are two options:
1) Use a "tile" object to represent each hex tile, it will have pointers to the tile adjacent to it (You could probably also get away without pointers by using an array).
2) Use a "square" grid to approximate the hex grid.
I can see pros and cons to both ways. The application I have in mind is a turn based game, so it doesn''t have to be lightning quick - but I''d rather have as fast an implementation as possible within reason. I guess it should be fairly easy to deal with...
So any suggestions? Past experiences? Thanks!
- FlanMan
I''d use a regular square grid, but visualise it sheared to one side.
Helpful links:
How To Ask Questions The Smart Way | Google can help with your question | Search MSDN for help with standard C or Windows functions
Helpful links:
How To Ask Questions The Smart Way | Google can help with your question | Search MSDN for help with standard C or Windows functions
It all depends on how much you want to spend on making this game better. Implementing a hexagon grid will take a lot more programming than a square-shaped grid, with a questionable amount of improvement to the gameplay. If you ARE going to use a hex grid, go whole hog and store the tiles as hexagons, rather than approximating hexagons with squares. Since your program is turn-based, there is almost nothing you could do that would ever noticably slow the game down, since you don''t have to process a screen-full of graphics every 40th of a second.
However, siaspete has a good suggestion also - you could just go with a grid of squares and then draw them skewed (as parallelograms) on the screen - this means a lot less coding for you, but it still looks sort of "3d-like". You would just store tile info in probably a 2d memory array, then access that array every time you draw to the screen.
Twilight Dragon
Win32 API Programmer
www.freewebz.com/j-world
However, siaspete has a good suggestion also - you could just go with a grid of squares and then draw them skewed (as parallelograms) on the screen - this means a lot less coding for you, but it still looks sort of "3d-like". You would just store tile info in probably a 2d memory array, then access that array every time you draw to the screen.
Twilight Dragon
Win32 API Programmer
www.freewebz.com/j-world
TDragon: you''re missing the point.
He didn''t asked if he should make the game hex or square grid based, nor the way to draw it!
He is going to make a hex tile based game and asked how to represent this grid of tiles in the program. Nothing graphical.
FlanMan:
I''ve never worked with hex-tile based stuff, but i think a square array will be easier to manage than representing each tile as an object with neighbours.
With the array, you can access everything more directly, easier and i find it personally easier to represent and to work with.
It''s maybe also because i don''t really understand how you would manage tiles as objects with pointers to it''s neighbours. Easy things like finding distances between tiles can become complex: how do you find out the distance, the right path? (the tiles doesn''t know the direction their are from each other, and there are nearly unlimited ways to reach 2 tiles)
cheers
He didn''t asked if he should make the game hex or square grid based, nor the way to draw it!
He is going to make a hex tile based game and asked how to represent this grid of tiles in the program. Nothing graphical.
FlanMan:
I''ve never worked with hex-tile based stuff, but i think a square array will be easier to manage than representing each tile as an object with neighbours.
With the array, you can access everything more directly, easier and i find it personally easier to represent and to work with.
It''s maybe also because i don''t really understand how you would manage tiles as objects with pointers to it''s neighbours. Easy things like finding distances between tiles can become complex: how do you find out the distance, the right path? (the tiles doesn''t know the direction their are from each other, and there are nearly unlimited ways to reach 2 tiles)
cheers
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
