StateMachine nightmare :D: Page 2 - Godot Community Forums

StateMachine nightmare :D

cybereality

Yes, there are different ways to define states. For example, in one of the demos I was working on, I made a function to check for jumping. It looked something like this:

func is_jumping():
    return abs(velocity.y) > 1.0:

I still had a jumping state, because it made things easier to transition states and also disable certain actions while jumping. However, you could design a system without flags, with a bunch of simple functions like that that operate on some global state (like velocity, in this case).

That said, I'm a big fan of OOP and I think it does make many things easier. I find a lot of the classes I write, if well designed, can be copied to new projects and they work out-the-box without any modification. But it's very easy to over-engineer something, and there have been times I just restarted a project from scratch because the design was bad and it was easier to rewrite it than try to fix it. So it can go both ways.

xyz

@cybereality Don't get me wrong, I'm not dissing object orientation in any way. I just don't quite subscribe to the mantra that everything is an object. I tend to keep to conservative side when it comes to introducing a new class into a system. But this is not really oop vs. non-oop thing. You can fully implement a state machine pattern using flags and cascading ifs as well as go without a state machine in a very strict object oriented way.

I probably shouldn't have used that term "flags" to name the alternative to a finite state machine. It's misleading. You described it better - it's about using aspects of entity's "global state" (that is - its whole relevant runtime data) to determine what should or can happen at that point in time. This data may or may not include flags that resemble some finite state machine functionality. And it may or may not be implemented in object oriented fashion.

But the more I think about it the more it looks like a bad choice to use finite state machine to describe entity's actions. It may be ok for some actual states like "cursed". Actions however are a different matter, unless you want to end up with one of those crude games that don't let you change direction mid-jump because it's too busy being in a "jump" state :) So I find it somewhat baffling that state machines for games are often introduced precisely with an example of modeling player's actions.

Let's look at a simple platformer. The player can execute three actions: dash, jump, slash. If you model this as a finite state machine, only one of these actions can be happening at time. However a game that feels responsive will take care that player can combine them in any way - jump mid dash while keeping dash speed and then slash in the middle of such dashed jump :) How can a finite state machine handle this without introducing multiple instances of itself or letting the bunch of ifs creep in? Which defies the proclaimed reason for using it in the first place.

divergy321

Ohhh... Now i see, I thinked that i have built some kind of state machine, but it actulay is not. It do same work but in own bulky way. I think i put myself in frames with all this, as a result there are difficulties with simple modifications. I see, that if i will restructure or recreate all by using "flag" based system elements, it will be easyer to solve many problems. Also I see that on this way many challanges awaits, and i cant find any good tutorial that will show how to avoid most of problems. Maybe someone know any good tutorials or other educational resouces about "flag" state system? I cant find anything any good tutorial, so i will be grateful for info :) Also maybe there is a name for this flag based state system? Of course I can try to face all those problems and feel everything on my own, but Id like to avoid unnecessary difficulties =)

fire7side

Flags are one of the oldest methods of keeping from repeating a thing before it is finished. If you have an is_jumping flag, you know you can't call it again, unless you allow a double jump or something. Generally you end up with disorganized code if it gets too complicated. But basically, you make your decision on which flag is true and which is false. I wouldn't recommend it because most people's code looks pretty bad when it gets complicated. Kind of a spaghetti code type situation. My code, without objects, looks terrible and always has. I have more errors and it's harder to find where they are. I'm sure I could organize it in some way, but that usually ends up being a rewrite. Objects just force you to separate your code, as in states. You have all your jumping code in your jumping state. You know where the transitions are, so it's generally easier to maintain especially for beginners or people that don't organize things very well like me. Any large project, like Godot, is object oriented because if it wasn't it would just collapse under it's own weight. You can take it too far with a small game. You don't have to start with a basic building block like a node or whatever, but you always want to separate your code into some type of blocks so you can find and repair problems. You are lucky you started out with some state machine code or you would be having a hard time finding all the problems with it. It still ends up complex, that's just the nature of the beast, it's just like keeping things in your house where there is a place for everything. Then you know where it is. But you won't find a flag system code somewhere or at least a name for it. If it's a simple set up, a lot of people will use it. If you are a skilled enough coder, you could probably still categorize everything and use it on a complex project but most people will end up with unmaintainable code. You at least have a system there. Much better than coming up with solutions one at a time for everything. Like "Oh that's right, I forgot when I'm jumping up I need to go through the object. Where is the code for that now?"

xyz

The thing is, if all your states/actions are mutually exclusive and can happen only one at the time, you're good with using a single tidy finite state machine. Just like they say in tutorials :)

As soon as there is parallelism of actions involved, you'll need at least as many finite state machines as there are actions that can happen in parallel, and they'll probably still need to talk to each other. This can get messy and alternatives should be considered.

Mutual exclusion is always mentally easier to handle than parallelism but your gameplay may suffer if you ditch parallelism.

So first you need to figure out how much can happen simultaneously, maybe make a diagram of which of your actions can overlap. Then you can decide if finite state machine is the right pattern to solve the problem.

@fire7side Code separation is good but it's not dependent on a specific design pattern. You can separate code nicely regardless of how your system is designed.

cybereality

@xyz said: Let's look at a simple platformer. The player can execute three actions: dash, jump, slash. If you model this as a finite state machine, only one of these actions can be happening at time. However a game that feels responsive will take care that player can combine them in any way - jump mid dash while keeping dash speed and then slash in the middle of such dashed jump :) How can a finite state machine handle this without introducing multiple instances of itself or letting the bunch of ifs creep in? Which defies the proclaimed reason for using it in the first place.

In this case, with a FSM, you would need combined states, such as "dash jump", "jump slash", etc. But you will need that anyhow, since you probably have a different animation when you are doing a "jump slash", you might need different velocity (like the slash slows down your velocity when jumping) and have to handle different transitions (for example, you could allow "jump" while "jumping" to do a double jump, but you don't want to allow double jumping while doing a "jump slash"). There is no avoiding this. State machines make the logic easier to follow and bugs easier to fix.

xyz

@cybereality said: In this case, with a FSM, you would need combined states, such as "dash jump", "jump slash", etc. But you will need that anyhow, since you probably have a different animation when you are doing a "jump slash", you might need different velocity (like the slash slows down your velocity when jumping) and have to handle different transitions (for example, you could allow "jump" while "jumping" to do a double jump, but you don't want to allow double jumping while doing a "jump slash"). There is no avoiding this. State machines make the logic easier to follow and bugs easier to fix.

Sure, you could get away with adding all possible combinations of vanilla states but this has a lot of potential to end up in exponential code bloat as the states are added and more and more combinations need to be covered. Why have a whole new state class with a lot of code repetition if the difference is only in animation sequence and hitbox activation. And probably more important - this does not allow for much finesse in timing. Say your dash duration is 1 second, jump is .75 and slash is .35. You dash at 0.0, then you slash at .25 and then you jump at .45. And then cranks on your state machine start to fall of :)

I'd much rather have a small number of atomic states and a system (of animation) that can cleverly combine them in asynchronous fashion, resulting in all sorts of emergent composed states that I don't really need to name or consider every possible combination separately. The character would then feel much more alive than a robot that can only exist inside a single, rigidly defined state at a time :)

divergy321

I think that I filnaly decided which state machine pattern i will follow. I will rebuild all from zero, and try to realize "Concurrent state machine". I think it will combine "Flag" state system flexibility and "Finite State Machine" rigidity. Now when I finaly see "setget" incredible potential I can also understand the construction of a FST. Here is likt to article about it if someone will be interested: https://gameprogrammingpatterns.com/state.html#concurrent-state-machines And here is likt to Youtube video i watched:

Recently i discovered for self that there exists AnimationTree node, and i think properly animation change I could reach by using this node. I think it will be much easier =)

fire7side

I agree on AnimationTree. Why not use a node that has been developed in c++ and has a visual setup, all debugged and ready to go? I don't know why more people don't use it. If you are just going left or right, you could also use upper body and lower body animations, so then the bear could actually walk and chew gum at the same time and concurrent animations would actually make sense. Generally, though, you need a separate animation for everything so, although it does have duplicate code, it doesn't really matter, and anywhere the code is duplicated, you can just call a function. Really, though, the more you rework code, the more you learn.

« Previous Page