1. CSCE 552 Spring 2009 Inverse Kinematics and AI By Jijun Tang

2. Inverse Kinematics FK & IK Single Bone IK Multi-Bone IK Cyclic Coordinate Descent Two-Bone IK IK by Interpolation

3. FK & IK Most animation is “forward kinematics”  Motion moves down skeletal hierarchy But there are feedback mechanisms  Eyes track a fixed object while body moves  Foot stays still on ground while walking  Hand picks up cup from table This is “inverse kinematics”  Motion moves back up skeletal hierarchy

4. Example of Inverse Kinematics

5. Single Bone IK Orient a bone in given direction  Eyeballs  Cameras Find desired aim vector Find current aim vector Find rotation from one to the other  Cross-product gives axis  Dot-product gives angle Transform object by that rotation

6. Multi-Bone IK One bone must get to a target position  Bone is called the “end effector” Can move some or all of its parents May be told which it should move first  Move elbow before moving shoulders May be given joint constraints  Cannot bend elbow backwards

7. Cyclic Coordinate Descent Simple type of multi-bone IK Iterative: Can be slow May not find best solution: May not find any solution in complex cases But it is simple and versatile: No precalculation or preprocessing needed

8. Procedures Start at end effector Go up skeleton to next joint Move (usually rotate) joint to minimize distance between end effector and target Continue up skeleton one joint at a time If at root bone, start at end effector again Stop when end effector is “close enough” Or hit iteration count limit

10. Properties May take a lot of iterations Especially when joints are nearly straight and solution needs them bent  e.g. a walking leg bending to go up a step  50 iterations is not uncommon! May not find the “right” answer  Knee can try to bend in strange directions

11. Two-Bone IK Direct method, not iterative Always finds correct solution  If one exists Allows simple constraints  Knees, elbows Restricted to two rigid bones with a rotation joint between them  Knees, elbows! Can be used in a cyclic coordinate descent

12. Two-Bone IK Constraints Three joints must stay in user-specified plane: e.g. knee may not move sideways Reduces 3D problem to a 2D one Both bones must remain original length Therefore, middle joint is at intersection of two circles Pick nearest solution to current pose, or one solution is disallowed: Knees or elbows cannot bend backwards

13. Example Allowed elbow position Shoulder Wrist Disallowed elbow position

14. IK by Interpolation Animator supplies multiple poses Each pose has a reference direction  e.g. direction of aim of gun Game has a direction to aim in Blend poses together to achieve it Source poses can be realistic  As long as interpolation makes sense  Result looks far better than algorithmic IK with simple joint limits

15. Example One has poses for look ahead, look downward (60 。 ), look right, look down and right Now to aim 54 。 right and 15 。 downward, thus 60% (54/90) on the horizontal scale, 25% (15/60) on the downward scale  Look ahead (1-0.25)(1-0.6)=0.3  Look downward 0.25(1-0.6)=0.1  Look right (1-0.25) 0.6=0.45  Look down and right (0.25)(0.6)=0.15

16. IK by Interpolation results Result aim point is inexact  Blending two poses on complex skeletons does not give linear blend result  But may be good enough from the game perspective Can iterate towards correct aim

17. Attachments e.g. character holding a gun Gun is a separate mesh Attachment is a bone in character’s skeleton  Represents root bone of gun Animate character Transform attachment bone to world space Move gun mesh to that pos+orn

18. Attachments (2) e.g. person is hanging off bridge Attachment point is a bone in hand  As with the gun example But here the person moves, not the bridge Find delta from root bone to attachment bone Find world transform of grip point on bridge Multiply by inverse of delta  Finds position of root to keep hand gripping

19. Artificial Intelligence: Agents, Architecture, and Techniques

20. Artificial Intelligence Intelligence embodied in a man-made device Human level AI still unobtainable The difficulty is comprehension

21. Game Artificial Intelligence: What is considered Game AI? Is it any NPC (non-player character) behavior?  A single “ if ” statement?  Scripted behavior? Pathfinding? Animation selection? Automatically generated environment?

22. Possible Game AI Definition Inclusive view of game AI: “ Game AI is anything that contributes to the perceived intelligence of an entity, regardless of what ’ s under the hood. ”

23. Goals of an AI Game Programmer Different than academic or defense industry 1. AI must be intelligent, yet purposely flawed 2. AI must have no unintended weaknesses 3. AI must perform within the constraints 4. AI must be configurable by game designers or players 5. AI must not keep the game from shipping

24. Specialization of Game AI Developer No one-size fits all solution to game AI  Results in dramatic specialization Strategy Games  Battlefield analysis  Long term planning and strategy First-Person Shooter Games  One-on-one tactical analysis  Intelligent movement at footstep level Real-Time Strategy games the most demanding, with as many as three full-time AI game programmers

25. Game Agents May act as an  Opponent  Ally  Neutral character Continually loops through the Sense-Think-Act cycle  Optional learning or remembering step

26. Sense-Think-Act Cycle: Sensing Agent can have access to perfect information of the game world  May be expensive/difficult to tease out useful info  Players cannot Game World Information  Complete terrain layout  Location and state of every game object  Location and state of player But isn ’ t this cheating???

27. Sensing: Enforcing Limitations Human limitations? Limitations such as  Not knowing about unexplored areas  Not seeing through walls  Not knowing location or state of player Can only know about things seen, heard, or told about Must create a sensing model

28. Sensing: Human Vision Model for Agents Get a list of all objects or agents; for each: 1. Is it within the viewing distance of the agent? How far can the agent see? What does the code look like? 2. Is it within the viewing angle of the agent? What is the agent ’ s viewing angle? What does the code look like? 3. Is it unobscured by the environment? Most expensive test, so it is purposely last What does the code look like?

29. Sensing: Vision Model Isn ’ t vision more than just detecting the existence of objects? What about recognizing interesting terrain features?  What would be interesting to an agent?  How to interpret it?

30. Sensing: Human Hearing Model Humans can hear sounds Human can recognize sounds and knows what emits each sound Human can sense volume and indicates distance of sound Human can sense pitch and location  Sounds muffled through walls have more bass  Where sound is coming from

31. Sensing: Modeling Hearing How do you model hearing efficiently?  Do you model how sounds reflect off every surface?  How should an agent know about sounds?

32. Sensing: Modeling Hearing Efficiently Event-based approach  When sound is emitted, it alerts interested agents  Observer pattern Use distance and zones to determine how far sound can travel

33. Sensing: Communication Agents might talk amongst themselves!  Guards might alert other guards  Agents witness player location and spread the word Model sensed knowledge through communication  Event-driven when agents within vicinity of each other

34. Sensing: Reaction Times Agents shouldn ’ t see, hear, communicate instantaneously Players notice! Build in artificial reaction times  Vision: ¼ to ½ second  Hearing: ¼ to ½ second  Communication: > 2 seconds

35. Sense-Think-Act Cycle: Thinking Sensed information gathered Must process sensed information Two primary methods  Process using pre-coded expert knowledge  Use search to find an optimal solution

36. Thinking: Expert Knowledge Many different systems  Finite-state machines  Production systems  Decision trees  Logical inference Encoding expert knowledge is appealing because it ’ s relatively easy  Can ask just the right questions  As simple as if-then statements Problems with expert knowledge: not very scalable

37. Finite-state machine (FSM)

38. Production systems Consists primarily of a set of rules about behavior Productions consist of two parts: a sensory precondition (or "IF" statement) and an action (or "THEN") A production system also contains a database about current state and knowledge, as well as a rule interpreter

39. Decision trees

40. Logical inference Process of derive a conclusion solely based on what one already knows Prolog (programming in logic) mortal(X) :- man(X). man(socrates). ?- mortal(socrates). Yes

41. Thinking: Search Employs search algorithm to find an optimal or near-optimal solution  Branch-and-bound  Depth-first  Breadth-first A* pathfinding common use of search  Kind of mixed

42. Depth and breadth-first

43. Thinking: Machine Learning If imparting expert knowledge and search are both not reasonable/possible, then machine learning might work Examples:  Reinforcement learning  Neural networks  Decision tree learning Not often used by game developers  Why?

44. Thinking: Flip-Flopping Decisions Must prevent flip-flopping of decisions Reaction times might help keep it from happening every frame Must make a decision and stick with it  Until situation changes enough  Until enough time has passed

45. Sense-Think-Act Cycle: Acting Sensing and thinking steps invisible to player Acting is how player witnesses intelligence Numerous agent actions, for example:  Change locations  Pick up object  Play animation  Play sound effect  Converse with player  Fire weapon

46. Acting: Showing Intelligence Adeptness and subtlety of actions impact perceived level of intelligence Enormous burden on asset generation Agent can only express intelligence in terms of vocabulary of actions Current games have huge sets of animations/assets  Must use scalable solutions to make selections

47. Extra Step in Cycle: Learning and Remembering Optional 4 th step Not necessary in many games  Agents don ’ t live long enough  Game design might not desire it

48. Learning Remembering outcomes and generalizing to future situations Simplest approach: gather statistics  If 80% of time player attacks from left  Then expect this likely event Adapts to player behavior

49. Remembering Remember hard facts  Observed states, objects, or players  Easy for computer Memories should fade  Helps keep memory requirements lower  Simulates poor, imprecise, selective human memory For example  Where was the player last seen?  What weapon did the player have?  Where did I last see a health pack?

50. Remembering within the World All memory doesn ’ t need to be stored in the agent – can be stored in the world For example:  Agents get slaughtered in a certain area  Area might begin to “ smell of death ”  Agent ’ s path planning will avoid the area  Simulates group memory

51. Making Agents Stupid Sometimes very easy to trounce player  Make agents faster, stronger, more accurate  Challenging but sense of cheating may frustrate the player Sometimes necessary to dumb down agents, for example:  Make shooting less accurate  Make longer reaction times  Engage player only one at a time  Change locations to make self more vulnerable

52. Agent Cheating Players don ’ t like agent cheating  When agent given unfair advantage in speed, strength, or knowledge  People notices it Sometimes necessary  For highest difficultly levels  For CPU computation reasons  For development time reasons Don ’ t let the player catch you cheating!  Consider letting the player know upfront  No one wants to fight a stupid enemy, trade-off

53. Finite-State Machine (FSM) Abstract model of computation Formally:  Set of states  A starting state  An input vocabulary  A transition function that maps inputs and the current state to a next state

54. FSM

55. In Game Development Deviate from formal definition 1. States define behaviors (containing code) Wander, Attack, Flee 2. Transition function divided among states Keeps relation clear 3. Blur between Moore (within state) and Mealy machines (transitions) 4. Leverage randomness 5. Extra state information, for example, health

56. Moore and Mealy

57. Good and Bad Most common game AI software pattern  Natural correspondence between states and behaviors  Easy to diagram  Easy to program  Easy to debug  Completely general to any problem Problems  Explosion of states  Often created with ad hoc structure

58. Finite-State Machine: UML Diagram

59. Approaches Three approaches  Hardcoded (switch statement)  Scripted  Hybrid Approach

60. Hardcoded FSM void RunLogic( int * state ) { switch( state ) { case 0: //Wander Wander(); if( SeeEnemy() ) { *state = 1; } break; case 1: //Attack Attack(); if( LowOnHealth() ) { *state = 2; } if( NoEnemy() ) { *state = 0; } break; case 2: //Flee Flee(); if( NoEnemy() ) { *state = 0; } break; }

61. Problems with switch FSM 1. Code is ad hoc  Language doesn ’ t enforce structure 2. Transitions result from polling  Inefficient – event-driven sometimes better 3. Can ’ t determine 1 st time state is entered 4. Can ’ t be edited or specified by game designers or players

62. Scripted with alternative language AgentFSM { State( STATE_Wander ) OnUpdate Execute( Wander ) if( SeeEnemy ) SetState( STATE_Attack ) OnEvent( AttackedByEnemy ) SetState( Attack ) State( STATE_Attack ) OnEnter Execute( PrepareWeapon ) OnUpdate Execute( Attack ) if( LowOnHealth ) SetState( STATE_Flee ) if( NoEnemy ) SetState( STATE_Wander ) OnExit Execute( StoreWeapon ) State( STATE_Flee ) OnUpdate Execute( Flee ) if( NoEnemy ) SetState( STATE_Wander ) }

63. Scripting Advantages 1. Structure enforced 2. Events can be handed as well as polling 3. OnEnter and OnExit concept exists 4. Can be authored by game designers  Easier learning curve than straight C/C++

64. Scripting Disadvantages Not trivial to implement Several months of development  Custom compiler With good compile-time error feedback  Bytecode interpreter With good debugging hooks and support Scripting languages often disliked by users  Can never approach polish and robustness of commercial compilers/debuggers

65. Hybrid Approach Use a class and C-style macros to approximate a scripting language Allows FSM to be written completely in C++ leveraging existing compiler/debugger Capture important features/extensions  OnEnter, OnExit  Timers  Handle events  Consistent regulated structure  Ability to log history  Modular, flexible, stack-based  Multiple FSMs, Concurrent FSMs Hard to be edited by designers or players

66. Extensions Many possible extensions to basic FSM  OnEnter, OnExit  Timers  Global state, substates  Stack-Based (states or entire FSMs)  Multiple concurrent FSMs  Messaging