godot-extended-libraries / godot-next

Godot Node Extensions - Basic Node Extensions for Godot Engine
MIT License
957 stars 61 forks source link

Add State Machine Implementation #69

Closed nonunknown closed 4 years ago

nonunknown commented 4 years ago

AS Promised here's my contribution, plz tell me if something has to be done

willnationsdev commented 4 years ago

@nonunknown Hey there. I appreciate you making the submission. Unfortunately though, I'm not sure whether it's the best place to keep it. I can imagine keeping a state machine implementation repository inside the Godot Extended Libraries organization, but I don't think making it part of this repo is the best idea.

For most of the items in here, they are simple enough to code in script, so they aren't kept in the engine, but they are also things that, more or less, often have a single way of going about them. State machines in contrast have a myriad of possible implementations, and so including a prescribed general solution would be a much bigger undertaking imo.

I would however, encourage you to create a dedicated repository. And if you wanted to really create a generic state-machine framework with broad appeal, I have some ideas on how it could be done, to some degree anyway. But no matter what, it's entirely likely that anything you build wouldn't be used directly in projects. At least, not without crafting a large amount of tooling to work with the content.

If you were going to build one, it'd need, at the very least...

  1. Built-in serializability: states and their possible transitions would need to be described via a resource type (or even more than one). E.g. a StateNetwork resource that contains an Array of StateData resources (each with a name) and a Dictionary<String, String> of allowed transitions between the states.
  2. Appealing to node tree users: For example, people could create StateMachine nodes that wrap a StateNetwork and then just let them add State nodes as children to designate available states. All configuration of StateMachine and State nodes could then ultimately update the serialized StateNetwork resource.
  3. Appealing to visual graph users: For example, make selecting a StateMachine node or StateNetwork resource also bring up a StateEditor bottom panel in the Godot Editor which displays a GraphEdit with nodes and wires depicting the available states and the connections between them. Bonus points for figuring out how to animate them for "code flow" effects or even have them update in real-time, running simulations, etc.
  4. Appealing to code-only users: For example, having a StateNetworkBuilder class that facilitates in building a StateNetwork resource from code alone, without the need for any Editor visualizations.

As I said, creating a generic solution that appeals to many people and handles a wide variety of use cases is extremely difficult. It'd be a ton of work, and I'm not even really sure it'd be worth it in the end. But, it might very well find a place in the community and get a lot of support, so what do I know? ;-)

It would also be a good idea to see how others have implemented state machines for Godot on GitHub as I have seen many different ones here and there, iirc.

I didn't bother doing a more in-depth code review of what you've initially submitted, but if you'd prefer I give you my feedback as well, I can also do so, but I don't plan on merging it into Next. However, my quick glance at it tells me that you should read the official GDScript style guide and adapt your code accordingly. The standards are relatively recent, so you might find older GDScript code that doesn't follow it, but any new code on GitHub should really endeavor to follow the standards as much as possible.

Let me know if you have any questions. I'm sorry if you end up feeling like you wasted your time, but I would happily include the project in GEL if you'd like to make it a community-maintained version. At that point, you can continue to develop your project, and perhaps others can offer suggestions for how to enhance it further by opening Issues and Pull Requests, etc.