Althugh I agree I will hit performance problems faster on navigation or collisions. My intent is to make more room for them. I agree I will never bottle neck myself with BTree alone 😄

Yes, I am totally unsure that removing one or to ifs is even worth it. That being said, without proper debugging tools and monitors we will probably never know so I will also look into #21 and check the docs of how to add custom profilers.

Match in GDScript is not yet as optimized as in Python I think

That is interesting, so if and match are basically the same, but I don't think there is any considerable impact on this scale.

I also agree that descriptive names are key I just want to pack more info at a galance without making them too long and hard to read and process in my brain.

My suggestion is do not use any names like lleaf_walk_actor_1. Using literal language and building "sentences" really helps with the readability. You can also save parts of a tree as a scene and reuse it.

Ah and about C#/C++ rewrite for performance I always consider that an option, if needed, but I prefer to keep it as a last-last-last resort :D

I actually really like the idea of using C++ to make heavy calculations and calling these functions with GDScript!

from behaviourtoolkit.

Thank you so much for this proposal!

My problem with adding multiple nodes for the same task boils down to one reason: It comes at the cost of accessibility, maintainability and readability. I suspect that an even more atomic design will yield not much improvement of performance, since usingif or even more optimal match does not have a big impact on your _process time.

Usually used (but not only) for AI Actors, that in some games (like in mine) can have large numbers those calls might be in many use cases un-needed and called on every frame D:

You would need benchmark these results to see if such a change would be worthwhile. If you have huge groups of AIs calling tick every frame is mostly necessary and there are other ways (#3) that this could be optimized. If they share the same tree, there might even be other possibilities of pooling etc.

Second problem I worry about is that it makes BTree less readable, user either will need to remember, check in inspector or add to nodes name information who the Leaf is calling.

You are supposed to give the leaves very literal and descriptive names anyway. For example:

BTRoot
	WanderAround
		IsNotBlocked
			IsBlocked
		GoToLocation
		WaitForAShorWhile	

I think more leaves for one activity would heavily clutter the UI and overwhelm the user. Developing your own version of them is very easy, so if this one if is causing you problems. If that is the case, using GDScript for Behaviour is NOT the way to go and C# or probably even C++ would be a beter solution.

Other notes

Te bo more coherent with LeafCall it also should support Custom nodes as well...

Yep, totally. That's true!

from behaviourtoolkit.

In any case, please finish changing #37 and I will push the new version to the asset lib, as it contains critical fixes.

To determine if this atomic approach really does have a big impact (I highly suspect it does not as match is basically free, a big benchmark would be useful. I think other systems will hit the ceiling much faster than this (like navigation or collision). I tested a scene with 600 agents and _process didn't seem to struggle one bit.

from behaviourtoolkit.

Thx for your input!

Althugh I agree I will hit performance problems faster on navigation or collisions. My intent is to make more room for them. I agree I will never bottle neck myself with BTree alone 😄

Match in GDScript is not yet as optimised as in Python I think:

• https://www.gdquest.com/tutorial/godot/gdscript/optimization-code/
• https://ask.godotengine.org/52544/which-is-faster-match-vs-if-elif
• godotengine/godot#75682

It might be optimised in the future tho. Althugh, benchmarking would be needed I agree.

I also agree that descriptive names are key I just want to pack more info at a galance without making them too long and hard to read and process in my brain. xD

In any case, please finish changing #37 and I will push the new version to the asset lib, as it contains critical fixes.

Sure I will :)
I will just make for my project custom atomic Signal node because I plan to use them a ton xD

We can evaluate this proposal again when I will finish my prototype and we will have benchamrking ready. Then we can check on it again. :)

from behaviourtoolkit.

Ah and about C#/C++ rewrite for performance I always consider that an option, if needed, but I prefer to keep it as a last-last-last resort :D

(I think I would prefer to improve match in GDScript myself, than to do rewrites in my game hahaha xD)

from behaviourtoolkit.

Yes, I am totally unsure that removing one or to ifs is even worth it. That being said, without proper debugging tools and monitors we will probably never know so I will also look into #21 and check the docs of how to add custom profilers.

Yup, thats true.

That is interesting, so if and match are basically the same, but I don't think there is any considerable impact on this scale.

Yeah scale is small and maybe one day it will be optimised, although it generates more calls than just match or if in practice.
When we will be able to test it on real project with profiling tools things will be more clear what to do.

My suggestion is do not use any names like lleaf_walk_actor_1. Using literal language and building "sentences" really helps with the readability.

Thats my plan but in practice things are rarely how they should be TnT

You can also save parts of a tree as a scene and reuse it.

Yup thats one of ma fav features in Godot

I actually really like the idea of using C++ to make heavy calculations and calling these functions with GDScript!

Actually I'm the same, but in practice, from my experience, when your game grows... things... start to be "interesting"... especially in geme dev where you have to experiment a lot and after 100x itteration you have no idea what is happening anymore but it works so you just try to not break it xD

Even if you rewrite small part integrating it might be less trivial... compilation is waste of time... especially for many architectures and OSes TnT. Thats why I try to avoid it. Although I will probably have to rewrite some to C++ for Switch, I'm happy that it is so straight forward in Godot. xD

It's much easier to contribute C++ code to the Engine itself than use it in a complex game. I contributed in the past but didn't had need/time for now to do more xD I try to focus on my project for now.

I try architecture my project in a way that uses havilly composition and hardcore rule of "one responsibility". In theory it would be easier to C++/C# ify this type of code but... I don't trust it xD (nothing is ever easy...)

from behaviourtoolkit.

It's much easier to contribute C++ code to the Engine itself than use it in a complex game. I contributed in the past but didn't had need/time for now to do more xD I try to focus on my project for now.

I thin GDExtension is wonderful and pretty easy to setup, as it doesn't require recompiling the engine!

from behaviourtoolkit.

True GDExt is pretty cool 😎 although I still will try to use it as little as possible :D

from behaviourtoolkit.