CO Games Development 2 Week 19 Extensions to Finite State Machines

Slides:



Advertisements
Similar presentations
Configuration management
Advertisements

ARCHITECTURES FOR ARTIFICIAL INTELLIGENCE SYSTEMS
Lecture 8: Three-Level Architectures CS 344R: Robotics Benjamin Kuipers.
Artificial Intelligence in Game Design Representing NPCs as Finite State Machines.
Artificial Intelligence in Game Design Hierarchical Finite State Machines.
Using Cellular Automata and Influence Maps in Games
IofT 1910 W Fall 2006 Week 5 Plan for today:  discuss questions asked in writeup  talk about approaches to building intelligence  talk about the lab.
SE-565 Software System Requirements More UML Diagrams.
Winrunner Usage - Best Practices S.A.Christopher.
1 CO Games Development 1 Week 6 Introduction To Pathfinding + Crash and Turn + Breadth-first Search Gareth Bellaby.
Artificial Intelligence in Game Design Behavior Trees.
Architecture styles Pipes and filters Object-oriented design Implicit invocation Layering Repositories.
1 CO Games Development 2 Week 19 Probability Trees + Decision Trees (Learning Trees) Gareth Bellaby.
1 CO Games Development 2 Week 17 – Goal-Oriented Action Planning Gareth Bellaby.
Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, Operating System Concepts Operating Systems Lecture 6 System Calls OS System.
Prog. techniques. Standard prog. techniques Complex programs can be broken down into simpler parts called “Modules” These come in 2 types,“Procedures”
Games Development 2 Review & Revision Strategy CO3301 End of Semester 1.
SOFTWARE DESIGN. INTRODUCTION There are 3 distinct types of activities in design 1.External design 2.Architectural design 3.Detailed design Architectural.
Games Development 2 Overview & Entity IDs and Communication CO3301 Week 1.
Games Development Game Architecture: Entities CO2301 Games Development 1 Week 22.
Artificial Intelligence for Games Finite State Machines
AI & Machine Learning Libraries By Logan Kearsley.
Computer Graphics Matrix Hierarchies / Animation
Dr Nick Mitchell (Room CM 224)
Finite State Machines (FSM) OR Finite State Automation (FSA) - are models of the behaviors of a system or a complex object, with a limited number of defined.
1 CO Games Development 1 Week 4 Finite State Machines + Maths Gareth Bellaby.
1 CO Games Development 2 Week 16 Blackboard Model Gareth Bellaby.
Finite State Machines Logical and Artificial Intelligence in Games Lecture 3a.
1 CO Games Development 2 Week 13 Influence Maps Gareth Bellaby.
Team Member AI in an FPS and Goal Oriented Action Planning.
Representing Structure and Behavior
Implementing Subprograms
Recursion.
Chapter 10 : Implementing Subprograms
OOP - Object Oriented Programming
Architectures of Digital Information Systems Part 1: Interrupts and DMA dr.ir. A.C. Verschueren Eindhoven University of Technology Section of Digital.
CO Games Development 2 Week 16 Blackboard Model
Animation and Simulation Plus Interaction
Advantages of FSM Their simplicity make it easy for inexperienced developers to implement with little to no extra knowledge (low entry level)
CHP - 9 File Structures.
CO Games Development 2 Week 22 Trees
Do software agents know what they talk about?
COMPILERS Activation Records
Games Development 2 semester 1 Review & Revision
Event driven architectures
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Enemy and Friendly AIs Richard Gesick.
Hierarchical Architecture
#01 Client/Server Computing
Build Intelligence from the bottom up!
Build Intelligence from the bottom up!
About Instructions Based in part on material from Chapters 4 & 5 in Computer Architecture by Nicholas Carter PHY 201 (Blum)
Implementing Subprograms
Algorithm An algorithm is a finite set of steps required to solve a problem. An algorithm must have following properties: Input: An algorithm must have.
Princess Nourah bint Abdulrahman University
Coding Concepts (Basics)
CO Games Development 2 Week 24 - Revision Lecture AI Revision
Software Design Lecture : 9.
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Build Intelligence from the bottom up!
Chapter 2: Operating-System Structures
Subsuption Architecture
Configuration management
CO4301 – Advanced Games Development Week 3 Parsing Continued
Chapter 8, Design Patterns Introduction
Games Development Game Architecture: Entities
Chapter 2: Operating-System Structures
Exception Handling.
Implementing Subprograms
#01 Client/Server Computing
Presentation transcript:

CO3301 - Games Development 2 Week 19 Extensions to Finite State Machines Gareth Bellaby

Topics Additions to standard FSMs. Probabilistic FSM Extensions to FSMs: Stack-based FSM Hierarchical FSM Subsumption FSM

Additions to FSMs A FSM is a machine which models states, transitions between states, and actions. FSMs are in common usage. FSMs are a comparatively easy way of modelling behaviour. They are also very effective. FSMs are flexible.

Additions to FSMs On entry operations. On exit operations. Allowing event notifications to trigger transitions. Reference to additional information, including requests for information.

Probabilistic FSM Describes any FSM which includes probabilities. Probabilities are placed on transitions out of states. Can have: An output state which has a probability associated with it. Multiple output states with probability scores used to select between them.

Probabilistic FSM Probabilities could be fixed. Probabilities could change over time, e.g. activation and decay. Note that you extend probabilities in lots of ways, e.g. multiple stimuli, trigger functions, etc.

Stack-based FSM Track past states using a stack. Stacks are pushed on and popped off the stack at transitions. This means that an agent can be interrupted and later return to a previous state. For example, an agent is in a patrol state. The agent becomes involves in combat. The patrol state is pushed onto the stack. After the combat has ended the patrol state is popped off the stack and the agent returns to this state.

Stack-based FSM Stack-based FSM can produce a simpler FSM than a standard FSM. Note that it may not always be appropriate to return to a previous state.

Hierarchical FSM A state may link to another FSM or set of FSMs. Transition from a state leads to a brand new FSM. Use the stack to store the initiating state. If control is passed down the hierarchy then the new FSM starts at its own initial state. Hierarchical FSMs allow you to identify and separate out behaviour or tasks. Helps reduce size and complexity of a FSM.

Hierarchical FSM

Hierarchical FSMs For example, there could be a state called "Find Enemy". This could be a high level state which runs another FSM. States may be concrete. A state may have a direct effect upon the world. A state may be abstract. A state may not have a direct effect upon the world.

Hierarchical FSMs Two alternatives: 1) Control is passed completely down to the sub-FSM. 2) More commonly the different levels of the FSM are evaluated concurrently.

Hierarchical FSMs Note that if execution passes to another FSM lower down the hierarchy you would have to record the original state and any associated data because control may pass back at some point.

Hierarchical FSMs May lead to code re-use since a task could be used in several different situations. It is good idea to design your game to allow the re-use of FSMs. For example, combat and movement states can be reused. The hierarchy of states can produce behaviour unique to an agent even if states are shared with other agents.

Hierarchical FSMs It is possible to swap FSMs in and out. This can be done with any one of the FSM layers. Hence an agent could exhibit different implementations of a task in different situations, e.g. different combat FSMs. Or a higher layer could be changed so that different planning behaviour occurs.

Hierarchical FSMs A state could have sub states. This can bypass the need to have a new FSM. Don't do it too much else it can lead to the FSM becoming broken or at least difficult to keep track of.

Subsumption FSM The term subsumption was invented by Rodney Brooks. Intelligent behaviour can be built from a collection of simple machines. Decompose complex behaviour into simple modules, operations or tasks. The modules are implemented as layers.

Subsumption FSM Layers of FSMs. The layers of FSMs all operate at the same time. Lower layers deal with short-term goals. Higher layers deal with long-term goals. For example A low layer implements obstacle avoidance. A higher layer implements attraction to a target.

Subsumption FSM Lower layers have priority. This should mean that the system is robust. Subsumption architectures have been used in games such Jedi Knight: Dark Forces and Halo: Combat Evolved (Rabin, Intro. to Games Dev.) Example: Planning FSM. Movement FSM.

Subsumption FSM Layers can deal with radically different operations or tasks. For example, a low-level FSM could implement character animation. Keeps sight of long-term goals. Goals stay relevant.

Further reading Rabin, S., (2003), "Common Game AI Techniques", AI Game Programming Wisdom 2, Charles River Media: Hingham, Mass, USA. Stack-Based FSMs: Tozour, P.l, (2003), "Stack-Based Finite-State Machines", AI Game Programming Wisdom 2. Yiskis, E., (2003), "Finite-State Machine Scripting Language for Designers", AI Game Programming Wisdom 2. Subsumption Architectures Borovikov, I., (2006), "Orwellian State Machines", AI Game Programming Wisdom 3. Yiskis, E., (2003), "A Subsumption Architecture For Character-Based Games", AI Game Programming Wisdom 2.