3.3Pathfinding Design Architecture

저 자 : Dan Higgins

발표자 : 김용욱

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

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 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

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