Hierarchical State Machine vs Stacked State Machine and questions

Question

I am creating a Player character for my game that at its core has 4 States. Idle, Moving, Attacking and Defending.

The problem I am facing is mixed states. For example when a player moves and attacks what will happen. From my understanding a HSM (Hierarchical State Machine) would have the 4 core states, and each state would represent a smaller state machine.
Assuming the master state machine (first image) and sub state machine for movement (second image). In order to implement a "move attack state" Would I need to create a separate state machine for mixed actions? Or implement it to either the "Move" or "Attack" sub state machine?

On the other hand. Using (SSM) Stacked State Machines, from my understanding would mean that we still have a default state machine (first image), however we run concurrently additional ones. In this case, how would we handle mixed actions (for example, attacking while moving, dashing while airborne)? Would we assume a common state for moving and attacking that is made up of a machine for movement and one for attacking and transition between the two?

Which do you think would be better in a matter of scalability. Or perhaps which would be easier to append to in the future?

Thanks in advance!

Shingly

Answer 1

I recon it comes down to what would actually serve your projects needs best. To get feedback on this you might want to start by sharing a little more about what your game is like. And don't just consider the player controller but perhaps also what the needs of any npc/bot logic might be.

Smolensk

Answer 2

The question is whether or not attacking should be possible independent of movement. If no (e.g. in a fighting game), I would add a displacement component to the Attack state and maybe rename Move to MovementInput. And when the player enters the Attack state, it takes control of all movement until it finishes. The Attack-Move is then just a normal Attack with a modified movement control scheme.

If you want the 2 to be independent (e.g. in a twin-stick shooter), then I would define a 2 separate state machines: (Hold, Walk, Run) and (Wait, Attack, Deflect). Both run in parallel at the same time, but they can call each other without modifying their internal state. E.g. if I'm currently in Walk, I can press M2 to initiate Deflect, but this doesn't take me out of Walk. The meta-state machine would then consist of tuples: ((Hold, Wait), (Hold, Attack), (Hold, Deflect), ... , (Run, Attack), (Run, Deflect)).
Although, I would really try to avoid implementing it explicitly, unless you have a very complex control scheme.

Both approaches can scale with well-defined states. The 2nd one perhaps less, because of the amount possible connections between a large number of FSMs, but that's a problem with every modular system. It really depends on the type of behaviour your want to model.

Tracery

Answer 3

I'd recommend giving this section of Game Programming Patterns a good thorough read.

Europium