3.3 Pathfinding Design Architecture 저 자 : Dan Higgins 발표자 : 김용욱

Abstract Hundreds of units could pathfind without bogging down the system How to split paths up over time? Keep the user believing that paths are computed instantaneously

Terms A* machine : Generic A* engine described in article 3.2 Unit Anything else that wish to pathfind from one point to another Node A* node which encompasses information like Position, cost Pathfinding revolution Single iteration through the A* engine’s main loop Out-of-sync It occurs in network game, the game ceases to be the same. Major problem for multi-player games

The Road to Cross The first of many hurdles to cross “Game freeze” – plague of pathfinders In large map, A* consume much time Time-sliced pathfinding Split the paths up over time In the real-time strategy game, giant maps, thousands of units by using a three-step path architecture Quick path Full path Splice path

Quick path To get unit moving To respond quickly High speed short-distance pathfinder To buy us time to compute the real path in the background How works? 10 revolution limit Five-tile path is generated

Full path The real deal Search thousands of A* nodes to find the correct path Put the full path on the pathfinding queue

Splice path When quick path and full path are completed Path = quick path + full path Correct and Smooth out The errors made by the quick path High-speed path Same as quick path From the unit’s current position To some point further down the complete path

Splice path

Priority paths What happens? If a unit gets to the end of its quick path before the full path is finished computing How it works? Takes the unit out of the pathfinding queue Sets its max revolutions cap a little bit higher Then finishes the path

Managing the paths Single revolution 1. Get the cheapest node 2. Look at its neighbors 3. Put the node on the closed list Path manager Use revolutions to balance performance Path manager update Consists of performing X number of overall revolution per game tick

Managing the paths Time-slicing technique Equal time Divide the revolutions by the number of paths in the queue All pathfinding engines get an equal amount of processing time each tick Progressive Start with a low number of max revolutions per tick Each time through the queue, this number should get larger Biased In order to get quick paths for the user

3.4 How to Achieve Lightning-Fast A*

Abstract A* optimization Implementing the pathfinding engine Focus on high-level and low-level optimization Speed up optimization

Optimization High-level Redefine search space Bound the amount of A* node flooding Group pathfinding Low-level C++ optimization

For fast A* Don't use STL while STL is amazing, pathfinding warrants a hand-written linked-list and hash-table system Memory pool Use limits on your pools to handle typical situations

For fast A* Caching make a flags Flags array to indicate the state of each node The array is 1 byte per tile The incredible lookup speed and optimization Clear unexamined Passablepassable for A* Blockednot passable for A* open in open list Closedin closed list

For fast A* Sliding window if you can't afford the memory to dedicate to a flags array try using a sliding window system

For fast A* Hash table transform open and closed lists into hash tables Make sure to play with the hash function Cheapskate Use a cheap list Sorted heap structure - Slow insertion, Fast removal Unsorted list - Fast insertion, slow removal Cheap list List of 15 node that are the cheapest on the open list Search for the cheapest node on the Open list

For fast A* Fast storage Used more memory Only one fast-storage pathfinder for entire game An array of pointers to nodes for searches long-distance pathfinders use STL map, hash_map, hash_set To store all nodes for fast lookups