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

Int'l Conf. Artificial Intelligence | ICAI'16 | 3

John P. Baggs, Matthew Renner and Eman El-Sheikh Department of Computer Science, University of West Florida, Pensacola, FL, USA

A path-finding algorithm requires the following: a start Abstract – Video games are becoming more computationally point, an end point, and a representation of the environment complex. This requires video game designers to carefully in which the search is to take place. Today, the two main allocate resources in order to achieve desired performance. methods environments are represented in video games are This paper describes the development of a new alternative to with square grids and navigation meshes. Square grids take a traditional A* that decreases the time to find a path in three- specific section of space in the environment and map the dimensional environments. We developed a system using Unity space to a matrix location. The matrix has to be large enough 5.1 that allowed us to run multiple search algorithms on to contain the number of squares needed to represent the different environments. These tests allowed us to find the environment. Navigation meshes were developed in the 1980s strengths and weaknesses of the variations of traditional A*. for robotic path-finding and most games after the 2000s have After analyzing these strengths, we defined a new alternative adopted these navigation meshes. In [3], a navigation mesh is algorithm named Dynamically Weighted BDBOP that defined as “…a set of convex polygons that describe the performed faster than A* search in our experiments. Using walkable surface of a 3-dimensional environment”. this search, video game developers can focus the limited resources on more complex tasks. 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. Keywords: A*, Navigation Mesh, Path-finding, Dynamically However, at the same time, the number of squares increases

Weighted BDBOP, Video Games the search space for the path-finding algorithm. As the search

space increases, the time complexity increases. Another issue 1 Introduction with square grids is that the squares are laid on top of non- movable or static obstacles. Because the obstacles are Path-finding algorithms are used in many Computer Science represented in the grid, collision detection is required during application areas, including robotics and video games. One of path-finding. Navigation meshes directly address these two the most popular path-finding algorithms used is the A* challenges. A navigation mesh represents the environment search. A* is an improvement on Dijkstra’s shortest path with polygons that are completely free of obstacles. This algorithm. The improvement significantly cuts down the condition, and the condition that all polygons are convex, number of nodes that need to be visited during the search. A removes the need for collision detection anywhere inside a decrease in the number of nodes correlates directly with a polygon [4]. There is no restriction on the size that a polygon decrease in the space and time complexities of the search. can be as long as the rules of being convex and obstacle free A*’s improvement upon Dijkstra’s algorithm comes from the are maintained. A navigation mesh search space consists of use of a heuristic method to reduce the search space [1]. significantly fewer nodes than the square grid search space for the same environment. For these reasons, our research Today, video games require an enormous amount of focuses on developing and implementing a navigation mesh computational resources. A majority of these resources are for experimentation with path-finding algorithms. dedicated to graphics rendering and calculations in the physics engine [2]. Given these limited resources, all This paper summarizes two main contributions: computational components of video games must be optimized 1. Results and conclusions from an experiment comparing for speed and memory management. Path-finding, a different path-finding algorithms on a set of three- component of non-player character (NPC) intelligence, is a dimensional environments developed using Unity 5.1. We computationally intensive task; therefore it is essential to implemented A* and popular variations of A*. These variants improve the path-finding computational efficiency. Because include Bi-Directional A*, Fringe search, optimized versions of it’s search speed, A* is one of the most widely used path- of traditional A*, Beam search, Dynamically Weighted A*, finding algorithms in the video game industry. This research and Bi-Directional A*. During the experiment, each search addresses improving the efficiency of path-finding was run on each environment 1000 times, collecting data for a algorithms. comparison of each search algorithm’s performance on a given environment.

ISBN: 1-60132-438-3, CSREA Press © 4 Int'l Conf. Artificial Intelligence | ICAI'16 |

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

ISBN: 1-60132-438-3, CSREA Press © Int'l Conf. Artificial Intelligence | ICAI'16 | 5

agentToGoal is the search starting from the agent and going to the goal openList is the heap that holds the nodes that can be expanded goalToAgent is the search starting from the goal and going to the agent closedList is a table that holds expanded nodes ρ is a constant that will divide the number of polygons to get the number currentNode holds the node the search is currently expanding of times each search will iterate goal is the desination of the search α is the number of iteration (# of Polygons / ρ) 0.nodesExpanded := 0 0.while (pathFound = false) 1.while (openList <> Empty AND nodesExpanded < α) 1. if (α <= 1) 2. currentNode := openList’s popNode() 2. returnValue := agentToGoal’s doSearch (# of Polygons *2) 3. nodesExpanded := nodesExpanded + 1 3. if(returnValue = 1) // goal was found 4. closeList’s addNode(currentNode) 4. pathFound := true 5. if (hasGoal(currentNode, goal) = true) 5. else 6. finalSolutionStart := currentNode 6. no path can be found 7. return 1 // currentNode has the goal in it 7. else 8. if (doesContainNode(otherAgentClosedList) = true) 8. returnValue := agentToGoal’s doSearch(α) 9. finalSolutionStart := currentNode 9. if (returnValue = 1) // goal was found 10. return 2 // frontiers meet at currentNode 10. pathFound := true 11. for all k ∈ N where N is the set of neighbors for currentNode 11. else if (returnValue = 2) // a frontier connection was found 12. if (doesContainNode(closedList, k) = false) 12. pathFound := true 13. g : getCenter(currentNode) – getCenter(k) + gFromStart 13. else if (returnValue = -1) // openList is empty no path is found 14. if (doesContainNode(openList, k) = false) 14. no path can be found 15. openList’s addNode(k, currentNode, gCost) 15. else 16. else 16. returnValue := goalToAgent’s doSearch(α) 17. lastG := getG(openList, k) 17. if (returnValue = 1) // agent was found 18. if (g < lastG) 18. pathFound := true 19. openList’s updateNode(k, g) 19. else if (returnValue = 2) // a frontier connection was found 20. if (openList = Empty) 20. pathFound := true 21. return -1 // no path is found 21. else if (returnValue = -1) // openList is empty no path is found 22. no path can be found Figure 2. Pseudocode for each search’s doSearch() function

Figure 1. Pseudocode for the coordinator of reasons we discuss further in the System Design section, we Dynamically Weighted BDBOP were unable to conduct our two searches in parallel. Therefore, the coordinator runs the searches in alternating The main improvement made to the data structures used for successions. If a designer also elects to use alternating A* was to use a min-heap for retrieving the node in the open successions for the bi-directional aspect of the search, they list with the lowest cost value. Inserting into the open list goes must choose how many iterations, which we refer to as α, from an O(n) operation to an O(log(n)) operation [8]. The each search completes before switching to the opposite search. open list was ordered so that a removal would be O(1), but in Our implementation uses an α defined by the number of the min-heap we must maintain the heap order each time we polygons in the navigation mesh divided by some constant, ρ. remove the lowest node. This requires an O(log(n)) operation. Deciding what value to use for ρ may require some Another improvement we made was to use a lookup table for experimentation before finding the appropriate value of α for searching the closed list. Each node in the navigation mesh is your particular system. We used a trial and error process, given an id that corresponds to an index in the lookup table. during which we noticed that the statistic affected most by The A* algorithm also requires a search of the open list to see changing the value was nodes visited. We used the value of ρ if a node is on it, so we created a lookup table for the open list that kept the average number of nodes visited across all of our as well. The lookup tables will take up some space since you environments the lowest. Figure 1 lists pseudocode for the need two arrays, each of which has a length that is equal to the Dynamically Weighted BDBOP algorithm’s coordinator. number of nodes in the search space. A single byte can represent each node in the lookup table since all that is 3.1.2 The Searches required is a true or false value, which will help with space requirements. Our considerations for optimizations were Each of the searches needs an open list, a closed list, a current dealing with time complexity, and thus could accommodate an node, a goal location, and the closed list of the opposite extra data structure for the open list. search. The open list is implemented as a min-heap with all of the typical heap operations, with one alteration being that a 3.1 Dynamically Weighted BDBOP 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 The algorithm requires four mechanisms: nodes to represent greatest f cost value is removed. Figure 3 demonstrates how the environment, the two searches that are needed for the bi- the limit can be applied to the open list when adding a new directional functionality, and a coordinator to run the two node. This limit lowers the space complexity of the search. searches. One must be careful when choosing the limit because a limit too low can lead to an incomplete search. The open list also 3.1.1 The Coordinator 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 The coordinator is in charge of creating the two searches, closed list was implemented as an array of nodes whose running them, and receiving information from them. For indices correspond to the id of each node in the search space.

ISBN: 1-60132-438-3, CSREA Press © 6 Int'l Conf. Artificial Intelligence | ICAI'16 |

n is the max number of nodes the developer wants the list to hold node holds the polygon in the navigation mesh that the new node will startingH is the distance from the starting node to the goal hold heap a min-heap that represents the openList parentNode is the node that this node follows in the solution path nodesHeld is the number of nodes held by the currently heap g is the cost to get to this node from the start of the search E is the number of Nodes Expanded to reach the current Node h is the heuristic cost that is used for each node 0. addNode (polygon, parentNode, g) f is the total cost to expand this node 1. if ( nodesHeld = 0) E is the number of nodes that were expanded to reach this node 2. newNode := createANode (polygon,parentNode,g, goal, startingH, 1) nCost is the startingH divided by the smallest polygon length 3. else startingH is distance from the starting node to the goal 4. nodesExpanded := getExpandedNodesTo (parentNode) + 1 ε is used for the dynamic weight 5. newNode := createANode (polygon, parentNode, g, goal, startingH, E) ω is the dynamic weight that is added to the totalCost 6. if (nodesHeld > n) 0.createANode(polygon, parentNodeToAdd, gToAdd, goal,startingH, E) 7. deleteMaxNode () 1. node := polygon 8. heap [nodesHeld] := newNode 2. g := gCostToAdd 9. shiftUp (nodesHeld) 3. parentNode := parentNodeToAdd 4. nCost := startingH / getSmallestPolygonLength () Figure 3. Pseudocode for addNode() function on the openList 5. if (E <= nCost) of a search 6. ω := 1 – (E / nCost) 7. else This allows all searches of the closed list to become O(1) 8. ω := 0 operations. When the coordinator tells a search to execute it 9. h := getHeuristicCostToGoal (node) gives the search α and the closed list of the opposite search. A 10. f := g + ( 1 + (ε * ω)) * h 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 4. Pseudocode for creating a node with a Figure 2 shows the pseudocode for the doSearch() function for dynamically weighed heuristic each search in Dynamically Weighted BDBOP algorithm. If the iterations complete before any of these conditions are met are given to a search to represent the search space. One impact the search pauses and tells the coordinator that it has not of using Unity to conduct our searches was that Unity found the goal yet. The coordinator then starts the opposite discourages the use of user threads. For this reason, we search, either for the first time or where it previously left off. decided to use alternating successions instead of running This continues until one of the searches satisfies an end searches in parallel for the searches that had a bi-directional condition. nature.

3.1.3 The Node 4.2 Environments A node holds information about a polygon from the The 11 environments used in our experiment were 3 navigation mesh, a reference to its parent node, and the f, g dimensional environments. These environments encapsulated and h costs for the polygon’s location in the navigation mesh. an agent (the starting point), a goal (the end point) and static The node also calculates the dynamic weight, ω, used on the obstacles. These obstacles were later cut out of the navigation heuristic. Figure 4 shows pseudocode for calculating the mesh. The size of the environments and the number of dynamic weight in a node for the Dynamically Weighted obstacles in the environments varied. Most environments were BDBOP algorithm. 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 4 System Design 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 4.1 Using the Unity 5.1 Game Engine ranged from 32 to 8,173. In general, the more obstacles there Unity 5.1 [9] provided us a platform for creating 3 are in an environment, the larger the number of polygons in dimensional environments and a means to run our experiment the navigation mesh. on them. All the rendered objects in an environment in Unity are made up of triangles. The navigation mesh was 4.3 Data Collection constructed by merging the triangles Unity generated that Each search algorithm was run 1000 times on each represent walkable surface area and then subdividing this area environment. The following data was collected from each into convex polygons until every polygon no longer held a search algorithm for each run: static obstacle. It is worth mentioning that our navigation mesh is a polygonal navigation mesh not strictly a triangular • Search time (seconds) mesh. Once the navigation mesh is completed the polygons • Number of nodes expanded

ISBN: 1-60132-438-3, CSREA Press © Int'l Conf. Artificial Intelligence | ICAI'16 | 7

• Max number of nodes in Open List out of the eleven environments we tested on, losing only by a • Path length (# of polygons) small margin on the other three environments. The Dynamic • Path cost (meters) Weighting and Bi-Directional components of Dynamically Weighted BDBOP appear to have done their job in reducing The following data was collected for each environment: the total number of nodes visited by the search. Figure 5 • Number of initial polygons (before building 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 Figure 7. Max Open List Size for the 6 search algorithms on algorithms on 6 test environments 6 test environments

navigation mesh) the eleven environments. Figure 6 shows the number of nodes • Number of static obstacles visited by each search on six of the different environments. • Number of final polygons (after navigation mesh is Each environment used relatively equal amounts of space built) with the exception of Fringe search, which performed poorly in terms of space used. Figure 7 shows the maximum number 5 Results of nodes in the open list for each search algorithm on six of the eleven environments. The limit imposed on the size of the After comparing the data from the different search algorithms open list of Dynamically Weighted BDBOP was only reached against each other we found that Dynamically Weighted once during testing. This occurred on the environment with BDBOP was the fastest and visited the fewest nodes in eight the largest number of final polygons (8,173).

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 (m2) (m) (m) 4 400 20.01665 20.01665 20.01665 20.01665 20.01665 20.01665 25 400 29.2007 29.2007 29.2007 29.2007 29.2007 29.2007 32 1,200 58.10884 48.336 48.336 55.96035 48.336 48.336 64 1,200 63.57973 63.57973 63.57973 63.57973 66.07505 63.57973 151 3,600 103.7901 90.30271 90.30271 103.7901 100.5537 90.30271 1473 200,400 3862.1 3437.157 3445.417 3760.751 3474.831 3437.157 3068 89,600 676.8464 642.2347 643.4597 681.0273 700.7254 642.2347 4202 250,000 1483.118 1483.118 1483.118 1483.118 1483.118 1483.118 5903 2,760,000 31495.76 31376.67 31376.67 31495.76 32732.87 31376.67 8173 500,000 5809.746 4004.154 4005.499 5312.438 4050.381 4004.154 Figure 9. Path costs for each search on 10 test environments

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

uncommon in video games. For example, Unity 5.1 has a limit would prefer to use environments that are typical of those of 228 polygons for navigations meshes built with Unity’s nav used in the latest video games. Our hope is that further testing mesh baker [9], and games like ‘Jak and Daxter’ have a and experimentation with the search algorithms will lead to maximum polygon count of 256, with meshes rarely improvements in efficiency that can be beneficial to the video exceeding 64 polygons [10]. Further testing on a larger set of game industry and, more generally, other path-finding environments that are similar to those used in video games applications. today will provide a better understanding of Dynamically Weighted BDBOP’s viability as a path-finding algorithm in video games. 8 References The speed increase Dynamically Weighted BDBOP has [1] Xiao Cui and Hao Shi, “Direction Oriented Pathfinding over traditional A* can help video game developers with the in Video Games”, IJAIA, Vol. 2, No. 4, October 2011. CPU constraints. With video games becoming more complex for systems to run, the constraints they put on CPUs are [2] Xiao Cui and Hao Shi, “An Overview of Pathfinding in becoming a bigger problem. These constraints leave limited Navigation Mesh”, IJCSNS, Vol. 12, No. 12, December, resources for other video game requirements such as artificial 2012. intelligence. With Dynamically Weighted BDBOP the developer has more resources available after a path is found to [3] P. Tozour, “Building a Near-Optimal Navigation Mesh,” handle more complex tasks like decision making for NPCs. in AI Game Programming Wisdom, vol. 1. Rockland, MA: This is due to how fast Dynamically Weighted BDBOP can Charles River Media, 2002, ch. 2, sec. 3, pp. 171-185. complete a search and give a path back to an agent. A* took on average over a tenth of a second on larger environments [4] G. Snook, “Simplified 3d Movement and Pathfinding and then over two seconds to complete the path on the Using Navigation Meshes,” in Game Programming Gems, environment with the largest polygon count (8,173). This vol. 1. Boston, Ma: Cengage Learning, 2000, ch. 3, sec. 6, pp. would put a major lag in the game. Dynamically Weighted 288-304. BDBOP on the other hand never took longer than two hundredths of a second to complete a search. [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. 125-132.

7 Conclusion and Future Work [6] Andru Putra Twinanda, “Fringe search vs A* for NPC As video games continue to advance, they are becoming more movement “, School of Electrical dan Informatics Engineering and more computationally complex, requiring faster hardware Institut Teknologi Bandung, Bandung, Indonesia, 2008. and more efficient algorithms to achieve desired performance. Our research focused on improving the efficiency of a typical [7] Amit Patel, Amit’s A* Pages [Online], Available: path-finding method used in video games. Representation of http://theory.stanford.edu/~amitp/GameProgramming/, the environment was the first consideration. The use of a accessed April 9, 2016. navigation mesh instead of a square grid allowed us to reduce [8] S. Rabin, “A* Speed Optimizations,” in Game the search space. Next we examined the performance of Programming Gems, vol. 1. Boston, Ma: Cengage Learning, several search algorithms and proposed a variation to A*, 2000, ch. 3, sec. 5, pp. 272-287. which we termed Dynamically Weighted BDBOP. The top performer among the searches we tested was Dynamically [9] Unity Online Manual [Online], Available: Weighted BDBOP, which had the lowest average search time. https://unity3d.com/unity/whats-new/unity-5.0, accessed April The various alterations we made to the search algorithms and 9, 2016. data structures demonstrated what mechanisms lowered the total search time, which mechanisms increased search time [10] S. White and C. Christensen, “A Fast Approach to and possible areas for further improvement. Navigation Meshes,” in Game Programming Gems, vol. 3. Our future work will be to continue testing and modifying Boston, Ma: Cengage Learning, 2002, ch. 3, sec. 6, pp. 307- the search algorithms to enhance efficiency. One path 320. 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