FSMs in Platformers

Hello
I am not an expert on this, but I'd like to share and maybe discuss.
For my game objects, I have two fsm right now; one for input and one for motion.

In the input FSM, I have the following states: KEYBOARD (input comes from keyboard), INERT (object doesn't think), WANDER (walks around the area), HUNT (find things to kill), FLEE (run in opposite direction of danger). Theses states does not do much, they mostly change the states of the motion FSM.

In the motion FSM, I have the following states: IDLE (not moving), WALK (move), RUN (move faster).

I don't use nested states because I feel it's too complicated. I think I will add one more FSM for animation later on, but this is what I have right now.
What do you think? ;o

Are you working on a platformer? Or maybe a 2D RPG type of game?

If you are working on a platformer, do you not need states for jumping and being on the ground? Or could you just represent them using a boolean variable? I like the idea of using a state machine for the animations - what I was actually going to do was just set the animations in the walk state, or in the run state etc. - but this seems like a better solution.

Are you working on a platformer? Or maybe a 2D RPG type of game?

If you are working on a platformer, do you not need states for jumping and being on the ground? Or could you just represent them using a boolean variable?

Right, It's a 2d rpg. If it was a platformer though, I would use a boolean value to represent grounded or not. That way, I don't have a seperate state just for one particular direction, and that's consistent with the way I lay them out in my 2d rpg.

Or maybe make it more general have 4 boolean values to represent touching south, touching east, touching north, and touching west. Most of the time touching south can be interpreted as grounded, but the other directions can be interpreted as grounded too if you decide to implement gravity scew. Just a thought ;o

I like the idea of using a state machine for the animations - what I was actually going to do was just set the animations in the walk state, or in the run state etc. - but this seems like a better solution.

Animation is low priority for me right now, so I don't know how well that idea is because I don't have a working implementation of it. Still worth a try though.