The following slides were presented at the GDC 2003 roundtable: AI Interface Standards: The Road...

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)


Goals

• Provide interfaces for basic AI

functionality

• Enable code recycling and

outsourcing

• In the long run: Support for

dedicated hardware


Committee Composition

~ 70 members:

45% game developers

30% middleware

25% academia


Working Groups

• Decision Trees

• Pathfinding

• Steering

• Finite State Machines

• Rule-based Systems

• Goal-oriented Action Planning

• World Interfacing


Schedule

• After GDC: report on what

we have done so far

• Next GDC: presentation of

draft documents in a larger

setting

Your input today!


Outline for Today

• Interleaved working group reports

and discussions

• Presented by

Alexander Nareyek (CMU)

Nick Porcino (LucasArts)

Mark Kolenski (Blue Fang

Games)


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)


Session 1:

Interface Formats


System & AI Architecture

Function Library(simple, efficient)

Vs.

Agent-based(distribution, flexible)


How Do We Specify our Standards?

• Abstract levels:

Ontologies & XML

• C/C++ Interfaces

• C/C++ Reference

Implementation


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%


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%


Session 2:

World Interfacing

Following slides prepared by Christopher Reed;presented by Nick Porcino


Outline

1) Goals

2) Definitions (World & AI)

3) World Services

3A) Senses

3B) Actuators


(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.


(2) Definition: The World

• The game world is everything

– Master simulator and arbitrator

– Manager of all data (state)

– Provider of services


(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


(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


(2) Definition: AI

• AI may have:

– State

– Goals

• AI can:

– Select activities

– Respond to the world


(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.


(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.


(3) Services

• There are two primary types

of services that the world

provides to AI:

A) Senses

B) Actuators


(3A) Senses

• Sensory information provides

an agent with awareness

about the game world.


(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.


(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.


(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.


(3A1) Events

• The game world tells AI what

events are available by

posting them to the Event

Space.


(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.


(3A2) Queries

• Queries allow AI to ask

questions about the game

world.


(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)?


(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?


(3A2) Queries

• There may be additional types

to test for collisions and

visibility, but the format has

not been decided.


(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.


(3B) Actuators

• There are two types of

actuators:

1) Actions – short term behavior

2) Effectors – long term behavior

with non constant parameters


(3B1) Actions

• Actions have a finite and

small duration with

unchanging parameters.

• An example of an action is

making a sound.


(3B1) Actions

• It is the responsibility of the

game to make sure that

actions are resolved and

carried out on behalf of the

AI.


(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.


(3B1) Actions

• The game tells AI what

actions and effectors are

available by placing them on

the action and effector

blackboards.


(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.


(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.


(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.


Overview

(3A) Senses

-(3A1) Events (short)

-(3A2) Queries (question)

(3B) Actuators

-(3B1) Actions (short, static)

-(3B2) Effectors (long, dynamic)


Discussion:

World Interfacing


• 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…


Session 3:

Decision Trees

Following slides prepared by Mark Kolenski;presented by Mark Kolenski


Decision TreesWhat ARE They?

• Different disciplines and

definitions.

• May be probabilistic, dynamic,

used in learning, expert

systems, philosophy.


Simple Example

• Attack or defend?

• Actions are called (child)

nodes.


Example (cont.)

• How to decide?

• Utility Function - one

convenient number per node.

• Perform the node that comes

out the „best“.


Life is Not So Simple

• Probabilities (Bayesian)

• Degrees of Belief

• Chance (Nasty World)


In Games

• Do Many Games Use Them?

• Not clear

• Why? Uncertainty (or to make

a humanlike opponent).


Agreements

• K.I.S.S. In The Beginning

• Definitions

• Real Game Decisions

• GOAL: Preliminary Interface


Discussion

• Should We Bother?

• At What Level?

• How General?


Discussion:

Decision Trees


• 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


COFFEE BREAK!

Please be back at10:30


Session 4:

Pathfinding

Following slides prepared by Noel Stephens;presented by Mark Kolenski


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.


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.


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?


A graph is a class that contains a

collection of nodes.

What is a Graph?What is a Graph?

Graph

Node

Node

NodeNodeNodeNodeNodeNode


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


ConnectionConnectionSetSet


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


ConnectionConnection



ConnectionConnectionSetSet


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


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.


Discussion:

Pathfinding


• 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.


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


Discussion:

Steering


• 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.


Session 6:

Finite State Machines

Following slides prepared by Nick Porcino;presented by Nick Porcino


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


Definitions

• overview

• like UML statecharts, with some simplifications

• FuSM, HSM


XML Description

• objective

• methodology

• definition


API Description

• objective

• methodology

• definition


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


Discussion:

Finite State Machines


• 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.


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


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


RBS in Video Games: Applications

• NPC Behaviours: Quake,…• Strategy / Tactics: Age of Empires,...• Simulation: Civilization


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


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


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


State of Discussion

• Possible use of RBS in Sport game such as Baseball

• Real-time issues

• Interfacing with game world


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


Discussion:

Rule-based Systems


• SOAR might be a good way to learn about RBS.


Session 8:

Goal-oriented Action Planning

Following slides prepared by Ruth Aylett;presented by Alexander Nareyek


The Issues

• Agreeing what GOAP is/is not– NOT: decision tree, FSM, agent

architecture, A*, behaviours

– IS: predictive, a sequence of actions, generative


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)


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


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


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


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


What is out there?

• Many architectures– BDI, HAP, Cougar

– But that is NOT the purpose of this group


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


Some initial proposals

• Recast PDDL subset in C++– For speed and relevance

– Use numeric representations


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


Planning

• Search actions to meet goal– A* one possibility (already used

for pathplanning)

– But may force large searches


Open issues

– Level of abstraction

– Timing issues (how many frames for execution?)

– Representing other-NPC data (e.g. position)

– Need for a concrete example


Where next

• Complete and refine current proposal

• Try it out on an example

• Iterate


Discussion:

Goal-oriented Action Planning


• 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


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


http://www.igda.org/committees/ai.php

The following slides were presented at the GDC 2003 roundtable: AI Interface Standards: The Road...

Documents

Transcript of The following slides were presented at the GDC 2003 roundtable: AI Interface Standards: The Road...