3.3 pathfinding design architecture 저 자 : dan higgins 발표자 : 김용욱
Post on 31-Dec-2015
221 Views
Preview:
TRANSCRIPT
Abstract Hundreds of units could pathfind without bogging dow
n 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 unit
s 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
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
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 situation
s
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
Passable passable for A*
Blocked not passable for A*
open in open list
Closed in 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
top related