BehaviorStore

Remarks

Why buckets. The naive version — one list of Behavior and a virtual call per entity — is a cache miss and an indirect call per entity, which is precisely what the ECS below exists to avoid. Behaviours are kept in a T[] per concrete type, so a batch is contiguous and the call site sees one type.

And why no generator. [04](../../../docs/plan/04-ecs-and-scripting.md) has Vixen.Ecs.Generators emit a static void Update_PlayerController(Span<…>) per behaviour type to get that. It is not needed: BehaviorBucket<T> is closed at the Add<T> call site, where the concrete type is already known, and its loop is the same monomorphic walk over the same contiguous array. A generator would add build-time machinery to produce code the JIT already gets to specialise. The generator is still owed for the [Inspector] metadata the editor needs, which genuinely cannot be had any other way.

Enabled and disabled are partitioned, not filtered. Each bucket keeps its enabled behaviours in a prefix of its array, so the update loop stops at the boundary and a thousand disabled behaviours cost nothing — the [SkipIfDisabled] split from doc 04, without an attribute, because there is no reason not to always do it.

Fields and properties (4)

• public World World

  The world the behaviours' entities live in.

• public GameTime Time

  The clock the behaviours currently running are seeing — the frame's, or the fixed step's inside SystemPhase.FixedUpdate.

• public int Count

  How many behaviours exist, enabled or not.

• public CoroutineScheduler Coroutines

  The scheduler this store's behaviours run their coroutines on.

Methods (10)

• public BehaviorStore(World world, CoroutineScheduler? coroutines = null)

  Creates a store for a world.

• public T Add<T>(Entity entity, T behavior) where T : Behavior

  Attaches a behaviour to an entity.

• public T Add<T>(Entity entity) where T : Behavior, new()

  Attaches a behaviour constructed with its parameterless constructor.

• public T? Get<T>(Entity entity) where T : Behavior

  The entity's behaviour of a type, if it has one.

• public ReadOnlySpan<Behavior> AllOn(Entity entity)

  Every behaviour on an entity.

• public void Destroy(Behavior behavior)

  Queues a behaviour for destruction at the next lifecycle drain.

• public bool Remove(Behavior behavior)

  Takes a behaviour off its entity now, running none of its callbacks.

• public void RunLifecycle()

  Runs every queued lifecycle callback, in the order the design fixes: destroy, then Awake all, then OnEnable all, then Start all.

• public void RunUpdate()

  Runs Update on every enabled, started behaviour.

• public void RunLateUpdate()

  Runs LateUpdate on every enabled, started behaviour.

Used by (28)

• ArenaThirdPersonShooter
• PlayerRigThirdPersonShooter
• BehaviorVixen.Engine
• BehaviorLateUpdateSystemVixen.Engine
• BehaviorLifecycleSystemVixen.Engine
• BehaviorRegistrationTestsVixen.Engine.Tests
• BehaviorTestsVixen.Engine.Tests
• BehaviorUpdateSystemVixen.Engine
• CoroutineTestsVixen.Engine.Tests
• EngineLoopVixen.Engine
• ISceneBehaviorBinderVixen.Engine
• SceneAndPrefabTestsVixen.Engine.Tests
• SceneBehaviorBinderVixen.Engine
• SceneManagerVixen.Engine
• SpawnerVixen.Engine.Tests
• SyncListReplicationTestsVixen.Net.Engine.Tests
• SyncListReplicatorVixen.Net.Engine
• SyncStateReplicatorVixen.Net.Engine
• SyncStateTestsVixen.Net.Engine.Tests
• BehaviorAuthoringTestsVixen.Editor.App.Tests
• BehaviorBridgeVixen.Editor.SceneView
• BehaviorSceneTestsVixen.Editor.SceneView.Tests
• ComponentsViewVixen.Editor.App
• EditorApplicationVixen.Editor.App
• OrderingGameVixen.App.Tests
• RegisteredVixen.Editor.App
• SceneDocumentVixen.Editor.SceneView
• SceneSerializerVixen.Editor.SceneView