Entity Component System VS OOP

Game Mechanics
#1

So, I’ve always used object oriented programming. I only recently found out what an entity component system is. It sounded like a good idea, so I implemented one based on this tutorial. After asking a question about it, I found out that sproingie wasn’t too impressed with the whole idea:

It’s a really great post if you read the whole thing. It helped me out a lot. I took sproingie’s word on it, and decided not to use the entity component system.

However, I’m starting to question why so many people here feel this way about this type of system. While I was using it, I found it to be very helpful, and made certain things more simple. Anyone want to discuss what they like/dislike about entity component systems over OOP? Is it simply a matter of “If it aint’ broke, don’t fix it?”

#2

An Entity Component System is OOP, so the question would rather be ECS vs approach XY.

#3

For me it’s mostly that I do not work on games that have anything like the number of possible interactions that make a component based system less complex than a simple 2 or 3 level traditional object class hierarchy.

Cas :slight_smile:

#4

for me after 2 minutes of thinking:

pro ECS:

  • flexible
  • easy to “glue in” third party libs (physics, etc.)
  • better “modding” support
  • better support for resource driven development

contra ECS:

  • usually more to type in non resource driven development
  • bad code-completion support (typing “get” results in getComponent(…), nothing else ;))
  • prone to nullpointer exceptions
  • prone to the “game engine dilemma” (more effort to the engine, less effort to the game)
#5

I’m not completely negative on Entity Systems, I just think they’re oversold. If you read the T-Machine article, a lot of the benefits being touted are things like cache coherency and reference locality, which are big deals with consoles with their in-order CPUs and small memory space. None of these benefits are going to materialize in a typical java implementation, so what you’re left with is simply the code organization principles that Entity Systems give you. They’re not bad principles – composition is really a good thing overall – but they’re not a panacea. Forgoing direct references in favor of “Entity IDs” all the time is just silly unless you’re gaining real measurable benefit from this extra level of indirection.

#6

Cache coherency and memory locality are, it seems, pretty big deals for desktop CPUs as well these days. So… if you need that sort of stuff, well, you need it.

Cas :slight_smile:

#7

Thanks everyone. I’m going to try it out again, just to see how it works out for me. :slight_smile:

#8

Oh I agree, but stuffing object references into an Array doesn’t cut it. Something like MappedObjects would be getting there, but none of the ECS implementations I’ve seen actually do anything like this.

#9

Yes, mapped objects is where it’s at. If you don’t have them then you are probably just undergoing huge pain for no gain.

Cas :slight_smile:

#10

With regards to cache coherency, MappedObjects can be done completely in Java. Shameless self-plug: http://bitbucket.org/mludwig/entreri

And it definitely improves performance.

#11

I have largely found the same thing. An interesting question might be, how many different objects/enemies/interactions/etc. do you need to have to make a component system worthwhile?

#12

Component based is neither OO nor not-OO. It’s a data design model (by segregation). And in the context of languages which don’t support arbitrary containers natively, it’s also a design pattern. [SnarkMode]It’s yet another great idea from the same brain that came up with Objective-C. Although it was originally termed software ICs. Can’t imagine why that didn’t catch on.[/SnarkMode] It’s a really fine idea. If you’re writing, say, banking software…and especially if you choose a language well suited it. In the context of games? Almost always a huge waste of time except in the narrow case of needing to processing massive amounts of entities. At the same time. Which isn’t necessarily the same has having a massive number of active entities. And even in that case I’m not sure it’s a great idea. Because you can always build your system to use data segregation instead of creating/using some arbitrary container management system. As an aside, my guess is that most libraries are composition by type, rather than composition by name…meh.

The most recent discussion (that I recall) on this subject is here in which I say this. Actually Cas started a rant Still hardly any games, why entity systems suck, and why 4k is good.

WRT: MappedObject. Faking structures is a great improvement, but you’re still stuck for caching hints. And all of this is assuming that one did a good job of figuring out data segregation and maintain aux info to let you traverse the data linearity and not cause cache thrashing is some other core.

WRT: Cylabs pro list:

  • flexible … with respect to the one archtype, one class ultra deep rigid design pretty much only a beginner would do, then yeah…otherwise not really.
  • easy to “glue in” third party libs (physics, etc.) … don’t see how this is true
  • better “modding” support … Pseudo-mixins and a basic extension mechanism cover pretty all your bases here and likewise these are ‘at runtime’ changes. If you wanted to get really fancy, you could add hot-deployment.
  • better support for resource driven development … don’t see how this is true.
#13

I was thinking if you were maybe serverside and had 100,000k entities to process 10 times a second, just possibly it might be worth the hassle. But then you’d probably have just been better off throwing another core or two at the problem and avoiding it all. Or of course if you’re running on something with a tiny cache and fat bandwidth pipes through multiple processing stages like PS hardware, but none of us are doing that here.

Cas :slight_smile:

#14

Here’s the deal. The performance gains come from the data segregation (ya gotta get this right) and approximately linear walks of memory per worker which are not component based specific. The ES specific bits are all performance drains. The one possible situation I might consider using a CS is if I wanted true ~100% uptime and wanted to be able to easily apply live code updates. This “might” be easier than a more traditional hot-deployment scheme…or not I haven’t thought about it enough to form an opinion.