Cache performance and chunk usage

[KontosTwo]

In Unity DOTS, we generally want to minimize the number of unique component combinations AKA archetypes. This means no "God Objects", or in DOTS terms, entities with a huge number of components. Adding just one unique component to any of these "God Entities" would create an entirely new archetype chunk populated by just one large set of components.

In my ECS architecture, actors have a gargantuan number of configurable data components, with many, many arcehtype variations. The separate Monobehavior-based PandaBT framework would query component data from these myriad God Entities. Overall, my current system is very inefficient at utilizing the cache and conserving chunk space.

Fortunately, EntitiesBT seems to avert this problem. I'd like to ask a few questions on if or how EntitiesBT uses the cache well and minimizes chunk waste.

1. Are all these Node/Variant implementations their own component types, or are they all treated as Node/Variant? If the latter, then chunk utilization would be superb. Even the former is okay if many of the same Node/Variant implementations are used.
2. Even though EntitiesBT is burst-incompatible, massive performance gains could still be made if the BT data structures are laid out in an ECS-adhering way. Is this true? (Not to mention multithreading seems to be enabled by just toggling a flag)
3. Can EntitiesBT be tinkered with to support breaking God Entities into many manageable and efficient groups of homogenous components? For example, consider the following entity.

Soldier = ([Flanking Components],[Tactics Components],[Gun Components],[Morale Components],[Armor Components])

Any small variation in this archetype, such as adding a single "RadioComponent" for example, would waste chunks and decrease execution performance. In addition, PandaBT would require querying data from all these groups of components for their related behavior tree action nodes. Of course, this God Entity could still be split up into many sub-entities that can still be read from PandaBT's Monobehavior code, but the amount of Editor dragging and dropping would drive many crazy. The potential alternative using EntitiesBT is the following entities:

Soldier = ()

Smart Flank = ([Subset of Flanking Components],[EntitiesBT Components])
Panic Flank = ([Subset of Flanking Components],[EntitiesBT Components])
Rookie Flank = ([Subset of Flanking Components],[EntitiesBT Components])
Reload = ([Subset of Gun Components],[EntitiesBT Components])
Aim = ([Subset of Gun Components],[EntitiesBT Components])
Shoot ([Subset of Gun Components],[EntitiesBT Components])

And so on.

The Soldier entity is now just a blank "folder" entity, while each of its data components are now tied to their related behavior components. Cohesion is nicely tight, each chunk is now populated by a large number of easily manageable entity components, and any systems that operate on the data components (AimForSniperSystem, FlankPathfindingCalculationSystem, etc) won't iterate over unnecessary components.

Each entity could also now be saved as a prefab, with prefab variants used to inject different configuration values. They can then be dragged and dropped into different areas of a behavior tree (the Covering Fire subtree and Flanking Fire subtrees would both use a prefab instance of Shoot, for example). Or, have just one base instance of the data components, and create a special authoring that injects a special node variant that refers to this base data entity.

@quabug please do tell if EntitiesBT can be utilized to solve this problem.

[quabug]

1. Are all these Node/Variant implementations their own component types, or are they all treated as Node/Variant? If the latter, then chunk utilization would be superb. Even the former is okay if many of the same Node/Variant implementations are used.

The memory layout of behavior tree is absolutely independent from Unity.Entities, there's no components at all.
The nodes data (tree) will be stored in a continuance blob, NodeBlob, after build/load.

Entity or GameObject just different data sources for behavior tree which can be access via their own Blackboard.

2. Even though EntitiesBT is burst-incompatible, massive performance gains could still be made if the BT data structures are laid out in an ECS-adhering way. Is this true? (Not to mention multithreading seems to be enabled by just toggling a flag)

Tree structure of EntitiesBT is not "an ECS-adhering way", but the performance ought to be better than OO behavior tree since the memory gap between each nodes designed to be minimal.
Anyway, it's always a good idea to test your use cases to see if there is an improvement in performance.

3. Can EntitiesBT be tinkered with to support breaking God Entities into many manageable and efficient groups of homogenous components? For example, consider the following entity.

I am not familiar with PandaBT, but I think there's no significant difference between PandaBT(MonoBehavior) and EntitiesBT on the way to access entity components.

A EntityQuery will be generated automatically for each trees, and will combined into a one-fit-all JobHandle(job dependencies) before tick behavior trees in Job task, which is not ideal from a performance point of view though.

---

I am not sure I fully understand your questions, so please point out if something is still unclear.
And it is best if you can provide some code examples of how do you use PandaBT to access entity components.

[KontosTwo]

Here's the parent class that all "AILinker" classes inherit from.

RequireComponent(typeof(EntityStore))]
    [RequireComponent(typeof(BehaviorTreeAILinkerAggregator))]
    public abstract class BehaviorTreeBaseAILinker : MonoBehaviour, IBehaviorTreeAILinker
    {
        private TextAsset ai;
        private MessageQueueSystem messageQueueSystem;

        protected EntityManager EM
        {
            get;
            private set;
        }

        protected Entity User
        {
            get;
            private set;
        }

        protected void WaitForEvents<T>(EventType initializingEventType, params List<EventType>[] eventSequences)
        {
            SendMessageAndWaitForEvents(
                (sourceId) => {},
                eventSequences
            );
        }

        protected void CreateMessageAndWaitForEvents<T>(T message, params List<EventType>[] eventSequences)
            where T : struct, IEventMessage
        {
            SendMessageAndWaitForEvents((sourceId) =>
            {
                // create the message
                message.SourceId = sourceId;

                var messageQueue = messageQueueSystem.CreateEventWriter<T>();

                messageQueue.Write(message);

                messageQueueSystem.AddJobHandleForProducer<T>(default);
            },
            eventSequences);
        }


        private void SendMessageAndWaitForEvents(Action<SourceId> sourceIdAction, params List<EventType>[] eventSequences)
        {
            if (Task.current.isStarting)
            {
                var sourceId = new SourceId
                {
                    initiatingEntity = User
                };

                // send the message
                sourceIdAction.Invoke(sourceId);

                // make the user entity wait for events with this sourceId
                EM.AddComponentData(User, new EventSourceWaitingComponent
                {
                    sourceId = sourceId
                });

                // populate the event types that the user will be waiting on
                var unfulfilledEventTypes = EM.AddBuffer<EventTypeUnfulfilledComponent>(User);
                var unfulfilledEventSequences = eventSequences.Length;
                for (var i = 0; i < unfulfilledEventSequences; i++)
                {
                    var eventSequence = eventSequences[i];
                    var numUnfulfilledEventTypeIds = eventSequence.Count;
                    for (var j = 0; j < numUnfulfilledEventTypeIds; j++)
                    {
                        var unfulfilledEventTypeId = eventSequence[j];

                        unfulfilledEventTypes.Add(new EventTypeUnfulfilledComponent
                        {
                            eventTypeId = unfulfilledEventTypeId,
                            sourceId = sourceId,
                            completed = false,
                            success = false
                        });
                    }
                }
            }
            else
            {
                if (EM.HasComponent<EventWaitingSuccessComponent>(User))
                {
                    EM.RemoveComponent<EventWaitingSuccessComponent>(User);
                    CompleteWaitingForEvent();
                    Task.current.Succeed();
                }
                else if (EM.HasComponent<EventWaitingFailureComponent>(User))
                {
                    EM.RemoveComponent<EventWaitingFailureComponent>(User);
                    CompleteWaitingForEvent();
                    Task.current.Fail();
                }
            }
        }
    }

Here's an example implementation

 public class AttackGrenadeLoadoutAILinker : BehaviorTreeBaseAILinker
    {
        private static readonly List<EventType> ATTACK_GRENADE_LOADOUT_SWITCH_EVENT_SEQUENCE = new List<EventType>()
            {
                ATTACK_GRENADE_LOADOUT_SWITCH,
                ITEM_INVENTORY_SWITCH,
                ITEM_USER_SET_ACTIVE_ITEM
            };

        private static readonly List<EventType> ATTACK_GRENADE_LOADOUT_THROW_EVENT_SEQUENCE = new List<EventType>()
            {
                ATTACK_GRENADE_LOADOUT_THROW,
                THROWABLE_THROW
            };

        [Task]
        public void SwitchToAttackGrenade()
        {
            CreateMessageAndWaitForEvents(new AttackGrenadeLoadoutSwitchMessage
                {
                    userEntity = User
                },
                ATTACK_GRENADE_LOADOUT_SWITCH,
                ATTACK_GRENADE_LOADOUT_SWITCH_EVENT_SEQUENCE
            );
        }

        [Task]
        public void ThrowAttackGrenade()
        {
            CreateMessageAndWaitForEvents(new AttackGrenadeLoadoutThrowMessage
                {
                    userEntity = User
                },
                ATTACK_GRENADE_LOADOUT_THROW,
                ATTACK_GRENADE_LOADOUT_THROW_EVENT_SEQUENCE
            );
        }

        [Task]
        public bool HasAttackGrenade()
        {
            var activeItemEntity = EM.GetComponentData<ItemUserActiveItemComponent>(User);
            return !activeItemEntity.Equals(Entity.Null);
        }
    }

Anything annotated with [Task] is the equivalent of a BT node. A .txt file will use these nodes like thus

tree "SwitchToAttackGrenade"
    SwitchToAttackGrenade

tree "ThrowAttackGrenade"
    ThrowAttackGrenade

tree "HasAttackGrenade"
    HasAttackGrenade

sequence
    tree "HasAttackGrenade"
    tree "SwitchToAttackGrenade"
    tree "ThrowAttackGrenade"

What I'm concerned about is the Monobehavior implementation of PandaBT, and the consequence of running dozens, if not one or two hundred, instances of it. Also, the every-frame checking of ECS data through EntityManager random access, in order to verify that the right events are generated by completed ECS systems. Finally, this architecture encourages "God Entities".

I should probably also ask if it's possible to access component data from entities from inside an EntitiesBT Node or Variant

[quabug]

I should probably also ask if it's possible to access component data from entities from inside an EntitiesBT Node or Variant

For main threaded nodes, the EntityManager must pass into node by an IComponentData for further using:

    [BehaviorTreeComponent]
    public class EntityManagerData : IComponentData
    {
        public EntityManager Value;
    }

    [UpdateBefore(typeof(VirtualMachineSystem))]
    public class EntityManagerSystem : SystemBase
    {
        protected override void OnUpdate()
        {
            Entities.WithoutBurst().ForEach((EntityManagerData em) => em.Value = EntityManager).Run();
        }
    }

    public struct SomeNode : INodeData
    {
        public NodeState Tick<TNodeBlob, TBlackboard>(int index, ref TNodeBlob blob, ref TBlackboard bb)
            where TNodeBlob : struct, INodeBlob
            where TBlackboard : struct, IBlackboard
        {
            var em = bb.GetObject<EntityManagerData>().Value;
            ....
        }
    }

I have no idea how to pass necessary data for accessing entities in a job node since it is hard to predicate which ComponentDataFromEntity<> should be created before running behavior tree (maybe some ILPostProcessor stuff could do the trick?). Otherwise it will work as long as you pass ComponentDataFromEntity<> into node just like other job did.

What I'm concerned about is the Monobehavior implementation of PandaBT, and the consequence of running dozens, if not one or two hundred, instances of it. Also, the every-frame checking of ECS data through EntityManager random access, in order to verify that the right events are generated by completed ECS systems. Finally, this architecture encourages "God Entities".

The most significant difference, which impact performance, between PandaBT and EntitiesBT is memory layout of tree (nodes).

There's no difference on accessing components for both BT neither in main thread nor in job.

[KontosTwo]

Thank you for these answers. Performance and QoL improvements were what I'm looking for, and although EntitiesBT doesn't offer enough of a performance boost, your answers still generated some good food for thought. I'll try improving my PandaBT architecture to reduce God Entities and improve ease of use