Setting up a node based state machine

PhantomFox128

Yes, I'm back at this again and still haven't figured it out.

It's not the lack of knowledge on state machines that's stumping me. I know what they are, what they're supposed to do and I've read the chapter on Game Programming Patterns several times. That's not the issue. It's implementing them in Godot that I don't understand. I know the simple way would be an enum with a match statement, but I'm pretty sure my project is well beyond that, hence why I'm trying to implement a multiple node based approach (a state machine node with child nodes for each individual state for example).

I've tried virtually every tutorial/guide I could find on the matter and nothing has worked so far. They've all been either needlessly complicated and not explained well (if at all) or don't go beyond the most basic code. The big resource everyone points to is the GDQuest tutorial, but I found that one to be rather cumbersome and tough to follow. So I'm wondering: is there a more simple, easier to understand tutorial/guide/resource on node based state machines?

cybereality

You don't need Nodes, you can create a base class just in script (there will be no visual representation of the state). The base class just has a few generic functions like "update()", "enter_state()", "exit_state()", which you override in the child class. Then the child class extends the base class, put your logic in "update()" and then add any state-specific variables you need in that class. Then you'd need an manager class (you can call it "Machine" or whatever) which would control the whole thing. In the Machine class, it also has an "update()" function which calls the "update()" function of the current state (the current state is of type of the base class above). You'd also have a "switch_state(new_state)" function which first calls "exit_state()" on the current state, sets current state to the new state, and then calls enter state on the new current state. In this case, you don't need any enums or match statements. I think this is the right way to go about it. I know people keep asking, maybe I can write a tutorial if that doesn't make sense.

PhantomFox128

@cybereality said: I know people keep asking, maybe I can write a tutorial if that doesn't make sense. That would be really helpful, if you're up for it! I don't think I've encountered an approach like you're describing, so I'm kinda having some trouble visualizing it.

Byteonium

@cybereality said: In this case, you don't need any enums or match statements. I think this is the right way to go about it. I know people keep asking, maybe I can write a tutorial if that doesn't make sense.

I like the OOP-based approach to the state machine principle. Nonetheless I have some questions about your idea: 1. Do you suggest to basically derive a "state class" for every designed state from the base class you proposed or did I get it entirely wrong on that part? In C# or Java this would be a no-brainer for me, but is this possible using GDScript? 2. Your "Machine" class somehow needs to control the state classes. Should it do so by "owning" them (e.g. by containing them in a variable) and calling their respective methods? How would the Machine class know that a state should be switched?

If you are up for it (as Azerkit put it) I would be also very happy if you decided to write a tutorial on this :-)

cybereality

Yeah, let me see if I can code a quick example. My idea is more from C++, so I'll have to see if GDScript can do it.