A Faster Alternative to Traditional A* Search: Dynamically Weighted BDBOP

Transcription

1 Int'l Conf. Artificial Intelligence ICAI'16 3 A Faster Alternative to Traditional A* Search: Dynamically Weighted BDBOP John P. Baggs, Matthew Renner and Eman El-Sheikh Department of Computer Science, University of West Florida, Pensacola, FL, USA Abstract Video games are becoming more computationally complex. This requires video game designers to carefully allocate resources in order to achieve desired performance. This paper describes the development of a new alternative to traditional A* that decreases the time to find a path in threedimensional environments. We developed a system using Unity 5.1 that allowed us to run multiple search algorithms on different environments. These tests allowed us to find the strengths and weaknesses of the variations of traditional A*. After analyzing these strengths, we defined a new alternative algorithm named Dynamically Weighted BDBOP that performed faster than A* search in our experiments. Using this search, video game developers can focus the limited resources on more complex tasks. Keywords: A*, Navigation Mesh, Path-finding, Dynamically Weighted BDBOP, Video Games 1 Introduction Path-finding algorithms are used in many Computer Science application areas, including robotics and video games. One of the most popular path-finding algorithms used is the A* search. A* is an improvement on Dijkstra s shortest path algorithm. The improvement significantly cuts down the number of nodes that need to be visited during the search. A decrease in the number of nodes correlates directly with a decrease in the space and time complexities of the search. A* s improvement upon Dijkstra s algorithm comes from the use of a heuristic method to reduce the search space [1]. Today, video games require an enormous amount of computational resources. A majority of these resources are dedicated to graphics rendering and calculations in the physics engine [2]. Given these limited resources, all computational components of video games must be optimized for speed and memory management. Path-finding, a component of non-player character (NPC) intelligence, is a computationally intensive task; therefore it is essential to improve the path-finding computational efficiency. Because of it s search speed, A* is one of the most widely used pathfinding algorithms in the video game industry. This research addresses improving the efficiency of path-finding algorithms. A path-finding algorithm requires the following: a start point, an end point, and a representation of the environment in which the search is to take place. Today, the two main methods environments are represented in video games are with square grids and navigation meshes. Square grids take a specific section of space in the environment and map the space to a matrix location. The matrix has to be large enough to contain the number of squares needed to represent the environment. Navigation meshes were developed in the 1980s for robotic path-finding and most games after the 2000s have adopted these navigation meshes. In [3], a navigation mesh is defined as a set of convex polygons that describe the walkable surface of a 3-dimensional environment. There are several efficiency related issues with square grid environments. The smaller the squares in the grid, the more detailed the description of the environment becomes. However, at the same time, the number of squares increases the search space for the path-finding algorithm. As the search space increases, the time complexity increases. Another issue with square grids is that the squares are laid on top of nonmovable or static obstacles. Because the obstacles are represented in the grid, collision detection is required during path-finding. Navigation meshes directly address these two challenges. A navigation mesh represents the environment with polygons that are completely free of obstacles. This condition, and the condition that all polygons are convex, removes the need for collision detection anywhere inside a polygon [4]. There is no restriction on the size that a polygon can be as long as the rules of being convex and obstacle free are maintained. A navigation mesh search space consists of significantly fewer nodes than the square grid search space for the same environment. For these reasons, our research focuses on developing and implementing a navigation mesh for experimentation with path-finding algorithms. This paper summarizes two main contributions: 1. Results and conclusions from an experiment comparing different path-finding algorithms on a set of threedimensional environments developed using Unity 5.1. We implemented A* and popular variations of A*. These variants include Bi-Directional A*, Fringe search, optimized versions of traditional A*, Beam search, Dynamically Weighted A*, and Bi-Directional A*. During the experiment, each search was run on each environment 1000 times, collecting data for a comparison of each search algorithm s performance on a given environment.

2 4 Int'l Conf. Artificial Intelligence ICAI'16 2. A proposal for a new variant on A*. The proposed algorithm outperforms A* in both time and space complexity. The new algorithm sacrifices A* s guaranteed optimal solution in order to attain these performance gains. The solutions found by the new algorithm were optimal in some cases, but not all. Later in the paper we argue that the differences between solutions found by our algorithm and the optimal solution are not concerns to a video game developer. 2 Related Work Common practice in the video game industry for representing 3 dimensional environments, up until the early 2000s, was to use waypoints. Waypoints are a set of manually generated points in the environment that form a path that the agent can walk upon. The time it takes for developers to manually place these waypoints is not feasible for larger maps. Another drawback is that waypoints do a poor job of representing the environment because they only represent single points and the line connecting those points. The restrictive nature of Waypointer led to the use of the more flexible navigation meshes and square grids for representing environments. Xiao Qui discusses the limitation of square grids representing environments [1]. Square grids often require a large number of cells to adequately describe an environment. A well designed navigation mesh that is used to describe the same environment as a square grid will result in far fewer total nodes needed than the square grid will. One reason for this is that the nodes in a square grid cover the entire environment including the non-walkable areas, while a navigation mesh represents the walkable areas in the environment. Another reason for this is that the way a navigation mesh is designed is to create convex polygons as nodes that represent as much of the environment as they can in a given space and that do not include static obstacles. This allows the navigation mesh to use fewer nodes than a square grid to represent the same environment, effectively reducing the search space for a pathfinding algorithm, which serves to reduce the search time for the algorithm to find a path. Various path-finding algorithms can be used across both square grids and navigation meshes to find a valid path between two points. Fringe search is one such algorithm the use of which on square grids was researched in an attempt to determine if it could outperform A*. The Fringe search algorithm is a take on Iterative Deepening A* (IDA*) which uses recursive depth-first search of the environment until either the goal is found or a node that exceeds the threshold is found. If the threshold is exceeded it is increased and the search starts over [5, 6]. Fringe search iterates over the frontier of the search tree like IDA* but uses a data structure to help the search. The data structure used by Fringe Search can be thought of as two lists: one for the current iteration (now) and one for the next iteration (later) [5]. The paper concluded that Fringe search was faster in its calculations even though Fringe search expanded and visited more nodes than A*. Our results using an implementation of Fringe search differ from this and are discussed in the Results section. A valuable resource during our research into different pathfinding algorithms was a blog written by Amit Patel [7]. Patel describes multiple variations on the A* search in his blog. We implemented several search algorithms based on these brief descriptions, including Dynamically Weighted A*, Beam Search and Bi-Directional A*. The concise and clear descriptions of the algorithms made the implementations relatively straightforward. 3 Algorithm Design Dynamically Weighted Bi-Directional Beam OPtimized (BDBOP) search is a variation on A* that we created which uses features of Dynamically Weighted, Bi-Directional, Beam and Optimized A* searches. During our research into variations and methods of optimizing A* we noticed that there are different benefits gained from using each algorithm. After narrowing down our focus to algorithms that specialized in reducing the number of nodes visited in the search we formulated our algorithm design. Additionally, we optimized these searches with respect to the speed at which they navigate their data structures, strictly in terms of their Big O complexities. Dynamically Weighted BDBOP visits far less nodes than traditional A*. This allows Dynamically Weighted BDBOP to outperform A* even without the efficiency optimizations to the data structures. The defining characteristic of Bi-Directional search is that it conducts two A* searches in parallel or two A* searches in alternating successions. One search starts from the start node and searches for the goal node, while the opposite search begins at the goal node and searches for the start node. The search is complete when the frontiers of the searches meet or one of the two searches finds their destination node. Bi- Directional search visited fewer nodes when used to navigate our environments than A* did. The next search we evaluated was Dynamically Weighted A*. Dynamically Weighted A* places a high priority on getting the search moving quickly in the general direction of the goal in the beginning and then as the search gets closer to the goal precision becomes more important. This was accomplished by adding a weight to the heuristic. The weight decreases as the search gets closer to the goal. This results in fewer nodes visited than traditional A* but does not guarantee an optimal path. The Beam Search algorithm improves upon the space complexity of traditional A* by placing a limit on the size of the open list used in A*. One must be very careful when deciding the limit to impose on the open list, because too severe of a limit may lead to an incomplete search.

3 Int'l Conf. Artificial Intelligence ICAI'16 5 agenttogoal is the search starting from the agent and going to the goal goaltoagent is the search starting from the goal and going to the agent ρ is a constant that will divide the number of polygons to get the number of times each search will iterate α is the number of iteration (# of Polygons / ρ) 0.while (pathfound = false) 1. if (α <= 1) 2. returnvalue := agenttogoal s dosearch (# of Polygons *2) 3. if(returnvalue = 1) // goal was found 4. pathfound := true 5. else 6. no path can be found 7. else 8. returnvalue := agenttogoal s dosearch(α) 9. if (returnvalue = 1) // goal was found 10. pathfound := true 11. else if (returnvalue = 2) // a frontier connection was found 12. pathfound := true 13. else if (returnvalue = -1) // openlist is empty no path is found 14. no path can be found 15. else 16. returnvalue := goaltoagent s dosearch(α) 17. if (returnvalue = 1) // agent was found 18. pathfound := true 19. else if (returnvalue = 2) // a frontier connection was found 20. pathfound := true 21. else if (returnvalue = -1) // openlist is empty no path is found 22. no path can be found Figure 1. Pseudocode for the coordinator of Dynamically Weighted BDBOP The main improvement made to the data structures used for A* was to use a min-heap for retrieving the node in the open list with the lowest cost value. Inserting into the open list goes from an O(n) operation to an O(log(n)) operation [8]. The open list was ordered so that a removal would be O(1), but in the min-heap we must maintain the heap order each time we remove the lowest node. This requires an O(log(n)) operation. Another improvement we made was to use a lookup table for searching the closed list. Each node in the navigation mesh is given an id that corresponds to an index in the lookup table. The A* algorithm also requires a search of the open list to see if a node is on it, so we created a lookup table for the open list as well. The lookup tables will take up some space since you need two arrays, each of which has a length that is equal to the number of nodes in the search space. A single byte can represent each node in the lookup table since all that is required is a true or false value, which will help with space requirements. Our considerations for optimizations were dealing with time complexity, and thus could accommodate an extra data structure for the open list. 3.1 Dynamically Weighted BDBOP The algorithm requires four mechanisms: nodes to represent the environment, the two searches that are needed for the bidirectional functionality, and a coordinator to run the two searches The Coordinator The coordinator is in charge of creating the two searches, running them, and receiving information from them. For openlist is the heap that holds the nodes that can be expanded closedlist is a table that holds expanded nodes currentnode holds the node the search is currently expanding goal is the desination of the search 0.nodesExpanded := 0 1.while (openlist <> Empty AND nodesexpanded < α) 2. currentnode := openlist s popnode() 3. nodesexpanded := nodesexpanded closelist s addnode(currentnode) 5. if (hasgoal(currentnode, goal) = true) 6. finalsolutionstart := currentnode 7. return 1 // currentnode has the goal in it 8. if (doescontainnode(otheragentclosedlist) = true) 9. finalsolutionstart := currentnode 10. return 2 // frontiers meet at currentnode 11. for all k N where N is the set of neighbors for currentnode 12. if (doescontainnode(closedlist, k) = false) 13. g : getcenter(currentnode) getcenter(k) + gfromstart 14. if (doescontainnode(openlist, k) = false) 15. openlist s addnode(k, currentnode, gcost) 16. else 17. lastg := getg(openlist, k) 18. if (g < lastg) 19. openlist s updatenode(k, g) 20. if (openlist = Empty) 21. return -1 // no path is found Figure 2. Pseudocode for each search s dosearch() function reasons we discuss further in the System Design section, we were unable to conduct our two searches in parallel. Therefore, the coordinator runs the searches in alternating successions. If a designer also elects to use alternating successions for the bi-directional aspect of the search, they must choose how many iterations, which we refer to as α, each search completes before switching to the opposite search. Our implementation uses an α defined by the number of polygons in the navigation mesh divided by some constant, ρ. Deciding what value to use for ρ may require some experimentation before finding the appropriate value of α for your particular system. We used a trial and error process, during which we noticed that the statistic affected most by changing the value was nodes visited. We used the value of ρ that kept the average number of nodes visited across all of our environments the lowest. Figure 1 lists pseudocode for the Dynamically Weighted BDBOP algorithm s coordinator The Searches Each of the searches needs an open list, a closed list, a current node, a goal location, and the closed list of the opposite search. The open list is implemented as a min-heap with all of the typical heap operations, with one alteration being that a limit is imposed on the size of the heap. If the size of the heap exceeds the limit after a node is added, the node with the greatest f cost value is removed. Figure 3 demonstrates how the limit can be applied to the open list when adding a new node. This limit lowers the space complexity of the search. One must be careful when choosing the limit because a limit too low can lead to an incomplete search. The open list also uses a lookup table to see if a specific node is in the list and a table to see at what index in the list a node is located. The closed list was implemented as an array of nodes whose indices correspond to the id of each node in the search space.

4 6 Int'l Conf. Artificial Intelligence ICAI'16 n is the max number of nodes the developer wants the list to hold startingh is the distance from the starting node to the goal heap a min-heap that represents the openlist nodesheld is the number of nodes held by the currently heap E is the number of Nodes Expanded to reach the current Node 0. addnode (polygon, parentnode, g) 1. if ( nodesheld = 0) 2. newnode := createanode (polygon,parentnode,g, goal, startingh, 1) 3. else 4. nodesexpanded := getexpandednodesto (parentnode) newnode := createanode (polygon, parentnode, g, goal, startingh, E) 6. if (nodesheld > n) 7. deletemaxnode () 8. heap [nodesheld] := newnode 9. shiftup (nodesheld) Figure 3. Pseudocode for addnode() function on the openlist of a search This allows all searches of the closed list to become O(1) operations. When the coordinator tells a search to execute it gives the search α and the closed list of the opposite search. A search ends when the goal is found, the current node is in the closed list of the opposite search, or the open list is empty. Figure 2 shows the pseudocode for the dosearch() function for each search in Dynamically Weighted BDBOP algorithm. If the iterations complete before any of these conditions are met the search pauses and tells the coordinator that it has not found the goal yet. The coordinator then starts the opposite search, either for the first time or where it previously left off. This continues until one of the searches satisfies an end condition The Node A node holds information about a polygon from the navigation mesh, a reference to its parent node, and the f, g and h costs for the polygon s location in the navigation mesh. The node also calculates the dynamic weight, ω, used on the heuristic. Figure 4 shows pseudocode for calculating the dynamic weight in a node for the Dynamically Weighted BDBOP algorithm. 4 System Design 4.1 Using the Unity 5.1 Game Engine Unity 5.1 [9] provided us a platform for creating 3 dimensional environments and a means to run our experiment on them. All the rendered objects in an environment in Unity are made up of triangles. The navigation mesh was constructed by merging the triangles Unity generated that represent walkable surface area and then subdividing this area into convex polygons until every polygon no longer held a static obstacle. It is worth mentioning that our navigation mesh is a polygonal navigation mesh not strictly a triangular mesh. Once the navigation mesh is completed the polygons node holds the polygon in the navigation mesh that the new node will hold parentnode is the node that this node follows in the solution path g is the cost to get to this node from the start of the search h is the heuristic cost that is used for each node f is the total cost to expand this node E is the number of nodes that were expanded to reach this node ncost is the startingh divided by the smallest polygon length startingh is distance from the starting node to the goal ε is used for the dynamic weight ω is the dynamic weight that is added to the totalcost 0.createANode(polygon, parentnodetoadd, gtoadd, goal,startingh, E) 1. node := polygon 2. g := gcosttoadd 3. parentnode := parentnodetoadd 4. ncost := startingh / getsmallestpolygonlength () 5. if (E <= ncost) 6. ω := 1 (E / ncost) 7. else 8. ω := 0 9. h := getheuristiccosttogoal (node) 10. f := g + ( 1 + (ε * ω)) * h Figure 4. Pseudocode for creating a node with a dynamically weighed heuristic are given to a search to represent the search space. One impact of using Unity to conduct our searches was that Unity discourages the use of user threads. For this reason, we decided to use alternating successions instead of running searches in parallel for the searches that had a bi-directional nature. 4.2 Environments The 11 environments used in our experiment were 3 dimensional environments. These environments encapsulated an agent (the starting point), a goal (the end point) and static obstacles. These obstacles were later cut out of the navigation mesh. The size of the environments and the number of obstacles in the environments varied. Most environments were square, with the exception of two special cases we constructed. One was a horseshoe with the goal and starting point each on opposite ends of the horseshoe. The other was a very long narrow rectangle. Both of these environments yielded interesting results when the searches were tested on them. The number of polygons in the navigation meshes ranged from 32 to 8,173. In general, the more obstacles there are in an environment, the larger the number of polygons in the navigation mesh. 4.3 Data Collection Each search algorithm was run 1000 times on each environment. The following data was collected from each search algorithm for each run: Search time (seconds) Number of nodes expanded

5 Int'l Conf. Artificial Intelligence ICAI'16 7 Max number of nodes in Open List Path length (# of polygons) Path cost (meters) The following data was collected for each environment: Number of initial polygons (before building out of the eleven environments we tested on, losing only by a small margin on the other three environments. The Dynamic Weighting and Bi-Directional components of Dynamically Weighted BDBOP appear to have done their job in reducing the total number of nodes visited by the search. Figure 5 shows the average search time for each algorithm on each of Figure 5. Average search time of each algorithm on each test environment Figure 6. Number of Nodes visited by the 6 search algorithms on 6 test environments navigation mesh) Number of static obstacles Number of final polygons (after navigation mesh is built) 5 Results After comparing the data from the different search algorithms against each other we found that Dynamically Weighted BDBOP was the fastest and visited the fewest nodes in eight Figure 7. Max Open List Size for the 6 search algorithms on 6 test environments the eleven environments. Figure 6 shows the number of nodes visited by each search on six of the different environments. Each environment used relatively equal amounts of space with the exception of Fringe search, which performed poorly in terms of space used. Figure 7 shows the maximum number of nodes in the open list for each search algorithm on six of the eleven environments. The limit imposed on the size of the open list of Dynamically Weighted BDBOP was only reached once during testing. This occurred on the environment with the largest number of final polygons (8,173).

6 8 Int'l Conf. Artificial Intelligence ICAI'16 Figure 8. Xanadu map used for testing DWBDBOP A* Bi-Directional Dynamic Fringe Beam Weighted Polygon Map Size Path Cost (m) Path Cost Path Cost (m) Path Cost (m) Path Cost(m) Path Cost Count (m 2 ) (m) (m) , , , , , , ,760, , Figure 9. Path costs for each search on 10 test environments Fringe search performed consistently worse than the other searches except on environments that consisted of long narrow corridors. Our testing included two such environments. One is a straight and narrow path 120 meters wide and 23 kilometers long, the other resembles a horseshoe (Xanadu, shown in Figure 8) and is about 2.8 kilometers in total length. Even though Fringe Search did not perform the best among all the algorithms on these two environments, Fringe search s performance disparity between different types of environments demonstrated that certain searches are better suited for certain environments than for others. Naturally, a game developer will want to pick the appropriate search for any given environment. On an environment such as Xanadu the heuristic is telling the search to go in a direction that it cannot for nearly half the search leading to inefficiency. An intermediary goal in the middle of the horseshoe would help the performance of A* by improving the accuracy of the heuristic in deciding which node to expand next. The next step in our testing would be to increase the number and diversity of environments we run the search algorithms on in order to get a better idea of the strengths and weaknesses of each search. We hope to discover another unique situation that we can learn from, such as the one we encountered with Fringe Search. The knowledge gained from analyzing such performance anomalies may lead to further methods for improving the searches. 6 Discussion Dynamically Weighted BDBOP is the fastest of the searches we tested, but does not always give an optimal path. The need for an optimal path in video games is not always the number one concern. Quite often a developer will prefer a faster search with a near optimal path to a slower search with an optimal path. Figure 9 shows the path costs for all the search algorithms on several of the environments along with the environment size and polygon count. Dynamically Weighted BDBOP s path cost is very close to optimal in nearly all cases and even achieves an optimal solution in four of the environments. There was one environment where Dynamically Weighted BDBOP s path cost had a 36 percent difference from the optimal path cost. This was on the map with highest polygon count (8,173), encompassing 500,000 square meters. The regular Dynamically Weighted search also performed poorly on this map in terms of path cost. Environments with such high polygon counts are very

7 Int'l Conf. Artificial Intelligence ICAI'16 9 uncommon in video games. For example, Unity 5.1 has a limit of 228 polygons for navigations meshes built with Unity s nav mesh baker [9], and games like Jak and Daxter have a maximum polygon count of 256, with meshes rarely exceeding 64 polygons [10]. Further testing on a larger set of environments that are similar to those used in video games today will provide a better understanding of Dynamically Weighted BDBOP s viability as a path-finding algorithm in video games. The speed increase Dynamically Weighted BDBOP has over traditional A* can help video game developers with the CPU constraints. With video games becoming more complex for systems to run, the constraints they put on CPUs are becoming a bigger problem. These constraints leave limited resources for other video game requirements such as artificial intelligence. With Dynamically Weighted BDBOP the developer has more resources available after a path is found to handle more complex tasks like decision making for NPCs. This is due to how fast Dynamically Weighted BDBOP can complete a search and give a path back to an agent. A* took on average over a tenth of a second on larger environments and then over two seconds to complete the path on the environment with the largest polygon count (8,173). This would put a major lag in the game. Dynamically Weighted BDBOP on the other hand never took longer than two hundredths of a second to complete a search. 7 Conclusion and Future Work As video games continue to advance, they are becoming more and more computationally complex, requiring faster hardware and more efficient algorithms to achieve desired performance. Our research focused on improving the efficiency of a typical path-finding method used in video games. Representation of the environment was the first consideration. The use of a navigation mesh instead of a square grid allowed us to reduce the search space. Next we examined the performance of several search algorithms and proposed a variation to A*, which we termed Dynamically Weighted BDBOP. The top performer among the searches we tested was Dynamically Weighted BDBOP, which had the lowest average search time. The various alterations we made to the search algorithms and data structures demonstrated what mechanisms lowered the total search time, which mechanisms increased search time and possible areas for further improvement. Our future work will be to continue testing and modifying the search algorithms to enhance efficiency. One path involves comparing Bi-Directional search run in parallel against Bi-Directional Search run in alternating successions. We would also like to see how the performance of Bi- Directional Search is affected when the search goal is updated to the opposite search s current node every time that current node changes. Also, we would like to explore if Dynamically Weighted BDBOP would place a lag in the system during path-finding for multiple NPCs at the same time. For testing we would like to use a much larger set of environments, and would prefer to use environments that are typical of those used in the latest video games. Our hope is that further testing and experimentation with the search algorithms will lead to improvements in efficiency that can be beneficial to the video game industry and, more generally, other path-finding applications. 8 References [1] Xiao Cui and Hao Shi, Direction Oriented Pathfinding in Video Games, IJAIA, Vol. 2, No. 4, October [2] Xiao Cui and Hao Shi, An Overview of Pathfinding in Navigation Mesh, IJCSNS, Vol. 12, No. 12, December, [3] P. Tozour, Building a Near-Optimal Navigation Mesh, in AI Game Programming Wisdom, vol. 1. Rockland, MA: Charles River Media, 2002, ch. 2, sec. 3, pp [4] G. Snook, Simplified 3d Movement and Pathfinding Using Navigation Meshes, in Game Programming Gems, vol. 1. Boston, Ma: Cengage Learning, 2000, ch. 3, sec. 6, pp [5] Y. Bjornsson, M. Enzenberger, R. C. Holte and J. Schaeffer, "Fringe search: Beating A* at Pathfinding on Game Maps", IEEE CIG'05, 2005, pp [6] Andru Putra Twinanda, Fringe search vs A* for NPC movement, School of Electrical dan Informatics Engineering Institut Teknologi Bandung, Bandung, Indonesia, [7] Amit Patel, Amit s A* Pages [Online], Available: accessed April 9, [8] S. Rabin, A* Speed Optimizations, in Game Programming Gems, vol. 1. Boston, Ma: Cengage Learning, 2000, ch. 3, sec. 5, pp [9] Unity Online Manual [Online], Available: accessed April 9, [10] S. White and C. Christensen, A Fast Approach to Navigation Meshes, in Game Programming Gems, vol. 3. Boston, Ma: Cengage Learning, 2002, ch. 3, sec. 6, pp