10

I'm developing a real time, tile-based RTS. This is an example map:

Map

This map consists of 4 regions with 256 tiles each. Blue tiles represent obstacles. Units can move in the standard eight directions. Units are bound to tiles; one tile can hold one unit.

These are some examples of the ideal paths I'm looking for. Typical A* stuff:

enter image description here

My question is: Is a navigation mesh applicable to a tile-based RTS? I've only seen navigation maps used in games where units are free-moving and not bound to a grid of tiles. What would the navigation mesh look like on this particular map? An example image would be excellent.

mario_sunny
  • 237
  • 3
  • 7
  • For what it's worth, I seem to recall hearing that some of Starcraft I's pathing "oddness" was due to the late decision to switch from 2d to isometric 3d -- all the pathing code was written expecting 2d terrain! – Raven Dreamer Feb 15 '15 at 22:08

1 Answers1

12

Yes, navigation meshes are still applicable to tile based games. Although, they would primarily be used as a optimization. For example, I've converted the lower left of your image to use a navigation mesh:

enter image description here

In this case, each green square would be a navigation node. As you can see, this drastically reduces the number of nodes that A* needs to process. Units can then simply path to the center of each of these nodes.

The generation of these nodes is a different issue. It can be complex deciding how to form the nodes. There's a few questions on the site where you might find some ideas on how you'd like to implement that:

Subdividing a polygon into boxes of varying size

Identifying quad patterns in a two-dimensional array

https://stackoverflow.com/questions/20220215/minimum-number-of-rectangles-in-shape-made-from-rectangles

This navigation mesh can also essentially be used as a "first pass" path finding. If a path is found through the navigation mesh, you know that a path exists. This is a faster test to see if two points are connected.

Community
  • 1
House
  • 73,224
  • 17
  • 184
  • 273
  • 1
    I'm having a hard time understanding how this is superior to pure A*. How would your navmesh optimize the pathfinding calculation for the green path in the original answer, for example? – mario_sunny Feb 15 '15 at 22:31
  • 4
    The green path has 15 nodes, the mesh path has 5. This doesn't even include the number of dead ends that need to be analyzed when finding that path. The point of the navigation mesh is not necessarily to make the most direct routes, it's to reduce the amount of nodes that A* has to search through, thus dramatically increasing the speed of A*. There are strategies to placing nodes in your navigation mesh that can find a balance between direct paths and fewer nodes (for example, nodes on each corner of all the obstacles). There's also optimizations that can be performed on the finished path. – House Feb 15 '15 at 22:35
  • I'm beginning to understand. Would the green path look any different with the navmesh optimization? You seem to be implying that the unit will move to the center of each rectangle on his way to the endpoint. Are you suggesting the post-A* optimizations would shorten the path? – mario_sunny Feb 15 '15 at 22:40
  • 3
    Yes, if you used the center of each node, the path would look different. However, you can decide to use something other than the center (like you could use the corners of each node). Or you can make it so your nodes are no larger than four squares (making fewer nodes but making the nodes follow the geometry closer). Or you can perform some optimizations on the path to be more direct after you find it. You can even use the nav-mesh as a first pass, then use A* to path through each node (allowing you to "path as you go", while the unit is moving, spreading the performance impact out over time). – House Feb 15 '15 at 22:49