What logic should be avoided on the Behavior Tree?


New member
Hello, I'm just getting up to speed on behavior trees and I find them making a lot of sense for some things and counter-intuitive for others. I can see that it's tempting to stick as much logic as possible inside of one but that could lead to a big mess. I'm wondering what people have found easier to keep out of the tree like animations, sfx, raycasts etc. Also, how do you intertwine the separate logic? Would you use a sort of state machine which the tree would set and have your outside logic in there? Cheers.
Last edited:


Staff member
Think of behavior trees as describing the flow, rather than the actual implementation. I've found it best to have the tree describe at a high level what the agent should do, and then the individual tasks or underlying component does the actual logic.

This was the approach that I took for our character controller. The behavior tree will say to move to this position or attack this target, but it doesn't do the actual movement or attacking. Instead the pathfinding agent (NavMeshAgent) will move the character, and the weapon will do the actual attack. You can see this flow in more detail at https://opsive.com/support/document...er/integrations/opsive-character-controllers/