A Critique of the Entity Component Model

Interesting article. I am working with entity component model lately and so far I am more satisfied with it than with OO. It needs a lot of mental adjustments to understand how to design the game differently.

 

Anyway, I want to point out one thing. When you remove components from the flow and store all data in the entities, you are losing some important features - shared and/or reusable data.

 

Components as the smallest data unit can be easily shared among other entities. That means you save some memory and also some processing time, because changing component in one entity makes that change applied to all other entities that contain this component. That can be very useful in some scenarios.

 

For example you want your weapons to have all the same base stats. You can create one component with that and assign the reference to all weapons created. Later you may decide that all these weapons need little tweak on one stat, so you just change it in that one component and it's all good. If you need one weapon to be special and stand out, you give it just its own component with own stats.

 

Other feature I have mentioned is reusable data. This can be handy for example for positioning. Instead of having like 10 components with the same X,Y,Z just because there is more items on that very spot, you can simply share one component among them. Other use is for pooling where entity gets removed, but some frequently used components can be stored in stack and reused for new entity. Garbage collector will be more happy this way, less mess to clean up and smaller overhead in creating those objects all over again.

FredyC, maybe I am reading your post wrong, but your entities should not share the same instance of your components. If the property of component changes at run-time, it it would change for all the entities that have a reference to it, would probably would not be desired in most games.

 

For the example you gave where you want to change the stats of an item, that would just be changing the stat in code or config, and anyone who creates an instance of that item would have the new stat. Unless you want to change that stat at runtime, but again this would not be the way to handle that.

----

 

For the me the component entity model makes things easier because you have systems that manage the relationships between entities, and the world. The components themselves are just a set of properties, and all the logic an interactions are managed in the systems. When all the logic is contained in the entities themselves, then it gets tricky as they need references to the map and the rest of the world to handle all the interactions.

I think you are reading it correctly, although I didn't meant to share all the components. It's per case and if it desired by design. I just wanted to point out, that by removing components completely, you are losing this possibility, because each entity needs to have own copy of data.

The article is well-written but in my opinion is kind of vague and speculative..

 

Both OOP and ES approaches can solve _most_ games in arguably the most efficient way.. I guess they are both perfectly valid in many aspects. But there is a reason people are tending to change into ES progressively. It compromises speed in some cases but is always a more powerful and flexible solution if done right. I've even seen implementations where ES performs better!

 

As the OP said, choose the tool right for the task. In most cases, either of the approaches will probably do. But you can hardly get it wrong with a good ES, imo.

Hmm, I agree with the first paragraph of the article, but not much of the rest!

 

Firstly, there's no requirement to create a bunch of hierarchies, one per component type (eg. movement, attack). There's no real reason why you need a different interface in each of those cases. There are situations where you think you might benefit from one - eg. compile-time binding of intra-component dependencies - but it's not mandatory. And if you move away from rigid type systems like C++ or Java, you don't need it at all. It's 2014; you don't have to treat scripting languages as a magic wand you wave at the end of an article.

 

Secondly, the whole systems/duck typing thing makes no sense. If you know you need to query for a renderMesh, you could look that up by name, or by type, or by registering it with an observer pattern, etc. There are many ways to join that up without requiring that the GraphicsSystem looks it up strictly by the property name. And really you've not removed useless components; the renderMesh is the component. You just have the processing logic elsewhere. And that's how a lot of people like to make these systems. Ultimately, having a rendering system inspect your data to find a renderMesh is equivalent, both in terms of the toolchain used and the results produced, as adding in a component derived from a Renderable interface. You swap out those objects to change the behaviour.

 

Thirdly, you cite a 'very clever' implementation of the entity component system, that was vaunted to be superior for MMOs. The series of articles you cite, though strangely popular, is also strangely vague on implementation, seriously mischaracterises object-oriented programming, does not make a solid case for why it is better, and in fact I'd be surprised if anybody is using it in a production setting. Most MMOs do not want to be reading and writing to a database that often. It's true that many MMOs will split processing tasks across multiple servers, but generally it's both necessary and desirable to have a central process that mediates everything rather than trying to enforce an entity's segregation in impractical ways. 90% of the problems people encounter with components are trying to get them to work together adequately, and handling different components on different servers just ratchets up the pain there by a large margin.

 

I agree that component-based systems have become a strange fad that ask more questions than they answer. But I think you're criticising the wrong aspects, and not really suggesting a concrete solution.

Nice to see an article taking the other side the Entity Component System (ECS).  I have been meaning to make a post asking people how they feel about the ECS now since Scott Bilas started talking about it way back when.  I bought into the concept and armed with my hammer started to look for nails, if you get my meaning...

 

Eventually the Kool-Aid wasn't what I thought and I trashed the ECS and went back to more traditional methods and just got things done again. So much time was spent trying to make the ECS work and very little time getting game features done. 

 

Composition can be used within a Entity without going with a full blown ECS.  An Entity that 'has a' model works fine.  Make the model an interface if you need to. Is making the everything engine for the everything game your target?  Are writting you middleware? If not then just move on and get things done.

 

The sharing data/properties isn't really part of the scope for this article or ECS really.  An Entity can have a master prototype that defines all the const data for it.  One method can have these values copied to the instance when created (fire and forget).  Another method might hold a delta from it's prototype (think of lua tables going to it's index meta method when a value isn't found). 

 

I'm not saying that ECS are wrong or bad as I have never shipped a game with one.  I just tend to wonder.  Also is it just me or does the pitch for an ECS sound like the pitch that RAD tools used to use? "Look how fast you can make a calculator!"  Amazed you go home only to realize, ah, I'm not making a calculator...

I think you have some typos.  The Flying Goblin class is named FylingGoblin instead of FlyingGoblin.

 

Melee is spelt with three 'e'

I am also glad to see an article that is questioning entity component systems. I am curious why people say it is entity-component vs OOP since and entity component system is a design pattern that uses OOP.

 

I am not 100% certain about all of the critiques but my take away from the article is don't waste your time trying to build a system like everyone else uses. Build a system that gets the job done. Whether it is 'OOP' or ECS, build what you need to finish your game.

While I'd be the first to agree that a lot of people use (or overuse) component-based implementations of entity systems, I don't think this article does a very good job *at all* of addressing any of the actual subtleties of the problems inherent in them. Everything is painted in extremely broad strokes, often choosing rather poor fundamental examples of component-oriented (or more generally aggregation-over-inheritance) designs, making assumptions that those are the only ways to implement such a system, and then making logical leaps to very complex implementations to illustrate how "bad" this is.

There is a library that gives you such duck typing in C++ allowing you to have a middle ground decision if you don't want to sacrifice the performance when you use a scripting language.

The library is made for the Boost collection, but it's not a part of it yet. It's pending review.

Docs link: http://ibob.github.io/boost.mixin/
Source link: https://github.com/iboB/boost.mixin

I think you have some typos.  The Flying Goblin class is named FylingGoblin instead of FlyingGoblin.

 

Melee is spelt with three 'e'

 

Yeah. Also "allot" isn't a word that means "many."

 

I also think that "funny" commentary like the "did you just describe MVC" and the "oh wise one" quips detract from the otherwise serious nature of the article.

Having used an entity component system in a few medium-sized projects, I have some opinions here.

 

First of all, you make some statements I do agree with: An ECS isn't necessary to solve the "dreaded diamond pattern", and it also certainly isn't necessary in order to be able to instantiate objects based on a description in a text file (although it probably makes it easier).

 

The rest of your article kind of wanders away from ECS criticism though (indeed, the second half doesn't really seem to have much to do with ECS). And the few criticisms you make, I don't agree with or don't understand.

 

Good job, now we went from one anti-pattern (deep inheritance hierarchy) to a different anti-pattern (wide inheritance hierarchy). The central issue is that the inheritance hierarchy tries to incorporate orthogonal concepts and that is never a good idea.

 

 

 

 

I'm not really sure what you see as the problem with a wide inheritance hierarchy. Yes, orthogonal concepts are grouped together under a single Entity. That's kind of the point though. Logic (in the systems) operates on individual components though, so I don't see the problem.

 

 

Putting the structural criticism aside, a naive implementation of the entity component model can in no way be efficient. 

 

 

 

That's true for pretty much anything.

 

 

The simplest way to resolve the issue, without altering the design too radically, is the introduction of systems. In this case the actual implementation is within the systems and the components are just indicating the desired behaviour. The result is that a system has all the relevant data in a very concise and compact format and as a result can operate quite efficiently. But if you look closely you can see that we have all these useless components.

 

 

A minor point: technically, the introduction of systems doesn't necessarily allow or restrict where components can be stored. You could store them in compact per-type arrays even without systems, and even with systems you could store different component types right of the entity.

 

"We have all these useless components": I don't understand what you mean by this.

 

 

In my usage of an ECS, these are some problems I think are actually issues:

 

- Debuggability. It becomes more difficult to identify objects in the game world (e.g. is the the player character? I have no idea, all I'm looking at right now is a meshcomponent that is being interpreted by the graphics system). It's more difficult to put a breakpoint and step through the logic applied to a particular entity. 

- "Communication between components". That's in quotes, because components don't really communicate between each other, given that logic tends to exist in the systems instead. So what I'm getting at is that while it is nice to think you have pieces of isolated code each each system, sometimes they do need information from each other. An example would be where one system is responsible for organizing entities into a data structure that allows for quick retrieval/search based on position, and other systems need to access this data. The important thing to remember though, is that ECS is not an alternative to other design patterns - it works with them. Use the right abstraction where you need it.

- Most systems operate over more than one component. Often, performance is a stated goal of ECS implementations: operating on one piece of code logic at a time on one type of data which is stored in a contiguous chunk of memory can help avoid cache misses. However, when a system needs process multiple components on an entity (e.g. Physics and Position, say), this theoretical performance benefit can be lost, since sequential access in one component array may mean random access the other component array.

 

 

Here are some areas where I think ECS shines:

 

It really encourages complete separation of concerns. Systems only look at the components they need - they just touch the data they're interested in. The result is that you end up with small pieces of independent logic that comprise your game. This makes it very easy to change parts of your code without risking breaking other parts.

 

An ECS creates friction against writing big monolithic spaghetti code or creating unnecessary dependencies, thus encouraging you to refactor/organize things in a better way.

 

It really discourages code duplication, since you are encouraged to create component/systems for any pieces of reusable logic - and thus that same logic is easily applied to any entity. Less code equals less bugs, period. 

 

The bigger and more complex your game becomes, the more these benefits will become apparent. I find I can get more done with less code when using an ECS, as opposed to "traditional OOP", and I spend a lot less time fixing bugs.

Here are some areas where I think ECS shines:

 

It really encourages complete separation of concerns. Systems only look at the components they need - they just touch the data they're interested in. The result is that you end up with small pieces of independent logic that comprise your game. This makes it very easy to change parts of your code without risking breaking other parts.

 

An ECS creates friction against writing big monolithic spaghetti code or creating unnecessary dependencies, thus encouraging you to refactor/organize things in a better way.

 

It really discourages code duplication, since you are encouraged to create component/systems for any pieces of reusable logic - and thus that same logic is easily applied to any entity. Less code equals less bugs, period. 

 

The bigger and more complex your game becomes, the more these benefits will become apparent. I find I can get more done with less code when using an ECS, as opposed to "traditional OOP", and I spend a lot less time fixing bugs.

 

I think this is very nice summary. I just would like to add one more - testability. Writing unit tests for systems is much more easier as you can just set input value for the component and then write expectation for the value in the component. It cannot get easier than that.

 

And for the debuggability ... it is true that breakpoints for one entity are hard to achieve, however there is opportunity in the fact, that you can make "snapshot" of the entity and then rerun this snapshot through the systems how many times you want. Since everything is so separated, you could even run whole code with just that entity there and see what those systems are doing with it. Having unit tests (ideally with 100% coverage) really helps too as you can just apply this snapshot there and see where it breaks.

I agree, the canonical entity-component-system design has its flaws.

 

However, I think the article is missing the point a bit; it's attacking more the idea that design patterns are rigid and have to be adhered to.  I think the greater picture of entity-component-systems is that composition works better for game objects than inheritance, not that everything needs to conform to a strict philosophy.

 

The best programmers use the tools they need, not the one tool they were recommended to use.

But if you look closely you can see that we have all these useless components.

Why? Why they're useless?You seem to imply it is obvious they have become useless somehow, yet all I see is a pretty clear distinction between behavior (systems) and data (components). Normally you'd stop there, with your components attached to entities and the systems with sets of the different component types they need to work on.

 

You state no good reason to remove components at all after that point, thus no reason to follow with your argument further (that quickly gets derailed but that's a different issue).

 

Right until that point I was following you perfectly, but then you state out of nowhere that the components are useless then proceed to butcher up what you had built for no reason.

I am honestly humbled by your constructive criticism. I must admit that writing this article was sort of a knee jerk reaction to yet an other starry eyed ECS article. After some introspection, I think my biggest qualm is not the ECS itself (it is just a pattern after all), but the naive and oversimplified rhetoric surrounding the issue. It is a bit like the screen graph gospel two decades ago. (Two decades?! I feel old.)

 

This article went through half a dozen revisions and rewrites, ranging in tone between CS paper and the ramblings of a crazy old man. I settled for my normal and rather informal writing style, I picked up from Jeff Atwood. The tone shifts at the end are sort of intentional, they interrupt the lull of the rhetoric and as a result make you question your line though and my reasoning. I must agree that this stylistic element is not the most popular.

 

Typos... I am dyslexic and even though I put a lot of effort into checking my writing for spelling mistakes, some always end up in the text. I am grateful for each typo found; i would rather have somebody point it out, than having the mistake linger.

 

Although I could have spelled it out more explicitly, the "OOP vs ECS" discussion is a non-starter and misses the point. Each and every article I have ever read about the ECS hat two problems it tried to address, a deep inheritance hierarchy and a god class. The problem is that the ECS is not the solution to these problems, it is rigorously refactoring the biggest offenders of well established  OOP design principles. The result will probably not resemble even closely an ECS.

 

But if the ECS does not actually address deep hierarchies or a good class, what does it solve? It provides flexibility where none would be. I fully agree with the approach the Unity engine took. Their use of the ECS is the solution to the problem "How do we get game designers to build objects without code?".

 

It is no coincidence that the other place I found an ECS outside of game development was in the implementation of a scripting engine. The ECS is great at providing a high level of flexibility, especially for run-time composition and for this it does the job quite well.

 

The flip side of the argument is that, if you need this high level of flexibility, why are you using a strongly typed language anyway? So my question is, if you need this high level of flexibility why are you actually not using a weakly typed system? It is shocking how few developers even know about the concept of duck typing or soft/hard layer mixing.

 

The reason why I did not delve into the specifics, such for example debugging, is because the ECS is already mildly flawed on a design level. What is bad about a wide inheritance hierarchy? The term you are looking for is "ravioli code".

 

One of the my biggest issues I have the articles about ECS is that few talk about how an ECS could fit into the entire engine. There are sane ways to integrate a ECS into your game, but none of the code samples I have ever seen get close sanity. (If you have actual rendering code in your components, you are doing it wrong.)

 

There are valid uses cases of a ECS, where the benefits outweigh the flaws. The important part is to be aware of these flaws and keep and open mind. Maybe the problem you are trying to solve can be solved differently than you initially though.

 

Thank you for the feedback, my writing and reasoning is far from perfect. 

Any design or methodology can be misapplied. It can be easy to criticize those misuses, especially when they are common. They should be, but good ideas should not be discarded because of bad practices.

 

In my idea of a good ECS there are no hierarchies. Do note that in your proposal to have separate hierarchies you don't avoid the issue you are concerned about. Instead you just move it to a different level of the hierarchy. A designer could want a goblin that can both fly and walk, or one that can both use a sword and cast spells.

 

To me, ECS is the end result of the thorough application of duck typing. Rather than thinking of entities in terms of Goblins and Attacks, and Melee and Magic, ECS requires the designer to think in terms of what they want their entities to consist of (components/data) and what operations can be applied to them (systems). In this way of thinking (properly applied) it no longer matters what the entity is, but what can be done with it.

 

Personally, I do favor the use of ECS for core/engine code and eschew it for entity logic. The engine is where ECS can be most easily applied. For example, you can have an entity with a position component and a velocity component and your physics system can do integration (Euler, RK4, etc.) to update that entity's components. A.I. isn't always so simple. In that case I favor scripts, which can easily be integrated in the ECS by having entities have a scripts component and a system that calls relevant script hooks during each logic update.

you need to look at each and every entity and check if it has components that are relevant

It looks like you are not criticizing the ECS, but an awful variation of it; IMHO, your article would be better off titled "A Critique of Badly Implemented Patterns". The problems you listed for ECS are basically bad implementation, while the real problems aren't even mentioned.

Usually, what annoys me when using ECS is that it ramps up the complexity of my systems, when compared to a simple class hierarchy. It creates the necessity for more code and new patterns to be inserted in the model, such as observer and factory, when they would be unnecessary otherwise. This increased complexity weights a lot when debugging, specially when we have component-component communication.

Of course, it does have its fair share of problems, but it usually doesn't open more issues than it solves. I'd say it changes the issues, one solution for one problem. But in many many cases it is worth it.

And I can't really see what problem you are trying to solve with Duck Typing...

From reading the replies, I conclude there are (a lot of) of downsides to ECS that haven't been covered in this article. Would someone be willing to write an article that tackles (some) of these downsides?

Semi-informal writing styles work excellently for a blog post, but less so for article formats, IMO.

The grammar, spelling, and structure of the article is fine. There were hardly any typos or misspellings - not any more than other articles.

 

I'd love to read more articles written by you.

I am also glad to see an article that is questioning entity component systems. I am curious why people say it is entity-component vs OOP since and entity component system is a design pattern that uses OOP.

 

I am not 100% certain about all of the critiques but my take away from the article is don't waste your time trying to build a system like everyone else uses. Build a system that gets the job done. Whether it is 'OOP' or ECS, build what you need to finish your game.

Yes I think its component and aggregation vs inheritance pattern. I think a game might need both solution where the one or the other make most sense. And it's more Data oriented design vs OOP.  

 

The way I see the benefit is compute your stuff more from the perspective of the hardware architecture of how CPU or GPU interworking with caches and memory. Like memory alignment and keep data sets within cache lines. vs OOP real-world moddeling of how humans see it.

 

 

It's like this singleton types of component manager process after each other where each  goes through a large set of its component objects but split over as many cores so many threads as possible.

The world is shifting to many cores CPU the high-end will go to 8 cores HT so eats 16 threads. And it doesn't stop there.

These data oriented and component driven solution support concurrency in much better way.

 

That what I make out of all those articles in books and on the internet.

 

For a novice like me those articles make sense. This not so. It doesn't convince me at all.

These data oriented and component driven solution support concurrency in much better way.

 

 

Yes! No! Maybe! Having implemented many a system, inside and outside of game development, I can say that a ECS does neither favor nor deter from a solid concurrent execution model. The most solid case for the ECS is the Intel Paper Designing the Framework of a Parallel Game Engine. Even through they never lose either the words entity or component, if you look at their universal object and associated specific system objects, it quickly looks like an ECS. In this paper they basically do functional decomposition to use as much concurrency as possible. 

 

On the other hand in their excellent video series Don't Dread Threads, they make the very valid point that function decomposition has it's limits. You may actually get more out of your system by doing data decomposition. The key benefits here are two, first you probably can provide a higher level of concurrency and in most cases you can get away with almost no synchronization primitives. Using openMP to parallelize a few core loops may actually give your the biggest bang for your buck. Granted the real art is to do both, functional decomposition and data decomposition.

 

The thing that an ECS provides is an extreme level of flexibility at the cost of added complexity. In regard to concurrency it fares similar to other solutions. The key point here is added complexity; if a small simple system outperforms on one core because of memory locality an ECS with a high level or concurrency, you have gained nothing. Only use and ECS if you really need these extreme levels of flexibility.

 

Concurrency is like with optimization, don't do it until you really need it.

Actually, now that I think about it, your ideas about duck typing are in fact very applicable to the ECS design.  If you think about it, the components-as-data and systems-as-behaviour model is very much like duck typing - the function (system) can operate on any object (entity) as long as it has the right members (components).

 

ECS is just a slightly more rigid implementation of duck typing in statically-typed languages that allows for a lot of performance for the flexibility you get.