🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Why choose square tiles and not hex ones?
If you examine AOE/K, you''ll see that they actually do use hex to determine unit movement on square tiles.
Okay, we''ll assume that your tiles are discrete, that is you can''t be partially in one tile and partially in another.
Diamond isometric tiles are the same as squares, from a functional point of view. Implementing is a bit tricky, but there''s lots of help for that.
So, the differences. First, consider a fireball that affects a two space radius. If you''re using squares, you have to decide if you count the two spaces as cardinal direction steps, or try to work out an equation, or just affect everything even two diagonal spaces away. Each of these choices gives you a different shape, none of which much resemble a circle. Hexes, on the other hand, require no decision, and no computing. The hexes form concentric rings, which approximate circles a lot better than you can manage with squares.
On the other hand, hexes involve 60 degree angles. Most stuff in life comes in 90 degree angles, at least to a human way of thinking. It''s hard to reconcile these cleanly. If you have two roads, one going north-south, and the other east-west, one of them will either cut across the tiles, sometimes in the middle of a tile, sometimes on an edge, or else the road will have to zigzag NE, SE, NE, SE, etc. which doesn''t look natural.
One idea I''d had is to make a hex based game, but design the artwork such that things are built with six directions in mind, six sides to a building, roads come to 6-way interections, (Well, three more usually, but still..) and so forth...
Diamond isometric tiles are the same as squares, from a functional point of view. Implementing is a bit tricky, but there''s lots of help for that.
So, the differences. First, consider a fireball that affects a two space radius. If you''re using squares, you have to decide if you count the two spaces as cardinal direction steps, or try to work out an equation, or just affect everything even two diagonal spaces away. Each of these choices gives you a different shape, none of which much resemble a circle. Hexes, on the other hand, require no decision, and no computing. The hexes form concentric rings, which approximate circles a lot better than you can manage with squares.
On the other hand, hexes involve 60 degree angles. Most stuff in life comes in 90 degree angles, at least to a human way of thinking. It''s hard to reconcile these cleanly. If you have two roads, one going north-south, and the other east-west, one of them will either cut across the tiles, sometimes in the middle of a tile, sometimes on an edge, or else the road will have to zigzag NE, SE, NE, SE, etc. which doesn''t look natural.
One idea I''d had is to make a hex based game, but design the artwork such that things are built with six directions in mind, six sides to a building, roads come to 6-way interections, (Well, three more usually, but still..) and so forth...
As i understand, the use of hex tiles or hex grids is used to determine the 6 basic directions and sides of individual units. These being:
-front
-front right flank
-front left flank
-rear right flank
-rear left flank
-and rear
Having every unit in games consist of these 6 sides allows for a more correct simulation of movement and actions. The next best option is to calculate everything using lines and pins (vector) although this can become cumbersome very quickly for the user and should only really be used as a last resort unless you can come up with a decent interface.
"So you're the one that designed that game are you?"
*Gulp* "Umm, yeah"
-front
-front right flank
-front left flank
-rear right flank
-rear left flank
-and rear
Having every unit in games consist of these 6 sides allows for a more correct simulation of movement and actions. The next best option is to calculate everything using lines and pins (vector) although this can become cumbersome very quickly for the user and should only really be used as a last resort unless you can come up with a decent interface.
"So you're the one that designed that game are you?"
*Gulp* "Umm, yeah"
Author
Thanx 4 all the input guys! I think I have quite a list of differences right now. But if anybody still hasn't put in his 2 cents, feel free to do so.
I just realized that there are two types of hex tiles: the one described by Paul and the other one is that one rotated 90 degrees resulting in the tile having these 6 sides instead:
-front right flank
-front left flank
-left flank
-right flank
-rear right flank
-rear left flank
The only difference I can tell is that with this one, we zig-zag north and south while with Paul's version we zig-zag east and west. Anybody know of any more differences?
ahw: the only answer I can come up with is that diagonal movement would be unfair because you would move further in the same amount of steps as you would be moving along the hypothenus which is always longer than the horizontal and vertical sides. back to square one it seems...is this a trick question?
p/s: this is the longest thread I've ever got going since I joined GameDev. Help me make it longer!
Edited by - epic709 on October 13, 2000 3:26:00 PM
Edited by - epic709 on October 13, 2000 3:28:57 PM
I just realized that there are two types of hex tiles: the one described by Paul and the other one is that one rotated 90 degrees resulting in the tile having these 6 sides instead:
-front right flank
-front left flank
-left flank
-right flank
-rear right flank
-rear left flank
The only difference I can tell is that with this one, we zig-zag north and south while with Paul's version we zig-zag east and west. Anybody know of any more differences?
ahw: the only answer I can come up with is that diagonal movement would be unfair because you would move further in the same amount of steps as you would be moving along the hypothenus which is always longer than the horizontal and vertical sides. back to square one it seems...is this a trick question?
p/s: this is the longest thread I've ever got going since I joined GameDev. Help me make it longer!
Edited by - epic709 on October 13, 2000 3:26:00 PM
Edited by - epic709 on October 13, 2000 3:28:57 PM
One other thing your bound to work out is that with larger critters two hextiles are usually used. This allows for more people to attack it by it''s larger surface area. although you''ll still have to work out how they move through hextiles. I used to use hexs when i DM''ed D&D for displaying party order, it works very neatly.
You might also be able to find a use for the diagonals in hextiles. I used them in D&D for pole weapons, this way you can calculate when someone''s too close to be hit by one.
"So you're the one that designed that game are you?"
*Gulp* "Umm, yeah"
You might also be able to find a use for the diagonals in hextiles. I used them in D&D for pole weapons, this way you can calculate when someone''s too close to be hit by one.
"So you're the one that designed that game are you?"
*Gulp* "Umm, yeah"
In reply to Chiroptera, even if your movement is discrete there is no reason that damage/distance checks should be. Why not use the distance between the tile centers as an analogue value, so your fireball would do maximum damage in it''s own cell, and minimum damage at a certain radius. This way no-one gets an advantage by being on a diagonal, even with square tiles.
Personally, I wouldn''t use discrete values anyway, just using tiles (hex or square) to represent the environment. An example of a game that does this well is Dungeon Keeper, during fights creatures will crowd in a circle around the foe, but rooms are built using square tiles. It would have worked just as well with a hex map without affecting gameplay at all (apart from not being able to build straight bridges
).
Seeya,
Dan
Personally, I wouldn''t use discrete values anyway, just using tiles (hex or square) to represent the environment. An example of a game that does this well is Dungeon Keeper, during fights creatures will crowd in a circle around the foe, but rooms are built using square tiles. It would have worked just as well with a hex map without affecting gameplay at all (apart from not being able to build straight bridges
). Seeya,
Dan
Hmmm... Well...
I''m not right sure at the moment, but - with diamonds - isn''t it possible to make units move 41% slower when moving diagonally?
I''m not right sure at the moment, but - with diamonds - isn''t it possible to make units move 41% slower when moving diagonally?
You can simply choose not to have per-tile-movement and make accurate movement instead. I think it could work in a strategy game also (gimme one reason why not).
Or then you can have time value for each unit telling how much it can move per turn. And just substract 1.414 from it when moving diagonally.
Or then you can have time value for each unit telling how much it can move per turn. And just substract 1.414 from it when moving diagonally.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
