# Inconsistent movement / line-of-sight around obstacles on a hexagonal grid

In a roguelike game I've been working on, one of my core design goals has been to allow the player to "Play the game, not the grid."

In essence, I want the player's positioning to be tactical, because of elements in the game world, not simply because some grid tiles are more advantageous than others in relation to enemies. I am fine with world geometry not being realistic, but it needs to be consistent.

In this process I have run into most of the common problems (Square tiles? Diagonal movement, LOS, corner cases, etc.) and have moved to a hexagonal tile grid. For the most part this has been great, and I've not had too many inconsistencies.

Recently, however, I have been stumped by the following:

Points A and B are both distance 4 from the player (red lines). Lines-of-sight to both are blocked by walls (black tiles). However, due to the hexagonal grid, A can be reached in 4 moves, whereas B requires 5 moves (blue lines).

On a hex grid, "shortest path" seems divorced from "direct path"; there may be multiple shortest paths to any point, but there is only one direct path (or two in some situations). This is fine; geometry need not be realistic.

However, this also seems inconsistent: Similar obstacles are more effective in some positions than in others. A player running away from an enemy should be able to run in any direction, increasing the distance between the two actors. However when placing obstacles or traps between themselves and enemies, the player is best served by running in one of the six directions that don't have multiple shortest paths.

Is there a way to rationalise this? Am I missing something that makes this behaviour consistent? Or is there a way to make this behaviour consistent? I am most certainly over-thinking this, but as it is one of my goals, I should do it due diligence.

-
I don't understand "when placing obstacles or traps between themselves and enemies, the player is best served by running in one of the six directions that don't have multiple shortest paths.". Could you add an example please ? – Heckel Jun 11 '14 at 14:00
Isn't this true on square grids too? I think this is both an advantage and disadvantage of using grids. – amitp Jun 11 '14 at 14:06
@Heckel, If I may use the image in the question as an example. Running directly away from an enemy in the tile labelled "A" (towards the top of the image), obstacles between myself and the enemy have little effect, as there are multiple shortest paths around the obstacle (illustrated by the blue line). When running away from "B" (towards the bottom-left of the image), there is only one shortest path, and going around the obstacle forces a longer path (again illustrated in blue). – Darq Jun 11 '14 at 14:11

As long as your movement space isn't Euclidean and things can block an entire grid space, you'll have this problem.

If you want people to not "play the grid" you're probably going to have to not use a grid.

-
Unfortunately, as far as I can see, this is the correct answer. Any "chunking" up of space, regardless of how distance is calculated (Euclidean, Manhattan, or Chebyshev) is going to lead to this kind of problem. Thanks for your answer! – Darq Sep 8 '14 at 6:25

(I don't have enough reputation to comment) The answer here is that the distances are wrong. A is closer than B. To convince yourself, compare A and the reflection of B w.r.t. the player, so I don't think there is an issue here.

Hex grids are tricky in a lot of ways.

-
Thanks for your answer. Indeed, the distances are different when we consider Euclidian distance. However I have been calculating my distances using Manhattan / Chebyshev distance, where every "ring" of hexagons is one unit further away. The advantage being that distance is simple for a player to calculate by just counting hexes. I would like to continue using this simpler distance if at all possible, but your answer indicates that I may have to re-investigate Euclidian distance. Thanks again! – Darq Jun 13 '14 at 20:11
I recall encountering this workaround in some pathfinding I did for the AI in my own version of Steve Jackson's Ogre. You can tweak a pathfinding sort to account for both hex distance and Euclidean distance when it's really important. – Fuhrmanator Sep 15 '14 at 20:49