« AS1 and AS2 at Madrid Underground ( or Metro, or subway ) | Inicio | The State pattern and game development ( II ) »

The State pattern and game development ( I )

We are going to try to implement the State pattern to help us develop complex games or games whose entities have a complex or reactive behaviour.

First, we must consider that this implementation is quite lazy, and the example we're going to explain is simple enough to be explained, but with some complexity, so we can consider to implement this solution. Obviously, as the complexity of the game behaviour, or the complexity of the game entities behaviour grows, this will become a better solution. And also remember that my English is very poor, so, please, be nice :$

So, let's start. First, let's see what "state pattern" means. The intent is: Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. ( here you can find a complete explanation )

So, this pattern should be a good solution when , for instance:
1.- The behaviour of an object depends of its internal state, and must change at runtime depending of that state.
2.- To describe the object's behaviour we use long conditional sentences, with multiple branches. We'll try to put each branch in a different object .

So, in other words, we will try to describe an object's behaviour as a collection of different states, in a way that the object itself could manage its behaviour moving from one state to another.

Sounds interesting, isn't it?. Let's try to build an example.

Now we need some imagination. Imagine we have to develop a game ( "Explode the bubble" ). There will be a given number of bubbles on the stage that bounce when they hit the ground, but that don't bounce against the walls ( I mean, if a bubble leaves the stage by its right side, it must appear again by the left side, and the opposite ). There's a given time to explode a given number of bubbles ( clicking them ). When a bubble explodes, another one appears, so there's always the same number of bubbles on stage. The initial position and velocity ( velocity as a vector, not speed ) are setted randomly. So, if we explode less than the minimum number of bubbles, we loose, but we explode more than that minimum number, we are offered to give it another try. Then we can leave the game, or try again, but we'll have to explode more bubbles in less time. And so on., until we loose, or we leave the game.

At first sight, we can separate our code into two different entities: the game world, and the bubble, so we could write two different classes. The first one will manage the top level logic ( putting bubbles on stage, checking if there have been enough exploded bubbles, checking if the time is over… ), and the second one will manage the bubble behaviour ( bounces, explosions,… ). Let's take a closer look at the last one.

Obviously, the graphic representation of the bubble will be a MovieClip. So we could think about the Bubble class as a subclass of MovieClip, where the onEnterFrame method will be responsible of checking if the ball has left the stage, if it must bounce against the floor, that places the ball on the stage depending of those circumstances ( in other words, that implements a mechanism to calculate the bubble's movement equation ), that detects when the user has clicked the ball, and tells it to the game world, that manages the explosion animation…..

Well, I guess this is not the moment to discuss about inheritance and composition ( I hope so, at least ). Anyway, I don't think there's a right way and a wrong way of doing things ( or of writing code ). But, in this case this approach doesn't seem to be the most appropriate.

First, our Bubble class will have to implement a wide open range of functionalities ( from physical behaviours to just graphics presentation ). So the cohesion will be very low. And that's not very good. ( in other words: keep complexity manageable ).

But also, the Bubble behaviour should be implemented using a long switch statement, or a lot of "if" sentences ( if it must bounce, make it bounce; if it leaves the stage, put the bubble in it's new position; if nothing else happens, just calculate its new position and place it ). And that's one of the scenarios to implement this pattern. And, not in this case, but if the entity's behaviour is reactive, everything makes even more sense.

Have we stimulated your curiosity?. There will be more soon.

Comentarios

Dear Cesar,

I give a few different, free implementations of statecharts (hierarchical state machines) in my book and web site, for Flash 5, MX, and MX 2004. They are not fully-compliant with UML statecharts, but they cover pretty much all of the important ones.

Maybe they can help your effort. I would recommend checking out Miro Samek's work (www.quantum-leaps.com) for your bubble class. It is a very efficient way to do what you need to do, and I give MX and MX 2004 implementations of his engines (which are given on his web site in C, C++, C#, and Java, I think).

Hello, Jonathan.

Thanks for pointing me to such good resources ( both your site, which I knew, and quantum-leaps ).

I hope you find the rest of this "article" of interest.

As I know the state pattern, I just use a function property in as2. And then change the function reference. Just like in as1.

In Java I know the state pattern used when you reasign diferent objects references, where each object has just a member method (functor object)