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 the map is 10,000 by 10,000, there are 100,000,000 nodes, and to find this path through a conventional method such as A* or Dijkstra's would require a large amount of memory and a long time.
So my question is: How can I find the best path?
The algorithm I'm considering would divide the world into 100 sections, each with 1,000,000 nodes. Each section would then be divided into 100 subsections. This would be repeated until each subsection contains 100 nodes. The algorithm would then find the best path of sections, then subsections, then sub-sub sections until it finds the best set of nodes. Would this work and is there a better way?
I'm also considering a jump-point search, but I don't know it, and it'd be a pain to learn just to find that it can't do it.
Edit: I have attempted to add A*. However, it took about 5 seconds to run, which is about 4 seconds longer than ideal.
Since the map is 10.000 x 10.000 the number of nodes is 100.000.000. Using a straightforward implementation of A* would be impractical and certainly wouldn't make the game scalable in mapsize.
I would recommend you to use the following solution, which is essentially what you were thinking:
HPA* (Hierarchical Path A*). This method creates different hierarchies of map. You may automate the process by saying every block of 100x100 pixels is a region. Then, for every block, we need to find the adjacent blocks and where the entries and exits for each block is. If the connection between the two blocks is more than a node then we use two nodes to represent the problem. This image explains the new graph that we're trying to build. (Black=obstacle and grey are connecting nodes between blocks).
This method provides good results as can be seen from an execution using maps from the game Baldur's Gate with every block being 10x10.
For more information read this article from Nathan Sturtevant (he is one of the most succesful path-finding researcher when it comes to games). https://skatgame.net/mburo/ps/path.pdf
For an explanation of HPA please check this lecture of Sturtevant (min 43:50 for HPA). https://www.youtube.com/watch?v=BVd5f66U4Rw
Also, if you want to see HPA* in action check this video that Sturtevant made: https://www.youtube.com/watch?v=l7YQ5_Nbifo
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
- the player doesn't move around the map too quickly and
- 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.
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.
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.
If your map has uniform weight (except for obstacles of course), you may have better performance with either:
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.
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.
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
- Make sure all the graph data is in memory
- Use bidirectional Dijkstra - assuming you have multi-core
- Look into using contraction hierarchies, this will greatly improve the performance.
- Pre-calculate everything that you can such as path weights.
来源：https://stackoverflow.com/questions/37466738/pathfinding-on-large-map