Differences

This shows you the differences between two versions of the page.

--- ecs-core-overview [2026/04/27 15:42] – [Data Model] diviner
+++ ecs-core-overview [2026/08/16 15:11] (current) – diviner
@@ Line 4: / Line 4: @@
 * **Data Model**
-  * Runtime State
-    * [[Entity]]
-    * [[Component]]
   * Static State
     * Entity Static Data
     * Component Static Data
     * System Static Data
+  * Runtime State
+    * [[IEntity]]
+    * [[Component]]
 * **Business Logic**
   * Services
@@ Line 25: / Line 25: @@
 The architecture defines two different types of Static State: EntityStaticData (and its dependent ComponentStaticData) and SystemStaticData.
-The EntityStaticData defines instructions for the [[IEntityFactory]] used to generate a type of Transient Runtime State called [[Entity]] (described below). From the same EntityStaticData configuration, multiple Entities can be instantiated. There can also be multiple different EntityStaticData serialized files, each configuring a different type of [[Entity]]. The EntityStaticData class is sealed and concrete. The way it defines different behaviors for different Entities is via composition, by a populated ComponentStaticData array. ComponentStaticData cannot exist on its own, it only makes sense as an entry to an EntityStaticData's Component collection, and each ComponentStaticData needs an implementation. For example, the [[ITransformComponentStaticData]] defines an Entity that has a Transform, and by extension can have a position and rotation in 3D space, as well as be part of Transform hierarchies. EntityStaticData without this specific ComponentStaticData will lack this capability.
+The EntityStaticData defines instructions for the [[IEntityFactory]] used to generate a type of Transient Runtime State called [[IEntity|Entity]] (described below). From the same EntityStaticData configuration, multiple Entities can be instantiated. There can also be multiple different EntityStaticData serialized files, each configuring a different type of [[IEntity|Entity]]. The EntityStaticData class is sealed and concrete. The way it defines different behaviors for different Entities is via composition, by a populated ComponentStaticData array. ComponentStaticData cannot exist on its own, it only makes sense as an entry to an EntityStaticData's Component collection, and each ComponentStaticData needs an implementation. For example, the [[ITransformComponentStaticData]] defines an Entity that has a Transform, and by extension can have a position and rotation in 3D space, as well as be part of Transform hierarchies. EntityStaticData without this specific ComponentStaticData will lack this capability.
 Unlike EntityStaticData, SystemStaticData is meant to be implemented by concrete implementations and cannot exist as is. Each implementation can only have one serialized file, and the implementation is registered by the dependency injection framework as Singleton. Therefore every reference to the same SystemStaticData always points to the same object, and that singleton instance can be injected via constructor injection. Where EntityStaticData define Entities and their behaviors, SystemStaticData usually act as configuration files for specific systems and services (hence their name).
@@ Line 31: / Line 31: @@
 === Runtime State ===
-Runtime state is any state created during the lifetime of the Application. As such, it can be any class necessary to service the business logic. However, there is one structure that is treated exceptionally by the architecture: the [[Entity]]. The following diagram showcases how an [[Entity]] structure is composed.
+Runtime state is any state created during the lifetime of the Application. As such, it can be any class necessary to service the business logic. However, there is one structure that is treated exceptionally by the architecture: the [[IEntity|Entity]]. The following diagram showcases how an [[IEntity|Entity]] structure is composed.
 {{ :2026-04-27_17h50_45.png?669 |}}