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 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

• Understanding Entity-Component-Systems - the source of a hierarchical class diagram
• artemis-odb-contrib Wiki: Event Bus
• Naturally Selected 2D - a Ludum Dare game made by DaanVanYperen
• artemis-odb: Game Gallery
• T-machine.org: Entity systems are the future of MMOG development
• Cowboy Programming: Evolve Your Hierarchy