1 / 42

Scaling Up To More Sophisticated AI Without Overburdening Developers - Lessons Learned

Scaling Up To More Sophisticated AI Without Overburdening Developers - Lessons Learned. Marc Atkin Irrational Games. AGDC 4-Dec-2004. Motivation. Why Do We Want Better AI?. Bad AI is always noticed AI often inconsistent between games – why can’t we build on previous work?

trona
Download Presentation

Scaling Up To More Sophisticated AI Without Overburdening Developers - Lessons Learned

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Scaling Up To More Sophisticated AI Without Overburdening Developers - Lessons Learned Marc Atkin Irrational Games AGDC 4-Dec-2004

  2. Motivation

  3. Why Do We Want Better AI? • Bad AI is always noticed • AI often inconsistent between games – why can’t we build on previous work? • The AI is a big part of what makes a game world immersive and fun

  4. What’s Stopping Us? • What makes AI complex? • AI has many possible reactions to many situations • Many behaviours are operating on the AI at any given time • Hard to account for all the possible interactions • Impression that academic AI research isn’t applicable (too slow, too complex, too flaky)

  5. The Basic Idea: Use Modularity • It’s not just for coding anymore! • Produces AI that is easier to understand and debug • Produces AI that it reusable within and between projects • The key point: Design the AI architecture so that it facilitates modularity

  6. Tribes: Vengeance • First-person shooter • Emphasises speed and freedom of movement (jetpacks!) • 3rd in the series

  7. AI Challenges • AI works in service of the game: • AI characters shouldn’t act stupidly • yet still be fun to fight • AI’s should exhibit diversebehaviour • AI’s should jetpack and ski • AI’s should react to their environment • AI’s should have recognizable roles • Sniper, duelist, mortar user, etc.

  8. System Overview Animation System GameWorld AI NavigationSystem PhysicsSystem Pathfinder

  9. What makes our game characters “intelligent”? • A large set of sophisticated, hand-designed behaviors • Common sense reactions • The ability to exploit opportunities • A consistent long term viewof tasks to be accomplished

  10. What makes our game characters “intelligent”? • A large set of sophisticated, hand-designed behaviors • Common sense reactions • The ability to exploit opportunities • A consistent long term viewof tasks to be accomplished Tyrion: An architecture for specifying and executing AI behaviour

  11. How Tyrion Works

  12. Resources, Goals, and Actions • Goal: A description of adesired world state • Action (or behaviour):A method for achieving a goal • Resource:An entity required toperform an action

  13. Resource Hierarchy Team Squads Vehicles Driver/Gunners Characters Legs/Arms/Head

  14. Resource Hierarchy Team Strategic level Squads Tactical level Vehicles Driver/Gunners IndividualUnits Characters Legs/Arms/Head Motor Control

  15. Action/Goal Hierarchy Squad Attack From All Sides Attack Goals Grunt Character Duelist NormalAttack DuelistAttack MoveTo Goal Legs / Arms FireAt Goal MoveTo Fire Weapon

  16. Action Structure • Goal satisfied by action • Selection heuristic • Evaluates appropriateness of actionin a given situation • Message callback functions for child actions • Message callback functions for sensors • Body (Unreal script latent code) • Typically executes over a number of game ticks

  17. Example Action: Search • Satisfies:SearchGoal( target, searchDistance ) • Only action that satisfies this goal • Child action callbacks: • Set errorCode • Sensor callback: • Terminate action if target spotted

  18. Example Action: Search (cont) • Body: • Store location and rotation • ActivateSensor( TargetSensor, target ) • Loop over searchPositions: • WaitForGoal( MoveToGoal, searchPosition) • Fail() if MoveToGoal was not achieved • Play LookingAround animation • Pause AnimationTime seconds • WaitForGoal( TurnGoal, originalRotation ) • Succeed()

  19. Sensor Hierarchy • Sensors can build upon one another, too DodgeSensor: Warns a character about incoming projectiles TargetSensor: Triggers when a particular unit is visible EnemySensor: Maintains a list of visible hostiles Vision System

  20. AI and Scripting • High level behaviours look a lot like scripts • A script is essentially a one-time use behaviour • Tyrion could be used to drive the scripting system

  21. Example Script • Executes when player enters trigger • Spawns AI’s • Moves AI’s into position and has them attack player

  22. Example Script • Executes when player enters trigger • Spawns AI’s • Moves AI’s into position and has them attack player Sensor activation Posting sub-goals

  23. Execution Model • 10 times a second: • Iterate over every resource: • Order unmatched goals by priority • Find actions that achieve them • Tick every running action • Tick every active periodic sensor;send messages • If an action completes, mark its goal as achieved/failed; send messages

  24. A Day in the Life of a Grunt • A Grunt AI with three goals: • PatrolGoal (priority 40) • AttackGoal (priority 50, dormant) • DodgeGoal (priority 90, dormant) • AttackGoal will activate when an enemy is sighted • DodgeGoal will activate when a visible projectile will hit the AI

  25. A Day in the Life (cont) PatrolGoal AttackGoal DodgeGoal Patrol is executing 40 legs arms

  26. A Day in the Life (cont) PatrolGoal AttackGoal DodgeGoal Patrol is executing 40 legs Enemy spotted! Sensor wakes up AttackGoal arms X 40 50 Attack executes; posts subgoals for legs & arms legs 50 arms

  27. A Day in the Life (cont) PatrolGoal AttackGoal DodgeGoal Patrol is executing 40 legs Enemy spotted! Sensor wakes up AttackGoal arms X 40 50 Attack executes; posts subgoals for legs & arms legs 50 arms Projectile spotted! Sensor wakes up DodgeGoal X X 40 50 90 Dodge executes; needs legs arms continue executing Attack! legs 50 arms

  28. A Day in the Life (cont) PatrolGoal AttackGoal DodgeGoal Patrol is executing 40 legs Enemy spotted! Sensor wakes up AttackGoal arms X 40 50 Attack executes; posts subgoals for legs & arms legs 50 arms Projectile spotted! Sensor wakes up DodgeGoal X X 40 50 90 Dodge executes; needs legs arms continue executing Attack! legs 50 arms X Dodge finishes: legs resume Attack subgoal 40 50 legs 50 arms

  29. Lessons Learned

  30. Sophisticated AI != Expensive AI • This is not an expensive system • No search due to scoring function on actions • Action to goal matching only occurs when goal list changes for the resource • Although there are many actions running simultaneously, at any given time a lot are sleeping • Most of high-level AI was written in Unreal Script (20x slower than C++) yet it still wasn’t a bottleneck.

  31. Some AI is expensive • Superficially simple systems that require large amounts of debugging and tweaking (e.g. emergent AI) • Search (e.g. planning, pathfinding) • Line checks (e.g. vision)

  32. Analysis (pluses) • Character actions were very useful in coordinating squads and chaining sub-actions • Useful to think of legs and arms as separate resources • Architecture no harder to use than others, but quite easily reusable for other projects • Using squad goals worked well: helped reduce the amount of level design work

  33. Analysis (minuses) • Full potential of architecture not exploited: FPS opponents are only human-like to a degree; their required spectrum of behaviours is fairly limited • Exposed too much detail to designers; editor could have been streamlined • We didn’t use the AI architecture to drive the scripting system: duplication of effort

  34. General Lessons Learned • Create AI that’s required by the game • Create debugging tools early • Leave time for tweaking • Make sure the player knows when the AI does something cool • Does good AI make a game fun (or is it just that bad AI makes a game not fun)?; do games need scripted set-pieces?

  35. Take-home Message • powerful AI != expensive AI • One AI description language can control control teams, squads, characters, and scripting • A modular AI is a reusable AI – let the AI engine handle the interaction complexities

  36. The End

  37. Unused Slides Follow….

  38. Oh No, Not Another Hierarchy! • Control hierarchies are a dime adozen in the AI/robotics literature • Tyrion’s more interesting features: • No set number of levels • Uniform description language and execution model used across levels • Separate sensing system • Dormant goals • Supervenience: information is sent up, goals are sent down

  39. Relationship to AI Planning • Tyrion can be viewed as a Task Network (or Partial Hierarchical) Planner Goal A Possible Actions

  40. Relationship to AI Planning • Tyrion can be viewed as a Task Network (or Partial Hierarchical) Planner Goal A Possible Actions Sub-goals Possible Sub-Actions

  41. Relationship to AI Planning • Tyrion can be viewed as a Task Network (or Partial Hierarchical) Planner Goal A Possible Actions Sub-goals Possible Sub-Actions x Outcome for goal A

More Related