State Machines


Another concept we're going to need for more advanced games is called a state machine . By using state machines, we can more easily map out the changes that an object (perhaps a movie clip on the stage) goes through during its life in our game. Often you have some element that behaves in a certain way for a while, but then something happens that requires a change in behavior. By using a state machine diagram, we can easily map out these behavior changes. After we have designed our state machine, implementing it in ActionScript is almost trivial.

What Is a Finite State Machine?

A Finite State Machine (FSM) is a device that records its own current state. At any time, an FSM can receive input that will cause it to change state, and these changes are based on the input that the FSM is given. This concept has many applications, including computers themselves . However, the theory of state machines came long before the first computer was invented.

FSMs were originally created as a way to describe language and its semantic characteristics. This technique was adopted by mathematics and later by programmers as a way of mapping out logic.

Drawing a State Machine

The best way to learn what state machines are is by seeing them in their graphical form. Here's how it works.

To represent a state, we draw a circle. Inside the circle, we put the name of the state. The name can be anything we want, such as a letter, a number, a word, or anything else we can use to identify one state from the others.

Between the states are lines that represent possible state changes. These lines are directional, and they have arrows on the end to demonstrate that. Next to each state change line is a list of all the possible input values that would cause that particular state change.

Any state machine has a starting state. That is the state of the machine when it is first initialized . In a drawing, this is identified by a small caret pointing to one state.

We've already had a complex example of buttons and how they change state based on what the user does with the mouse. If we break this down visually, you'll see how intuitive this form can be. Take a look at Figure 7.2.

click to expand
Figure 7.2: A simple state machine shows the state changes that Flash does for you in your button movie clips.

As you can see, we have three circles: one _up , one _over , and one _down . These correspond to the state you can use to make movie clips act like buttons. Recall that when you create a clip that has these three states defined, if you attach a handler, Flash does the state changes for you. The events that Flash changes on are given as the state transition input in Figure 7.2.

Notice that each line has an arrow showing you which way the transition goes, as well as a label showing you which events trigger which state changes. The change from _up to _over , for example, is done on a rollOver event. Likewise, the _over state changes to _down on a press event, but it changes to _up on a rollOut event.

Also notice the caret on the left side of the _up state. That indicates that _up is the initial, or starting state.

These drawings give us an easy way to both read and write state change diagrams. Creating the code from a visual diagram of a state machine is even easier. The other option is to use a state transition table, but that solution is far less intuitive to read.

Let's look at another simple state machine. This one is an example of one possible strategy routine for a wizard in a real-time strategy game such as C&C or Warcraft . Consider Figure 7.3.

click to expand
Figure 7.3: A simple state machine for a unit in a realtime strategy game.

In this example, we have four states: wait , attack , heal , and flee . Most states have transitions to the other states, but some transitions are missing. heal , for example, does not transition to wait directly. There are conditions on each of the state changes. When the machine is in the waiting state, if an opponent comes nearby, the machine will move into the attack state. From here, you could easily write code to model this state machine.

It's important to note that there can and will be code that exists in each state circle. This is code that is executed every frame the machine is in the given state. State change checks will be part of this code. When the proper input is given to spur a state change, there will often be a piece of state change code that runs one time, as the machine changes state. From that point on, the new state code is run every frame.

The following script is a sample implementation of the state machine shown in Figure 7.3:

 createEmptyMovieClip("wizard",1); wizard.state = "wait"; wizard.onEnterFrame = wizard_state_machine; function wizard_state_machine(){     switch(this.state){         case "wait":              //do nothing              //if(opponent is nearby)              //    this.state = "attack";              //else if(friend is nearby and wounded)              //    this.state = "heal";              break;         case "attack":              //attack nearest opponent              //if(friend is wounded)              //    this.state = "heal";              //else if(I am wounded)              // this.state = "flee";              break;         case "heal":              //heal friends that are nearby              //if(I am wounded)              //    this.state = "flee";              //else if(no wounded friends)              //    this.state = "wait";              break;         case "flee":              //run away from any nearby opponents              //if(no opponents nearby)              //    this.state = "wait";              break;     } } 

This is a large script, but it's quite simple. First we create a wizard clip and assign it a property state , which we initialize to "wait" . From there, we attach an onEnterFrame handler to implement the state machine. We immediately define the state machine and its implementation as a big switch statement with each case being a state name.

Each of these case statements handles the functionality for one state. First it does any work the state needs and then it performs a series of state transition checks.

This kind of state machine implementation is advantageous. You'll see this implementation used in this chapter's game as well as many of our future games. It will become second nature to you.

We could go on about state machines for many hundreds of pages and still not cover the topic completely. My intention in bringing up state machines was not to give you a complete understanding of the topic, but to introduce you to them and give you enough knowledge to be able to employ them in your own games. Now that I have described them and shown you some examples, it's time to move on to this chapter's game. There will be a couple of state machines used in this game to give you further examples.




Macromedia Flash MX 2004 Game Programming
Macromedia Flash MX 2004 Game Programming (Premier Press Game Development)
ISBN: 1592000363
EAN: 2147483647
Year: 2004
Pages: 161

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net