Closed nonunknown closed 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...
StateNetwork
resource that contains an Array of StateData
resources (each with a name) and a Dictionary<String, String>
of allowed transitions between the states.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.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.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.
AS Promised here's my contribution, plz tell me if something has to be done