Here’s how I am doing enemy behavior. I don’t use behavior trees, just blueprint:
A timer drives updates for enemy behavior:
Enemies are held in an array.
First we gather all data necessary to make decisions. This is typically a bool. Can See Player? Close Enough to Attack?
If there is line of sight and we are within the enemies field of view, then enemy knows player location:
In field of view?:
Convert dot product of player location to enemies forward vector to degrees, and make sure it is within a certain threshold. (e.g. ~90-140)
Note the Select on Combat Stance. If my player is in prone position, then I just make the enemies FOV smaller, thus making it less likely to detect the player. I prefer simple logic like this instead of complex simulations, because the only thing the player knows is how likely they will be seen. No reason to over-complicate!
Line of sight?":
A line trace from enemies head bone to the player. I use a max distance so that enemies wont spot you from across the level.
In that case, Is Alerted (e.g. aggro’d) is also true. In my game, I only set this once. Once aggro’d the enemy stays aggro’d.
After data is gathered with which to make decisions with, then we can make those decisions for each enemy:
This is just handled by priority:
Depending on the type of enemy, I branch behavior into a few varieties:
Continuous means that the timer update will keep updating the state. For instance, if we are charging the player, we want to keep updating that so that the enemy tracks players position fast enough.
But if the enemy is currently attacking (playing an attack montage), then we want to gate that off so that we don’t keep calling the montage too frequently. So when the attack montage starts we set a bool to close the gate, and when the montage finish the bool is flipped. Then another attack can happen if we are still going down that branch.
I recommend trying to build a simple system like this first before trying to work with an extremely robust system like behavior tree. For a beginner, BT would be like trying to learn how to drive by piloting an F-22. With a simple blueprint only setup like this, you can avoid the complexities of passing data between multiple classes, and also you can most readily see and understand the execution flow. Whereas if you work with a system built by somebody else, there is a lot of stuff happening that is hidden and you won’t understand.
I find it helpful to verify my logic carefully before diving into code:
If you sketch it out like this and then imagine the execution flow going down each branch, you can catch your logic errors before getting into the weeds with code.