Why Entity Component Systems matter?

Forget about Object-Oriented Programming. Look at this flat world built of small data chunks and separated logic. A world easy to refactor. Meet Entity Component Systems.

What is ECS?

It’s an architecture used mostly for game development. It’s slowly becoming more and more common in this industry.

Entity Component Systems architecture consist of:

  1. Component is pure data without functionality/logic
  2. System works on top of Entities having per-system-specified Components, implements logic
  3. Entity is just a bag of Components

Data kept only in Components is a straight path to flatness.

Reason: easier refactors

ECS architecture is strongly advised to be used to develop games because of frequent need for refactoring (because it’s hard to foresee which ideas are fun and there is not a lot of usability in games). Thus, you don’t need dilemmas like down below:

class hierarchies are bad!

Class hierarchies are essentially bad because it’s what makes people refactoring reduntantly. We should refactor because of changes into functionality requirements, less because of a code structure. With only components and systems it’s usually a matter of splicing or joining components or splicing/joining systems. Why is that simple? Because data and logic are not mixed.

→ Logic code does not define the data, only the data defines which logic parts will be executed.

Only gamedev?

Well, not really. But mostly, ideally, yes.

  1. Component contains just the data – you could call it ValueObject or DataSource or whatever.
  2. Entity is just a bag of Components but ideally – just an ID like an ID for a row in relational database.
  3. System contains update(float deltaTime)  method which is mostly about time-sensitive processing of data. Games or some realtime audio processing, perhaps? (actually I’ve read once about such audio system somewhere)

So, focusing on the core concept of data and separately operating on the data you could bring few other architectures, like CQRS / redux / Elm. The missing part would be messaging. But wait, it’s not OOP, remember? Entities do not communicate or behave! Data does not behave. Systems do. A pretty useful Event Bus exists in artemis-odb-contrib project.

Pros – OK. What Cons?

To me, it seems a little harder to reason about what we implement just by looking at list of components. For instance, let’s look at this list of components:

Lots of data, not really telling a story. And that’s actually not that weird because data is separated from behavior. Let’s look for behaviour then – in systems of the same project:

This doesn’t tell any story yet but helps figuring out which bag of classes does what.

For instance, render folder contains those classes:

Now we know what’s rendered in the game! That’s huge.

At first you may think that a big list of all systems in one folder could bite you. However, if you split your code files by feature then it is the same level of complexity as in any other project.

Experimenting is good but…

Wait, no! It’s not just a matter of experiments. It’s been used even in MMO games. There’s this popular “source of truth” about ECS → T-machine.org: Entity systems are the future of MMOG development – explaining how important it is for game development.

It’s really hard to forget about OOP. But once ECS clicks into your mind, frequent redesign is going to be nice and comfortable. If you need a “real life” comparison of learning curve then it’s a lot easier to overcome ECS approach than functional programming paradigm.

How to learn it? Start by staring at projects made with artemis-odb.

Resources

  • Great article. It’s interesting to see that all that OOP revolution is now returning to times before OOP. I see that it’s also connected to functional programming paradigm where data & functions are independent.

    • Yeah, totally agree. OOP in it’s popular concept of fields+methods is a huge simplification of real world which totally doesn’t help in software engineering + development.

  • Piotr Aleksander Chmielowski

    Interesting article. But as a side note: in OOP we also have a tool to keep the class hierarchy flat – it is called “composition over inheritance rule” and it simply states that it is forbidden to extend classes.

    • Yes, and ECS is all about this rule. Assuming you still want DRY and there are multiple types of entities behaving similiarly but differently to some degree. Then you end up with separated data and behavior, right?

  • Pingback: Artemis Entity Tracker – inspecting your game state through network – NamekDev()

  • Pingback: Exploring directions to fix game programming – NamekDev()