Variable Jump Height?

xyz

HerbalHerb How many games you've shipped that use fsm for managing player state?

Toxe

IMO both can be the right and wrong tool. As always it's about code clarity and readability.

If you have only a few conditions then if's are fine.
If you have a couple more then if's are still fine but you should try grouping them a little (like in subfunctions).
If you got still more conditions then a good state machine can help a lot.
If you got still more conditions then you are fucked either way.

xyz

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"

Toxe

xyz Someone who knows what they are doing can make both work just fine. 🤷 And someone who doesn't, well, doesn't. 😉

Toxe

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. 😉

xyz

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

xyz I am talking about state machines (and the State pattern, if we want to throw that into the mix as well) in general and just like any other tool they have their uses. And, just like any other tool, they can equally be misused. But one pro aspect is can be that they might make your design a little more data-driven, which in turn can help with visualizing what is going on with debug UIs.

xyz 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"

Oh we can agree on that one for-f'ing-sure. 😆

xyz

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

Maybe you're talking about something else, but I think of a state machine as a way to reduce the number of possible states.

With four boolean flags treated independently, there are 2⁴ = 16 states that you have to deal with. With six flags, there are 2⁶ = 64 states. Most of those states are typically not reachable or not of interest. Organizing the flags into states might reduce the number of possible states to , for example, six states, which is much easier to manage.

xyz

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.

« Previous Page