So I’m learning the generalities of behavior trees and how they work, and I have a question about the action nodes; Task nodes as I believe they’re referred to in UE4.
I tried looking at how the MoveTo functionality worked… but couldn’t follow it completely…
So, should action nodes move the target directly, or should they tell the the controller some new target position and the controller handles it. The reason I ask is if it’s the latter, then there also needs to be some task node to cancel the moving functionality, right? If we have an AI that is told to move to point A, but if he get’s shot at we want him to just stop and shoot, then we would need to tell the controller to cancel movement.
Hopefully I’ve made sense. Just to reiterate - My main question is should Task nodes modify the actor position directly, or just give the actor a target position and return running until that position is reached?
The high-level idea is that BT tasks should be triggering actions in AI and observing their progress. Also, BT tasks are responsible for aborting the action they’ve triggered when given BT task is aborted itself.
You can, of course, create a task that would micro-manage some activity in its tick, but we encourage people to avoid that approach if possible, since it’s less efficient.
So, following your example, to cancel move to stop and react to being shot you need to make your “react to being shot” behavior higher priority then the “move” behavior. This way, then the being-shot-reaction kicks in the move will get auto-aborted.
Now the question you might ask is “how does the higher priority behavior kick in”. The answer in one word is: Decorators. Our BT implementation is designed to be event-driven and we have a bunch of features to support that. The simplest one is decorators that can observe blackboard’s key and in reaction to value changes abort lower priority tree branches, or abort the branch they’re sitting on (or both!)
Hope it makes sense.
So when you say " the being-shot-reaction kicks in the move will get auto-aborted", the abortion happens because of the decorator? Since the MoveTo task will never actually be executed since the “react to being shot” task is higher priority, something else has to abort the AI’s moving, correct?
I suppose I’m still not understand WHO tells the AI to stop move to it’s given position.
I mean a setup like this:
Then BT is being traversed in search for next task to perform
Do Hit Reaction will be ignored since the condition (
Check if was hit) is false. The
Check.. decorator is set up for aborting lower priority, which means lower priority behavior will get aborted as soon as this condition’s value becomes true.
how would the check if i was hit go? from a character bp this is simple, from an overlap or hit event on the collision. but in here you dont have access to those events, so you would have to get that info from the character, in which case would it just be checking every tick if a variable is set on the character and be way more expensive processing wise? and lets say you get a HitReaction bool from the character, where do you set it back to false? in the character as well??? maybe i am ignorant but im wondering if the juice is worth the squeeze with the behavior trees.
No, you just store that info in the blackboard and the BT decorator gets notified about the changes, no polling. Part of reaction can be clearing BB values (although I would re-thing stuff if I was to modify BB from within a decorator - risk of “invalidating” current BT context).
i still dont understand where and when the hit reaction blackboard value would be set in order for this to trigger when the attack happens. i tried clearing the BB value in the reaction task, but that crashed unreal. so i also dont understand where and when you would clear the blackboard value either. if you had to do it from the character it would be less than ideal because a hit reaction is dependent on the animation timing, which is being played from the BT now, not the character.
You would still use an overlap/hit event in your character or controller blueprint. In that event, you can access the blackboard and set your flag ‘JustBeenHit’. You then have a blackboard decorator testing this value attached to your reaction task. As for resetting it, it really depends on the behaviour you’re trying to achieve, but one method would be to reset it from within the reaction task just before it completes. There is no reason this should cause any problem.
awesome, thanks for the quick responses. clearing the hit react bb value in the task worked this time no crashing. i think i am beginning to understand…