Behavior Tree framework based on and used for Unity Entities (DOTS)
Why another Behavior Tree framework?
While developing my new game by using Unity Entities, I found that the existing BT frameworks are not compatible with Entities and also lack of compatibility with plugins like odin, so I decide to write my own.
Features
Actions are easy to read/write data from/to entity.
Use Component of Unity directly instead of own editor window to maximumize compatibility of other plugins.
Data-oriented design, save all nodes data into a continuous data blob
Stateless nodes.
Seperate runtime nodes and editor nodes.
Easy to extend.
Also compatible with Unity GameObjects without any entity.
Able to save behavior tree into campact-binary-formatted file.
Flexible thread control: force on main thread / force on job thread / controlled by behavior tree
It seems well designed but this doesn’t appear to use burst or even jobs at all right? It does look nice and clean for an existing project that hasn’t been converted yet.
No, you cannot use job or burst with default EntityBlackboard, since it is get/set component data directly use EntityManager.
But you can create your own blackboard which compatible with job or even burst.
It is hard to design such blackboard that able to fill data from Entity before running in job.
Maybe something like EntityQuery? I’ll think about it.
About burst, there must have some kind of runtime polymorphism (like VirtualMachine which call different function by node id), for running different behavior/function/method for different node. But it is hard, or even not possible(?), to implement polymorphism by using burst C#.
Before that, it won’t have any support of burst.
One of the Burst team’s earliest stated goals was zero boxing. Things could change, but I wouldn’t expect that kind of support to come soon.
It’s made some things much less convenient. But on the plus side, when we are able to find new approaches which work inside that requirement, the results are often very performant.