Finite State Machine

Finite State Machine
Nicholas Phillips
DigiPen Institute of Technology
The purpose of this is to try and alleviate any confusion over what exactly a finite
state machine is, and how it is used in a game. The formal definition of a finite state
machine reads as follows: "An abstract machine consisting of a set of states (including
the initial state), a set of input events, a set of output events, and a state transition
function. The function takes the current state and an input event and returns the new set
of output events and the next state. Some states may be designated as "terminal states".
The state machine can also be viewed as a function which maps an ordered sequence of
input events into a corresponding sequence of (sets of) output events.
There, wasn't that pleasant? I know you don't need me to elaborate after such a
marvelous description, but let's try and view it from another angle. For our purposes, the
state machine is a transducer of sorts, changing your characters into different states of
being. Right now I'm in the state of typing, and you're in the state of reading. A state can
be any action you do or feeling you perceive. Also, even though I'm in the typing state
and you're in the reading state, we're both probably in a state of boredom. Or at least I'm
in a state of boredom, and you're in a state of confusion. So you see how one can exist in
multiple states simultaneously. In a game this would amount to a character that doesn't
have to stop running to attack. For instance, the character might have an upper body and
lower body state each with their own specific action functions that would be invoked by
the main game engine every iteration of the main game loop. (In C we say we are
"calling" a function. You're calling upon them to do their duty.) In this case the
character would have two function pointers inside its structure, where each one would be
pointed to the address of the appropriate action function before they were called once a
game loop. (A game loop is commonly referred to as a ‘frame.’) How does the main
game engine know which functions to point those function pointers to? Well, that
depends on the preconditions that must be met before entering that state. For example, I
will soon be in the sleeping state, but the precondition of me being tired must be true
before entry into that state is possible. With the Fun Library, those preconditions are
shown as arrows.
Another example I will give will utilize the behavior of the Pac Man ghosts. I’ve tried
to use methods similar to that of the DigiPen Fun Library, although I am guilty of
creating a few pretend functions to suit my needs. You should be able to locate their
equivalents with minimal effort. Something else I’d like the advanced students to note
with these examples is that I’m using the frame speed of the game for my timers. This is
generally frowned upon as amateur because it forces the game speed to depend on the
processor speed of the machine you run it on. Naughty. The correct way to regulate
game speed is to set up your own timer independent of the frame rate using the clock
speed of the machine. (1000 ticks per second)