Entity component system, basics

Entity Component System (ECS) - very popular architecture for developers, who wants to avoid hell of “rewrite all code” cases when new mechanics was added or removed and moves to flexible and expandable solution without performance penalties. What are main features of ECS?

Entity Component System (ECS) - very popular architecture for developers, who wants to avoid hell of “rewrite all code” cases when new mechanics was added or removed and moves to flexible and expandable solution without performance penalties. What are main features of ECS?

ECS based on 3 main terms: entity, component and system (it’s obvious from architecture name).

Entities

Entity - any object in game. For example, it can be playable unit, ui button, event message from one system to another, etc. Entities haven’t properties but can contains them - works as containers for components.

Components

Main idea of ECS - moving from Inheritance to Composition in OOP. No more pain in attempt to mix different behaviours and stitch one class for them. Instead of this we splits properties for separate isolated blocks (Components) for builds entities with required complex behaviour later:

Components have no logic and contains properties (data) only.

Systems

But we can’t create behaviour with data only, we need some logic blocks for component’s processing. And we have Systems for this - blocks of code, that can process components attached to entities which were filtered with some conditions.

Systems don’t contains any local data or references to specified entities: they can only process list of entites with one behaviour (for which this system was developed) - it’s all what any System can do.

Entities, components, systems - why so complex? With ECS we can split any complex behaviour for small atomic parts for easier testing, adding and even removing new game mechanics without crashing all other exist parts.

But wait, we already have such system in Unity, right? What differences between Unity components and ECS? Unity components - it’s not ECS, but EC:

  • GameObject => ECS Entity.
  • MonoBehaviour => ECS Component + ECS System (we can name it just Component).

If we will create 10000 game objects with some simple behaviour (implemented inside MonoBehaviour) - performance of this test will be not bad enough, it was described by Unity developers. If we moves to Managers as suggested in article - we will get ECS with some constraints. So, if we will move from simple to complex, we will get something like this: MonoBehaviours -> Managers -> ECS.

Ready to use solutions

One of the most popular solutions for Unity is Entitas (entitas ported to another code languages and engines). Very huge and complex project that tries to simplify programmer life with automatic generation of tons of wrapper classes for easier data manipulation. This is main positive and main negative feature at same time. Runtime code size - 0.5Mb, wrapper generation + editor integration - 3Mb.

Unity developers now in active development of built-in ECS solution that should be released in this year. Well… As usual, no fixed deadlines, UT can’t releases any version and names it as Stable - no news here. We should wait another year after release for fixing all critical issues in new ECS, it means - builtin solution still not exists.

Code generation and code size up to 3.5Mb - not my way. And I’m very lazy to learn how Entitas works inside - I made decision to create my own ECS from scratch - fat free and with small memory footprint at editor and runtime. Maybe I will write some posts anout this ECS next time.