# Finite State Machine for player states

I have a state machine for a game I am developing. The player can be in four states, depending on button clicks, and some game elements (being in thin air, or standing on the ground). I am just wondering if I should use arrows between all the possible states changes? All states in this diagram need to go through the Idle state, but in the game, you could easily go from Walking to Jumping by pressing the "jump"-button whilst walking. The same applies for the Jump state to the Falling state. After a jump, the player immediately transfers to the Falling state. Is this something I need to put in the finit state machine diagram? The diagram might end up messy with extra arrows, and I would like to avoid it, but if this diagram was meant for a thesis or in lecture I want the diagram to be correct.

I am sorry if this question is too opinion based.

For every way your state could change, you need an arrow (with an condition and a priority). If you always would have to go back to the idle state, your conditions would have to be really good. Imagine the player state of jump is just dependent of pressing the jump button, then you either could jump forever (caused by the idle return state depending on no button pressed), or you could not jump while walking.

Also think of hybrid states like moving while falling or jumping, if needed. The priorities might not be that important, only if two possible state changes could happen at the same time.

• Thank you for your answer. I am just wondering how you would write a hybrid state? Do you draw a new box with both states marked inside the box?
– John
May 29 '17 at 9:11
• With hybrid state I meant a state like 'moving while falling' while 'walking' and 'falling' still exist. That is somewhat of use if you need this state for animation or other control (moving while fall should be possible, but maybe not running) May 29 '17 at 9:26

PSquall got it right. Just to add on to that, if this is for a thesis or lecture you want to look at using UML state machine diagrams to model the machine. Also you could have your jump state transition into falling once the peak of the jump is reached, and falling back into idle once you're back on the ground. If youre interested i also wrote a small article on planning out and writing a simple state machine like what you have there using cocos2d-x, but the theory stuff should be transferable.

For anything serious you'll end up with many more states and hybrid states, and you'd also want to consider states like getting hit or being stunned. There's also such a thing as concurrent state machines which amounts to two or more machines linked together running side by side so you can logically separate certain things like what you're doing and what is happening to you or what you're carrying.

• Great article, thank you for your input. The state machine was intended for kids learning how to program. I wanted to keep it as simple as possible. The state machine you had in your article was a good example.
– John
Jun 3 '17 at 21:29