New Tasks

Behavior Designer supports tasks that use the GameObject architecture as well as tasks that use Entities within the DOTS architecture. The GameObject tasks inherit the Task abstract class which has an API similar to the MonoBehaviour class. Entity tasks implement various interfaces in order to ensure they provide the correct functionality. The list below contains the advantages of each approach:

GameObject Advantages:

• Easy to create. The workflow is extremely similar to MonoBehaviour component with OnStart, OnUpdate, etc.
• Can reference objects. This is an inherit limitation of Entities in that they can only pass objects by value.
• Can use Shared Variables. Shared Variables are classes shared between objects which means they cannot be used with the Entity workflow.
• Can use any existing Unity system. Unity is still working on updating all of their systems to use DOTS, which means that for some situations you have to use the GameObject approach.
• Still uses DOTS to traverse the tree. Behavior Designer still uses DOTS in order to traverse the tree.

Entity Advantages:

• Can use Burst. The Entity tasks use structs which allows the code to be burstable.
• Can use the job system in parallel. This allows for extremely fast execution across multiple threads.
• Extremely performant. If you want to have hundreds of thousands of entities on the screen you are going to need to use all Entity tasks.

As a general rule if you only have under ~50 behavior tree agents and don’t have any computationally heavy tasks it is recommended that you use the GameObject approach. The behavior tree traversal will still be quick and you won’t notice much difference by switching to Entity based tasks. GameObject tasks still have many advantages over Entity tasks. If you’ve later profiled your project and notice that a particular task is causing a bottleneck you can then switch that task to an Entity-based task.