Why clutter the hierarchy with Nodes for each state? Why not just have a plain ol’ class or resources, with init, enter, process, and exit methods? The statemachine could just have a list of them internally and call process on whatever the current one is. This is like using Monobehaviours for everything when you don’t need to, imo.
So the reason this was done was so you don’t have to redefine a lot of functions (for example the Update function), instead we can just override the current _PhysicsProcess() method, it also give access to methods like GetNode() and QueueFree(), while it is entirely possible to do it using a decoupled system, there are example online of in unity people using Monobehaviour styled Statemachines as well. The instructor is just showing one way of doing it. There are pro’s and con’s to each system, weighing them and figuring out which is better would have to fall on the person making the system.
Thanks for the comment though, gave us something to think about 
EDIT: Also using the system where the nodes are the components in the states alows for designers to manage states as well Thanks for reading!
2 Likes
Cool, thanks for the response.
Just talking shop for fun. Not trying to be “that guy”. 
The nodes can get out of hand imo. So an alternative is create a resource for each state with Init(); Enter();Process(delta); and Exit(). And then there’s the single FSM node that has an array of those resources.
Peace and respect. Thanks for the reply.
This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.