@daneren2005/shared-memory-ecs 1.5.1 → 1.7.0

package/README.md

@@ -2,8 +2,8 @@
 
 A small, reusable Entity / Component / System core backed by shared memory
 ([`@daneren2005/shared-memory-objects`](https://www.npmjs.com/package/@daneren2005/shared-memory-objects)).
-It contains only the engine-agnostic parts of the ECS - no game specific concepts (factions, terrain,
-fog of war, sub-classed entities, required components, etc).
+It contains only engine-agnostic ECS concepts. Games supply their own components, entity classes, templates,
+systems, and domain data.
 
 ## Concepts
 
@@ -14,24 +14,29 @@ fog of war, sub-classed entities, required components, etc).
   config to the raw block values) and `attach(entity, memory, index)` (builds the accessor over that block).
   Loading a component is `attach(entity, memory, memory.create(toBlock(config)))`; splitting it this way lets a
   worker build the block off-thread (it calls only `toBlock`) and the main thread wrap it (`attach`) when it
-  adopts the entity. Plus an optional `save(component)` and `free(component)`. A component's data splits into
-  `Config` (defining props supplied up front, e.g. `maxHealth`) and `Serialization` (runtime-derived state,
-  e.g. current `health`); `toBlock` sees `Config & Serialization` while `save` returns only the `Serialization`
-  slice. `free` runs when the component is torn down (see [Freeing extra resources](#freeing-extra-resources)).
+  adopts the entity. Plus an optional `save(component)`, `free(component)`, and `died(component, entity, world)`.
+  A component's data splits into `Config` (defining props supplied up front, e.g. `maxHealth`) and
+  `Serialization` (runtime-derived state, e.g. current `health`); `toBlock` sees `Config & Serialization` while
+  `save` returns only the `Serialization` slice. `free` runs when the component is torn down (see
+  [Freeing extra resources](#freeing-extra-resources)); `died` runs when the entity is killed, with it still
+  readable (see [Reacting to death](#reacting-to-death)).
 - **`ComponentRegistry<C>`** – the map of all component definitions for a game.
 - **`EntityFactory<C>`** – maps an entity `type` name to a base (template) config. Loading an entity layers
   the caller's config over its type's template, so shared static data lives in one place and a save only
-  needs the `type` plus the entity's serialization. `BaseWorld#loadEntity` always goes through the factory.
+  needs the `type` plus the entity's serialization. Optionally, a template's immutable `class` selects a
+  game-provided `BaseEntity` subclass and restricts which components that template may load.
 - **`BaseWorld<C>`** – builds one `MemoryComponent` per registered component (attached to that component's
   definition as `world.registry[name].memoryComponent`) and runs systems. It is generic over your component
   map `C`, so `world.registry`, `entity.components`, `setComponent`, etc. are fully typed. Its entities live
   in `world.entities`, a `Map` keyed by `eid` — see [Iterating entities](#iterating-entities).
-- **`BaseEntity<C>`** – an `eid`, an optional `id`, and a bag of memory-backed components. It has no
-  direct property accessors and only loads/saves component data. Every entity has an `entity` component
-  whose `type` (a plain, worker-invisible string) records the factory template it was built from.
+- **`BaseEntity<C>`** – an `eid`, its `id` alias, immutable `type`, `dead` state, and a bag of memory-backed
+  components. Every entity has an `entity` component whose immutable `type` and optional immutable `class`
+  are interned strings stored in shared memory. A game can subclass `BaseEntity` to expose direct convenience
+  getters for one entity class.
 - **Systems** – `System`, `IterableSystem`, `EntitySystem` (main-thread iteration over entities with a
-  given set of components) and `ComponentSystem` (runs an update function over raw memory blocks,
-  off-thread when Web Workers + `SharedArrayBuffer` are available).
+  given set of components), `EntityWorkerSystem` (runs an update function over raw memory blocks,
+  off-thread when Web Workers + `SharedArrayBuffer` are available), and `WorkerSystem` (an `EntityWorkerSystem`
+  that runs once per tick over its sub-queries instead of once per entity — see [Per-tick systems](#per-tick-systems-workersystem)).
 
 ## Defining components
 
@@ -129,10 +134,68 @@ and the `entity` block stores only a pointer to it at `TYPE_INDEX`. Reading `ent
 resolves that pointer back to the string through the world's cache; a worker can do the same (see
 [Reading an entity's type in a worker](#reading-an-entitys-type-in-a-worker)).
 
+### Entity classes and scoped templates
+
+An entity `type` names one concrete template. Its optional `class` names the stable family that chooses a
+wrapper constructor and the components that family permits. Callers still pass only `{ type, ...overrides }`:
+the factory resolves class from the template, and neither identity can change after construction.
+
+```ts
+import {
+	BaseEntity,
+	BaseWorld,
+	EntityFactory,
+	defineEntityClasses,
+	defineEntityConfigs,
+} from '@daneren2005/shared-memory-ecs';
+import type { ComponentsOf, EntityConfigOf, EntityInstancesOf } from '@daneren2005/shared-memory-ecs';
+
+const registry = {
+	health: healthDefinition,
+	value: valueDefinition,
+};
+type Components = ComponentsOf<typeof registry>;
+type Config = EntityConfigOf<typeof registry>;
+
+class ActorEntity extends BaseEntity<Components, Config> {
+	get health() { return this.components.health?.health; }
+}
+class ItemEntity extends BaseEntity<Components, Config> {
+	get value() { return this.components.value?.value; }
+}
+
+const classes = defineEntityClasses(registry, {
+	actor: { entity: ActorEntity, components: ['health'] },
+	item: { entity: ItemEntity, components: ['value'] },
+} as const);
+
+const templates = defineEntityConfigs(classes, {
+	guardian: { type: 'guardian', class: 'actor', maxHealth: 100 },
+	token: { type: 'token', class: 'item', value: 5 },
+} as const);
+
+type Entities = EntityInstancesOf<typeof classes>;
+const factory = new EntityFactory<Components, Config, Entities>(templates, classes);
+const world = new BaseWorld<typeof registry, Components, Config, Entities>(registry, { factory });
+
+const item = world.loadEntity({ type: 'token' });
+console.log(item instanceof ItemEntity);            // true
+console.log(item.components.entity.class);          // "item"
+console.log(item.id, item.type, item.dead);          // BaseEntity identity accessors
+```
+
+`defineEntityConfigs` checks each template against its class's component definitions, so adding a health-only
+property to the item template is a type error. The factory repeats the boundary at runtime: loading or attaching
+a component outside the class allowlist throws, protecting dynamically loaded data too. Client/editor metadata
+that no component consumes should remain in a separate authoring type and be transformed into the scoped ECS
+template.
+
+Classless factories keep the original behavior: they create `BaseEntity` and scan the complete registry.
+
 ## Iterating entities
 
 `world.entities` is a `Map` keyed by `eid`, not an array, and so is `entities` on `EntitySystem` and
-`ComponentSystem`:
+`EntityWorkerSystem`:
 
 ```ts
 world.entities.forEach(entity => { ... });   // in the order they were added
@@ -186,25 +249,25 @@ physics library exports its `*_INDEX` constants.
 Reach for this when a profile says to, not by default. A menu, a save, a system that touches a dozen entities:
 use the accessors.
 
-## ComponentSystem workers
+## EntityWorkerSystem workers
 
-`ComponentSystem` needs a `getWorker()` that returns a real `Worker`, and an `updateFunction`. Your
-worker entry file calls `createComponentWorker(self, updateFunction)`, importing it from the
+`EntityWorkerSystem` needs a `getWorker()` that returns a real `Worker`, and an `updateFunction`. Your
+worker entry file calls `createEntitySystemWorker(self, updateFunction)`, importing it from the
 [`/worker` subpath](#importing-in-workers) so the worker bundle stays small. When Web Workers or
 `SharedArrayBuffer` are unavailable it transparently falls back to running the same update function on
 the main thread. Attach any extra per-run data (the equivalent of the old faction/fog-of-war fields)
 by overriding `addDataToWorld(world)`. Declare its shape with the `W` type parameter (an interface
-extending `ComponentSystemWorld`) so both `addDataToWorld` and the `updateFunction` see it typed:
+extending `EntityWorkerSystemWorld`) so both `addDataToWorld` and the `updateFunction` see it typed:
 
 ```ts
-interface DamageWorld extends ComponentSystemWorld {
+interface DamageWorld extends EntityWorkerSystemWorld {
 	damage: number
 }
 
 const damageUpdate: EntityUpdateFunction<Components, { health: Int32Array }, DamageWorld> =
 	(world, entityId, components) => { components.health[0] -= world.damage; };
 
-class DamageSystem extends ComponentSystem<Components, { health: Int32Array }, DamageWorld> {
+class DamageSystem extends EntityWorkerSystem<Components, { health: Int32Array }, DamageWorld> {
 	addDataToWorld(world: DamageWorld) { world.damage = 5; }
 }
 ```
@@ -220,11 +283,11 @@ itself. Both are optional properties on the `EntityUpdateFunction`.
 (structured-cloned across the boundary) and returns a `Partial<W>` that is merged onto `world` on every
 subsequent run. Use it for state that must be seeded from the main thread but then persist inside the worker
 — a seeded RNG, a lookup table, a config object — without paying to re-send it each frame. Type the init
-data with the `D` type parameter (the fourth on `EntityUpdateFunction` / `ComponentSystem`) so `getInitData`
+data with the `D` type parameter (the fourth on `EntityUpdateFunction` / `EntityWorkerSystem`) so `getInitData`
 and the `init` hook agree on its shape; it defaults to `unknown` when a system has no init data:
 
 ```ts
-interface DamageWorld extends ComponentSystemWorld {
+interface DamageWorld extends EntityWorkerSystemWorld {
 	damage: number
 }
 interface DamageInitData {
@@ -238,7 +301,7 @@ const damageUpdate: EntityUpdateFunction<Components, { health: Int32Array }, Dam
 // `DamageInitData | undefined` (undefined when the system supplies no getInitData).
 damageUpdate.init = (data) => ({ damage: data?.baseDamage ?? 1 });
 
-class DamageSystem extends ComponentSystem<Components, { health: Int32Array }, DamageWorld, DamageInitData> {
+class DamageSystem extends EntityWorkerSystem<Components, { health: Int32Array }, DamageWorld, DamageInitData> {
 	constructor(world: BaseWorld<Components>) {
 		super(world, {
 			name: 'DamageSystem',
@@ -253,7 +316,7 @@ class DamageSystem extends ComponentSystem<Components, { health: Int32Array }, D
 ```
 
 Unlike `addDataToWorld` (an overridable method on the system), `getInitData` is a config option — it lives in
-the options passed to the `ComponentSystem` constructor, so a system used without a subclass can supply it
+the options passed to the `EntityWorkerSystem` constructor, so a system used without a subclass can supply it
 there directly.
 
 **`preRun`** runs once per run, before any entity is updated, with the run's `world`, the full entity list,
@@ -270,33 +333,77 @@ damageUpdate.preRun = (world, entities, queries, callbacks) => {
 (An `entityRemoved(world, entityId, callbacks)` hook completes the set — it fires once per entity that left
 the system this run, so a worker can release any per-entity state it was holding.)
 
+### Per-tick systems: `WorkerSystem`
+
+Some systems have no entities of their own — they run **once per tick** to scan or count other entities, and
+maybe spawn something. A `WorkerSystem` is an `EntityWorkerSystem` whose function is called **once per run** over
+the named sub-queries instead of once per entity. It has no main query, so it runs every interval even with
+zero entities, and it reuses the whole worker/query/`createsEntities`/`addDataToWorld` machinery:
+
+```ts
+// once per run: no per-entity loop, just the queries
+const spawnerUpdate: WorkerSystemRunFunction<Components, SpawnerWorld> = (world, queries, callbacks) => {
+	const asteroids = queries.asteroids ?? [];
+	if(asteroids.length < world.minAsteroids) {
+		createEntityWorker(world, { type: 'asteroid', x: 0, y: 0 }, callbacks);
+	}
+};
+
+class SpawnerSystem extends WorkerSystem<Components, SpawnerWorld> {
+	minAsteroids = 20;
+	constructor(world: TestWorld) {
+		super(world, {
+			name: 'Spawner',
+			updateFunction: spawnerUpdate,
+			createsEntities: true,
+			deltaBetweenRuns: 1000,
+			getWorker: () => new Worker(SPAWNER_WORKER_URL, { type: 'module' }),
+			queries: { asteroids: { required: ['asteroid'] } },
+		});
+	}
+	// Fresh per-run data — structured-cloned to the worker each run, so keep it plain/cloneable.
+	addDataToWorld(world: SpawnerWorld) { world.minAsteroids = this.minAsteroids; }
+}
+```
+
+Its worker entry uses `createSystemWorker` (the run-function counterpart of `createEntitySystemWorker`),
+passing the registry only when it creates entities or adds components:
+
+```ts
+import { createSystemWorker } from '@daneren2005/shared-memory-ecs/worker';
+createSystemWorker(self, spawnerUpdate, registry);
+```
+
+The run function may carry the same `init` / `entityRemoved` hooks as an `updateFunction`. Everything else —
+callbacks, worker fallback, off-thread creation — behaves exactly as an `EntityWorkerSystem`.
+
 ### Importing in workers
 
 Each worker entry file is bundled on its own, and a single-entry bundle cannot tree-shake this package's
-barrel: importing `createComponentWorker` from `@daneren2005/shared-memory-ecs` drags the whole library -
+barrel: importing `createEntitySystemWorker` from `@daneren2005/shared-memory-ecs` drags the whole library -
 `BaseWorld`, every system, their `@daneren2005/shared-memory-objects` dependencies - into the worker, even
 though a worker never runs any of it (easily ~20kb of dead code per worker). Import worker-side helpers from
 the `@daneren2005/shared-memory-ecs/worker` subpath instead. It exposes only what runs in a worker -
-`createComponentWorker`, `createEntityWorker`, `killEntityWorker`, `DEAD_INDEX`, `TYPE_INDEX` (plus the
-worker-relevant types) - so the bundle stays tiny:
+`createEntitySystemWorker`, `createSystemWorker`, `createEntityWorker`, `addComponentWorker`,
+`removeComponentWorker`, `killEntityWorker`, `DEAD_INDEX`,
+`TYPE_INDEX` (plus the worker-relevant types) - so the bundle stays tiny:
 
 ```ts
 // damage.worker.ts - the worker entry file
-import { createComponentWorker } from '@daneren2005/shared-memory-ecs/worker';
+import { createEntitySystemWorker } from '@daneren2005/shared-memory-ecs/worker';
 import { damageUpdate } from './damage-update';
 
-createComponentWorker(self, damageUpdate);
+createEntitySystemWorker(self, damageUpdate);
 ```
 
 The same applies to any module the worker file pulls in: an update function that calls `createEntityWorker`
 or `killEntityWorker` should import them from `/worker` too. Type-only imports (`EntityUpdateFunction`,
-`ComponentSystemWorld`, ...) can come from either path since types are erased, and main-thread code
-(`ComponentSystem`, `BaseWorld`, `EntityFactory`, ...) keeps importing from the package root.
+`EntityWorkerSystemWorld`, ...) can come from either path since types are erased, and main-thread code
+(`EntityWorkerSystem`, `BaseWorld`, `EntityFactory`, ...) keeps importing from the package root.
 
-A worker that creates entities (see [Creating entities from a worker](#creating-entities-from-a-worker)) passes
-your component registry as the third argument - `createComponentWorker(self, shipUpdate, registry)` - so it has
-each component's `toBlock`. Only do this in workers that actually create entities; it pulls the registry (and
-whatever it imports) into that worker's bundle.
+A worker that creates entities or adds components passes your component registry as the third argument -
+`createEntitySystemWorker(self, shipUpdate, registry)` - so it has each component's `toBlock`. Only do this in
+workers that need it; it pulls the registry (and whatever it imports) into that worker's bundle.
 
 ### Reading an entity's type in a worker
 
@@ -314,7 +421,7 @@ const update: EntityUpdateFunction<Components, { entity: Uint32Array }> = (world
 	// ...branch on type, etc.
 };
 
-class TypedSystem extends ComponentSystem<Components, { entity: Uint32Array }> {
+class TypedSystem extends EntityWorkerSystem<Components, { entity: Uint32Array }> {
 	constructor(world: BaseWorld<Components>) {
 		super(world, { name: 'TypedSystem', required: ['entity'], updateFunction: update, getWorker: () => new Worker(/* ... */) });
 	}
@@ -331,7 +438,8 @@ on the main thread) resolves the same way.
 An update function runs on shared memory, so anything it writes is already visible on the main thread. What
 it cannot do from there is touch the world, so the things that have to happen back on it go through
 `callbacks`: `entityComponentChanged` (emitted on the entity as `component-property-updated`), `entityDied`
-(as `death`), and `createEntity` (see [Creating entities from a worker](#creating-entities-from-a-worker)).
+(as `death`), `createEntity` (see [Creating entities from a worker](#creating-entities-from-a-worker)), and
+component changes requested by `addComponentWorker` / `removeComponentWorker`.
 All of them are collected during the run and applied once it completes.
 
 `emitEntityEvent` is the escape hatch for an event of your own: name it whatever you like and give it
@@ -401,20 +509,22 @@ createEntityWorker(world, { type: 'ship', x: 100, y: 150 }, callbacks);
 
 `createEntityWorker` layers your overrides over the `ship` template, mints a unique id from a shared atomic
 counter (so it never collides with one the main thread or another worker hands out), and for each component
-the merged config triggers, pushes a block into its pool and writes the values - all off-thread. It reports
+the merged config triggers, pushes a block into its pool and writes the values - all off-thread. With entity
+classes registered, the worker also resolves the template's class and considers only its allowed components. It reports
 back an id-plus-block-indexes descriptor; when the run completes the main thread *adopts* it, building the
-always-present `entity` component there (interning the `type` is a main-thread job) and wrapping each block the
-worker wrote - no block is copied or re-allocated. Like every other worker report-back, the new entity first
+always-present `entity` component there (interning `type` and `class` is a main-thread job), asking the factory
+for the registered wrapper, and attaching each block the worker wrote - no block is copied or re-allocated. Like
+every other worker report-back, the new entity first
 exists on the following frame, so the system picks it up next run.
 
 Two things make this work, both opt-in so only the workers that create entities pay for them:
 
 - Register the system with `createsEntities: true`. That ships the factory templates to its worker on load.
-- In that system's worker entry, pass your component registry to `createComponentWorker`, so the worker has
+- In that system's worker entry, pass your component registry to `createEntitySystemWorker`, so the worker has
   each component's block builder:
 
   ```ts
-  createComponentWorker(self, shipUpdate, registry);
+  createEntitySystemWorker(self, shipUpdate, registry);
   ```
 
 Every component is already defined as two halves for exactly this — `toBlock(config)` (the block values) and
@@ -436,9 +546,48 @@ const shipHealth: ComponentDefinition<HealthComponent, Int32Array, HealthConfig>
 };
 ```
 
-This runs identically on the main-thread fallback. Two current limits: a `loadInFinishLoading` component (one
-that reads other entities) is skipped, since the worker has no world to read; and an adopted entity is always
-the base `BaseEntity` - a factory per-type subclass is not applied to it.
+This runs identically on the main-thread fallback. A `loadInFinishLoading` component (one that reads other
+entities) is skipped, since the worker has no world to read. A worker does not receive constructors; it returns
+the serializable class key, and the main-thread factory constructs the wrapper during adoption.
+
+### Adding and removing components at runtime
+
+On the main thread, use the entity directly:
+
+```ts
+ship.loadComponent('shield', { capacity: 100 });
+ship.removeComponent('shield');
+```
+
+Both operations notify every system. Required and excluded (`not`) queries change membership as needed. An
+entity already present through other required components is re-sent to worker systems too, so their cached
+component bundle gains or loses an optional component on the next run.
+
+Inside an update function, use the worker helpers instead. They record structural changes without changing the
+component snapshot currently being iterated:
+
+```ts
+import { addComponentWorker, removeComponentWorker } from '@daneren2005/shared-memory-ecs/worker';
+
+if(equippedShieldGenerator && !components.shield) {
+	addComponentWorker(world, entityId, 'shield', { capacity: 100 }, callbacks);
+} else if(!equippedShieldGenerator && components.shield) {
+	removeComponentWorker(entityId, 'shield', callbacks);
+}
+```
+
+The main thread applies those commands after the worker run completes, emits the normal component-added or
+component-removed event, and queues query deltas. The originating run therefore keeps a stable snapshot and all
+systems see the new structure no later than their next run. Removing a component uses the same deferred-free
+safety described below.
+
+Worker-side addition needs two opt-ins because it allocates a block:
+
+- Set `addsComponents: true` on the `EntityWorkerSystem`.
+- Pass the component registry to that system's `createEntitySystemWorker(self, update, registry)` call.
+
+`addComponentWorker` calls the definition's worker-safe `toBlock(config)` and cannot add the always-present
+`entity` component or a `loadInFinishLoading` component. Worker-side removal needs no allocation opt-in.
 
 ### Freeing component memory safely
 
@@ -485,6 +634,35 @@ It is deferred to the same safe point as the component's own block (see above),
 entity dies — so a system still mid-run over that memory can't see your resource released early. Reload calls
 it without any `death` event, so it is the reliable place to avoid leaks when a world is reused.
 
+### Reacting to death
+
+To *react* when an entity dies — spawn drops at its position, credit a kill, play an effect — a component
+definition can carry an optional `died(component, entity, world)`. It fires exactly once per death, on the main
+thread, with the dying entity **still fully readable** (its blocks are only *deferred*-freed, never torn down
+before the hook runs), for both a worker kill (`killEntityWorker`) and a main-thread `killEntity`:
+
+```ts
+const oreDepositDefinition: ComponentDefinition<OreDeposit, Int32Array, OreDepositConfig> = {
+  type: Int32Array,
+  size: 3,
+  loadProperties: ['oreAmount'],
+  toBlock(config) { /* ... */ },
+  attach(entity, memory, index) { /* ... */ },
+  died(component, entity, world) {
+    // The asteroid is still readable here, so spawn its drop where it was.
+    const { x, y } = entity.components.position!;
+    world.loadEntity({ type: 'Ore', x, y, amount: component.oreAmount });
+  },
+};
+```
+
+The hook is engine-agnostic: attach death behavior to the component that represents it. A throwing `died` can't
+abort the death — it is caught and surfaced as a `system-error` event (`phase: 'died'`) while the entity is still
+removed. Unlike `free`, `died` fires **only** on a real death, never on `world.load()`/`clear()` teardown.
+
+For a non-declarative hook, the world also emits `world.on('entity-died', entity)` at the same point (distinct
+from `entity-removed`, which fires for every removal, reloads included).
+
 ### Reusing a world: `load` and `clear`
 
 A world is meant to be reused rather than rebuilt. `world.load(config)` swaps in a fresh scenario — it removes

package/dist/actions/add-component-worker.d.ts

@@ -0,0 +1,3 @@
+import type { ComponentMap } from '../component-definition';
+import type { EntityWorkerSystemCallbacks, EntityWorkerSystemWorld } from '../systems/entity-worker-system';
+export default function addComponentWorker<C extends ComponentMap, K extends keyof C>(world: EntityWorkerSystemWorld, entityId: number, componentName: K, config: Record<string, unknown>, callbacks: EntityWorkerSystemCallbacks<C>): void;

package/dist/actions/build-worker-entity.d.ts

@@ -1,4 +1,5 @@
-import type { WorkerAllocator, WorkerCreateEntityConfig, WorkerCreatedEntity } from '../systems/component-system';
+import type { WorkerAllocator, WorkerCreateEntityConfig, WorkerCreatedComponent, WorkerCreatedEntity } from '../systems/entity-worker-system';
+import type { WorkerEntityClassRegistry } from '../entity-class';
 export interface WorkerCreatableComponent {
     loadProperties: Array<string>;
     loadInFinishLoading?: boolean;
@@ -10,4 +11,5 @@ export type WorkerCreateRegistry = {
 export type FactoryConfigs = {
     [type: string]: Record<string, unknown>;
 };
-export declare function buildWorkerEntity(config: WorkerCreateEntityConfig, factoryConfigs: FactoryConfigs, registry: WorkerCreateRegistry, allocator: WorkerAllocator): WorkerCreatedEntity;
+export declare function buildWorkerEntity(config: WorkerCreateEntityConfig, factoryConfigs: FactoryConfigs, registry: WorkerCreateRegistry, allocator: WorkerAllocator, classes?: WorkerEntityClassRegistry): WorkerCreatedEntity;
+export declare function buildWorkerComponent(name: string, config: Record<string, unknown>, registry: WorkerCreateRegistry, allocator: WorkerAllocator): WorkerCreatedComponent;

package/dist/actions/create-entity-worker.d.ts

@@ -1,2 +1,2 @@
-import type { ComponentSystemCallbacks, ComponentSystemWorld, WorkerCreateEntityConfig } from '../systems/component-system';
-export default function createEntityWorker(world: ComponentSystemWorld, config: WorkerCreateEntityConfig, callbacks: ComponentSystemCallbacks): void;
+import type { EntityWorkerSystemCallbacks, EntityWorkerSystemWorld, WorkerCreateEntityConfig } from '../systems/entity-worker-system';
+export default function createEntityWorker(world: EntityWorkerSystemWorld, config: WorkerCreateEntityConfig, callbacks: EntityWorkerSystemCallbacks): void;

package/dist/actions/kill-entity-worker.d.ts

@@ -1,2 +1,2 @@
-import type { ComponentSystemCallbacks, EntityUpdateComponents } from '../systems/component-system';
-export default function killEntityWorker(entityId: number, components: EntityUpdateComponents, callbacks: ComponentSystemCallbacks): void;
+import type { EntityWorkerSystemCallbacks, EntityUpdateComponents } from '../systems/entity-worker-system';
+export default function killEntityWorker(entityId: number, components: EntityUpdateComponents, callbacks: EntityWorkerSystemCallbacks): void;

package/dist/actions/remove-component-worker.d.ts

@@ -0,0 +1,3 @@
+import type { ComponentMap } from '../component-definition';
+import type { EntityWorkerSystemCallbacks } from '../systems/entity-worker-system';
+export default function removeComponentWorker<C extends ComponentMap, K extends keyof C>(entityId: number, componentName: K, callbacks: EntityWorkerSystemCallbacks<C>): void;

package/dist/component-definition.d.ts

@@ -2,6 +2,7 @@ import type { TypedArrayConstructor } from '@daneren2005/shared-memory-objects/i
 import type MemoryComponent from './memory-component';
 import type { ComponentTypedArray } from './memory-component';
 import type BaseEntity from './entity';
+import type BaseWorld from './world';
 import type { EntityComponent, EntityComponentConfig, EntityComponentSerialization } from './entity-component';
 export interface BaseComponent {
     index: number;
@@ -17,6 +18,7 @@ export interface ComponentDefinition<Component extends BaseComponent, T extends
     attach(entity: BaseEntity, memory: MemoryComponent<T>, index: number): Component;
     save?(component: Component): Serialization;
     free?(component: Component): void;
+    died?(component: Component, entity: BaseEntity, world: BaseWorld): void;
 }
 export type RegisteredComponentDefinition<Component extends BaseComponent, T extends ComponentTypedArray = ComponentTypedArray, Config = any, Serialization = object> = ComponentDefinition<Component, T, Config, Serialization> & {
     memoryComponent: MemoryComponent<T>;