well, I'm not about to answer for him, but I still want to comment based on my own experiance.    Hexes are so much harder to create than squares I think.   Also, hexes are only 50% bettar than squares, you run into the exact same inaccacies when you try to go any direction that isn't one of the faces.   You gain the power to make 30 degree turns at the loss of the ability to make 90 degree right turns.    So I wouldn't say its that much more accurate of representation, it only has 2 more direction choices.

I personally like squares more, just because its easier to line things up, and I'm a little OCD about that kind of thing.

Only as long as diagonal movement has the same path cost as movement in the 4 base directions (up, down, left, right - sorry, I don't know the word for it, I'm not a native english speaker). If you assign different cost to diagonal movement, it can be quite ok I think.

Consider a square with a side a=1. The diagonal would be a * sqrt(2). Or just sqrt(2) in this case. So the side/diagonal ratio is 1.41(...). Many games don't bother with that much accuracy and just make horizontal/vertical movement cost 1, the same as diagonal.

Floating point arithmetic has disadvantages compared to integer arithmetic, not to mention it's inconvenient for player to add 1.41 in his head. But there's a really close approximation with small integers: diagonal costs 7 points, horizontal/vertical costs 5 points. 7/5 = 1.4. So with my approximation it takes 100 diagonal moves to produce 1 square of difference from reality.

I believe the octagon shape would be the best of both worlds.

This is one of those decisions which must be done by developers during the extreme early stages...  even now whatever has been decided most likely cannot be changed.

That was my immediate thought... and I'm too lazy to check so I'm gonna just trust Tamren

But octagons don't tesselate

What about my favorite?   The dodecahedron?

yeah, I'm totally confused how we are expected to wrapping solve the lack of tesselation in octagons for the above stated reason.   That being said, we could have a complex over-lapping system (where octagons overlap each other, i.e. put another octagon over every 'G' as seen in piderman's diagram so that the diagnols of each octogon passes through the centers of the adjascent octogons.) to create the best system!   again though, programming would be a pain in the butt.

The octagon shapes allow logical movement in any main direction.  Otherwise you'd have to move 1 square forward and 1 square sideways for moving diagonal when using squares.

In any case this is one of the earliest decisions made for game creation so any discussion is extremely unlikely to make a difference.

I think you've misrepresented my stance. I was trying to say that it would be confusing if player was forced to add numbers like 1.41 and 1. 7 and 5 are still quite accurate and easy to add for anyone knowing the multiplication table. I think 7 and 5 are the best compromise. For computers 7 and 5 is likely to be a good choice because float arithmetic is slower than integer arithmetic, not to mention lack of rounding errors.

The whole point of grid-based system is that it should be reasonably easy to calculate for humans. It's easy to see at a glance how much distance it is. That's why many strategy and logic games use grid.  RTS games don't use grid, but I don't think anyone considers RTS games proper strategy games (half-serious).

My apologies b0rsuk if I did not paraphrase you well.  I was just trying to quickly sum up the general issue where movement costs would be different depending whether you are moving orthogonally or diagonally, without getting into the specifics.

I do realize that you were suggesting representing these different costs as best fit integers (7 and 5) rather than as floating points values (sqrt(2) and 1) to ease certain calculations.  But, regardless of the numerical representation, the very fact that the movement cost on a square grid would not be consistent for all directions is confusing. It also causes problems with unit speed.  For a unit that would have had a movement speed of 1, what would it's movement speed be with the integer system?  5 or 7?  You'd end up with unit speeds based loosely around multiples of 5 or 7 which would also get confusing.  Even though the distances are expressed as integers rather than floats the concept is the same and it leads to unnecessary complication.

Where I was suggesting that you and I agree is that the point of using a grid system is to make things easier, both for humans and AI.  Where we also agree is that you should be able to estimate distance at a glance.  In my OP this is why I suggested hexes over squares as there is less distortion of distance.

Simply put: If you were to turn off the grid and just look at two units and estimate the distance between them, you'd be more accurate more often with hexes than squares.  That really is my only point.

Cheers.

P.S. I'm also with ya on TBS vs RTS.  My vote is for smart thinking over quick thinking anyday

The difference between having a grid and using pure positional logic is a massive increase in resources.  Faking an octagonal grid just for the hell of it would be nutty.

I see the confusion here...

I was referencing the movement grid = octagon

Another was mentioning the map appearance grid = squares

These do not have to be identical.

I'm confused, I think most of the discussion was about the tactical map.  Its pretty clear they at least started with squares

Do you mean you can move diagonally off a square? If not, I'm afraid I don't understand what you mean

This sounds interesting but has a little problem. Say you stand in the middle of an octagon and move a distance of d to one side. Now if you go diagonally you will also move a distance of d. However, broken down in distance along the x and y axis that is d/sqrt(2) each, which is not a rational number. Meaning, unless you come back to the place you started you will never be able to reach a particular other spot by two different routes. So two units, standing in different places will not have a coinciding movement 'grid'. So that would need some extra work in the form of 'collision' detection because units will never be on the exact same spot

One could of course fix this by using hexes erm I mean of course Equilateral trianges Because these have inner angles of 60 degrees, if you move diagonally and then over the opposing diagonal you will be on the same spot as had you moved in a straight direction.

Such difficulties! Let's go traditional and use squares