Hi everyone,

I'v a little issue on how I should implement a state machine logic in my game.

(as described in http://www.gamedev.net/page/resources/_/technical/game-programming/state-machines-in-games-r2982)

I'm programming a platformer and state machine logic seems fine for it except for one particular case.
Let say I've three states for the player, idle, walk and attack

• idle is the beginning state.
• walk is triggered when pressing a direction and end when this direction is released or when another state is called.
• attack is triggered when attack button is pressed.

All of thes states are neighbors from each other : each of them can transition to one another.

But if I press a direction, then the attack button (without releasing direction), when attack state is expired, the character should transition back to walk.

There's a bunch of solution tha crosses my mind for that but I'm not sure what's the best :

• character has an internal state walking or not triggered by direction down and direction up, which is used to choose the next state after attack. It seems a little clumsy as it is kind of a parallel state machine.
• adding an input event "direction pressed" in addition of "direction down" and "directionup" which is fired in event queue from the moment direction is pressed until it is released, walk event should be now triggered by this event.

or other things I hevn't thought of.

What do you think ?

(as described in http://www.gamedev.net/page/resources/_/technical/game-programming/your-first-step-to-game-development-starts-here-r2976)

I'm not sure where in the cited article a state machine is described. So I assume you are speaking of explicitly modeling a state machine in code. Here are some thoughts:

1.) Parallel state machines and hierarchical state machines are invented after noticing that a single state machine is not suitable to handle more complex situations well. In this sense it is not really clumsy. However, I'd not categorize your current need as complex situation.

2.) If the amount of belonging states is low, in this case the amount of states denoting moving, then the "combinatorial explosion" (that originally led to hierarchical state machines) can be accepted. I.e. all the states { move_forward, move_backward, ..., attack_forward, attack_backward, ... } may be generated, so that attacking states have the following state implicitly implemented. This is a clean solution from the point of view of a standard state machine, but obviously not the most popular one w.r.t. developers ;)

3.) Activation and de-activtion of states can be explicit, i.e. there are State::enter and State::exit methods which are invoked on the next current and the now obsolete current states, resp. When the invocation passes the other state as argument, the next current state can store it for later use. This would implement a dynamic transition mechanism.

4.) A more general approach would be to have a state stack where the current state can look up a kind of history of state invocations. This also would allow for a dynamic transition mechanism.

5.) The state machine need not necessarily be explicit. In fact a computer works as a state machine anyway. The set of current values of every variable in your game can be understood as the current state, and changing the values can be understood as transition. For example, a variable action may have the value 0 for standing, 1 for moving, 2 for attacking. Another variable direction may have the values 0 to 3 for forward, left, right, backward, resp. The values of action and direction then make the state. As you can see, at any time they have one of 12 possible values.

Sorry, my bad, the link wasn't the intended one. I corrected it.

Thank you for you're answer, I'll look a deeper into it.

1,2)

I consider more and more having two state machine because the case I described is not really the only one after all. I realized that in 2). As my game is 2d, there is actually two direction to attack so instead of just having an attribute facing left or facing right, it could be another state machine... Then I realized there are more states than I thought (attack while in mid air, facing left, right etc...). Even if sprite and hitboxes will be the same inverted, that's different states !

The fist would be conditionned by my movement vector (walking_right walking_left, falling, ascending...)

The second by the input (attacking, jumping, countering etc...).

Another way to do things when I look at 3), is having more states with different default next state. In my case, a attack (idle neighbor) that leads to idle state and a walkattack (neighbor of walk) that leads to walk state, even if these two states are resulting in the same animation...

4) The stack thing is tempting but seems too generic for what I want to acheive. I'll think of it if I ever tried to do a versus fighting game !

5) I really want it to be explicit because I'm working in collaboration with another game designer, who's not a programmer at all.

States machines are more complex than I thought, but I still stick to it because I feel it might prevent complex bugs (which is worse !).

Thanks for thes enlightening answers. I know have a clearer vision of what I need to do :

2 state machines : action and movement (where attack is an action and walk a movement), and a bunch of activities corresponding to combination of states.

A can have object can have of course only one activity at a time.

1. Player start moving : action = Idle, movement = walk >> walk activity
2. player pushes the attack button without releasing direction : action = attack, movement = walk >> attack activity
3. attack animation ends, action return to idle and movement still = walk >> walk activity

2 state machines : action and movement (where attack is an action and walk a movement), and a bunch of activities corresponding to combination of states.
A can have object can have of course only one activity at a time.

If your game is built such that the two are truly independent, that is, an attack is entirely upper body and does not involve the legs at all, then it may work. That will probably not work in practice, because compelling attack animations involve the full body. Without it either the swings will look feeble or the body will appear horribly out of balance. I imagine their legs are daintily running while their arms are involved an a half-body body-slam, not slowing the legs nor using them for force or balance.