Unity Behavior Designer study notes and work summary

Why use Behavior Designer

In daily work, we always use code to implement various AI, such as monsters attacking player characters, usually there are three stages, Idle (hanging up in place, usually far away from the player), WalkOrRun (compared with When the player reaches a certain distance, start chasing the player), Attack (start attacking the player when reaching a certain distance).
Normally, we will use a state machine to implement the above functions, but when there are many situations, it is more complicated to implement, so we can use the Behavior Designer plug-in, and this plug-in will take you to control it. To put it bluntly, someone else has packaged a script, and you only need to fill in the corresponding parameters to realize the control effect of the state machine.

Implement the simplest Behavior Designer

As shown in the figure above, select a Cube, then open Behavior Designer with Tool, right-click in the behavior tree panel to add a behavior tree, and then add an Action (behavior, what to do) Log, run it to see the output. We are in the Inspector panel information in .

Introduction to the properties of Behavior Designer

Introduce the properties in the panel:

Behavior

Behavior: Some settings of the behavior tree, set according to the needs of your own project.

Tasks

Composites: Composite use, which means that the current node has multiple behavior composites. The commonly used ones are Selector (realize the effect of Or, only one of multiple behavior nodes is used), Sequence (realize the queue effect, execute one by one, if there are behaviors to return If it is false, then it will end directly).
At present, I commonly use the above two, which will be explained in detail in the follow-up cases.
Decorators: decorating nodes, you can decorate a single node, such as flipping, if you want to get the effect, then continue. Inverter. I haven't used it much, so I won't introduce it here, and I will add it later if I use it.
Actions: Behavior nodes, that is, specific content, such as Log.
Conditionals: Judging nodes, judging whether the conditions are met, can be used in conjunction with Sequence, if the conditions are met, the subsequent content will be executed, and if the conditions are not met, the current state will be exited directly.

Variables

Variable value, here you can add some common values ​​(reference types) under the current behavior tree, which will be explained in detail later.

Inspector

The property setting is the same as the one that comes with unity, so I won’t explain too much here.

Case 1: Realize the simplest monster patrol effect

Here we assume Cube is the enemy, just add a behavior tree on Cube, then add Patrol under Action, and then set the parameters of Patrol to achieve it.
ps: The behavior tree plug-in relies on Unity's Nav navigation system, so you need to set the Plane to Nav static, and then add the NavMeshAgent component to the Cube.

We can see that Patrol is green, which means it has been executing

Case 2: The monster is patrolling, and the player walks towards the target point. If the monster is seen on the road, the player will chase the monster instead.

To fulfill the above requirements, we need to use a Selector (to determine whether the player is going to the target point or to pursue the monster, choose one of the two), a Sequence (to determine whether the monster has been found, and to pursue it if found), two A Seek under Action (used to go to the target point, one is to go to the initially set target point, and the other is to go to the target point of the monster), and one Can See Object under Conditionals to judge whether the target is found.
The detailed steps are shown in the figure below:




As shown in the figure: Initially Can See Object is always a fork, but there is a red circle, which means it has been detecting. Here is because we changed the Type in Sequence to Lower Priority, and the weight ratio on the left is If the right side is high, it will break the right side.
Abort mode also has Self and Both.
Self represents that it can interrupt itself. For example, when a monster is initially detected, the player pursues the monster, but the player’s speed is slower than the monster, so he fails to catch up and leaves the field of vision. If the condition of Can See is not met at this time, the player will interrupt and walk to the originally set target point. go.
Both means that Self and Lower Priority are executed at the same time.
This is not a demonstration here, and interested friends can try it out by themselves.
Demo case

Switching between different behavior trees

In an actual project, an object may have many different states, and the behavior in different states is slightly different. Although we can write a behavior tree (it’s complicated to think about it), therefore, the behavior tree plug-in supports an object to have multiple behaviors tree, but only one can be running at a time.
Let's take a simple demo as an example.
An employee needs to go from point A to point B for work. Point A is home and point B is the factory.
The logic is that employees start from point A, run to the factory, and run home after arriving at the factory for a period of time.
Employees may repair tiles today and build walls tomorrow. The only difference between the two is this. Therefore, we can create two behavior trees and only distinguish this animation.

public class AniTest : MonoBehaviour
{
    
    
    Animator animator;
    public Transform objPosition;
    public List<BehaviorTree> FirestS = new List<BehaviorTree>();
    public List<BehaviorTree> Seconds = new List<BehaviorTree>();
    private void Awake()
    {
    
    
        animator = GetComponent<Animator>();
        BehaviorTree[] trees= FindObjectsOfType<BehaviorTree>();
        foreach (var item in trees)
        {
    
    
            if(item.Group == 1)
            {
    
    
                FirestS.Add(item);
            }
            else
            {
    
    
                Seconds.Add(item);
            }
        }
    }

    private void Update()
    {
    
    
        if (Input.GetKeyDown(KeyCode.H))
        {
    
    
            foreach (var item in Seconds)
            {
    
    
                item.DisableBehavior();
            }
            foreach (var item in FirestS)
            {
    
    
                item.EnableBehavior();
            }
        }

        if (Input.GetKeyDown(KeyCode.J))
        {
    
    
            foreach (var item in FirestS)
            {
    
    
                item.DisableBehavior();
            }
            foreach (var item in Seconds)
            {
    
    
                item.EnableBehavior();
            }
        }
    }

    void EventTest()
    {
    
    
        Debug.Log("执行了动画事件");
    }
}

It can be seen that the First behavior tree is green at first, and then turns gray. At this time, I switched to another behavior tree Second through code control, and switched to that behavior tree and found that it was green.
And it is also a Second action (waving, First is a walk).
The behavior tree plug-in is very powerful. What I know so far is only the tip of the iceberg. It can also have unexpected effects with the event system that comes with the animation system. Control the behavior tree plug-in to play the animation, and some events can be executed after the animation is played.

Here is actually a change based on my actual work project experience. The previous work had to control the movement of workers, and the distance was not bad. What was missing was the final running animation.