the following slides were presented at the gdc 2003 roundtable: ai interface standards: the road...
TRANSCRIPT
The following slides were presented at the GDC 2003 roundtable:
AI Interface Standards: The Road AheadModerated by Alexander Nareyek, Nick Porcino and Mark KolenskiMarch 8, 2003, 9-11:30amSan 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).
Notes on the roundtable’s 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.
AI Interface Standards: The Road Ahead
GDC 2003Following slides prepared by Alexander Nareyek;
presented by Alexander Nareyek
AI Interface Standards Committee4
http://www.igda.org/committees/ai.php
Artificial Intelligence Interface Standards Committee(AIISC)
AI Interface Standards Committee5
Goals
• Provide interfaces for basic AI
functionality
• Enable code recycling and
outsourcing
• In the long run: Support for
dedicated hardware
AI Interface Standards Committee6
Committee Composition
~ 70 members:
45% game developers
30% middleware
25% academia
AI Interface Standards Committee7
Working Groups
• Decision Trees
• Pathfinding
• Steering
• Finite State Machines
• Rule-based Systems
• Goal-oriented Action Planning
• World Interfacing
AI Interface Standards Committee8
Schedule
• After GDC: report on what
we have done so far
• Next GDC: presentation of
draft documents in a larger
setting
Your input today!
AI Interface Standards Committee9
Outline for Today
• Interleaved working group reports
and discussions
• Presented by
Alexander Nareyek (CMU)
Nick Porcino (LucasArts)
Mark Kolenski (Blue Fang
Games)
AI Interface Standards Committee10
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)
AI Interface Standards Committee11
Session 1:
Interface Formats
AI Interface Standards Committee12
System & AI Architecture
Function Library(simple, efficient)
Vs.
Agent-based(distribution, flexible)
AI Interface Standards Committee13
How Do We Specify our Standards?
• Abstract levels:
Ontologies & XML
• C/C++ Interfaces
• C/C++ Reference
Implementation
AI Interface Standards Committee14
Discussion:
Interface Formats
(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%
(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%
AI Interface Standards Committee17
Session 2:
World Interfacing
Following slides prepared by Christopher Reed;presented by Nick Porcino
AI Interface Standards Committee18
Outline
1) Goals
2) Definitions (World & AI)
3) World Services
3A) Senses
3B) Actuators
AI Interface Standards Committee19
(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.
AI Interface Standards Committee20
(2) Definition: The World
• The game world is everything
– Master simulator and arbitrator
– Manager of all data (state)
– Provider of services
AI Interface Standards Committee21
(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
AI Interface Standards Committee22
(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
AI Interface Standards Committee23
(2) Definition: AI
• AI may have:
– State
– Goals
• AI can:
– Select activities
– Respond to the world
AI Interface Standards Committee24
(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.
AI Interface Standards Committee25
(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.
AI Interface Standards Committee26
(3) Services
• There are two primary types
of services that the world
provides to AI:
A) Senses
B) Actuators
AI Interface Standards Committee27
(3A) Senses
• Sensory information provides
an agent with awareness
about the game world.
AI Interface Standards Committee28
(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.
AI Interface Standards Committee29
(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.
AI Interface Standards Committee30
(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.
AI Interface Standards Committee31
(3A1) Events
• The game world tells AI what
events are available by
posting them to the Event
Space.
AI Interface Standards Committee32
(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.
AI Interface Standards Committee33
(3A2) Queries
• Queries allow AI to ask
questions about the game
world.
AI Interface Standards Committee34
(3A2) Queries
• There are several types of
questions that an agent may ask:
1) Provide information about an
entity:
- What is (Bob‘s) (health)?
- Is (Joe) (flying)?
AI Interface Standards Committee35
(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?
AI Interface Standards Committee36
(3A2) Queries
• There may be additional types
to test for collisions and
visibility, but the format has
not been decided.
AI Interface Standards Committee37
(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.
AI Interface Standards Committee38
(3B) Actuators
• There are two types of
actuators:
1) Actions – short term behavior
2) Effectors – long term behavior
with non constant parameters
AI Interface Standards Committee39
(3B1) Actions
• Actions have a finite and
small duration with
unchanging parameters.
• An example of an action is
making a sound.
AI Interface Standards Committee40
(3B1) Actions
• It is the responsibility of the
game to make sure that
actions are resolved and
carried out on behalf of the
AI.
AI Interface Standards Committee41
(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.
AI Interface Standards Committee42
(3B1) Actions
• The game tells AI what
actions and effectors are
available by placing them on
the action and effector
blackboards.
AI Interface Standards Committee43
(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.
AI Interface Standards Committee44
(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.
AI Interface Standards Committee45
(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.
AI Interface Standards Committee46
Overview
(3A) Senses
-(3A1) Events (short)
-(3A2) Queries (question)
(3B) Actuators
-(3B1) Actions (short, static)
-(3B2) Effectors (long, dynamic)
AI Interface Standards Committee47
Discussion:
World Interfacing
(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…
AI Interface Standards Committee49
Session 3:
Decision Trees
Following slides prepared by Mark Kolenski;presented by Mark Kolenski
AI Interface Standards Committee50
Decision TreesWhat ARE They?
• Different disciplines and
definitions.
• May be probabilistic, dynamic,
used in learning, expert
systems, philosophy.
AI Interface Standards Committee51
Simple Example
• Attack or defend?
• Actions are called (child)
nodes.
AI Interface Standards Committee52
Example (cont.)
• How to decide?
• Utility Function - one
convenient number per node.
• Perform the node that comes
out the „best“.
AI Interface Standards Committee53
Life is Not So Simple
• Probabilities (Bayesian)
• Degrees of Belief
• Chance (Nasty World)
AI Interface Standards Committee54
In Games
• Do Many Games Use Them?
• Not clear
• Why? Uncertainty (or to make
a humanlike opponent).
AI Interface Standards Committee55
Agreements
• K.I.S.S. In The Beginning
• Definitions
• Real Game Decisions
• GOAL: Preliminary Interface
AI Interface Standards Committee56
Discussion
• Should We Bother?
• At What Level?
• How General?
AI Interface Standards Committee57
Discussion:
Decision Trees
(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
AI Interface Standards Committee59
COFFEE BREAK!
Please be back at10:30
AI Interface Standards Committee60
Session 4:
Pathfinding
Following slides prepared by Noel Stephens;presented by Mark Kolenski
AI Interface Standards Committee61
The Path Finding GroupThe Path Finding Group
Our preliminary goal is to define the
core terminology and techniques
associated with commonly used
path finding algorithms and data
structures.
AI Interface Standards Committee62
General TerminologyGeneral 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.
AI Interface Standards Committee63
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?What is Path Finding?
AI Interface Standards Committee64
A graph is a class that contains a
collection of nodes.
What is a Graph?What is a Graph?
Graph
Node
Node
NodeNodeNodeNodeNodeNode
AI Interface Standards Committee65
A node is a class that contains a set of
connections to other nodes.
What is a Node?What is a Node?
Graph
Node
Node
NodeNodeNodeNodeNodeNode
ConnectionConnectionSetSet
AI Interface Standards Committee66
A connection holds information about the
path to the destination node as well as
a pointer to the destination node.
What is a Connection?What is a Connection?
Graph
Node
Node
NodeNodeNodeNodeNodeNode
ConnectionConnection
ConnectionConnection
ConnectionConnection
ConnectionConnectionSetSet
AI Interface Standards Committee67
Cost for a connection can be relative to
the agent contemplating the
connection.
How much does it cost?How much does it cost?
ConnectionConnectionAgent
Cost CallbackCost Callback
AI Interface Standards Committee68
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.Where we go from here.
AI Interface Standards Committee69
Discussion:
Pathfinding
(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 Alberta’s group.
AI Interface Standards Committee71
Session 5:
Steering
Following slides prepared by Bjoern Knafla and Thaddaeus Frogley;presented by Nick Porcino
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
• 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
• Integrate multiple (eventually conflicting) goals.
• Detect (potential) collisions with obstacles.
• Translate steering behaviors into character movement.
Problems to solve
75
• World representation.
• Steering behaviors.
• Arbiters.
• Internal information currency.
• Actuators.
Possible concepts / components of steering
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
• 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
• 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
• Steering behaviors and arbiters will work with the same value types.
• Basic value type will be a vector-pair.
Internal information currency
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
AI Interface Standards Committee81
Discussion:
Steering
(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.
AI Interface Standards Committee83
Session 6:
Finite State Machines
Following slides prepared by Nick Porcino;presented by Nick Porcino
AI Interface Standards Committee84
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
AI Interface Standards Committee85
Definitions
• overview
• like UML statecharts, with some simplifications
• FuSM, HSM
AI Interface Standards Committee86
XML Description
• objective
• methodology
• definition
AI Interface Standards Committee87
API Description
• objective
• methodology
• definition
AI Interface Standards Committee88
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
AI Interface Standards Committee89
Discussion:
Finite State Machines
(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 auml.org for ideas. This is an agent-based UML effort.
AI Interface Standards Committee91
Session 7:
Rule-based Systems
Following slides prepared by Abdennour El Rhalibi;presented by Mark Kolenski
Goal Oriented Action Planning92
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
Goal Oriented Action Planning93
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
ConflictResolutionAct
Inference EngineInference Engine
Goal Oriented Action Planning94
RBS in Video Games: Applications
• NPC Behaviours: Quake,…• Strategy / Tactics: Age of Empires,...• Simulation: Civilization
Goal Oriented Action Planning95
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
Goal Oriented Action Planning96
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
Goal Oriented Action Planning97
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
Goal Oriented Action Planning98
State of Discussion
• Possible use of RBS in Sport game such as Baseball
• Real-time issues
• Interfacing with game world
Goal Oriented Action Planning99
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,
Baldur’s Gate,…), Sport(Baseball,…), QuakeIII/Unreal…
– Implementation issues– Possible Standard for rules-based system
AI Interface Standards Committee100
Discussion:
Rule-based Systems
(Some) discussion comments:
• SOAR might be a good way to learn about RBS.
AI Interface Standards Committee102
Session 8:
Goal-oriented Action Planning
Following slides prepared by Ruth Aylett;presented by Alexander Nareyek
Goal Oriented Action Planning103
The Issues
• Agreeing what GOAP is/is not– NOT: decision tree, FSM, agent
architecture, A*, behaviours
– IS: predictive, a sequence of actions, generative
Goal Oriented Action Planning104
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)
Goal Oriented Action Planning105
Key Terms
• Plan– A sequence of actions
– Each action’s effects help meet pre-conditions of next in sequence
– Sequence meets a goal or goals when executed
Goal Oriented Action Planning106
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
Goal Oriented Action Planning107
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
Goal Oriented Action Planning108
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
Goal Oriented Action Planning109
What is out there?
• Many architectures– BDI, HAP, Cougar
– But that is NOT the purpose of this group
Goal Oriented Action Planning110
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
Goal Oriented Action Planning111
Some initial proposals
• Recast PDDL subset in C++– For speed and relevance
– Use numeric representations
Goal Oriented Action Planning112
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
Goal Oriented Action Planning113
Planning
• Search actions to meet goal– A* one possibility (already used
for pathplanning)
– But may force large searches
Goal Oriented Action Planning114
Open issues
– Level of abstraction
– Timing issues (how many frames for execution?)
– Representing other-NPC data (e.g. position)
– Need for a concrete example
Goal Oriented Action Planning115
Where next
• Complete and refine current proposal
• Try it out on an example
• Iterate
AI Interface Standards Committee116
Discussion:
Goal-oriented Action Planning
(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
AI Interface Standards Committee118
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
AI Interface Standards Committee119
http://www.igda.org/committees/ai.php