Pathfinding on large map

Question

I\'m creating a game with a 10,000 by 10,000 map.
I would like for a user to be able to set a location and have the computer instantly find the best path.
However, since

Answer 1

My initial understanding of the problem statement was like follows. There are predefined terminal locations on the map. The user selects a location on the map, and the best/shortest path to the closest one of those locations must be found.

If my understanding is correct, then you can precompute the shortest paths for all locations on your map through a single application of the BFS algorithm. You can efficiently store that information using just 2 bits per node (the value associated with each node will tell in which direction you must move from that node in order to stay on the shortest path).

However, as tobias_k has commented, the problem may be defined differently - the player selects an arbitrary location on the map and the best path from the current location to that location must be found. The previously described approach can again be utilized, provided that

1. the player doesn't move around the map too quickly and
2. some inaccuracy can be tolerated.

Then the already described algorithm is executed to find the shortest paths from any location on the map to a small circumference centered at the player's current location. Then for a short period of time that data can be used to quickly route the quasi-shortest path toward any location on the map. When the player, while moving, gets too close to the boundary of that circle, the algorithm is preemptively executed for the player's new location.

The disadvantage of this approach is that it consumes a lot of CPU resources. The advantage is its simplicity.

Answer 2

If your map has uniform weight (except for obstacles of course), you may have better performance with either:

1. An algorithm that preprocesses the grid into a graph, collapsing large, empty spaces into a single node. Navigation meshes break the traversable area into convex polygons each of which can be traversed in a single step. L1 path finder groups the obstacles together, reducing them to a visibility graph calculates the path over that.

2. An algorithm that does not expand every node. Jump-point search takes advantage of symmetry between different paths, only expanding nodes adjacent to obstacles, whereas A* would expand every node along the shortest path.

Answer 3

So even though there might be n^4 shortest paths on a square n by n map. storing all the paths doesn't necessarily require O(n^4) space. The idea is that given two different target locations on the map and their shortest path trees, than the closer those two points are on the map, the more common elements will their shortest path trees have. This is especially true when using a planar map like a grid with obstacles.

So the idea is to store only some complete shortest path trees for a small set of target locations (may even be only one target location). For the rest of the target locations only the difference of its shortest path tree to one of the previously stored shortest path trees is stored.

Then the algorithm to find the shortest path from one location to a target is to load a fully stored shortest path tree and then apply some diffs to it to get the shortest path tree of the target location. Then only the current player position needs to be found on the shortest path tree which is O(n^2) complexity.

I don't have any hard facts on how much storage space is needed for storing the shortest path trees and their diffs, but this could be in the range O(n^2 log(n^2)). Loading one and appyling the diffs might only have time complexity of O(n^2).

The shortest path tree for a target location represents all the shortest path from every location on the map to the target location.

This solution may also keep the used shortest path tree in memory and apply diffs as necessary in order to get the new shortest path tree to use. Then the complexity of getting the shortest path tree is not bound by the size of the map, but just by the size of the diffs to be applied. This scenario might really work well for games like the original Sacred or Diablo.

Answer 4

A high level concept might be to find the points of the start and end - say point (0,0) and point (10000, 10000) - and make a preliminary guess for a path going from beginning to end (in this case it would run diagonally the whole way up and to the right) Then start checking to see if it can successfully get there (if there are obstacles on that path or not). If there are then programmatically choose similar paths, or alternately find where the path fails and start there and try to iterate until it works, it might not be 100% the fastest but you will get a lot better results than finding every single possible way, then deducing the shortest path from that.

Implementation

• Method to find initial shortest path
• Run to see if it works
  • If it fails then either try similar path or start from failure

Answer 5

This will be a little longer than what fits into a comment, so hence an answer.

Your setup requires clarification. 10,000x10,000 is all good, but this statement is not:

since the map is 10,000 by 10,000, there are 100,000,000 nodes

Why would there be 1 node per each unit of the coordinate system? This is not how node pathfinding works, instead the nodes are supposed to be more sparse, and by their existance describe individual (sparse) points along the path. Between the node points, the object handles movement by other means. A grid pathfinding system might, in worst case (if no obstacles at all), have 100,000,000 points, but as the Q mentions nodes, i assume this is about node pathfinding.

100,000,000 nodes

100,000,000 nodes is 381 megabytes of memory if int32 and 763 mb if float64. In addition, there are node connections. I have no idea how these would be set in your case, but each connection requires 2 integers, say of 2 bytes each. Ie. if there are as many connections as nodes, another 381 mb is needed. All in all, we end up with graph data closer to one terabyte, and i claim that for sure something is wrong then.

How to solve the issue, provided we still have a huge node graph/a huge area? I would probably simplify, by creating larger quadrants (as you mentioned). Each quadrant would however hold nodes only along the 4 edges - all nodes inside a quadrant would be replaced by straight lines. This way, one would resolve the entry/exit points for each quadrant. This would be a separate node graph, for rough calculation. Then, inside a quadrant, one would always load the inner node graph for that quadrant only at time. Ofc there would be some kind of error invloved, but hey, that's reallife, right? If this is about human behaviour, well then it is not always fully optimised.

Pre-calculation, cache, speed, small data are keywords in game coding.

Answer 6

1. Make sure all the graph data is in memory
2. Use bidirectional Dijkstra - assuming you have multi-core
3. Look into using contraction hierarchies, this will greatly improve the performance.
4. Pre-calculate everything that you can such as path weights.