Debugging/Profiler tools about behaviourtoolkit HOT 5 OPEN

Got a basic FSM Debug to work! I'll add transitions, the options to add more FSMs. Still thinking about how to best implement a history and BT support.

from behaviourtoolkit.

I actually have looked into it. Since I am implementing #3 for the for 2.0.0 I might use this to add profiling as well! Gonna have to do some research on what to actually track etc.

Pointers/suggestions are always welcome!

from behaviourtoolkit.

Just a small idea dump. @SirPigeonz please add your thoughts and wishes!

• Number of Behaviours
• _process time for all Behaviours

This goes hand in hand with #3 grouping Behaviours together and custom tick intervals.

from behaviourtoolkit.

Thank you for your ideas!

About debugging Beehave made a lot of good designs which can be re-adopted and built upon.

I looked into using GraphEdit for this kind of stuff, but I'd rather stay away from it, until it is fully stable in future Godot versions. Also debugging state machines with this method is kinda hard.

The StateChart Plugin uses a very easy to implement Tree node (which i actually had implemented in early dev version, but ultimately scrapped).

That said, I can totally reimplement it for a quick release, before reworking the codebase for 2.0.0

@SirPigeonz I'll give the rest of your ideas some thought on how to implement them best and will update this issue with any new infos/ideas I have come up with!

from behaviourtoolkit.

@ThePat02 Thx for the response! Sounds exciting :) I like your ideas to combine many different behavioral patterns into one! I also like how you tacke UX of the system and documentation. Only things I'm missing are Debugging and Unit Test both you have in plans so that is amazing :) Although for now I can live without them, they will be important along the road tho.

I have few ideas how to extend it for my project and some of those ideas might be a good fit for main branch. If I will make some of them into working prototype. I can create PR and we can disscuss if they will be ok for main branch and if they need some extra work to be acceptable. I would love to contribute back if something will be of value.

About debugging Beehave made a lot of good designs which can be re-adopted and built upon.
You probably already know how it works but I will go over it explaining what I like and don't like and why, maybe it will be usefull for you.

1. I love that visual debugger is inside Debugging tab in it's own section, it's nice thing for 2 monitor users. I usually run my game on second monitor with editor still on first.
2. I like that blocks are color coded although I think it can be improved either by re-using your amazing icons color code (I rly love how they imidietly tell which node it is) or by also including them in design of the node block.
3. It's great that the debugger can be detached good for tripple monitors users (me in the future)
4. I like that there is the list of debuggable BTrees already in the Debugger it simplifies testing many trees.
5. It's nice it allows to draw the graph top-bottom and left-right (my fav is top-bottom tho mimics how Godot Node tree flow works).

What I think is missing in Beehave:

1. A way to display at least some debug info at runtime as an overlay. Usefull for users working with one monitor (not me) but some devs use laptops to work on the go they might miss this feature and would have to implement it themselves.
   State Charts add-on (amazing FSM add-on in my opinion) made special widget that can be added to a Scene as a Node:
   
   

What I don't know is how to combine visual debugging in BT and FSM it might be the main challange.
Maybe by default the BT tree node graph could be displayed and only currently active FSM tree hierachy would be added dynamically? After that some way to enter FSM section in isolation to display it's own nodes in typical FSM "spider web of madness" when user would need full view like in UE Animator or gd-YAFSM (other nice FSM add-on):

I'm not huge fan of "spider web of madness" I still have PTSD after working with UE Animation system for indie prototype... I much more prefer Tree structure for FSM just like in your addon or State Charts. Although "spider web of madness" is handy for debugging sometimes...
That said basic tree view for FSM and History like in State Charts is more usefull and will be less work to implement :)

But here I'm not enough fluent in combined systems of BT FSM to be of much help I'm affraid.
This idea is very ambitious and I like it!

You also want to add GOAP which I know even less about, only how it more or less works and when it's a good fit. ^^'

Profiling I don't have much experience I'm affraid. How Beehave does it is also nice so it's good place to get pointers too I guess.
I like that you can select which BT is monitored although if you plan separate Manager you might be on something that would be even better if I understand your idea properly :)

Good luck! I will fiddle with your addon and try think of more feedback for the potential debugger. :)

from behaviourtoolkit.