Finite State Machines, cont.

1
Finite State Machines, cont.

• Chad Hogg
• Sections 5.3 5.4 of
• AI Game Programming Wisdom 2

2
What is an FSM ?

• To theoreticians, a Finite State Machine or
  Automaton is an abstract model of a computer.
• In the context of this course, an FSM is not so
  abstract. Rather, each state of the machine
  corresponds to a piece of code.
• Is anyone unfamiliar with automata theory?

3
Defining an FSM

• Simplest type of FSM is a Deterministic Finite
  State Automaton ( DFA ).
• A DFA is defined as 5-tuple ( Q, ?, d, q0, F ),
  where
• Q is a finite set of states.
• ? is a finite set of symbols ( the alphabet ).
• d Q x ? ? Q is the transition function.
• q0 Î Q is the start state.
• F Í Q is the set of accept states.

4
So What ?

• Traditional approaches describe FSMs in code.
• But the definition of an FSM consists of 5 simple
  pieces of data.
• Therefore, it should be possible to create a
  generic FSM engine that operates on this data.
• This is known as a data-driven model.

5
Advantages of data-driven model

• Separate program control logic from FSM logic.
• Reduce duplicate code.
• AI designer does not need to know how it works.
• Easy update / testing of AI without recompile.
• If desired, AI can be changed by modders and
  level designers without exposing critical source
  code.

6
Game Modifications

• End-users are able to modify an existing game and
  distribute their changes.
• Level / graphic / AI design are expensive, so why
  not let the customer do some of it?
• Famous example Half-life, CS, NS, TFC, DOD
• Simpler data-driven example Civilization II
• Plain text files allow modifications of almost
  all game rules.

7
Ex Civilization II

• ( Technologies )
• Advanced Flight, 4,-2, Rad, Too, 3, 4
• Alphabet, 5, 1, nil, nil, 0, 3
• ( Personalities / Goals )
• Caesar, Livia, 0, 1, 1, Romans, Roman, 0, 1, 1
• Montezuma, Nazca, 0, 4, 0, Aztecs, Aztec, 0,-1, 1
• This is not very intuitive, but is
  well-documented.

8
However

• Not as customizable as it would sound.
• You still need to provide a set of state names
  and variables that may be queried by the
  transition function.
• Associating a state and specific code that runs
  while you are in, entering, or exiting that state
  remains in source code.
• Creating a robust system for the AI designers to
  work with will require a significant time
  investment.

9
Implementing FSM Data

• Q, the set of states is enumerated in code.
• ?, the set of input symbols ( conditions ) is
  enumerated in code.
• d, the transition function is defined in an
  external data file.
• q0, the initial state is set by the individual
  FSM objects in code.
• F, the set of accepting or final states is set by
  the individual FSM objects in code.

10
Data-driven ExampleLight Bulb (LB)

• Demo provided on textbook CD.
• Models an electric light circuit that is
  controlled by a timer to turn on or off every
  second.
• Not very Game AI-like, but simple enough to
  demonstrate the ease of implementation.

11
Ex(LB) State Definition

• The light is either on or off, so we have two
  states, FSMS_ON and FSMS_OFF.
• States are represented as values of an enumerated
  type and strings.

12
Ex(LB) More C Work

• We need to define any variables that should be
  exposed to the data file. In this case, the only
  thing necessary is the value of a timer.
• We need to define any operators that should be
  exposed to the data file. In this case, we use
  simple comparison operators for integers ( , gt,
  lt ).

13
Ex(LB) CLightBulb

• class CLightBulb
• TFSMltCLightBulbgt m_stateMachine
• CTimer m_timer
• void BeginOnState()
• void UpdateOnState() cout ltlt "\n--Light Bulb
  is On--\n" ltlt endl
• void ExitOnState() m_timer.Reset()
• void BeginOffState()
• void UpdateOffState() cout ltlt "\nLight Bulb
  is Off\n" ltlt endl
• void ExitOffState() m_timer.Reset()
• int GetTime( ) return m_timer.GetTimeElapsed(
  )
• CLightBulb()
• m_stateMachine.LoadStateMachine("light_bulb.fsm"
  )
• m_stateMachine.AddStateFunctions(this, FSMS_ON,
  BeginOnState, UpdateOnState,ExitOnState)
• m_stateMachine.AddStateFunctions(this,
  FSMS_OFF, BeginOffState, UpdateOffState,ExitOffSta
  te)
• m_stateMachine.AddVariableFunction(this, TIME,
  GetTime)
• void Update( )

void BeginOnState() void UpdateOnState() void
ExitOnState() These three functions perform
whatever action is associated with entering,
exiting, or continuing in a state.
int GetTime() There must also be a function for
each variable that the datafile can query. In
this case, there is only one.
TFSMltCLightBulbgt m_stateMachine The remaining
functionality of interfacing with the datafile
and calling the class functions is through this
member.
14
Ex(LB) The Data File

• Light Bulb Transition Definition Data File
• STATE_0 When in state FSMS_ON
• STATE FSMS_ON there is a transition to
• CONDITION_0_VAR TIME state FSMS_OFF whenever
  the
• CONDITION_0_FUNC GREATER_THAN condition TIME
  gt 1000 is met.
• CONDITION_0_VAL 1000
• OUTPUT_STATE_0 FSMS_OFF
• STATE_1 When in state FSMS_OFF
• STATE FSMS_OFF there is a transition to
• CONDITION_0_VAR TIME state FSMS_ON whenever
  the
• CONDITION_0_FUNC GREATER_THAN condition TIME
  gt 1000 is met.
• CONDITION_0_VAL 1000
• OUTPUT_STATE_0 FSMS_ON

15
Ex(LB) Watch Demo
But this example is trivial and boring
so I wrote my own demo of how data-driven FSMs
could be used to control units in a Real Time
Strategy game such as Warcraft II.
16
Ex(WC2) Game Mechanics

• Human and computer players control armies of
  various types of units and buildings.
• Micromanagement of units is possible, but even
  units controlled by humans need some AI.
• Goal is to destroy all units / buildings
  controlled by enemy players.
• My demo models the actions of 2 hostile groups of
  3 units that meet while following orders to go to
  a location.

17
Ex(WC2) FSM Diagram
18
Ex(WC2) Watch Demo

• There are 6 units, each of which is controlled by
  an instance of an FSM.
• Units take turns performing actions associated
  with their current states and possibly
  transitioning between states.
• Note the demo does not work exactly like the
  previous diagram it is difficult to fit all the
  details in a diagram.

19
Ex(WC2) Limitations

• There are several missing transitions, because
  this should really be based on a push-down
  automaton.
• Game units arent actually autonomous
  transitions may be mandated by a higher
  intelligence as well.
• Simplistic a unit may run from one enemy
  straight to another.

20
Data-driven Summary

• The Data-driven FSM model works great actions
  from decisions, and you expect to spend lots of
  time tweaking the decision-making ( state
  transitioning ) process.
• Not a very flexible system.
• Development time for engine is still much higher
  than development time for AI.
• A more robust scripting engine answers most of
  these problems.

21
Scripted FSM

• Rather than a data file that is read by the
  architecture, an entire language that will be
  compiled to bytecode.
• Much more flexible.
• Variables and functions for the transitions to
  query still need to be defined outside of the
  scripts, but you can now add new states very
  easily.
• Actions still need to be defined outside of the
  scripts, but connecting a state and an action now
  occurs in the script.

22
Script Syntax

• Behavior ( name of state )
• begin
• variable
• ( list of local variables )
• transition
• ( conditions to be checked each round )
• sequence
• ( what you do in this state )
• end

23
Sample Script

• behavior Test begin
• variable integer lastState 0
• transition
• if PlayerState ! lastState then
• begin
• if PlayerState 0 then
• log "Player's State Standing"
• else
• log "Player's State Moving"
• log "Player's Location ",PlayerLocation

• set lastState to PlayerState
• end
• sequence
• log "Testing 'test' script'"
• do forever
• begin
• goto 10,0,250
• idle 3
• goto 6,0,100
• stack "IdleForASecond"
• end end

24
Scripted Demo Movement

• Very simple demo for very complex project.
• 6500 lines of code vs. 2000 lines of code, most
  of which would not need to be altered.
• Does include support for remembering and
  returning to previous states.
• Building / updating the architecture will require
  significant resources. AI designers will need to
  be trained in the new language.

25
Conclusions
Traditional Data-driven Scripted
Code Complexity High Moderate High
Script Complexity N/A Low Moderate
Time To Implement High Moderate High
Ease Of Change Low Moderate High
Flexibility High Low High
26
References

• Civilization II, MicroProse Software, 1995.
• Du, Ding-Zu, and Ko, Ker-I, Problem Solving in
  Automata, Languages, and Complexity, Wiley, 2001.
• Fu, Dan, and Houlette, Ryan, The Ultimate Guide
  to FSMs in Games, AI Game Programming Wisdom 2,
  Charles River Media, 2004.
• Rosado, Gilberto, Implementing a Data-Driven
  Finite-State Machine, AI Game Programming Wisdom
  2, Charles River Media, 2004.
• Sipser, Michael, Introduction to the Theory of
  Computation, PWS, 1997.
• Warcraft II, Blizzard Entertainment, 1995.
• Yiskis, Eric, Finite-State Machine Scripting
  Language for Designers, AI Game Programming
  Wisdom 2, Charles River Media, 2004.
• Screenshots taken from Warcraft II, illustrations
  by Chad Hogg in MS Paint.
• This presentation and my demos are available at
  www.lehigh.edu/cmh204/.