Game Development Reference
In-Depth Information
}
clickedBlocksArray = new Array();
gameState = GameStates.STATE_START_REPLACING;
}
Adding the ColorDrop state machine
Before we talk about putting blocks on the screen, we should discuss the state machine we are
going to create in the
ColorDrop
class. We have already created a state machine for our
Main
class. It controls
Game
and tells it when to start a new game, start a new level, and run its game
loop by calling
runGame
. So far, this has been sufficient for most of our games. However, when it
comes to casual puzzle-style games, it can be beneficial to further refine the
runGame
method into
its own state machine. Before you close this topic and run away screaming, let us explain.
If you recall from Chapter 1, we created a very simplified state machine using a
switch
statement.
We explained why we think this is a good idea and showed you the code to implement it. To
review, we believe the state machine helps keep the game flowing logically and takes the place of
multiple Boolean variables and the messy tests involved to make sure they all have the right
values. We further refined that state machine in Chapter 2 to make it run more efficiently by
getting rid of the
switch
statement and using a
systemFunction
variable that is used to call the
current state function.
We need something similar for Color Drop's
Game
class. The reason is simple: we need more
control over the flow of the game. Since most of the time the game is waiting for user input, we
want to restrict what can actually be happening at any given time. For example, when blocks are
falling into place on the screen, we want to make sure the user cannot click on them. Without a
state machine in
Game
, we would have the same problem that would plague
Main
: too many
Boolean variables to test and keep updated. With a simple machine, all we need to do is to test
the current
gameState
to see what input is valid and what the game should be doing.
For Color Drop, we are going to create a simple state machine much like the one from Chapter 1
with a
switch
statement. We decided to do this to show you, the now advanced Flash game-
making
wunderkind
, that a
switch
statement style state machine can be very useful alongside the
systemFunction
style state machine.
Recall that we defined these states in the properties section of our
GameStates
class:
public static const STATE_INITIALIZING:int = 10;
public static const STATE_START_REPLACING:int = 20;
public static const STATE_WAITING_FOR_INPUT:int = 30;
public static const STATE_REMOVE_CLICKED_BLOCKS:int = 40;
public static const STATE_FADE_BLOCKS_WAIT:int = 50;
public static const STATE_FALL_BLOCKS_WAIT:int = 60;
public static const STATE_END_GAME:int = 70;
public static const STATE_END_LEVEL:int = 80;
public static const STATE_WAIT:int = 90;
We will use these states to manipulate the flow of the game, in way that is similar to creating a
small abstract programming language inside another programming language (AS3). One thing
that you will notice is that we attempt (wherever possible) to control the changing of states within
this
switch
statement. In that way, following the flow of the game is easier. While we can't always
keep state changes in this function, that should be the goal.
GameStates.STATE_INITIALIZING
is set by the
ColorDrop
class constructor and is a blanket state
for everything that happens when the game is starting, and
Main
is calling
newGame
and
newLevel
.
