basic ai techniques for npc behaviours: fstn · doom, tekken, air combat, etc.) – current phase...

Basic AI Techniques for NPC Behaviours: FSTNfor NPC Behaviours: FSTN

Finite-State Transition Networks

Action

Team Buddies (SCEE)™

dState

Percept

Transition

ActionA

dState

Percept

Transition

Action

Introduction

• Behaviours characterise the possible actions that NPCs or automatic players will perform in reaction to, e.g.:

– their physical environment

(e.g. Lemmings)

– human player’s location or real-time actions (e.g.

Doom, Tekken, Air Combat, etc.)

– current phase of the game

(e.g. RISK)

– Etc.

“Intelligent” Behaviours

• We here consider behaviours to be restricted to “intelligent behaviours” (i.e. AI-based)

• Computation of a trajectory in a racing game would not fall under that concept not fall under that concept --- only if based on kinematics.

• … but decisions to undertake/attack other cars/vessels do!

Behaviours and Gameplay

• Complex behaviours implement more intelligent opponents.

• They can also define a kind of “personality” for NPCs or opponents.

• The more you formalise behaviours, the more you make some gameplay concepts explicit.

Finite-State Systems

• They describe devices that can take discrete states.

• They can represent compiled plans.compiled plans.

• Two main concepts:

–SSSStates–TTTTransitions

Percept

Transition

(adapted from A. Whittaker)

FSTN (2)

ActionA

dState

Percept

Transition

Action

FSTN (3)

Register

dState

Percept

Transition

Action

Example: Quake™

• The artificial opponents go through a cycle of:

– being idle,

– attacking,

– reacting to attack,

– etc.

• Their behaviour is based on the definition of:

– the cycle of states and,

– the transitions between such states.

The “Original” Quake™ FSA

Quake FSA (comments)

attackattackattackattacksees enemy

kills enemy

gets killed

gets hurt

Compute LOS Compute damage

idleidleidleidle deaddeaddeaddead

kills enemy

loses interest loses sight

of enemy

gets hurt

Compute LOSCompute, e.g. time limit

retaliate

Search procedure

Change

appearancesearchsearchsearchsearch hurthurthurthurt

• For a given FSA, you can fine-tune behaviour:– You can vary the time limit for losing interest to make

characters more persistent.

– You can alter line of sight.

Quake FSA (Quake FSA (Quake FSA (Quake FSA (commentscommentscommentscomments))))

– You can have them escape if hurt, rather than retaliate.

• A good formalisation gives you the basis to make consistent changes and/or improvements.

Prefer FSA if:

• Small set of clearly identified states.

• Meaningful transitions.

• Clear pre-conditions (action representation).

• A priori definition, with little need for • A priori definition, with little need for change or experimentation.

• Variant: cascaded FSA.

FSA: Representing Transitions

FSA: from description to interpretation

• FSA are generally described for parsing

sequences of tokens.

• When they describe (compiled) plans or behaviours, you have to compute the next behaviours, you have to compute the next

transition, rather than accepting a token and checking compatible transitions.

Developing FSTN Systems

• The development of FSTN systems comprises several steps:

– Collecting the data.

– Formalising FSTN.

– Choosing an implementation tool/method.

– Testing.

– Maintenance.

Maintenance

• It is often difficult to manage a large large large large number of FSTN.

• This is a problem when adding new FSTN:

FSTN are a procedural formalism (and not declarative) and, as such, rather difficult to maintain

?? FSTN:

• integrating• testing

FSTN ExampleFSTN Example

Queuing Agents (1)

The cheeky agent

The violated agent

An available position

The ‘cheeky’ agent will

need to move to this

position before they

can advance in the

Figure 2.2

How an agent jumps the queue

Queuing Agents (2)

Introduce “conflict”Introduce “conflict”

Baseline Behaviour

“Double” Skip

Successful Skip

Cheating Fails …

Finite-State Transition Networks

Finite State Machines (FSMs) Finite State Machines (FSMs) - Implementation Issues -

• are a simple and efficient method to implement many game features.

• may be diagrammed using a standard diagram • may be diagrammed using a standard diagram format called a directed graph, which is easy to read and understand, even for non-programmers (this facilitates discussions with the Design team).

FSMs (2)

• describe under which events/conditions a current state is to be replaced by another

– for example, switching from an attack mode to an

escape mode if the NPC is hit.

• is mostly a design concept

– i.e. the game has no general FSM interpreter, but the

FSMs are usually created using individual entities

(scripts, or else).

Ghosts in PacMan

Ghosts’ behaviour in PacMan

• All ghosts have the same Evade state,

• Each ghost has its own Chase state,

– the actions of which are implemented differently for

each ghost.each ghost.

• The input of the player eating one of the power pills is the condition for the transition from Chase to Evade.

• The input of a timer running down is the condition for the transition from Evade to Chase.

Quake-like Bots

Bots’ behaviour

• Bots include states such as

– FindArmor, FindHealth, SeekCover, and RunAway.

• Even the weapons in Quake implement their own • Even the weapons in Quake implement their own mini finite state machines.

– E.g. a rocket may implement states such as

Move, TouchObject, and Die.

FIFA 2002

Football players in FIFA 2002

• Players’ behaviour can be defined via states such as:

– Strike, Dribble, ChaseBall, and MarkPlayer.

• In addition, the teams themselves are often implemented as FSMs and can have states such as:

– KickOff, Defend, or WalkOutOnField.

World of Warcraft

• NPCs in RTSs (real-time strategy games) such as World of Warcraft also make use of finite state machines.

• They have states such as:

– MoveToPosition, Patrol, and FollowPath.

Example for RTS genre

Example for FPS genre

State Transition Tables

• A better mechanism for organizing states and affecting state transitions.

• Definition: a table of conditions and the states those conditions lead to.those conditions lead to.

State Transition Tables (2)

• table can be queried by an agent at regular intervals,

• enabling it to make any necessary state transitions based on the stimulus it receives from the game environment. environment.

• Each state can be modeled as a separate object or function existing external to the agent, providing a clean and flexible architecture.

• One that is much less prone to confusion than embedding all transitions in an if-then/switch

Embedded Rules

• An alternative approach is to embed the rules for the state

transitions within the states themselves.

• States are encapsulated as objects and contain the logic

required to facilitate state transitions.required to facilitate state transitions.

• Each state is a self-contained unit and not reliant on any

external logic to decide whether or not it should allow itself

to be swapped for an alternative.

Bot class

• Imagine a Bot class that has member variables for attributes such as health, anger, stamina, etc., and an interface allowing a client to query and adjust those values. those values.

• A Bot can be given the functionality of a finite state machine by adding a pointer to an instance of a derived object of the State class, and a method permitting a client to change the instance the pointer is pointing to.

Process

• When the Update method of an Agent is called, it in turn calls the Execute method of the current state.

• The current state may then use the Bot interface • The current state may then use the Bot interface to query its owner, to adjust its owner’s attributes, or to effect a state transition.

• In other words, how a Bot behaves when updated can be made completely dependent on the logic in its current state.

References

• Programming Game AI by Example by Mat Buckland ISBN 1-55622-078-2

• Finite State Machine Tutorial• Finite State Machine TutorialBy Nathaniel Meyer http://www.generation5.org/content/2003/FSM_Tutorial.asp

… Even Better

• Develop a visual programming interface when FSTN are “drawn”

• Generates code corresponding to this FSTN • Generates code corresponding to this FSTN

• Communication between NPC/Bot’s states and those produced by the FSTN code

Quake™: from FSTN to RuleQuake™: from FSTN to RuleQuake™: from FSTN to RuleQuake™: from FSTN to Rule----based based based based SystemsSystemsSystemsSystemsSystemsSystemsSystemsSystems

(introducing SOAR-Quakebot by John Laird)

Quake III NPC AI

Most material from [van Waveren and Rothkrantz, 2001]

Quake’s FSTN

Layered Architecture

Team leader AI

AI NetworkMisc. AI Commands

Fuzzy Character Goals ChatsNavigation

Area Awareness System Basic Actions

Layered Architecture

• 1st layer: I/O layer for the bot (basic actions are the output)

• 2nd layer: “subconscious” intelligence, “fuzzy logic” for goal selection

• 3rd layer: mixture of production rules and “AI • 3rd layer: mixture of production rules and “AI network” (FSTN). High-level reasoning: navigation and fighting

• 4th layer: for team leaders (co-ordination knowledge)

Game “AI Network”

Long-Term Goal

Short-Term Goal

Activate Enemy

Stand Respawn

Battle

Short-Term GoalBattle RetreatBattle ChaseBattle Fight

Integration in the Game Engine

Server

Bot AI (layers 3-4)

Bot AI (layers 1-2)

networking

Client

Client Game

Renderer

Client code

provided the IO

functionality for

Human players

3D image

networking

Area Awareness System

• Provides Information about the current state of the world

• Includes: navigation, routing, other entities …

• Based on a 3D representation of the world• Based on a 3D representation of the world

• 3D bounded hulls (= areas)

• Everything the bot senses goes through the AAS

Area Awareness System

• The map is subdivided into convex hulls using Binary Space Partitioning (BSP)

• Areas specific property: the navigation • Areas specific property: the navigation complexity for travelling between any two reachable points in the area is minimal

• It is further required to compute reachability

“Terrain Reasoning”

• Predicting out-of-sight threats

• Dynamic situations (seeking cover, concealed paths)paths)

• Waypoint resolution

• Terrain pre-processing

Rule-based decisions

IF the bot is fighting

AND the bot is low on health

AND the bot does not have a powerful weaponAND the bot does not have a powerful weapon

THEN retreat from the fight

Rule-based decisions

IF the bot is fighting

AND the bot is not fit enough to fight

THEN retreat from the fightTHEN retreat from the fight

(but in Quake III, these are essentially implemented in several

procedures, not taking advantage of rule modularity)

“Fuzzy” Coefficients

• Inspired from Fuzzy Logic

• Fuzzy relations are used to express the relation between the bot’s current state and possible desires/goals

• Example: based on which weapon the bot is • Example: based on which weapon the bot is holding, and how much ammo the bot has for the weapon, the bot can attach a fuzzy value to its desire for more ammo

• Also used in conjunction with rules

Bot Characters

• 25 characteristics: –name, gender, aggression, alertness,

jumper, walker, attack skills, aim jumper, walker, attack skills, aim

accuracy, weapon weights, item weights,

chats, etc.

Results

• Quake III Arena bot

• Soar-Quakebots• Soar-Quakebots

• Performance vs. human-like ability

• Build an AI Engine around the Soar AI architecture– Soar/Quake II

– Soar/Descent 3

– Soar/Half-life

Soar/Games Project

Quake II

• Build autonomous, unscripted AIs

Interface

AI Engine

(Soar)

Knowledge

FilesActions

Sensor Data

• AI engine to support multi-method problem solving

– Applied to wide variety of tasks and methods

• Proposed unified theory for modeling human cognition

– Models a wide variety of human behavior: language, HCI, ...

• Combines reactive and goal-directed symbolic processing• Combines reactive and goal-directed symbolic processing

• Supports very large bodies of knowledge (>100,000 rules)

• Optimized implementation in ANSI C

• In the public domain

Soar Quakebot

• Goal: Human-like behavior– Fun and challenging to play against

– Not super-human

– Currently plays as well as good player

• Completely implemented in Soar– > 750 rules– > 750 rules

– Spread across operators for exploring, wandering, chasing, …

• Sensing similar to human

• Runs on separate PC from game– Uses ~5-10% of 400 MHz Win-95/98/NT machine

Execution Flow of an AI Engine

Simulated Perception

Self: orientation, position, health

Senses: vision, hearing, smell, taste, touch

Augmented Senses: radar, night-vision, …

> 80 sensors in Quakebot

Obstacle

Field of Vision

Simulated Actions

Movement, weapons’ use, communication

~20 actions in Quakebot

Obstacle

Execution Flow of an AI Engine

Finite-state machines

Subsumption

?Neural nets

Rule-based systems

C code

Planning systems

Rule-based Systems

• Program = set of if-then rules, not sequential code.

– Use whatever knowledge that is relevant to current

situation

Rule MemoryTactics, Movement Knowledge, ...

Working Memory

sensing, elaborations, persistent memories, goals, actions …

[ ] [ ][ ]

Match Changes

[ ] [ ][ ]

• Conditions contain variables and other first-order tests– If sense a weapon and do not have that weapon,

pickup the weapon.

(p rule1

(sense weapon ?weapon1)

(self weapon <> ?weapon1)

��

(action pickup ?weapon1))

• A single rule can have multiple instantiations– A single condition can match multiple working memory

elements

• Compilers convert rules into discrimination networks

Which Rule Should Fire?

• Matching finds which rules can fire in current situation.

Memory

Working [ ] [ ] [ ] [ ]

[ ] [ ]

Rule Instantiations

?Conflict resolution

• Conflict resolution picks which rules actually fire.

– Based only on syntactic features of rules and data.

– Must engineer rules so correct rule is selected each time.

Working

Memory

[ ] [ ] [ ] [ ]

[ ] [ ]

Weaknesses in Rules

• Conflict resolution based on syntactic features – Not knowledge of the task

• Rules combine three types of knowledge about actions– What is possible– What is possible

– What should be done (based on conflict resolution)

– How to do it

Leads to duplication if have multiplicity in one of the types

• No hierarchical organization of knowledge and goals

Soar’s Approach

• Organize knowledge as operators:

– Primitive & abstract actions

– Turn, move, climb, goto-door, get-item, wander, attack, chase

– Provides trace of behavior comparable to human decisions

• Use rules to propose, select, and apply operators

– Rules fire in parallel - act as an associative memory– Rules fire in parallel - act as an associative memory

– Provides fine-grain, situation-dependent behavior

– Conditional selection and execution determined dynamically

Execution Flow of Soar Engine

Elaboration

Propose Operators

Evaluate Proposed Operators

Select One Operator

Perform Operator Actions

Get item

Go through

Get item in room

Detect item

missing

Face item Move

to item

moving

door missingto itemmoving

to item

room door

with door

to door

Record

at door

Shoot Slide to

Stop move

to door

Stop slide

to door

Soar Quakebot Top Operators

WanderAttack ExploreRetreat Record

Remove

If enemy visible and

my health is > very-low-health-value (20%) and

his weapon is not much better than mine

THEN propose attack

If enemy visible and

my health is < very-low-health-value (20%) or

his weapon is much better than mine

THEN propose retreat

If no enemy visible or recorded and explored level

THEN propose wander

If no enemy visible or recorded and not explored level

THEN propose explore

Remove

If enemy just became not visible

and no enemy visible or recorded

THEN propose record-enemy

If hear enemy and no enemy visible or recorded

If record-enemy selected

THEN record enemy’s last position and time + 20 seconds.

If hear enemy and no enemy visible or recorded

THEN propose record-enemy

If time > recorded enemy’s saved time

THEN propose remove-enemy

If remove-enemy is selected

THEN remove recorded enemy structure

If there is a recorded enemy structure

THEN propose chase

Example Rules

IF I see a weapon that is much better than any I have

THEN I need that weapon

Attack

Get-item Face-enemy Side-step Approach Shoot

IF attacking an enemy and

there is an object I need and that

object is closer than attack-get-item-range

THEN propose get-item for that object

IF my health is less than low-health-value (40%)

THEN I need any health object

IF two get-item operators are proposed

THEN prefer selecting the one for the closer object

Get item

Go through

Get item in room

Detect item

missing

Face item Move

to item

moving

to item

room door

with door

to door

Record

at door

Shoot Slide to

Stop move

to door

Stop slide

to door

Get item

Go through

Get item in room

Detect item

missing

Face item Move

to item

moving

to item

room door

with door

to door

Record

at door

Shoot Slide to

Stop move

to door

Stop slide

to door

Get item

Go through

Get item in room

Detect item

missing

Face item Move

to item

moving

to item

room door

with door

to door

Record

at door

Shoot Slide to

Stop move

to door

Stop slide

to door

Get item

Go through

Get item in room

Detect item

missing

Face item Move

to item

moving

to item

room door

with door

to door

Record

at door

Shoot Slide to

Stop move

to door

Stop slide

to door

Get item

Go through

Get item in room

Detect item

missing

Face item Move

to item

moving

to item

room door

with door

to door

Record

at door

Shoot Slide to

Stop move

to door

Stop slide

to door

Get item

Go through

Get item in room

Detect item

missing

Face item Move

to item

moving

to item

room door

with door

to door

Record

at door

Shoot Slide to

Stop move

to door

Stop slide

to door

Get item

Go through

Get item in room

Detect item

missing

Face item Move

to item

moving

to item

room door

with door

to door

Record

at door

Shoot Slide to

Stop move

to door

Stop slide

to door

Get item

Go through

Get item in room

Detect item

missing

Face item Move

to item

moving

to item

room door

with door

to door

Record

at door

Shoot Slide to

Stop move

to door

Stop slide

to door

Get item

Go through

Get item in room

Detect item

missing

Face item Move

to item

moving

to item

room door

with door

to door

Record

at door

Shoot Slide to

Stop move

to door

Stop slide

to door

Example Tactics

• Collect-Powerups– Pick up best weapons from spawn locations

– Remember when missing items will respawn

– Use shortest paths to get objects

– Get health/armor if low on health/armor

– Pickup up other good weapons/ammo if close by to deny enemy

• Attack • Attack – Use circle-strafe

– Move to best distance for current weapon

• Chase enemy based on sound of running

• Ambush in corner that can’t be seen by enemy

• Hunt at nearest spawn room after killing enemy

Mapping

• Need information on location of walls, doors, etc.– Many tactics require this information

• Built up through exploration of a level– Similar to a robot exploring with range sensors

– Saved and reused when return to level

• Represented internally as a graph structure– Currently restricted to 2D rectangles

basic ai techniques for npc behaviours: fstn · doom, tekken, air combat, etc.) – current phase...

Documents

challenging travel behaviours

challenging behaviours

london undergound behaviours communications development...

threads & behaviours

measuring household food waste the uk...

12 tech behaviours

behaviours and motivation

seven behaviours

community change foundation: “mentoring to address risk...

powerbook 140/145/ 145b/170 -...

responsive behaviours

behaviours that challenge

behaviours for survival

attitudes and behaviours

tausug behaviours

character display module - focus lcds · lcd type tn fstn...

specifications for lcd module - panda-bg.com...g→ stn...

behaviours - answers

aua professional behaviours

specifications for lcd module - pacer usag stn positive,...