LunarCast Network
LunarCast [Home] [Replays] [Netplay] [Files] [Settings]
Maidens of the Kaleidoscope [Forum] [Forum Archive]
Gensokyo Archive [Gallery] [Replays] [Patches]

Entity Component Interface System

A new way to design component systems

What is this:
Revisiting the classical Entity Component Systems featured in many game engines with a new concept, Interfaces.

The flaws of existing systems:
Some flaws commonly seen in ECS implementations are exposing components as raw data making it difficult to change the underlying component structure, second it assumes or likes to assume that each component has one system, however in practice each system controls multiple components, one bearing the name of the system and others with related data, how are you supposed to classify these ? home and "roaming" components? Also sometimes for the sake of performance its better to split a component into smaller components with related data however still be under 1 system.

[Flaws of the ECS System diagram]
In the above diagram, we have an example entity, the Curved Laser which has Transform, Movement and Texture2D components among others.

  • Certain components do not requried Systems. A prime example is the Transform Component and System, because all the Transform component does is store the position of an Entity in world space, it does not need to be updated and does not need a system.
  • The movement system is also problematic, as it utilizes both the Transform and Movement components. Is the component with the same name as the system "special" in any way towards it? Is that the "Home" component and the others are "Roaming" or "Guest" components?
  • The Texture2D Component which like the Transform Component does not have a system, however it is used by the Render System, which is able to render entities bearing both a Texture2D and UVMesh Component or a RGBAMesh component, none of which have System bearing their name but are used exclusively by the Render System.
  • Many ECS systems expose the structure of the Components to the rest of the code, as it has to interface both with individual components by setting their values and with the systems themselves for performing operations involving multiple (or all) entities and components.


The solution to the issues of the ECS system is the Entity Component Interface System or ECIS, which completely decouples components from their "manager" systems and the game code from the Systems.

The Entity Component Interface System redefines the meaning of components and systems:
  • Components are primarily bundles of tightly coupled data which give an entity a trait or property. Additionally Components are the common denominator of duplicated data between two components. (Example: Movement and Collider both need a position, instead of duplicating the position data it is separated into a standalone component that both utilize.)
  • Systems perform continuous or on-demand global actions on a specific set of components and are not coupled to a specific component. (Example: The Motion System operates on the "Movement" and "Transform" components continuously to provide movement, and also has on-demand functions to slow/stop all entities.) If an entity does not have the correct set of compatible components the system simply ignores it.

The Entity Component Interface System defines and additional concept:
  • Interfaces are bundles of logically related functions for interacting with a particular concept the ECS system supports. (Example: The Movement & Motion Interface provides functions for setting and changing an individual object's velocity and also for slowing or accelerating all objects) (Additional example: The Position Interface provides functions for setting and retrieving an Entity's transform)


  • [ECIS architecture diagram]

    Return to Home