Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have been reading around about stack-based FSM, and I found it to be perfect for my game. However, when a character moves, it consequently have to face in some direction (and animation of each direction will be different), now the problem that I am facing in my state machine design is the scope of each state.

For example, should I divide the state into MOVE_LEFT, MOVE_RIGHT, MOVE_UP, MOVE_DOWN or should I create one MOVE state with some direction argument in it. Now, the latter seems to be better, however, if I am to trigger direction change, how would I do it for a one-state MOVE? I could directly change the direction argument and manually change the animation sequence, which will destroy the whole purpose of state machine (State machine should change animation sequence OnEnter() state). Else, I would have complicate the state machine into hierarchy of states (Sub-states,etc.), and this seem unconvincing for me.

Or maybe I should implement some type of multiple, simultaneous states ---- Character's State (Jump, Move, Idle, Attack, etc) and Direction's State (Up down left right), then make it works concurrently, and apply stack-based architectue on Character's State only.

share|improve this question

I find it easier to think of what you see on the screen as a state.

For example, is "MOVE" in MOVE + LEFT and MOVE + RIGHT the same visually? If it is not, then you need at least 2 different states for MOVE, and since LEFT and RIGHT are different states as well, you might be better off combining MOVE and LEFT as one MOVE_LEFT and so on.

As a counter example, is "HIT" in CRITICAL + HIT and NORMAL + HIT the same visually? Possibly. So we can have HIT as a state on it's own and CRITICAL, NORMAL as separate states.

share|improve this answer
+1 That's a neat way to think about it for small projects and new programmers. – Patrick Hughes May 27 '12 at 17:52

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.