Some clarity regarding behavioral trees


I would like to find out how performance could be better using behavioral trees.
And apart from having a different visual representation why it is wise using behavior trees as opposed to doing AI in event graphs.

Firstly i must mention i am completely foreign to behavior trees.
I have a thread here

But i feel this is something i need to be addressed by the guys making the tools.

The reason i want some clarification is because right now… possibly due to inexperience it seems very counter productive to have 4 separate elements in order to achieve AI behavior.
Not only due to it being unorganized, or shall we say organized in various elements as opposed to one, but sending information back and forth boggles my mind as to how this is considered cheaper on resources or “better” as all it is currently achieving is confusing me so much i am developing a migraine.

For example. If i want an instance of the AI character to do something and i am running a decorator i am casting on a tick back to the AI controller, and in order to get the correct information in a timely manner to the AI controller from the character blueprint i need to cast another tick event to update the AI controller.

So instead of having one tick event update what i need, i now have 3 tick events spread over 3 different “graphs or elements”.
I am hoping the reason for my cluttered work is due to not know what exactly it is i am doing.

To give a hint as to where i am coming from. My AI behavior created in an event graph was roughly one screen size where the blueprint is readable. In other words. Small. But now after trying to use trees, i am left with the same amount of work just on my character, and then a ton of extra work spread across decorators, tasks, behavior tree.

I apologize if this comes across as rude or attacking which is not my intention. I am merely trying to grasp what exactly are the benefits and if i should spend more time trying to find efficient ways of using behavioral trees because as mentioned… currently it is not efficient at all for me who have no prior experience in this.

im not a programmer, so i always thought there are no tossing info from one bp to another because after i hit pack for a windows, all of those blueprint wires become just a code with a lot of functions with specific order and references to global variables in it.

Hmm actually i have no idea. Still i see a lot a mention that casting should be kept to a minimum, especially concerning casting on a tick event.
Which is why im so confused as to why we need to cast so much…

Anyway i finally finished the tutorial in the documentation… tomorrow i will try and share variables again

there are no way to keep casting at minimum, pretty much every single event has cast to game instance/mode/state

Casting might be considered ‘expensive’ but that’s kind of a relative term. Unless you are trying to do it thousands of times a tick or something you should be perfectly fine. Here’s a thread where somebody tested it:

In general I think the caution against doing things on tick is that it’s sometimes ‘easier’ to just have a ton of stuff running on tick and it’s easy to start slowing things down doing stuff each frame when its better to just design proper logic and avoid it. Well designed logic will avoid doing stuff on tick that doesn’t need to be executed every frame, but there’s plenty of times it can’t be avoided and that’s ok.

Awesome thread thanks. At least the performance difference when using interfaces are minuscule because i always try to use interfaces as opposed to casting.
I invested about 14 hours now into behavioral trees. Will do another 10 hours and see if i can start understanding why to use this as opposed to normal graphs.