A rtificial I ntelligence for Games

1. Artificial Intelligence for Games Minor Games Programming Lecture 3

2. Artificial Intelligence for Games • Theory: • Graphs (Chapter 5) • Path Planning (Chapter 8) Jan Verhoeven j.verhoeven@windesheim.nl

3. Theory: Graphs,(see study book: chapter 5) • Graphs • Graphs in Game AI • Graph Search Algorithms • (DFS, BFS, Dijkstra)  self study • A*

4. Examples of graphs Which figures are? A graph A tree A forest A connected graph An unconnected graph

5. A navigation graph (navgraph)

6. Finding (shortest) path in a Maze

7. Finding (shortest) path in a Maze

8. State Graphs

10. A sliding puzzle

11. http://www.gizdic.com/freegames/gamespages/wolf_sheep_cabbage.htmhttp://www.gizdic.com/freegames/gamespages/wolf_sheep_cabbage.htm

12. Graph search algorithms • Visit every node in a graph • Find any path between two nodes • Find the best path between two nodes

13. Self study or previous knowledge • BFS • DFS • Dijkstra • READ THE FOLLOWING SLIDES

14. Depth First Search Last-in first-out We continue expanding the most recent edge until we run out of edges no edges out or all edges point to visited nodes Then we "backtrack" to the next edge and keep going

15. Characteristics Can easily get side-tracked into non-optimal paths Very sensitive to the order in which edges are added Guaranteed to find a path if one exists Low memory costs only have to keep track of current path nodes fully explored can be discarded Typical Complexity Time: O(E/2) Space: O(1) assuming paths are short relative to the size of the graph

16. Optimality • DFS does not find the shortest path • returns the first path it encounters • If we want the shortest path • we have to keep going • until we have expanded everything

17. Breadth-first search First-in first-out Expand nodes in the order in which they are added don't expand "two steps" away until you've expanded all of the "one step" nodes

18. Characteristics Will find shortest path Won't get lost in deep trees Can be memory-intensive frontier can become very large especially if branching factor is high Typical Complexity Time: O(p*b) Space: O(E)

19. What if edges have weight? If edges have weight then we might want the lowest weight path a path with more nodes might have lower weight Example a path around the lava pit has more steps but you have more health at the end compared to the path that goes through the lava pit

20. Weighted graph 1 v2 v1 1 1 5 3 1 v5 v4 v3 3 3 v1 v2 v3 v4 v5 v6 v7 2 2 1 0 1 1 5 0 0 0 v1 0 0 0 3 1 0 0 v6 v7 v2 2 0 0 0 0 0 1 0 v3 0 0 1 0 0 3 2 v4 v5 v6 v7

21. Dijkstra • Edgar Dijkstra (most famous Dutch computer scientist) • Dijkstra’s algorithm builds a shortest path.

22. A* • Dijkstra with a Twist: A*, includes an heuristic: the Euclidean distance • (variant: Manhattan Distance Heuristic). • See !! : http://en.wikipedia.org/wiki/A*_search_algorithm

23. A* in pseudo code …………;-) function A*(start,goal) closedset := the empty set // The set of nodes already evaluated. openset := set containing the initial node // The set of tentative nodes to be evaluated. g_score[start] := 0 // Distance from start along optimal path. h_score[start] := heuristic_estimate_of_distance(start, goal) f_score[start] := h_score[start] // Estimated total distance from start to goal through y. while openset is not empty x := the node in openset having the lowest f_score[] value if x = goal return reconstruct_path(came_from,goal) remove x from openset add x to closedsetforeach y in neighbor_nodes(x) if y in closedset continue tentative_g_score := g_score[x] + dist_between(x,y) if y not in openset add y to opensettentative_is_better := true elseiftentative_g_score < g_score[y] tentative_is_better := true else tentative_is_better := false if tentative_is_better = true came_from[y] := x g_score[y] := tentative_g_scoreh_score[y] := heuristic_estimate_of_distance(y, goal) f_score[y] := g_score[y] + h_score[y] return failure

24. Manhattan Distance

25. Graphs:Pathfinderdemo

26. DEMO Please do it now: • Run the pathfinder demo and experiment the different search algorithms. Also insert obstacles, mud and water ….

27. Theory: Path Planning,(see study book: chapter 8) • Navigation Graph Construction • Raven Navigation Graph • Creating a Path Planner Class • Sticky Situations

28. Navigation Graph Construction Points of Visibility (POV) navigation graph: Created by hand or Using expanded geometry techniques

29. Creating a POV using expanded geometry

30. NavMesh = network of convex polygons

31. Coarsely Granulated Graphs If a game restricts its agents to movement along the edges of a navigation graph only, such as the movement of the characters in the Pac-Man range of games ,then a coarsely granulated navgraph is the perfect choice.

32. Effect 1: Unsightly paths The path of an agent moving from its current position to the one marked by the X. Nasty.

33. Effect 2: Invisible positions

34. Run the CourseGraph demo

35. Finely Grained Graphs Can be generated using the Flood Fill Algorithm

36. Flood Fill Algorithm

37. Spatial Partitioning !! • One of the most frequently used methods of a path planning class is a function that determines the closest visible node to a given position. • The performance will be in O(n2) time. • As you saw in chapter 3, the efficiency of such searches can be improved by using a spatial partitioning technique such as cell-space partitioning.

38. Planning a path to a position The path planner must: • Find the closest visible unobstructed graph node to the bot's current location. • Find the closest visible unobstructed graph node to the target location. • Use a search algorithm to find the least cost path between the two.

39. Planning a path to a position A* is the better algorithm to search for the least cost path from the bot's current position to a specific target position

40. Planning a path to an item type When many similar item types are present, Dijkstra's algorithm is the better choice

41. Paths as Nodes or Paths as Edges? The game design requires that agents must change to the "swim" behavior when traveling from A to B (or vice versa), so the nodes A and B are annotated to reflect this. Do you see the problem?

42. Path Smoothing, Rough but Quick

43. Path Smoothing • (A) Rough and Quick: • See figures 8.13 thru 8.17 for an example of the algorithm • (B) Precise but Slow: • See figure 8.18 and the corresponding text

44. RUN PathSmoothing Demo

45. Methods for Reducing CPU Overhead • Precalculated Paths • Precalculated Costs • Hierarchical Pathfinding And: • Time-Sliced Path Planning (you can skip the code of pages 363-372)

46. Precalculated Paths

47. Precalculated Costs

48. Time-Sliced Path Planning • An alternative to precalculating lookup tables to lighten the CPU load is to allocate a fixed amount of CPU resources per update step for all the search requests and to distribute these resources evenly between the searches. • This is achieved by dividing up the searches over multiple time steps, a technique known as time slicing

49. Preventing the Twiddling of Thumbs • One consequence of time-sliced path planning is that there will be a delay from the time an agent requests a path to the time it receives notification that the search has been successful or unsuccessful.