Software Design – State Machine

For a class with different state, instead of using switch-case loop all the time, there should be a state system to manage the behavior for each state.

For example a monster with different attacking state, there should be a class for each state, and a list of the object with those classes to represent states. In this case, each state is an enemy behavior containing a list of enemy behaviors (see also: Software Design: Feature based design on class), which is a flexible pattern to receive enemy event and share behavior between different state. (p.s.: In the other word, a normal enemy is an enemy with one state.)

Fire Dragon: attack
-> Fire Ball State (current Enemy State): receive attack event, board-cast event to its behaviors
-> Fire Ball Behavior (the only behavior in Fire Ball State): receive attack event, generate a fire ball

Sudo code to construct the Fire Dragon like this:

class EnemyBehaviorList : EnemyBehavior {
    //take enemy behaviors in constructor
}

class FireBallState : EnemyBehaviorList {
    //to do something specific
}

Enemy fireDragon = new Enemy() {
    name = "FireDragon",
    behaviours = new List () {
        new FireBallState() {            //Fire Ball State
            new FireBallBehaviour(),     //Fire Ball Behavior
            new BehaviorA()
        },
        new BehaviorB()                 //Another State, can be a behavior
    },
    currentBehaviourIndex = 0
}


and the code to construct an enemy that will only generate fire ball:

Enemy fireDragon = new Enemy() {
    name = "FireDragon",
    behaviours = new List () {
        new FireBallBehaviour()
    },
    currentBehaviourIndex = 0
}

Share Button

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>