
Entity/Component Game Design: A Primer (2011) - 3131s
http://piemaster.net/2011/07/entity-component-primer/
======
jblow
If you want to successfully build a game, I recommend staying away from
entity/component or any other overcomplex system ... until such time as you
are an expert game programmer and _know_ that's what you really want (such a
time is likely never to come, for one reason or the other).

I have worked on games and engines using several different systems, and the
only ones I ever enjoyed treat entities as plain regular structs that you
operate on with procedures.

The games I have shipped all treat entities this way. And I never thought "I
wish I had made the entity system more complex". The top N problems on our
list, where N > 10, are always about graphics drivers or APIs.

Entities are hard enough when they are just structs. Don't insist on making
them harder, or you are likely to shoot yourself in the foot when it comes to
performance issues, later.

~~~
eigenbom
Have you written about this in more detail Jon? I'd love to read about it.

I'm not sure if there's an explicit definition somewhere, but i think an ECS
could be as simple as an entity struct that contains an (optional) physics
struct, that is then operated on by some physics module.

~~~
Ace17
What about entities that need specialized members?

e.g an "isOpen" member might make sense for a "door" entity, but it hardly
makes sense for a "bullet" entity.

My understanding is that Quake2 "solves" this issue by making a big structure
from the union of all specialized members (see: [https://github.com/id-
Software/Quake-2/blob/master/game/g_lo...](https://github.com/id-
Software/Quake-2/blob/master/game/g_local.h#L1054) ).

Although Quake2 certainly is industry-proven, it doesn't feel right for every
specialized entity behaviour function to depend on members needed by other
specialized entity behaviour functions.

~~~
jblow
The way I do it, each entity has one struct. So a Bullet is one strict and a
Door is one struct. They both share common base members that all entities
share.

But this is all that is really necessary. Once you start getting into
components, you add a lot of complexity (even if the pitch is that it's
"simple").

~~~
Ace17
Interesting.

I'm not fully convinced by components either, I don't like the idea of the
bullet behaviour code having to check if "this entity has 'propeller' and
'rigid_body' components", as if the bullet behaviour code had to re-discover
what a bullet was made of (BTW, this feels like a re-implementation of coarse-
grained dynamic duck-typing for static languages).

This problem is less visible when the game logic is written in Lua, where
dynamic duck-typing is the rule. I do write my game logic in C++/D, though,
and the problem is perfectly visible.

The way you describe how you would do it raises a few questions ; because now
it seems you can't process entities in a systematic/opaque way.

This implies that, say, the renderer has to loop over bullets, then to loop
over doors, and so on. Each time a new entity type is added, this part of the
code has to be modified, even though most entities might share the drawing
code (e.g mesh).

This sequence of loops appears in many places, like collision checking, game
logic update, save/load, etc. and all of them have to be updated when a new
entity type is added.

Something in my understanding must be wrong, because the way you do it
obviously works ; maybe the issues I just described isn't so problematic in
practise?

~~~
jblow
No, because they share a base Entity class.

~~~
Ace17
Thanks!

------
whalabi
A post on the same topic that hn liked: [https://unlikekinds.com/t/game-
components](https://unlikekinds.com/t/game-components)

(I wrote it)

------
Rusky
This article is mostly a list of ways _not_ to do entity/component- the sequel
(linked at the bottom of the post: [http://piemaster.net/2011/07/entity-
component-artemis/](http://piemaster.net/2011/07/entity-component-artemis/))
actually talks about how _to_ do it.

------
krapht
Simple bags of data and the functions that act on them. That's a message I can
get behind.

