Presentation is loading. Please wait.

Presentation is loading. Please wait.

The following slides were presented at the GDC 2003 roundtable: AI Interface Standards: The Road Ahead Moderated by Alexander Nareyek, Nick Porcino and.

Similar presentations

Presentation on theme: "The following slides were presented at the GDC 2003 roundtable: AI Interface Standards: The Road Ahead Moderated by Alexander Nareyek, Nick Porcino and."— Presentation transcript:

1 The following slides were presented at the GDC 2003 roundtable: AI Interface Standards: The Road Ahead Moderated by Alexander Nareyek, Nick Porcino and Mark Kolenski March 8, 2003, 9-11:30am San Carlos II, Hilton, San Jose Not all slides were shown because we were running out of time (especially for the groups on Rule-based Systems and Goal-oriented Action Planning).

2 Notes on the roundtables discussions are also added to the slides. These do of course not cover the full discussions. Check the forums (member access only) for more. Please note that not all results of voting alternatives add up to 100% - we did not ask for undecided in addition.

3 AI Interface Standards: The Road Ahead GDC 2003 Following slides prepared by Alexander Nareyek; presented by Alexander Nareyek

4 4AI Interface Standards Committee Artificial Intelligence Interface Standards Committee (AIISC)

5 5AI Interface Standards Committee Goals Provide interfaces for basic AI functionality Enable code recycling and outsourcing In the long run: Support for dedicated hardware

6 6AI Interface Standards Committee Committee Composition ~ 70 members: 45% game developers 30% middleware 25% academia

7 7AI Interface Standards Committee Working Groups Decision Trees Pathfinding Steering Finite State Machines Rule-based Systems Goal-oriented Action Planning World Interfacing

8 8AI Interface Standards Committee Schedule After GDC: report on what we have done so far Next GDC: presentation of draft documents in a larger setting Your input today!

9 9AI Interface Standards Committee Outline for Today Interleaved working group reports and discussions Presented by Alexander Nareyek (CMU) Nick Porcino (LucasArts) Mark Kolenski (Blue Fang Games)

10 10AI Interface Standards Committee Additional Thanks to: Ruth Aylett (University of Salford) Abdennour El Rhalibi (Liverpool John Moores University) Bjoern Knafla (University of Bielefeld) Thaddaeus Frogley (King of the Jungle) Christopher Reed (Raven Software / Activision) Noel Stephens (Paradigm Entertainment)

11 11AI Interface Standards Committee Session 1: Interface Formats

12 12AI Interface Standards Committee System & AI Architecture Function Library (simple, efficient) Vs. Agent-based (distribution, flexible)

13 13AI Interface Standards Committee How Do We Specify our Standards? Abstract levels: Ontologies & XML C/C++ Interfaces C/C++ Reference Implementation

14 14AI Interface Standards Committee Discussion: Interface Formats

15 (Some) discussion comments: Function Library vs. Agent-based Can't go from an agent interface to a function interface, but you can go the other way. Someone made the comment that agents burn bridges. Someone opined and no one contradicted a statement that an agent approach imposes a methodology on games development that may simply not be viable for many products and classes of games. Specifically, if the game design doesn't match the agent paradigm the W.I. will simply not be used. Vote: For primarily function library: 100% For primarily agent-based: 0% Interested in an agent wrapper for the function-based approach: ~15%

16 (Some) discussion comments: C or C++ Linking issues from languages such as GOAL or Perl need to be sorted out if C++ is to be viable. People could make a C++ wrapper if they were so inclined. Perhaps interfaces could follow the precedent of stdio.h and cstdio and how they live happily together. Vote: Pure C: 2 hands C approach with C++ wrapper: ~25% Pure C++ interface: ~50%

17 17AI Interface Standards Committee Session 2: World Interfacing Following slides prepared by Christopher Reed; presented by Nick Porcino

18 18AI Interface Standards Committee Outline 1)Goals 2)Definitions (World & AI) 3)World Services 3A) Senses 3B) Actuators

19 19AI Interface Standards Committee (1) World Interface Goals The objective is to provide an interface between AI and the Game World. We will begin with definitions for each of these concepts.

20 20AI Interface Standards Committee (2) Definition: The World The game world is everything –Master simulator and arbitrator –Manager of all data (state) –Provider of services

21 21AI Interface Standards Committee (2) Definition: The World The game world may have: –Static visual and navigable locations (scene) –Dynamic objects (entities) –Autonomous, thinking characters (agents) –Player controlled characters

22 22AI Interface Standards Committee (2) Definition: AI AI drives the decision making of an autonomous, computer controlled entity (agent) –Selects actions and behaviors –Does not execute these actions –Purely decision making

23 23AI Interface Standards Committee (2) Definition: AI AI may have: –State –Goals AI can: –Select activities –Respond to the world

24 24AI Interface Standards Committee (3) Services As the server, the game world needs to tell AI agents what services it provides to them, and then actually execute those services when requested.

25 25AI Interface Standards Committee (3) Services In a sense, the interface between the game and the world is seen as a blackboard. The interface simply provides a place for posting service requests, and makes no demands on how these requests are fulfilled.

26 26AI Interface Standards Committee (3) Services There are two primary types of services that the world provides to AI: A) Senses B) Actuators

27 27AI Interface Standards Committee (3A) Senses Sensory information provides an agent with awareness about the game world.

28 28AI Interface Standards Committee (3A) Senses There are 2 types of sensory services: 1) Events – Concious awareness of things that happen in the world. 2) Queries – All questions that an agent may ask about the world.

29 29AI Interface Standards Committee (3A1) Events Events happen all the time: Sounds, movements, collisions, and special effects are all examples of events. Events occur at a time, and may have a short, limited duration.

30 30AI Interface Standards Committee (3A1) Events Events are game specific. The interface we present will not attempt to create a library of events, but rather a mechanism for developers to create their own events.

31 31AI Interface Standards Committee (3A1) Events The game world tells AI what events are available by posting them to the Event Space.

32 32AI Interface Standards Committee (3A1) Events Agents and AI subsystems place an Event Watch for a given event on the Event Blackboard. The game world is then required to alert the agent when the event occurs.

33 33AI Interface Standards Committee (3A2) Queries Queries allow AI to ask questions about the game world.

34 34AI Interface Standards Committee (3A2) Queries There are several types of questions that an agent may ask: 1) Provide information about an entity: - What is (Bobs) (health)? - Is (Joe) (flying)?

35 35AI Interface Standards Committee (3A2) Queries 2) Provide a list of entities that match a given set of properties: - What entities are less than 30 feet away? - What entities are enemies and visible?

36 36AI Interface Standards Committee (3A2) Queries There may be additional types to test for collisions and visibility, but the format has not been decided.

37 37AI Interface Standards Committee (3B) Actuators Actuators provide a way for AI to interact with the game world. Some examples of actuators are Movement, talking, sounds, animations, picking things up, and shooting a weapon.

38 38AI Interface Standards Committee (3B) Actuators There are two types of actuators: 1)Actions – short term behavior 2)Effectors – long term behavior with non constant parameters

39 39AI Interface Standards Committee (3B1) Actions Actions have a finite and small duration with unchanging parameters. An example of an action is making a sound.

40 40AI Interface Standards Committee (3B1) Actions It is the responsibility of the game to make sure that actions are resolved and carried out on behalf of the AI.

41 41AI Interface Standards Committee (3B1) Actions Actions, like events, are game specific. The interface we present will not attempt to create a library of actions, but rather a mechanism to create them.

42 42AI Interface Standards Committee (3B1) Actions The game tells AI what actions and effectors are available by placing them on the action and effector blackboards.

43 43AI Interface Standards Committee (3B1) Actions Agents are not allowed to instantly execute their desired actions. Instead, they copy their request for a given action to the blackboard and leave the game to resolve the action.

44 44AI Interface Standards Committee (3B2) Effectors Whereas Actions have limited or short duration and do not change parameters, effectors can last a long time and are aware of changes in parameters.

45 45AI Interface Standards Committee (3B2) Effectors An example of an effector is Thrust, a quantity that is constantly changing and adjusting the velocity of an agent. Another example of an effector is animation.

46 46AI Interface Standards Committee Overview (3A) Senses -(3A1) Events (short) -(3A2) Queries (question) (3B) Actuators -(3B1) Actions (short, static) -(3B2) Effectors (long, dynamic)

47 47AI Interface Standards Committee Discussion: World Interfacing

48 (Some) discussion comments: Blackboard? Priority Queue? This should not be defined in the interface! Game programmers probably want to bypass all of this and build it themselves. Blackboard might be good as metaphor but should not be chosen as requirement for implementation. Whatever the communication scheme, searching of information should be minimized. Maybe, the WI should simply be a registry of callbacks with a filtering mechanism. The WI should serve the other interfaces (Pathfinding, etc), not the other way around. What is the level of events etc? Might get ugly…

49 49AI Interface Standards Committee Session 3: Decision Trees Following slides prepared by Mark Kolenski; presented by Mark Kolenski

50 50AI Interface Standards Committee Decision Trees What ARE They? Different disciplines and definitions. May be probabilistic, dynamic, used in learning, expert systems, philosophy.

51 51AI Interface Standards Committee Simple Example Attack or defend? Actions are called (child) nodes.

52 52AI Interface Standards Committee Example (cont.) How to decide? Utility Function - one convenient number per node. Perform the node that comes out the best.

53 53AI Interface Standards Committee Life is Not So Simple Probabilities (Bayesian) Degrees of Belief Chance (Nasty World)

54 54AI Interface Standards Committee In Games Do Many Games Use Them? Not clear Why? Uncertainty (or to make a humanlike opponent).

55 55AI Interface Standards Committee Agreements K.I.S.S. In The Beginning Definitions Real Game Decisions GOAL: Preliminary Interface

56 56AI Interface Standards Committee Discussion Should We Bother? At What Level? How General?

57 57AI Interface Standards Committee Discussion: Decision Trees

58 (Some) discussion comments: The interface on a DT should be give me a leaf! give me the next leaf!. The interface should allow construction (construction on- the-fly) and recursion of a tree. Some DTs are so huge they must be dynamically constructed, pruned, and discarded on the fly. It should be possible to mark nodes as done. Tree should be able to prune itself to speed processing and traversal. You run the risk of enforcing a particular implementation depending on how the DT interface is specified. Should support both offline and online construction of trees. Some offline constructions are very simple, such as tables. Survey: Who is currently using decision trees: 3 hands

59 59AI Interface Standards Committee C OFFEE B REAK ! Please be back at 10:30

60 60AI Interface Standards Committee Session 4: Pathfinding Following slides prepared by Noel Stephens; presented by Mark Kolenski

61 61AI Interface Standards Committee The Path Finding Group Our preliminary goal is to define the core terminology and techniques associated with commonly used path finding algorithms and data structures.

62 62AI Interface Standards Committee General Terminology What is path finding? –What is a graph? –What is a node? –What is a connection? –How much does it cost? Where we go from here.

63 63AI Interface Standards Committee The act of path finding is to search through a graph for a set of nodes that form the most optimal path to a specified destination. What is Path Finding?

64 64AI Interface Standards Committee A graph is a class that contains a collection of nodes. What is a Graph? Graph Node

65 65AI Interface Standards Committee A node is a class that contains a set of connections to other nodes. What is a Node? Graph Node ConnectionSet

66 66AI Interface Standards Committee A connection holds information about the path to the destination node as well as a pointer to the destination node. What is a Connection? Graph Node Connection Connection Connection ConnectionSet

67 67AI Interface Standards Committee Cost for a connection can be relative to the agent contemplating the connection. How much does it cost? Connection Agent Cost Callback

68 68AI Interface Standards Committee Our current focus has been to define the preliminary systems associated with path finding. Upon completing this it is certain that we will begin the task of taking theory and applying it to application. Where we go from here.

69 69AI Interface Standards Committee Discussion: Pathfinding

70 (Some) discussion comments: What about pre-computing perfect lookups? Grid-based approaches can be addressed via templates. Problem: relation between interface structure and pathfinding algorithms. Have you thought about hierarchical pathfinding? Reference to University of Albertas group.

71 71AI Interface Standards Committee Session 5: Steering Following slides prepared by Bjoern Knafla and Thaddaeus Frogley; presented by Nick Porcino

72 72 Our Goal: a standard interface to ease the integration of the user AI with a steering system. Current state: high-level concepts, nothing is implementation specific or set in stone. Introduction

73 73 Reactive, non-deliberative, based on local environment. For: boids, camera control, weapon targeting, non-cyclic pattern generation,... No backtracking, puzzle solving or "global" awareness. What is steering?

74 74 Integrate multiple (eventually conflicting) goals. Detect (potential) collisions with obstacles. Translate steering behaviors into character movement. Problems to solve

75 75 World representation. Steering behaviors. Arbiters. Internal information currency. Actuators. Possible concepts / components of steering

76 76 Steering behaviors are the key element of steering. Typical behaviors: seek/flee, pursue/evade, wander, arrival, obstacle avoidance, containment, wall following, path following, flow field following,... Steering behaviors

77 77 Combined steering behaviors and groups: crowd path following, leader following, unaligned collision avoidance, queuing, flocking,... Steering behaviors will produce "steering goals" used by arbiters. Steering behaviors

78 78 Will use steering behaviors to generate the "final steering goal" for the actuator. The user shall be able to plug-in his own arbiter. Possibly a combination of different arbitration strategies. Arbiter

79 79 Steering behaviors and arbiters will work with the same value types. Basic value type will be a vector-pair. Internal information currency

80 80 Should be user supplied to interface directly with the game. Will interpret the "final steering goal" delivered by the arbiter. Possible output: linear and angular accelerations. Actuator

81 81AI Interface Standards Committee Discussion: Steering

82 (Some) discussion comments: Had to emphasis to audience that even though they may have to supply aribtrators, the advantage is the uniform interface. Overall people didn't have much to say.

83 83AI Interface Standards Committee Session 6: Finite State Machines Following slides prepared by Nick Porcino; presented by Nick Porcino

84 84AI Interface Standards Committee Objectives identify how FSMs are commonly embedded in games define a common language to describe finite state machines define an XML description of FSMs for interoperability between tools define an API whereby FSMs can be efficiently and easily interfaced with other systems

85 85AI Interface Standards Committee Definitions overview like UML statecharts, with some simplifications FuSM, HSM

86 86AI Interface Standards Committee XML Description objective methodology definition

87 87AI Interface Standards Committee API Description objective methodology definition

88 88AI Interface Standards Committee Directions provides methods to facilitate interoperability with CASE tools provide easy interfacing to custom game authoring tools provide sample FSM implementations conforming to the specified API extensibility

89 89AI Interface Standards Committee Discussion: Finite State Machines

90 (Some) discussion comments: Interest in non-deterministic transitions. People misinterpreted probabilistic transitions as Fuzzy transitions. Some people described as FuSM what are really Markov Chains. FuSM might be viable technology on next generation hardware. It could be worthwhile to specify it now in anticipation of XBox2, PS3, etc. Someone suggested checking for ideas. This is an agent-based UML effort.

91 91AI Interface Standards Committee Session 7: Rule-based Systems Following slides prepared by Abdennour El Rhalibi; presented by Mark Kolenski

92 92Goal Oriented Action Planning Rule-Based Systems : Example IF (enemy visible) AND (my health is < very-low- health-value (20%)) OR (his weapon is much better than mine) THEN propose retreat

93 93Goal Oriented Action Planning Rule-Based Systems: Structure Rule Memory Working Memory Long-term Knowledge: (rules) Behaviours Definition Long-term Knowledge: (rules) Behaviours Definition World State Short-term Knowledge: (facts) World State Short-term Knowledge: (facts) Match Conflict Resolution Act Inference Engine

94 94Goal Oriented Action Planning RBS in Video Games: Applications NPC Behaviours: Quake,… Strategy / Tactics: Age of Empires,... Simulation: Civilization

95 95Goal Oriented Action Planning Rule-based System: Good and Bad Advantages –Corresponds to way people often think of knowledge –Very expressive and allows very complex behaviours –Modular knowledge Easy to write and debug compared to decision trees More concise than FSM Disadvantages –Can be memory intensive –Can be computationally intensive –Sometimes difficult to debug

96 96Goal Oriented Action Planning RBS Standard : Issues to Consider (I) Knowledge Representation –Production Rules –Frames/Object Oriented Representation Inference Mechanism –Rete/Treat… Control Mechanism –Forward/Backward Chaining –Depth/Breadth/Hybrid Search

97 97Goal Oriented Action Planning RBS Standard : Issues to Consider (II) System Architecture –Centralised –Multi-Agent architecture –BlackBoard World Interface issues –Interfacing with the game world : XML –Interfacing with the player : Script Implementation Issues –Language/API –New Technology

98 98Goal Oriented Action Planning State of Discussion Possible use of RBS in Sport game such as Baseball Real-time issues Interfacing with game world

99 99Goal Oriented Action Planning Presentation of Results Write-up of Report in state-of-the-art application of Rules-Based Systems to Video Games to be posted soon: –History of AI-Gaming –Application and Game Genres –FSM, Decision Tree, RBS: Definitions and Techniques –Latest Cases examples: RPG (Neverwinter Night, Baldurs Gate,…), Sport(Baseball,…), QuakeIII/Unreal… –Implementation issues –Possible Standard for rules-based system

100 100AI Interface Standards Committee Discussion: Rule-based Systems

101 (Some) discussion comments: SOAR might be a good way to learn about RBS.

102 102AI Interface Standards Committee Session 8: Goal-oriented Action Planning Following slides prepared by Ruth Aylett; presented by Alexander Nareyek

103 103Goal Oriented Action Planning The Issues Agreeing what GOAP is/is not –NOT: decision tree, FSM, agent architecture, A*, behaviours –IS: predictive, a sequence of actions, generative

104 104Goal Oriented Action Planning Key Terms Goal –State aimed for: e.g. in(gun, hand) Action –Achieves a goal: e.g draw-gun Pre-conditions –What must be true to carry out an action: e.g. in(gun, holster)

105 105Goal Oriented Action Planning Key Terms Plan –A sequence of actions –Each actions effects help meet pre-conditions of next in sequence –Sequence meets a goal or goals when executed

106 106Goal Oriented Action Planning The Issues Agreeing what it is good for in games –Not currently used unlike decision trees or path planning –So do we need it? Performance issues VITAL –Symbolic representations off- putting

107 107Goal Oriented Action Planning Good for … Repetitive fails by NPCs –But due to lack of memory of past actions Things too obviously driven by FSMs –GOAP can increase complexity of actions –Better believability

108 108Goal Oriented Action Planning Good for … Impoverished list of things to do, shallow goals –GOAP can provide more options and handle goal hierarchies Can remove duplicated code for different goals –As against hard-wired action sequences

109 109Goal Oriented Action Planning What is out there? Many architectures –BDI, HAP, Cougar –But that is NOT the purpose of this group

110 110Goal Oriented Action Planning PDDL Planner Domain Description Language –Community standard, represents actions, world, plans –A representation NOT a planning algorithm –Symbolic representation very costly –Too many features to attract developers

111 111Goal Oriented Action Planning Some initial proposals Recast PDDL subset in C++ –For speed and relevance –Use numeric representations

112 112Goal Oriented Action Planning For example GOAL = value or range of world variable –isSatisfied function to allow check on achievement ACTION –Prereq - same as goal –Adjustment - changes in world data on execution

113 113Goal Oriented Action Planning Planning Search actions to meet goal –A* one possibility (already used for pathplanning) –But may force large searches

114 114Goal Oriented Action Planning Open issues –Level of abstraction –Timing issues (how many frames for execution?) –Representing other-NPC data (e.g. position) –Need for a concrete example

115 115Goal Oriented Action Planning Where next Complete and refine current proposal Try it out on an example Iterate

116 116AI Interface Standards Committee Discussion: Goal-oriented Action Planning

117 (Some) discussion comments: The general concept of planning was not very clear to the audience, including the differences between GOAP and RBS. What would be the interface? How to make this in a non- game-specific way? How do you specify actions, goals? Following slides prepared by Alexander Nareyek; presented by Alexander Nareyek

118 118AI Interface Standards Committee Further Schedule Slides & roundtable report will be available on our webpage More detailed report on what we have done so far Next GDC: presentation of draft documents in a larger setting

119 119AI Interface Standards Committee

Download ppt "The following slides were presented at the GDC 2003 roundtable: AI Interface Standards: The Road Ahead Moderated by Alexander Nareyek, Nick Porcino and."

Similar presentations

Ads by Google