A* Reference: “Artificial Intelligence for Games”, Ian Millington.

Goals Find a “pretty- short” path from point A to point B. – The best path is often prohibitively expensive to find. S G

Graph-based algorithm Graph – Vertices (Nodes) – Edges Single edge Double edge Cost – (For map traversal), distance is the norm – Cost multiplier (>1) for rough terrain. Representation – Adjacency Matrix – Adjacency List

Graph Nodes vs. Search Nodes Graph Start == 0, Goal == 6 Search Tree There are usually many search trees for the same graph. 2.0

Graph Nodes vs. Search Nodes, cont. One approach: – GraphNode(id, …) Id … Neighbor_refs = […] # Or this could be stored in map – SearchNode(graphNode, parent) Parent is None for the starting node Create a search node as you traverse the graph.

Depth-first search S G Need a (bool) visited value for each graph node (to prevent re-visiting). Visit a (“random”) new node from the current node. Total Cost is the edge cost of all edges traversed. We have to try all possible search graphs to find the least costly path – EXPENSIVE! Total=17 Total=19

Breadth-first search S G Need a list of “frontier” nodes and a (bool) visited flag. Expand the frontier by one hop each iteration. We end up with several search trees. Problem: A lot of search trees – MEMORY + TIME INTENSIVE (especially for large graphs). The search trees are dependent on the graph structure (2=>6 vs 0=>6)

Heuristics (dictionary.reference.com) Pertaining to a trial- and-error method of problem solving used when an algorithmic approach is impractical. In A*: an estimate of how far a given node is from the goal state. – Accuracy is critical to good performance of A* – For path-finding, often the straight-line distance. We'll store 3 things for each search node: – The parent search node (if any) – The cost-so-far value – The cost-heuristic

OPEN, CLOSED “lists” We'll maintain two "lists" of search nodes: – OPEN: Those on the search "frontier" – CLOSED: Those we've already visited – anything not on these lists is unexplored The graph node doesn't have a search node. Often more efficient to maintain: – A Priority Queue for OPEN – A state variable for each search node (OPEN or CLOSED)

A* Algorithm 1.Create search node for Start Node a)Parent = None b)Cost-so-far = 0 c)Heuristic = (distance to goal) 2.Add this new node to OPEN 3.Repeat these steps until OPEN isn’t empty. a)Take the best node, C, off OPEN i.If C is the goal, construct a Graph-node sequence and return. ii.If not, add C to CLOSED. b)Repeat for each of C's neighbors, N: i.If N is unexplored, create a Search Node for it and add it to OPEN. ii.If N is on OPEN and path from C c.s.f. + cost(C,N) < N c.s.f. : – Update the parent and cost-so-far of N – Reheapify that node on OPEN iii.If N is on CLOSED and path from C c.s.f. + cost(C,N) < N c.s.f. : – remove it from CLOSED and put it on OPEN – Update the parent and cost-so-far of N 4.Return False (no path found)

MinHeap + A* A* uses this as its "metric" CostSoFar (actual cost from start to this node) + Heuristic (estimated cost from this node to the goal) Note: The heuristic is almost always an under- estimate. So…we give priority to those nodes that appear to take us closer to the goal.

Under-/over-estimating heuristic Very important to get as close as possible! – Too high => find a "bad" path before a "good" – Too low => look at too many nodes.

Nav-Meshes A common way to represent: – Walkable areas of a map. – Cover-spots – Jumping-points (to cross a chasm) – Ladders – Save points, ammo drops, etc. Key Ideas: – Not usually visible – Usually much lower poly-count than the actual ground

Nav-Meshes, cont. Display Mesh (16541 faces) Nav Mesh (301 faces)

Nav-Meshes, cont. We can use these for pathfinding… – Nodes are faces (their center?) – Edges are connections between neighboring faces Cost is just the euclidean distance between centers. Probably best done off-line – Finding neighbors can be costly.

Another application of A* … … … … … … … … … … Hueristic?