1. Oct 6, Fall 2005Game Design1 AI in games Simple steering, Flocking Production rules FSMs, Probabilistic FSMs Path Planning, Search Unit Movement Formations

2. Oct 6, Fall 2005 Game Design2 AI in video games  5-10% of CPU for Realtime  25-50% of CPU for Turn-based –Chase/Escape behaviors –Group behaviors –Finite State machines –Adaptation/Learning

3. Oct 6, Fall 2005 Game Design3 Questions  How good should the AI be?  Why are people more fun than NPC’s?  Will networked games reduce AI?  New directions for AI in games?

4. Oct 6, Fall 2005 Game Design4 Learning/Adaptation  Increment aggressiveness if player is doing well –The Computer-Based SATs do this!  Levels are a pre-programmed version of adaptation  Tuning  Stability  How might adaptation make play Better or Worse?

5. Oct 6, Fall 2005 Game Design5 Adaptation vs. Play quality  Do you want the monsters in Quake to get better as you get better?  Force the user to live with the consequences of his/her actions  Can surprise the designer (Creatures)  Pit AI creatures against each other to find bugs or tune actions  Robotwar

6. Oct 6, Fall 2005 Game Design6 What is good AI?  Perceived by user as challenging –Cruel, but fair!  User is surprised by the game –but later understands why  Feeling that reality will provide answers –able to make progress solving problem  What games have used AI effectively?

7. Oct 6, Fall 2005 Game Design7 Chase/Evade  Algorithm for the predator?

8. Oct 6, Fall 2005 Game Design8 Enhancements to Chase  Speed Control –Velocity, Acceleration max/min –Limited turning Radius  Randomness –Moves –Patterns

9. Oct 6, Fall 2005 Game Design9 Enhancements to Chase Anticipation Build a model of user behavior

10. Oct 6, Fall 2005 Game Design10 Steering Behaviors  Pursue  Evade  Wander  Obstacle Avoidance  Wall/Path following  Queuing  Combine behaviors with weights  What could go wrong?

11. Oct 6, Fall 2005 Game Design11 Group Behaviors  Lots of background characters to create a feeling of motion  Make area appear interesting, rich, populated

12. Oct 6, Fall 2005 Game Design12 Flocking -- (HalfLife, Unreal)  What might go wrong? Simple version: Compute trajectory to head towards centroid

13. Oct 6, Fall 2005 Game Design13 Group Behaviors  Reaction to neighbors -- Spring Forces Craig Reynolds SIGGRAPH 1987

14. Oct 6, Fall 2005 Game Design14 What could go wrong?  Repulsive springs around obstacles  Does not handle changes in strategy Exactly aligned Forces balance out in dead end

15. Oct 6, Fall 2005 Game Design15 “Perceptual” Models

16. Oct 6, Fall 2005 Game Design16 Production Rules If( enemy in sight ) fire If( big enemy in sight ) run away If( --- ) ----  Selecting among multiple valid rules –Priority weighting for rules or sensor events –Random selection  No state (in pure form)

17. Oct 6, Fall 2005 Game Design17 Finite State Machines  States: Action to take –Chase –Random Walk –Patrol –Eat  Transitions: –Time –Events –Completion of action Chopping Take Wood to closest depot Enough wood Drop wood: Go back to woods At depot At woods

18. Oct 6, Fall 2005 Game Design18 State Machine Problems  Predictable –Sometimes a good thing –If not, use fuzzy or probabilistic state machines  Simplistic –Use hierarchies of FSM’s (HalfLife)

19. Oct 6, Fall 2005 Game Design19 Probabilistic State Machines  Personalities –Change probability that character will perform a given action under certain conditions

20. Oct 6, Fall 2005 Game Design20 Probabilistic Example Fire At Enemy Run out of Range Enemy Within Hand- to-Hand Range 50% Far Enough to Take Shot Run Away Enemy Within Hand- to-Hand Range 50%

21. Oct 6, Fall 2005 Game Design21 Probabilistic State Machines  Other aspects: –Sight –Memory –Curiosity –Fear –Anger –Sadness –Sociability  Modify probabilities on the fly?

22. Oct 6, Fall 2005 Game Design22 Planning  Part of intelligence is the ability to plan  Move to a goal –A Goal State  Represent the world as a set of States –Each configuration is a separate state  Change state by applying Operators –An Operator changes configuration from one state to another state

23. Oct 6, Fall 2005 Game Design23 Path Planning  States: –Location of Agent/NPC in space –Discretized space Tiles in a tile-based game Floor locations in 3D Voxels  Operator –Move from one discrete location to next

24. Oct 6, Fall 2005 Game Design24 Path Planning Algorithms  Must Search the state space to move NPC to goal state  Computational Issues: –Completeness Will it find an answer if one exists? –Time complexity –Space complexity –Optimality Will it find the best solution

25. Oct 6, Fall 2005 Game Design25 Search Strategies  Blind search –No domain knowledge. –Only goal state is known  Heuristic search –Domain knowledge represented by heuristic rules –Heuristics drive low-level decisions

26. Oct 6, Fall 2005 Game Design26 Breadth-First Search  Expand Root node –Expand all Root node’s children Expand all Root node’s grandchildren  Problem: Memory size Root Child1 Child2 Root Child1 Child2 GChild1 GChild2 GChild3 GChild4

27. Oct 6, Fall 2005 Game Design27 Uniform Cost Search  Modify Breadth-First by expanding cheapest nodes first  Minimize g(n) cost of path so far Root Child1 Child2 GChild1 9 GChild2 5 GChild3 3 GChild4 8

28. Oct 6, Fall 2005 Game Design28 Depth First Search  Always expand the node that is deepest in the tree Root Child1 GChild1 GChild2 Root Child1 Root Child1 GChild1

29. Oct 6, Fall 2005 Game Design29 Depth First Variants  Depth first with cutoff C –Don’t expand a node if the path to root > C  Iterative Deepening –Start the cutoff C=1 –Increment the cutoff after completing all depth first probes for C

30. Oct 6, Fall 2005 Game Design30 Iterative Deepening Root Child1 Root Child1 GChild1 Root Child1 Child2 Root Child1 GChild1 GChild2 Root Child2 GChild3 GChild4

31. Oct 6, Fall 2005 Game Design31 Bidirectional Search  Start 2 Trees –Start one at start point –Start one at goal point

32. Oct 6, Fall 2005 Game Design32 Avoid Repeating States  Mark states you have seen before  In path planning: –Mark minimum distance to this node

33. Oct 6, Fall 2005 Game Design33 Heuristic Search  Apply approximate knowledge –Distance measurements to goal –Cost estimates to goal  Use the estimate to steer exploration

34. Oct 6, Fall 2005 Game Design34 Greedy Search  Expand the node that yields the minimum cost –Expand the node that is closest to target –Depth first –Minimize the function h(n) the heuristic cost function  Not Complete!  Local Minima

35. Oct 6, Fall 2005 Game Design35 A* Search  Minimize sum of costs  g(n) + h(n) –Cost so far + heuristic to goal  Guaranteed to work –If h(n) does not overestimate cost  Examples –Euclidean distance

36. Oct 6, Fall 2005 Game Design36 A* Search  Fails when there is no solution –Avoid searching the whole space –Do bi-directional search –Iterative Deepening

37. Oct 6, Fall 2005 Game Design37 Coordinated Movement  Somewhat more difficult than moving just one NPC –Disappearing goal –New obstacles in path –Collisions with other NPCs –Groups of units –Units in formation

38. Oct 6, Fall 2005 Game Design38 Coordinated Elements  Collision detection –Detection of immediate collisions –Near future  Perform the usual collision detection optimizations –Spatial hierarchies –Simplified tests –Unit approximations

39. Oct 6, Fall 2005 Game Design39 Collision Detection  Levels of collision –Hard radius (small) Must not have 2 units overlap hard radius –Soft radius (large) Soft overlap not preferred, but acceptable

40. Oct 6, Fall 2005 Game Design40 Collision Detection  With movement, need to avoid problems with bad temporal samples –Sample frequently –Detect collisions with extruded units –Use a movement line –Detect distance from Line segment

41. Oct 6, Fall 2005 Game Design41 Unit Line  Unit line follows path  Can implement minimum turn radius  Gives mechanism for position prediction  Connected line segments –Time stamps per segment –Orientation per segment –Acceleration per segment

42. Oct 6, Fall 2005 Game Design42 Prediction line  Given prediction, use next prediction as move  Prediction must have dealt with collisions already

43. Oct 6, Fall 2005 Game Design43 Collision Avoidance Planning  Don’t search a new path at each collision  Adopt a Priority Structure –Higher priority items move –Lower priority items wait or get out of the way  Case-based reasoning to perform local path reordering  Pairwise comparison

44. Oct 6, Fall 2005 Game Design44 Collision Resolution Summary  Favor: –High priority NPCs over Low Priority –Moving over non-moving  Lower Priority NPCs –Back out of the way –Stop to allow others to pass  General –Resolve all high-priority collisions first

45. Oct 6, Fall 2005 Game Design45 Avoidance  Case 1: Both units standing –Lower priority unit does nothing itself –Higher unit Finds which unit will move Tells that unit to resolve hard collision by shortest move

46. Oct 6, Fall 2005 Game Design46 Avoidance  Case 2: We’re not moving, other unit is moving –Non-moving unit stays immobile

47. Oct 6, Fall 2005 Game Design47 Avoidance  Case 3: We’re moving, other is not: –If lower priority immobile unit can get out of the way: Lower unit gets out of way Higher unit moves past lower to get to collision free point –Else If we can avoid other unit Avoid it!

48. Oct 6, Fall 2005 Game Design48 Avoidance  Case 3: We’re moving, other is not: –Else: Can higher unit push lower along Push! –Else: Recompute paths!

49. Oct 6, Fall 2005 Game Design49 Avoidance  Case 4: Both units moving –Lower unit does nothing –If hard collision inevitable and we are high unit Tell lower unit to pause –Else: If we are high unit Slow lower unit down and compute collision-free path

50. Oct 6, Fall 2005 Game Design50 Storage  Store predictions in a circular buffer  If necessary, interpolate between movement steps

51. Oct 6, Fall 2005 Game Design51 Planning  Prediction implies –A plan for future moves  Once a collision has been resolved –Record the decision that was made –Base future movement plans on this Blocking unit Get-To Point Predicted Position

52. Oct 6, Fall 2005 Game Design52 Units, Groups, Formations  Unit –An individual moving NPC  Group –A collection of units  Formation –A group with position assignments per group member

53. Oct 6, Fall 2005 Game Design53 Groups  Groups stay together –All units move at same speed –All units follow the same general path –Units arrive at the same time Obstruction Goal

54. Oct 6, Fall 2005 Game Design54 Groups  Need a hierarchical movement system  Group structure –Manages its own priorities –Resolves its own collisions –Elects a commander that traces paths, etc Commander can be an explicit game feature

55. Oct 6, Fall 2005 Game Design55 Formations  Groups with unit layouts –Layouts designed in advance  Additional States –Forming –Formed –Broken  Only formed formations can move

56. Oct 6, Fall 2005 Game Design56 Formations  Schedule arrival into position –Start at the middle and work outwards –Move one unit at a time into position –Pick the next unit with Least collisions Least distance –Formed units have highest priority Forming units medium priority Unformed units lowest

57. Oct 6, Fall 2005 Game Design57 Formations 1 2 3 4 5 6 7 8 9 123 4 5 67 8 9 1 2 3 4 5 6 7 8 9 Not so good… Better…

58. Oct 6, Fall 2005 Game Design58 Formations: Wheeling  Only necessary for non-symmetric formations 123 4 5 1 2 3 4 5 Break formation here Stop motion temporarily Set re-formation point here

59. Oct 6, Fall 2005 Game Design59 Formations: Obstacles 123 4 5 Scale formation layout to fit through gaps 12345 123 4 5 123 4 5 Subdivide formation around small obstacles

60. Oct 6, Fall 2005 Game Design60 Formations  Adopt a hierarchy of paths to simplify path-planning problems  High-level path considers only large obstacles –Perhaps at lower resolution –Solves problem of gross formation movement –Paths around major terrain features

61. Oct 6, Fall 2005 Game Design61 Formations  Low-level path –Detailed planning within each segment of high-level path –Details of obstacle avoidance  Implement path hierarchy with path stack High-Level Path Low-Level Path1 High-Level Path Low-Level Path2 High-Level Path Low-Level Path2 Avoidance Path

62. Oct 6, Fall 2005 Game Design62 Path Stack High-Level Path Low-Level Path1 High-Level Path Low-Level Path2 High-Level Path Low-Level Path2 Avoidance Path 1 2 Low-level path Avoidance path

63. Oct 6, Fall 2005 Game Design63 Compound Collisions  Solve collisions pairwise  Start with highest priority pair –Then, resolve the next “highest priority pair” now colliding

64. Oct 6, Fall 2005 Game Design64 General  Optimize for 2D if possible  Use high-level and low-level pathing  Units will overlap!  Understand the update loop –It affects unit movement  Maintain a brief collision history

65. Oct 6, Fall 2005 Game Design65 References  Used with permission from CS4455 course at GA Tech by Chris Shaw  http://www.cc.gatech.edu/classes/AY2005 /cs4455_fall/