(Google translator)
It depends on the scope of your state machine.
I’m not an expert, but I prefer nodes for the following reasons:
-
I have a visual representation of my states.
-
My states have an associated script where I can keep only the code related to that state. Even variables that are only used in that state are only there. This makes it easier for me to clearly understand what I’m doing in that state. This is what I consider most important.
-
If your state machine is hierarchical, you could even see states within states (although I haven’t implemented that myself).
-
You initialize states from the parent, traversing through the children.
-
You can include other child nodes within the states themselves if they require any extra functionality.
-
I like to put the states in the state machine, which is the parent of the states, as exported variables. This way, to perform a state change, I use the variable “machine.idle_state” to indicate the new state to go to, without having to work anywhere with enumerations of state names or callables that represent the states.
To create a state machine with nodes, you would simply create a machine class that extends Node and a state object that also extends Node.
class_name StateMachine extends Node
…
class_name State extends Node
…
Then the script for the StateIdle node will extend State, or, if you use inheritance, from the StateInFloor node, for example.
Anyway, I recommend you start implementing your state machine as you see fit and only modify it as you see problems with your design.
(In this other thread today there is interesting information about state machines that you might like to see: https://forum.godotengine.org/t/godot-architecture-7-steps-for-more-flexible-extensible-testable-code-video/137595/2 )