Turn Based: Square Grid vs. Hexagonal Grid

[SCO]

Dudes, convex polygon intersection is a closed problem, in 3d even. Checking if a point is inside a hex is a question of giving the polygon and the point into a frameworky code, being the polygon a square or a hex.

Edit : in fact if you want i'm just going to post a another guy work on pathfinding in aleatory polygons just so you can see how solved it is:

http://www.javagaming.org/index.php/topic,19539.0.html

 

[Khor1255]

Right! It doesn't really matter. It is all a matter of scale and taste.

I will say one thing, for smaller scale (bigger unit per area) pathfinding and anything else something other than a grid looks more natural. But for mapping, a square rules.

 

[geniusone]

hex grid programming

I am currently working on a game-type program learning how to program hex grids.

I am using Python and pygame. Lets see. like what denizsi said

...though basically, the logic was still square based with some interpolation.

about hex tiles.

in my program i moved the next row over. like so. Each star is a tile, and looking at it there are 6 stars around it.

* * * * * * * *
 * * * * * * * *
  * * * * * * * * 
   * * * * * * * * 
    * * * * * * * *

the previous image is a blown up image of 40x31.(the picture i used is 1 pixel to wide) so when you draw the image you only want to do about 22 down to fill in the gaps.

for y = 0 to 10
	for x = 0 to 10
		drawimage((x*40)+(y*20), y*22)
	next x
next y

Seeing if a mouse is inside a hex tile is a bit harder though.
because it wont be exact. the best you can do is using a square area that overlaps other hexagons.



The black area is of course the hexagon....the gimp
the green is the area where the mouse will be. as you can see it will over lap two other hexagons.

as for locating what tile you are over is ever a bit more harder. there were difficulties I had to overcome. With the tiles off-center, you have to find the location relative to where the first tile is. But if you want your tiles scrolling, then you have to change the relative tile...

I can go on forever about this. But if you guys want a tutorial or anything, I could take some time to make one. Just let me know. But until then, i hope this helps about how to draw hex tiles on the screen. It is pretty similar to drawing square tiles.

-Brian

 

[denizsi]

It's also possible to do correct geometric detection and it's neither difficult or resource heavy but rather tedious to write and utterly unnecessary in my opinion. It's the same square-based principle + you add angle calculation when within the square intervals relative to the either adjacent square. It gives pixel for pixel accuracy with the cursor.

 

[geniusone]

You know, i tried that out. and it works pretty well. Just some big if-else if chain. Doesn't do too many calculations, seems to work pretty well. Now I can make something pixel perfect

 

[denizsi]

You're welcome.

 

[keithburgun]

Surprised no one has mentioned this,

Surprised no one has mentioned this, but the reason why those who are in the know always use hexes is because, as wikipedia states,

"The primary advantage of a hex map over a traditional square grid map is that the distance between the center of each hex cell and the center of all six adjacent hex cells is constant. Compare this to a square grid map where the distance from the center of each square cell to the center of its four diagonal adjacent cells is longer than the distance to the center of its four cardinal adjacent cells. This is desirable for games in which the measurement of movement is a factor."

http://en.wikipedia.org/wiki/Hex_map

-Keith

 

[Hobbit Lord of Mordor]

No, I think we understand that, it's just another way of putting it.

Personally when I designed a combat system I used small-scale hexes, for the same reasons Khor1255 gave. If I was programming I would probably go for free movement / concentric circles approach.

 

[J1M]

Re: Surprised no one has mentioned this,

Surprised no one has mentioned this, but the reason why those who are in the know always use hexes is because, as wikipedia states,
-Keith

Would love to hear about how you, personally, deal with putting rectangular structures like buildings into your hex grids.

 

[Merkwürdigliebe]

How about greatly increasing movement points in a square based grid? Not meaning that you can move further but rather subdividing them so diagonal movement doesn't have to be rounded off so coarsely.

As an example instead of a character having 10 movement points, and moving in a straight line costing one points and diagonally 1 or 2. One could have say 1000 points instead where moving in a straight line(the same distance as before) costing 100 points and diagonally 141 points.

 

[Elzair]

Does D&D use squares or hexes? I think I remember squares from my play sessions.

 

[Panthera]

Re: Surprised no one has mentioned this,

D&D is squares.

Surprised no one has mentioned this, but the reason why those who are in the know always use hexes is because, as wikipedia states,
-Keith

Would love to hear about how you, personally, deal with putting rectangular structures like buildings into your hex grids.

The trick is to draw straight lines along borders. This will line up perfectly in one direction. In the other direction, you have to bisect every other hex. You can stand in those bisected hexes, but you can't move through them in the direction of the wall.

 

[denizsi]

Another approach in my mind with either grids is dynamically applied grids that are relative to the player and the world geometry, or premade grids tailored to each environment by hand to allow irregularly placed buildings at non-perpendicular angles but that's mainly for a single-character game and might be near-inconceivable with anything team-based.

When the combat first starts, the first round would be to adjust all the critters that originally would end up irregularly placed on the grid into the nearest square/hex feasible without overlapping each other. Actually this initial adjustment is what I've done with Oblivion/Fallout 3, and it seemed like it was working pretty good.

It might still work in a team-based game where you'd get the option to choose which nearest square/hex to move your characters to in the initial grid adjustment turn, but I suspect it would turn into a chore after a short while. Would it?

 

[J1M]

Re: Surprised no one has mentioned this,

D&D is squares.

Surprised no one has mentioned this, but the reason why those who are in the know always use hexes is because, as wikipedia states,
-Keith

Would love to hear about how you, personally, deal with putting rectangular structures like buildings into your hex grids.

The trick is to draw straight lines along borders. This will line up perfectly in one direction. In the other direction, you have to bisect every other hex. You can stand in those bisected hexes, but you can't move through them in the direction of the wall.

That is a solution that is only really practical for a tabletop game.

 

[Panthera]

Re: Surprised no one has mentioned this,

D&D is squares.

Surprised no one has mentioned this, but the reason why those who are in the know always use hexes is because, as wikipedia states,
-Keith

Would love to hear about how you, personally, deal with putting rectangular structures like buildings into your hex grids.

The trick is to draw straight lines along borders. This will line up perfectly in one direction. In the other direction, you have to bisect every other hex. You can stand in those bisected hexes, but you can't move through them in the direction of the wall.

That is a solution that is only really practical for a tabletop game.

Not really. Isn't it what Fallout does, minus the ability to stand in those hexes?

 

[denizsi]

Wow, time flies by. So, discuss!

Regarding the question of movement along a structure where a given edge is non-aligned to the grid, I suggest strips of grids adjacent to the edges which you can pass onto and from for the specific goal of moving along such an edge.

 

[Shemar]

As a player I would prefer hexes. Especially on larger scales (wargames). For RPG development, I think squares are the better fit. From a practical point of view a turn based game is also very likely to use tile graphics and square tiles are much easier to work with than hex tiles as most significant map elements (buildings, walls etc.) will conform a lot easier to a square grid than a hex grid. However if a developer manages to create a hex based game without sacrifising gameplay, more power to them, I'll happily play it.

 

[SteveL]

How about greatly increasing movement points in a square based grid? Not meaning that you can move further but rather subdividing them so diagonal movement doesn't have to be rounded off so coarsely.

As an example instead of a character having 10 movement points, and moving in a straight line costing one points and diagonally 1 or 2. One could have say 1000 points instead where moving in a straight line(the same distance as before) costing 100 points and diagonally 141 points.

Square grid, movement in 4 principle directions costs n movement points, diag moves cost n * sqrt(2) to get the distance ratio right. So using n = 100 and approximating the diagonal as 141 is one idea (or 1000, 1414 depending on how precise you want to get). Seems reasonable and simple enough, I like it.

Or you could still be precise with n = 1 and staying with integers, provided you're willing to use a probabilistic logic for handling the diagonals. On this scheme a diagonal move costs either 1 or 2 movement points and the game calls the random number generator to determine which, using p(1) + 2 * (1 - p(1)) = sqrt(2). This puts the expected value of movement points for a diagonal move at sqrt(2). Solving, we have p(1) = 2 - sqrt(2) which is approximately .586. So on each diagonal move you call the RNG to obtain a value 0 <= r < 1, if r < 2 - sqrt(2) the move costs 1 movement point otherwise it costs 2. And any AI pathfinding code would estimate the cost of diagonal moves as the expected value sqrt(2) as the geometry would dictate. How I could see this working in combat would be that you always can attack in the 4 principle directions, but you're gambling trying to attack diagonally - the attack only works if the diagonal distance gets calculated as 1 meaning it only has a .586 probability of success (otherwise you aren't close enough to attack).

 

[DraQ]

Re: Surprised no one has mentioned this,

That is a solution that is only really practical for a tabletop game.

So is highly discretized playfield when you think of it.

 

[Shemar]

How about greatly increasing movement points in a square based grid? Not meaning that you can move further but rather subdividing them so diagonal movement doesn't have to be rounded off so coarsely.

As an example instead of a character having 10 movement points, and moving in a straight line costing one points and diagonally 1 or 2. One could have say 1000 points instead where moving in a straight line(the same distance as before) costing 100 points and diagonally 141 points.

Square grid, movement in 4 principle directions costs n movement points, diag moves cost n * sqrt(2) to get the distance ratio right. So using n = 100 and approximating the diagonal as 141 is one idea (or 1000, 1414 depending on how precise you want to get). Seems reasonable and simple enough, I like it.

Or you could still be precise with n = 1 and staying with integers, provided you're willing to use a probabilistic logic for handling the diagonals. On this scheme a diagonal move costs either 1 or 2 movement points and the game calls the random number generator to determine which, using p(1) + 2 * (1 - p(1)) = sqrt(2). This puts the expected value of movement points for a diagonal move at sqrt(2). Solving, we have p(1) = 2 - sqrt(2) which is approximately .586. So on each diagonal move you call the RNG to obtain a value 0 <= r < 1, if r < 2 - sqrt(2) the move costs 1 movement point otherwise it costs 2. And any AI pathfinding code would estimate the cost of diagonal moves as the expected value sqrt(2) as the geometry would dictate. How I could see this working in combat would be that you always can attack in the 4 principle directions, but you're gambling trying to attack diagonally - the attack only works if the diagonal distance gets calculated as 1 meaning it only has a .586 probability of success (otherwise you aren't close enough to attack).

This is all way too complicated for something that can be approximated within 0.17/3=5.7% by a simple 2 straight 3 diagonal AP/cost movement (ideal for an average movement/turn value of 20). A 5/7 split reduces the innacuracy to 2.4% and a 10/14 split (which would make sens for a 100-base APs per turn) at just over 1%.

Besides, as a player I find the notion that the cost of a diagonal move can randomly fluctuate by 100% (from 1 to 2), even if it statistically evens out in the course of a fight or even a long move, pretty abhorrent. Even more so, the idea that a simple attack may or may not happen based on a random roll. Way too much randomness (especially randomness that has nothing to do with the realities of combat but just where the computer will randomly decide to round off the movement points) for a turn based game, where the whole point is tactical decisions, detailed planning and micro-management.

 

[DarkUnderlord]

vs

Squares look fairly nice, simple and clean. Hexes look a little overwhelming (maybe because every alternate square is given a different background colour, where-as the hexes aren't?).

Though surprisingly, drawing the hexes is quite easy. You just offset every second column by a set number of pixels and ignore the issues of people who want to click too close to the edge and end up clicking in the adjacent hex (some simple hovers to indicate what you've got highlighted solve that problem).

 

[Shemar]

I actually feel the hex display looks much better. I don't like the checkered background. Two comments:

One, it is not hard to properly calculate what hex was clicked. I actually have code that both draws a AxB hex grid (and can fill each hex with a designated 'tile') and detects mouse clicks on the proper hex (even in the corners).

Two, where the real disadvantages of hexes come is when you start having terrain features that span multiple hexes/squares (which in your example you do not).

 

[OminousBlueDot]

Why is it always hex vrs. grid? Why not octogons? Octogons would be awesome ...

Hexes appear overwhelming as you have several more choices to make, is all.

 

[DraQ]

Why is it always hex vrs. grid? Why not octogons? Octogons would be awesome ...

OminousBlueDot cannot into tiling.

 

[JarlFrank]

How about pentagons? Americans would probably like a wargame with pentagons.