Finite State Machines - DePaul Game Jam by dffhrtcv3


									Finite State
GAM 376
Robin Burke
Winter 2006

   Finite State Machines
     Theory
     Implementations

 Homework #2
 Break

 Lab
AI in the Game Loop

 AI is updated as part of the game
  loop, after user input, and before
 There are issues here:
     Which AI goes first?
     Does the AI run on every frame?
     Is the AI synchronized?
AI Update Step
   The sensing phase determines
    the state of the world                      AI Module
      May be very simple - state
       changes all come by
       message                                   Sensing
      Or complex - figure out what
       is visible, where your team is,
   The thinking phase decides                  Thinking
    what to do given the world         Engine
      The core of AI
   The acting phase tells the
    animation what to do
      Generally not interesting
AI by Polling

 The AI gets called at a fixed rate
 Senses: It looks to see what has
  changed in the world. For instance:
     Queries what it can see
     Checks to see if its animation has
      finished running
 And then acts on it
 Why is this generally inefficient?
Event Driven AI
   Event driven AI does everything in response to events
    in the world
      Events sent by message (basically, a function gets
        called when a message arrives, just like a user
   Example messages:
      A certain amount of time has passed, so update
      You have heard a sound
      Someone has entered your field of view
   Note that messages can completely replace sensing,
    but typically do not. Why not?
      Real systems are a mix - something changes, so you
        do some sensing
Finite State Machines
   A set of states that the agent can be in
   Connected by transitions that are triggered
    by a change in the world
   Normally represented as a directed graph,
    with the edges labeled with the transition
   Ubiquitous in computer game AI
   You might have seen them in theory of
    computation (or compilers)
Classic Application: Regular
   Any regular expression can be
    translated into a finite state machine
       this is part of what it means to be a
        regular expression
   Example (Perl)
       DePaul course ids
         • [A..Z]{2,3}([1..6]\d\d)
         • GAM376
What would the machine
look like?
Quake Bot Example
   Types of behavior to capture:
      Wander randomly if don’t see or hear an enemy
      When see enemy, attack
      When hear an enemy, chase enemy
      When die, respawn
      When health is low and see an enemy, retreat
   Extensions:
      When see power-ups during wandering, collect them
   Borrowed from John Laird and Mike van Lent’s GDC
      Example FSM
                                                    States:
                                                        E: enemy in sight
           ~E    E,~D
                                                        S: sound audible
                     D             E
                                                        D: dead
 Wander                        S                    Events:
~E,~S,~D                               S,~E,~D          E: see an enemy
                 E        ~S
                                   D                    S: hear a sound
                                                        D: die
                 Spawn             S
     D                                              Action performed:
                                                        On each transition
                                                        On each update in
                                                         some states (e.g.
      Example FSM Problem
                                                    States:
           ~E    E,~D                                   E: enemy in sight
                     D             E                    S: sound audible
            E                                           D: dead
 Wander                        S
~E,~S,~D                               S,~E,~D
                                                    Events:
                 E        ~S
                                   D                    E: see an enemy
                                   S                    S: hear a sound
     D           Spawn
                   D                                    D: die
                                       Problem: Can’t go directly from
                                       attack to chase. Why not?
            Better Example FSM
                                  ~S        Attack-S      States:
                                            E,S,~D            E: enemy in sight
           ~E                     S
                                                              S: sound audible
                     D                D   ~E    E
            E                                                 D: dead
 Wander                                    Chase          Events:
~E,~S,~D                                  S,~E,~D
                 E       ~S
                                  D                           E: see an enemy
                                                              S: hear a sound
                 Spawn                S                       D: die
                   D                                      Extra state to
                                                           recall whether or
                                                           not heard a sound
                                                           while attacking
                  Example FSM with Retreat
                            S        Attack-ES
             Attack-E                E,-D,S,-L
                                                                                      • States:
                                -S                   L
                                                                                         –   E: enemy in sight
                                                 -L                        E
                                                                     -E                  –   S: sound audible
                E E              -L                                                      –   D: dead
                                                            -L             Retreat-ES
                   E                                             L          E,-D,S,L
                                                                                         –   L: Low health
                                                                           -S         • Worst case: Each
       -L                                                                               extra state
  L                                                                               S
                                                                                        variable can add
   Wander              -E                        -E E                     E,-D,-S,L     2n extra states
                                                                                         • n = number of
                                      D D
                                                                                           existing states
                   D                             D
                                   Spawn                 -E,-D,S,-L
                                     D           S
Augmented FSM
   Typically, there will be book-keeping to do when
    transitioning between states
      For example
         • "direction of sound" variable
                • cleared when sound is absent and changing to "Wander"
   Most FSM implementations allow specification of
      update
         • what to do during each time increment in this state
       enter
         • what to do to start up this activity
       exit
         • what to do to end this activity
   Chase
      Enter
         •   Play animation "weapon forward"
         •   Play sound "battle cry"
         •   Set heading "direction of sound"
         •   Set speed "run"
       Update
         • Set heading "direction of sound"
         • Move
       Exit
         • Play animation "hand to ear"
         • Play sound "Huh?"
         • Set speed "walk"

   FSM for Blinky
Hierarchical FSMs
   What if there is no simple action for a state?
   Expand a state into its own FSM, which
    explains what to do if in that state
   Some events move you around the same
    level in the hierarchy, some move you up a
   When entering a state, have to choose a
    state for it’s child in the hierarchy
       Set a default, and always go to that
       Or, random choice
       Depends on the nature of the behavior
        Hierarchical FSM Example

              Wander              ~E           Attack

             Pick-up                                    ~S
                                                  D                   Spawn
Turn Right
                                          Note: This is not a
             Go-through                    complete FSM
               Door                            All links between top
                                                level states still exist
                                               Need more states for
          FSM (Markov Model)
                    Attack                              Adds variety to actions
                                                        Have multiple
                                                         transitions for the
                                                         same event
  Aim &
                   .3                                   Label each with a
Slide Right
 & Shoot                 .4
                                 .3          Start       probability that it will
                                   .3                    be taken
     Aim &                                              Randomly choose a
    Slide Left
     & Shoot
                        Aim &                            transition at run-time
                        Jump &
                         Shoot                          Markov Model: New
                                                         state only depends on
                                                         the previous state
Push-down State Machines
   Suppose we have some repeated behavior
      common to many states
      don't want to "forget" what we were doing
   Example
      change weapon if out of ammo
          • might want to do this while wandering, chasing, or
        if we make this a state
          • where do we transition after doing it?
   Separate global state
      Transition into this state temporarily
          • and pop back to origin
     Efficient Implementation
   Compile into an array of state-name,
   state-namei+1 := array[state-namei,
   Switch on state-name to call
    execution logic
   Hierarchical
      Create array for every FSM
        Have stack of states
          • Classify events according to stack
          • Update state which is sensitive to
            current event
   Markov: Have array of possible
    transitions for every (state-
    name,event) pair, and choose one
    at random
OO Implementation

 States as objects
 Actions as methods

 State machine can be very generic

 More in a minute
FSM Advantages
   Very fast – one array access
      think GBA
   Expressive enough for simple behaviors or characters
    that are intended to be “dumb”
   Can be compiled into compact data structure
      Dynamic memory: current state
      Static memory: state diagram – array implementation
   Can create tools so non-programmer can build
   Non-deterministic FSM can make behavior
FSM Disadvantages

   Number of states can grow very fast
       Exponentially with number of events:
 Number of arcs can grow even faster:
 Limited representational power

 Propositional representation
Varieties of representation
   Propositional logic:
      Statements about specific objects in the world – no
      Jim is in room7, Jim has the rocket launcher, the
       rocket launcher does splash damage
      Go to room8 if you are in room7 through door14
   Predicate Logic:
      Allows general statement – using variables
      All rooms have doors
      All splash damage weapons can be used around
      All rocket launchers do splash damage
      Go to a room connected to the current room
Representation in FSMs
   Can only handle propositions
       each transition predicated on a proposition
        being true or false
   Difficult to add comparative tests
       “pick up the better powerup”
       “attack the closest enemy”
   Expensive to count
       Wait until the third time I see enemy, then
         • Need extra events: First time seen, second time
           seen, and extra states to take care of counting
 switch statement
    we can implement a FSM with a switch statement
 Each state is a branch
   case CHASE:
        if ENEMY state = ATTACK
        else if ~SOUND state = WANDER
        else DoChase()
    case WANDER:
   Concise
      but a maintenance nightmare
  Transition table

       For each state and event
           record next

State        Event    NewState   UpdateFn

Chase        Enemy    Attack     DoChase()

Chase        ~Sound Wander       DoChase()
   Uses the "State" design pattern
       all information relative to an object's state is
       changing state is a matter of changing this
   Calling sequence
       Game -> Object "update yourself"
       Object -> State "update me"
       many advantages
         • state objects can be shared without duplicating
         • easy to store "previous state" information
Overall design

 Game-wide state machine
 When each object is updated,
     the state is loaded into the machine
      and processed
     new state is recorded with object

   Assumes that everything in the game
    uses a state machine
Structure view
Singleton pattern
   All states are unique instances
      only a single copy of the "Quench Thirst" state
   Benefit
      no dynamic allocation and destruction of state objects
   Drawback
      no object-specific information can be stored in the
   Technique
      use static allocation
      use a static member function that always returns this
      make constructor private
class QuenchThirst : public State<Miner>
   QuenchThirst(const QuenchThirst&);
   QuenchThirst& operator=(const QuenchThirst&);
   static QuenchThirst* Instance();
   virtual void Enter(Miner* miner);
   virtual void Execute(Miner* miner);
   virtual void Exit(Miner* miner);

QuenchThirst* QuenchThirst::Instance()
  static QuenchThirst instance;
  return &instance;
Improved design

   Each object may have slightly
    different requirements
     for how its state should be handled
     some may not need a state machine
     some may have something more
        • hierarchy, Markov, etc.
   Give each object its own state

   That this state machine has a global
    state and previous state
     very limited memory
     to handle state "blips"
   Perception by polling is inefficient
      never want to be "busy waiting"
   Example
      if guard does nothing until player enters
      guard should not be constantly checking "did player
        • in order to transition to next state
   Better method
      publish / subscribe
      have player send a message to each item in a room
       when he enters
      state transition can be predicated on this message

   Messages sent to specific recipients
     not hard to imagine an extension for
      localized messages
     global messages very expensive

 Modern games use messaging
 Need for unique entity ids and entity
Homework #2

   We are not using WestWorld
       too weird
   Instead
     AIsteroids
     an asteroids game
     you will be working with the AI
      controlling the ship
Part I

   Add a new state
     when there are few asteroids
     go into powering-up state
     try to avoid asteroids and just get lots
      of power-ups
     sort of a specialized idle mode
Part II

   Add toroidal geometry
     the AI does not measure distances
     off-screen wrap-around not used

   Change the code to do this right
        Major hint

pretend asteroid   wrap region
  is at position
 (x, y-screenH)


To top