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, line-of-sight to both are blocked by walls distance 2 from the player. Due to the hexagonal grid, A can be reached in 4 moves, circumventing the wall, whereas B requires 5 moves, as the wall more effectively blocks the path in this direction.

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 doesn't need to 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.

  • \$\begingroup\$ 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 ? \$\endgroup\$
    – Heckel
    Jun 11, 2014 at 14:00
  • \$\begingroup\$ Isn't this true on square grids too? I think this is both an advantage and disadvantage of using grids. \$\endgroup\$
    – amitp
    Jun 11, 2014 at 14:06
  • 2
    \$\begingroup\$ @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). \$\endgroup\$
    – Darq
    Jun 11, 2014 at 14:11

3 Answers 3


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.

  • 3
    \$\begingroup\$ 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! \$\endgroup\$
    – Darq
    Sep 8, 2014 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.

  • 1
    \$\begingroup\$ 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! \$\endgroup\$
    – Darq
    Jun 13, 2014 at 20:11
  • \$\begingroup\$ 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. \$\endgroup\$ Sep 15, 2014 at 20:49
  • 2
    \$\begingroup\$ In the future, if you need to comment on any Stack Exchange site, just contribute to the community or contribute enough to one site to get the association bonus. Its not a bug, its a feature that you can't comment before a certain threshold. However, this is not a comment, this is an answer, i was about the post the same thing. \$\endgroup\$
    – Krupip
    Jun 7, 2018 at 17:35

The mistake in this post was treating any red line that crosses a hex as being equal. Those red lines are not all the same length in the Euclidean space of the player's screen (ignoring the grid).

If we take the edge length of a hexagon to be our unit, 1, then a line connecting two opposite corners has Euclidean length 2, and a line connecting the centers of two opposite edges has Euclidean length \$\sqrt 3\$.

That makes the straight-line distance to A:

  • center to corner = 1
  • hex edge = 1
  • corner-to-corner = 2
  • hex edge = 1
  • corner to center = 1

...for a grand total of 6 hex edges' distance from the center of the start tile to the center of A.

Compare to the straight-line distance to B, which is:

  • center to edge = \$\frac {\sqrt 3} 2\$
  • 3 x edge-to-edge = \$3 \sqrt 3\$
  • edge to center = \$\frac {\sqrt 3} 2\$

...for a grand total of \$4 \sqrt 3 \approx 6.928\$ from the center of the start tile to the center of B - almost one full hex edge farther away.

Two ways to see this:


  1. Duplicate the map and rotate one copy around the starting point, so that A and B are in the same line. Notice how the copy of B is farther down the line than the original A.

  2. As suggested by Alexis Andre, mirror B across the starting point (shown in green). Now we can see that to reach either A or the mirrored B we need to move the same distance down the screen. But to reach the mirrored B we also need to move some distance left. So B's distance from the starting point must be strictly greater than A's.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .