Entity
The Entity
is the main data structure when working with an ECS.
An Entity
has a unique identity - Id
- and acts as a container for components, tags, script and child entities.
An EntityStore
is a container of entities and used to create entities with store.CreateEntity()
.
Entities can be deleted with entity.DeleteEntity()
.
Variables of type Entity
mimic the behavior of reference types.
Using an entity method on a deleted entity throws a NullReferenceException
.
To handled this case use entity.IsNull
.
Entities can be disabled.
Disabled entities are excluded from query results by default.
To include disabled entities in a query result use query.WithDisabled()
.
Entity example code is part of the unit tests see: Tests/ECS/Examples.
When tying out the examples use a debugger to check entity state changes while stepping throw the code.
Examples showing typical use cases of the Entity API
EntityStore
An EntityStore
is a container for entities running as an in-memory database.
It is highly optimized for efficient storage fast queries and event handling.
In other ECS implementations this type is typically called World.
The store enables to
create entities
modify entities - add / remove components, tags, scripts and child entities
query entities with a specific set of components or tags
subscribe events like adding / removing components, tags, scripts and child entities
Multiple stores can be used in parallel and act completely independent from each other. The example shows how to create a store. Mainly every example will start with this line.
Component
Components
are struct
s used to store data on entities.
Multiple components with different types can be added / removed to / from an entity.
If adding a component using a type already stored in the entity its value gets updated.
Result of entity.DebugJSON
:
Unique entity
Add a UniqueEntity
component to an entity to mark it as a "singleton" with a unique string
id.
The entity can than be retrieved with EntityStore.GetUniqueEntity()
to reduce code coupling.
It enables access to a unique entity without the need to pass an entity by external code.
Info Since version 3.0.0 there is more flexible and performant alternative available by using a Component Index. It supports defining a custom
IIndexedComponent<>
type and have several advantages:
The unique key can be of any type - e.g.
int
,Guid
,enum
,string
, ... . The key of unique entities is always astring
.The storage of a Component Index is optimized for low memory footprint and fast lookup.
Additional fields can be added to an
IIndexedComponent<>
type.
Tag
Tags
are struct
s similar to components - except they store no data.
They can be utilized in queries similar as components to restrict the amount of entities returned by a query.
If adding a tag using a type already attached to the entity the entity remains unchanged.
Clone / Copy entity
The methods Entity.CloneEntity()
and Entity.CopyEntity(Entity target)
are used to copy all components and tags from one entity to another.
CloneEntity()
creates a new entity having the same components and tags as the original entity.CopyEntity(Entity target)
copy all components and tags to the giventarget
entity. The target entity can be in the same or in a different store.
The example creates a new entity with the same components and tags as the original entity.
CopyEntity(Entity target)
can be used to copy a subset or all entities of one store to another store.
The entities in the target store will have the same entities ids as in the original store.
Script
Script
s are similar to components and can be added / removed to / from entities.
Script
s are classes and can also be used to store data.
Additional to components they enable adding behavior in the common OOP style.
In case dealing only with a few thousands of entities Script
s are fine.
If dealing with a multiple of 10.000 components should be used for efficiency / performance.
Script
s enable to override
their Start()
and Update()
.
These methods need to be called manually. The ECS has no build mechanism to execute these methods.
The ECS provide only access to all scripts added to entities of an EntityStore
.
E.g. Executing Update()
of all scripts in a store use:
Hierarchy
A typical use case in an Game or Editor is to build up a hierarchy of entities.
To add an entity as a child to another entity use Entity.AddChild()
.
In case the added child already has a parent it gets removed from the old parent.
The children of the added (moved) entity remain being its children.
If removing a child from its parent all its children are removed from the hierarchy.
Archetype
An Archetype
defines a specific set of components and tags for its entities.
At the same time it is also a container of entities with exactly this combination of components and tags.
Explanation An
Archetype
instance corresponds to an SQLTABLE
where its components are the counterpart of the table rows. In contrast to tables archetypes are created automatically on demand. A relational database requires to create tables upfront.
The following comparison shows the difference in modeling types in ECS vs OOP.
Inheritance ECS does not utilize inheritance. It prefers composition over inheritance.
Common OPP is based on inheritance. Likely result: A god base class responsible for everything. 😊
Code coupling Data lives in components - behavior in systems. New behaviors does not affect existing code.
Data and behavior are both in classes. New behaviors may add dependencies or side effects.
Storage An Archetype is also a container of entities.
Organizing containers is part of application code.
Changing a type Supported by adding/removing tags or components.
Type is fixed an cannot be changed.
Component access / visibility Having a reference to an EntityStore enables unrestricted reading and changing of components.
Is controlled by access modifiers: public, protected, internal and private.
Example
Performance
Runtime complexity O() of queries for specific types O(size of result set)
O(size of all objects)
Memory layout Continuous memory in heap - high hit rate of L1 cache.
Randomly placed in heap - high rate of L1 cache misses.
Instruction pipelining Minimize conditional branches in update loops. Process multiple components at once using SIMD.
Virtual method calls prevent branch prediction.
JSON Serialization
The entities stored in an EntityStore can be serialized as JSON using an EntitySerializer.
Note Currently serialization / deserialization only support struct fields - properties not. See Issue #28. Component and relation types are required to be struct's.
Writing the entities of a store to a JSON file is done with WriteStore()
.
Reading the entities of a JSON file into a store with ReadIntoStore()
.
Following attributes can be used to customize JSON serialization
[ComponentKey("data")]
- the attributed componentstruct
uses"data"
as component key[Ignore]
- the attributed component field is ignored[Serialize("n")]
- the attributed component field uses"n"
as JSON key
The JSON content of the file "entity-store.json"
created with serializer.WriteStore()
Last updated