Variable Jump Height?

Toxe The more conditions/states you have, the less useful is the fsm pattern, ironically. People who tout it typically don't have experience with using it for managing complex state. They went through a basic tutorial that uses 3 states and thought "wow, how clever"

OccasionalCrust What is a state machine? I am unfamiliar

A state machine is, in short, a design pattern that can help reduce code complexity when you have to deal with a lot of conditions like "on the ground", "walking", "running", "jumping", "falling", "idle" etc. There are a million ways to make a state machine and some can actually improve readability whereas a lot just make things more complicated. As always: it depends.

Toxe No. Classic fsm is objectively a poor choice for player state management. Beyond the simplest cases of player control, the pattern doesn't very well model all the finesse and complexity needed for something that plays and feels good. In a good action game, the player is almost never in a single discrete state. If you approach it like that you're guaranteed to end up with something that feels sluggish and unresponsive. You'll at least need to run several simultaneous fsms. This of course defeats the very purpose of using the fsm in the first place because you need to synch them which leaves you with the exact problem the fsm was supposed to solve.

It's fine for npc state management though, if npcs are sufficiently simple. But then again, a bunch of ifs would do the job just fine in that case.

But my main gripe is not with using the pattern itself, where adequate. You can conceptualize parts of your state management thinking in terms of discrete states just fine. I can't stand monolithic, bloated, turbo-oo implementations that are typically presented as "the solution"

Toxe they can equally be misused

Player state in an action game being one blatant example of misuse

Whenever I enter into discussion about this it always ends with me asking the proponent of "state machines" have they shipped a game that does it. The answer is always either "no" or they go silent

DaveTheCoder There's a fundamental difference. States in a fsm are mutually exclusive, flags aren't. They model different things. That's why it's important to know your problem very well to be able to choose pattern(s) that model it adequately.

If the thing you're modeling consists only of mutually exclusive states - fsm is excellent. It will model the problem perfectly.

However, player states in action games, least for most simplistic ones, are typically not entirely mutually exclusive. States will tend to overlap and run in parallel to a varying degree depending on the type and complexity of the game. In my experience, the more the gameplay/controls are finetuned to feel good, the more of such overlaps need to be introduced, and consequently the more you need to fight against the rigid framework of mutual exclusivity provided by a fsm. You may end up needing to handle so many "exceptions" that your code would become as "ugly" as when using just plain ifs, only worse because now you also have the whole fsm beast to cater to in addition.