games design massively multiplayer networking system architecture

Entity Systems are the future of MMOG development – part 3

Also known as: Nobody expects the Spanish Inquisition!

(because I’m now deviating from the original schedule I outlined in Part 1; what the heck, it was only a rough agenda anyway…)

Questions, questions…

First of all, there’s a bunch of good questions that have been raised in response to the first two posts:

  • what data and methods are stored in the OOP implementation of an entity?
  • where does the data “live”?
  • how do you do object initialization?
  • what does the ES bring that cannot be accomplished with an AOP framework?
  • what’s the link between entity systems and SQL/Relational Databases? (OK, so that one’s my own question from last time)
  • what, exactly, is an entity?

Let’s start with that last one first.

What, exactly, is an entity?

Obviously, I’ve already covered this from the conceptual perspective in the last post, where I defined them as:

For every discernible thing in your game-world, you have one Entity. Entities have no data and no methods

Great. But a couple of people were wondering what ACTUALLY is it, when you start implementing the thing? Is it a class? Is it an array of data? Is it a list of Components?

The last statement is particularly important: actually, entities have NO data and NO methods – an entity is not a stub for a class, it is not a struct of data, and – ideally – it’s not a list of Components. An entity is really just a name. Last post I also wrote that entities “do little more than to tag every gameobject as a separate item” – and that’s the key thing here, an entity is just a unique label for an in-game object.

I was a bit non-specific, because I didn’t want to say empirically that an entity cannot or should not be a list of components – sure, you CAN implement it that way – because many people do implement entities like that, and who’s to say what’s right or wrong here?

Although…I actually think that *is* the wrong way, and think that by the time you get to the last of these Entity Systems posts, you’ll probably agree with me ;). The problem is, the right way is usually too slow, so you’ll probably end up *to some extent* implementing entities as lists anyway, but if you do so as a performance optimization (e.g. by hiding that detail from the rest of the system) rather than as a logical implementation, it’ll cause fewer problems with your code in the long term.

So, to answer the question directly:

What is an entity?

An Entity is a number (a globally unique number)

Remembering, of course, that a String – or any other kind of unique label – is merely a fancy kind of number, not just in terms of how computers implement them, but in terms of how Mathematicians think of them. People tend to think that strings have extra features, for instance you can encode trees within strings easily (“root.node1.leaf”, for instance – as used in most OOP languages derived from C to navigate the namespace of classes, methods, etc) – although of course you can encode things like that in numbers, too, for instance “123045607” (using 0 to stand for the dot… i.e. “123.456.7”). But … you *really* don’t want to do this!

Gotcha number 1: only OOP programmers want to give entities hierarchical names. It can tunr out a pretty dumb idea, if you think about it: it’s usually an implicit refusal to let go of those OOP ways we’re so used to thinking in, when those OOP ways are exactly what caused most of the problems we’re trying to fix by using ES’s.

So, don’t be tempted into hierarchical encoding, and definitely don’t do ANY encoding in the entity names – there’s a much BETTER place to do metadata for entities (trust me).

And I’ll be calling the implementation of an entity a GUID from now on (“Globally Unique IDentifier”).

What data and methods are stored in the OOP implementation of an entity?

The answer for the previous question makes this one easy to answer: none. The entity is merely a label, and whilst you DO want to store and manipulate some metadata around that label (e.g. it’s kind of handy to have a list of all the entity names you’ve currently got in memory, and be able to rename them without breaking everything), you should be thinking of them as nothing more or less than a GUID (String. Number. Whatever!).

Where does the data “live”?

The first time I made an ES, I implemented the individual Entities as classes, and although I didn’t put any methods in those classes (that would just be bog-standard OOP!), I did put the data into them. It didn’t occur to me that I’d need to worry about where the data was living, so I just stuck it somewhere natural – in the Entity.

Of course, I’d made a cardinal error, because whatever feels “natural” to an OOP programmer is usually “completely wrong” in ES programming.

Anyway, the last time I did an ES I was a lot wiser, and so we put the data inside the Components. All of it.

Gotcha 2: ALL the data goes into the Components. ALL of it. Think you can take some “really common” data, e.g. the x/y/z co-ords of the in-game object, and put it into the Entity itself? Nope. Don’t go there. As soon as you start migrating data into the Entity, you’ve lost. BY DEFINITION the only valid place for the data is inside the Component

How does that work?

Well, you need to start thinking about your Components a bit more carefully here. I previously said that:

A Component labels the Entity as possessing this particular aspect

So, again, a Component is merely another “label”, just like the Entity itself. Right? Wrong. This is my fault – in the last post, I was trying to Keep It Simple for you, and glossed over quite a few things; because the very first ES I made, I treated the components as mere labels, that description came out most easily as “the simple version” of what they are. In more detail:

A Component is the chunk of stuff that provides a particular aspect to any Entity

…where “provides” means “does all the things that are necesssary to make this work”. Which means that all your Components certainly *could* be implemented as standard OOP objects. To define an Entity, you just provide a name (GUID) and a list of Component classes that it needs, and to instantiate that Entity, you just instantiate one object from each class (and then you need to somehow attach those in-memory objects to your GUID, probably by implementing the Entity as an empty class that just contains a GUID and a list-of-component-instances (which I said to avoid, but we’ll come back to that later)).

But, as you may have noticed by now, I’m vigourously against using OOP anywhere inside an ES implementation. This isn’t some strange dislike of OOP itself, it’s just that in my experience with ES development it’s all too easy for experienced OOP programmers to keep trying to sneak some OOP back in where it’s inappropriate, and it’s all too easy to delude yourself into thinking this is a Good Idea. And, worse, from the teams I’ve worked on in the past, it has consistently seemed that the better you are at OOP programming, the harder this is to resist…

You COULD implement your Components as OOP objects. But, really, if you go back to the definition of a “System” from the last post, you’ll see that the methods for acting upon Components should all live inside the Systems, not the Components. In fact, re-reading that last post, I notice that I explicitly described Systems as doing exactly this: “a System essentially provides the method-implementation for Components”.

One tiny exception to this rule: getters and setters are really useful. If you’re implementing your ES within an OOP language, you might allow yourself to implement Components as objects just to get the benefits of get/set and e.g. multiple different versions of each get/set that do basic type conversion, or integrity checking on data, etc. Be warned, though, that if you do you MUST implement them as flyweight objects (go google the Flyweight Pattern if you don’t know it) or else you’ll lose lots of the memory-management and efficiency advantages of a full ES.

Where does the data “live”?

Each Component is merely a classification label (e.g. “Renderable”) and a struct/array/list/whatever of the data relating to it’s purpose; all data lives in Components; ALL data.

How do you do gameobject initialization?

Here’s a fun one – I haven’t mentioned ANYTHING about object/entity intialization. It was really only from trying to use entity systems that I finally realized just how bizarre OOP is when it comes to initialization: you have some “magic methods” (constructor, destructor, finalizer, etc) that have nothing to do with the main description of OOP, but instead are part of a meta-programming that allows you to get your OOP system up and running, and to keep it running, and then to tear it all down again at the end. Until then, I’d not noticed how out-of-place those methods are…

Hats-off to the OOP folks: they integrated their meta-programming so neatly into OOP that in most languages it’s unnoticeable. But I’ve not yet seen the same trick done for an ES – so, get used to the fact that initialization is going to be a bit … “different” …

There’s really a bunch of issues here:

  • what’s the technical term for an entity’s archetype?
  • how do you define the archetypes for your entities?
  • how do you instantiate multiple new entities from a single archetype?
  • how do you STORE in-memory entities so that they can be re-instantiated later on?

What’s the technical term for an entity’s archetype?

There doesn’t seem to be one. Really. There’s a couple floating around, influenced by people’s own backgrounds but I’ve heard quite a few used interchangeably.

My favourites are:

  • template
  • model
  • assemblage

(I actually picked the last one from a thesaurus – looking for equivalents of “class” ;)).

The problem with both “template” and “model” is that they’re both very frequently used generic terms in programming. Entity is pretty good as a term, because it’s hardly used for anything else (and the main obvious competitor is now widely called a “gameobject” by game programmers). I’ve used both, in the past. Interchangeably. (cackle!)

So. “Assemblage”, anyone?

how do you define the archetypes for your entities?
how do you instantiate multiple new entities from a single archetype?
how do you STORE in-memory entities so that they can be re-instantiated later on?

Big topics. Really big. Too big to go into here (ah. Now I know what the next post is going to be about…).

What does the ES bring that cannot be accomplished with an AOP framework?

The simple, facetious, answer is: almost everything.

AOP (Aspect-Oriented Programming) doesn’t really help much to solve the problems that an Entity System solves (although it does solve similar ones that ALSO tend to be present when the ES-related ones are present), and doesn’t provide the new features that you get from an ES (e.g. the improved memory/data-performance).

An ES takes a system where there are many things going on that are all independent, which OOP tangles up together, and pulls them apart and lets them live on their own. It also highly efficiently manages simple interoperation between those disparate aspects of the program, and allows them to be disconnected, reconnected, at will.

AOP takes a system where there are things going on that are fundamentally DEPENDENT, which OOP tangles up together, and allows them to be reasoned about “separately, but together” – you can view the code for logging independent of the code which is being logged, but you have to still reason about them at the same time, you cannot merely ignore one or the other. By definition, different aspects (vested as Components) of an Entity are INdependent, and this whole “together” thing is an irrelevance.

However … AOP certainly helps if you have implemented with OOP something you ideally should have done with an ES, and you want to add new features to it, because the tangled OOP system is going to be a pain to modify without breaking stuff accidentally, and AOP will help you more precisely focus the impact of your changes. But it’s a poor replacement for just implementing the ES you wanted in the first place.

There is also a fairly large area of crossover between “some things you can do with entity systems” and “some things you can do with aspect oriented programming”, mainly because they are both fundamentally data-driven at the function-despatch level (which I’ll come back to later). However, they each use this data-drivenness in very different ways – AOP uses it to react to, and wrap itself around, the code of the program, whereas an ES uses it to react to the data of the program.

Using both together could be really exciting – but I’ve not been brave enough to try that yet myself.

What’s the link between entity systems and SQL/Relational Databases?

You might have guessed this by now – it’s been the theme of most of the answers above, starting from the very beginning of this post.

Mathematically-speaking, an Entity is a database Key, just as you’d see in any RDBMS.

Likewise, from a purely abstracted point of view, the “set of component-instances that comprise Entity #7742” is, literally, a database Query.

THIS is why I said at the start that, ideally, you do NOT want to store your component-instances as a list inside a struct/class representation of each Entity. Fundamentally, that set is NOT defined as a list (a list is a static thing, it’s members don’t change without you changing them), it’s defined as a query (whose members are always changing, whether you want them to or not), and using one where really you wanted the other tends to cause problems in the long term.

Obviously, you can use Lists as a simple form of query (that query being “what things are currently in this list”), but that’s a rather poor and inflexible kind of query. Life is much more interesting if you embrace the dynamicity of the query, and fetch the components (and, hence, the VALUES of the data…) by running a query every time you want one or more of them.

This is a fairly star-gazing view of how to make games: the game is just one giant database, running dynamic queries all the time. Current performance, even of fast RDBMS’s, is just way too slow to be running thousands of queries per frame on a home PC.

However, these articles are about ES’s for massively multiplayer online game development, not just standard game development, and that changes two things in particular:

1. Most of the game is NOT running on home PC’s, it’s running on arbitrarily beefy server-farms that are already running bajillions of QL queries (nearly always SQL these days, but any of MS SQL Server, Oracle, or MySQL).

2. The data is much much more important than rendering speed; we have almost no problem making incredibly beautiful 3D rendered landscapes, but managing the data to make those landscapes act and react as if they were real (i.e. world-logic, game-logic, etc) is something we still find rather hard

A new thought for the day…

Think what you can do with an ES if you deploy it on an MMO server farm, and go the full monty by making all your entity/component aggregations stored merely as SQL queries. Here’s some to start you off…

1. No more pain from “Relational vs OOP”

One of the slowest parts of MMO server performance is translating OOP objects into RDBMS tables so that the database can save them, and then translating them back again when the game needs to read them. This also wastes large amounts of programmer time on boring, annoying, tricky to maintain code to handle the serialization processes.

2. Massive increase in parallelization for free

If you make all processing data-driven, and you have no data-structures that have to remain synchronized, then it becomes a lot easier to “just add more CPU’s” to increase runtime performance…

3. Where else could you use SELECT instead of data structures?

When each System has to do it’s processing, it’s probably going to iterate over “all Entities that have my Component”. Is that something you can store easily in a standard data-structure? Or is it better off as a QL query? And what else can you achieve if you start doing your processing this way? (hint: there’s some nice benefits for the low-level network programming here…)

NEXT: Part 4

52 replies on “Entity Systems are the future of MMOG development – part 3”

Where can I read more about entity system development? Do you have books or other web sites you’d recommend This is great information and I’m looking forward to the next parts.

You could read Scott Bilas’s presentation from 5 years ago (linked in the first article), or have a look at Mick West’s summary of doing entity systems development for Neversoft, but they’re both too simple for my tastes, which is why I started writing these posts myself – to get some more detailed and practical info and advice out there.

NB: I only found Mick’s blog post very recently. It’s a good introduction to the ideas and approaches in entity systems – but again, it only covers basics.

On the positioning of Entity not storing any data, I think it should store at least the transformation position. I’m working on an commercial engine which the Entity do not have the position, so we need to either

1. Query the component which has the transformation data.
2. Cache the component that has transformation data inside Entity.

Hardly ideal. Also if you implement physics system as a component which is updated in another system, you need to update the transformation of it’s visual component, causing unnecessary dependencies.

It can be solved by having the transformation data in Entity. All systems update since components are linked to an entity..

Regarding archtype, a better name is to use is Palette.

Robin – the same argument can be made for many of the systems, and you end up with a monolothic Object, exactly the thing you were trying to get away from.

Without knowing how you have arranged your components, there’s not much specific alternative ideas I can offer, but if you find the data is frequently proving an annoyance to access then you should probably rethink either how you’ve split functionality between components, OR how you are actually invoking systems each game-tick. If you read between the lines on the SQL side of things, one option is of course to merge multiple components into a single component before passing them to the system for processing – something like that might help you?

Hello Adam,

I don’t quite agree with your definition of AOP being fundamentally dependent. I’ll just point to an example of the current Java middleware where concerns such as security or transactions can be developed without prior knowledge of what kind of components are deployed. Logging is a very poor example for AOP since it *IS* very much dependent on the component being used (nothing to stop developers from building functionally dependent aspects of course).

As for the rest, I’d be wary of advocating the approach too far (developers tend to take one hammer and use it everywhere) although if used in a clearly constrained subsystem, it certainly works around the inherent language limitations of Java, C++ et al (static compile time inheritance hierarchy). In that sense the relational model is indeed more suitable than the object-oriented model.

Ideally though you’d have a language with richer meta model. However, going outside mainstream languages you will hit the hiring/training issue and potentially also the additional cost of framework and library development.

No perfect solutions, it seems.

A lot of this sounds like a fancy way of dressing up the very old idea of declarative programming languages (specifically the logic and constraint programming languages such as Prolog and Mozart).

Phil – that’s one of the main points I’m getting at, short answer: yes, this is in large part an attempt to find a way to do SOME declarative programming from within non-declarative systems using non-declarative languages. And this is NOT an attempt merely to get around the problem that most professional programmers can’t/won’t do declarative programming: in this problem domain even if you were able to use declarative languages (i.e. could find enough programmers with the required skills), you would still want to be using non-declarative languages simultaneously.

One option is to turn C++ into a declarative version of C++, but that is not much better than just using Prolog in the first place – in fact, in most ways, it’s worse.

So what *do* you do where you simultaneously need BOTH a declarative language AND a non-declarative one?

One option is to perform your declarative work at the system level instead of at the main language level. If your application can have its declarative parts split off like that, then this might be a valid direction to take. The entity systems described here offer an architectural split that fits with the problem domain of game development, allowing declarative and non-declarative styles to be used together only for the parts of the problem domain where they are each actually needed.

At least, that’s the aim. And hopefully I can explain it a bit better than that over time :).

Hello Adam,
I’m very interested in the Entity System concept and I’ve been trying to include it in my current project even thought it’s not a multiplayer game.

I’ve stumbled upon an issue and I’m not sure if it’s a natural consequence of the way entity components are meant to be or a fail in my design.

I have saved the comments from my code in this pastebin:

If you had the time to have a look at those comments and let me know what you think, I’d be very grateful.

I’m looking forward to your next articles, that perhaps will clear up things a bit, especially implementation-wise.

Kind regards,

“you have no data-structures that have to remain synchronized”.
Please fix me : some Systems interact, for example the Placeable Component (remembering coordinates) interacts with the Controllable System (an object can be moved by the player) and the Pushable System (an object can be pushed by an other), thoses two read and write the coordinates. If they are on separate threads, they have to synchronize their access. Right ?

hi, i was just wondering when you said that a component is where all the data is struct/array/list whatever how would you implement the component. would it be a class or struct containing stuff for the entity to access through the label or would it be an array of data that the entity could access i was trying to figure this out and am confused how you exactly use the component to store the data. i know this post is old but i thought i would give it a shot :)

Either is fine.

There’s lots of ways you can implement an ES, so long as you stick to the core philosophy.

Which one you choose varies depending on the hardware + software platform you’re running on.

sweet, thanks for answering. ok this may sound like an OO freek here but could you use a abstract base component class and inherit from that… just for the components but still create everything else w/o OOP… i just cant think about how im going to store all the data and access it from an array lol, im still studying your parts 4 and 5 so i may learn more but this is a very interesting topic. the one thing that is different is im not an mmo developer lol just going to use this for regular games for now but i hope to be a mmo developer in the future once i get out of highschool and college lol

oh, sorry just one more question, when doing core things like windowing and stuff would you still use a window class and stuff our would you somehow use a component to define with window.. and for things like vectors and rects as well

I’m pretty sure this has been covered in the comments to the other parts already, but … short story: yes, you can use OOP to implement components.

BUT … why bother? There is almost no reason to do this.

c.f. the post on an Entity System with Android, linked to from part 1 I think, where I used a base OOP class for components, but IIRC the only content it had was a debug method for describing the component when printing out stack traces.

There’s literally almost nothing you could meaningfully put in that base class.

well, i was just wondering because the reason i would have a base class for component is so all the components could be stored in the same location… thanks for pointing out that you have a code example, i dident even notice that before :)

Yeah – if you’re using OOP merely to implement the ES itself – i.e. for internal parts of the ES (like your example, if I uinderstand correctly) – then that’s fine.

sweet, i was trying to do it today and i found myself falling into the oop trap lol i deleted the project and am going to give it another go tomorrow :) ok just so im clear using oop to define the base component and system class is fine just so i can store all the compoents and systems in the same area.

ok this is how i was implementing it today, my entity was a typedef for an int, and i was thinking that when a add a component to the entity i would add that component to the system that corresponds to the component. but i was thinking that entities would have more then one component so would you have an array of components/vector for each entity… or would you just add them to the system and use the entities index to access them. well i have learned alot and cant wait to try some more tomorrow but until then sleep :)

If you use ES long enough you will find that entities are really components in and of themself. After-all entities stored in a list are not much more than entries in an associated array, and in that regard are similar to components.

Once you start down this path you invariably have to implement Managers, which are a bit like systems, but handle references to component instances of a particular type.

Thus for example the Rendering System would query the RenderManager and completely skip the step of Querying each entity component . The RenderManager in turn keeps a list of references to all instances of any render components, but not the associated Entity or GUID. A system would only have to query the EntityManager if it had some specific use for entity instance data itself.

Lets consider the RDBS example. If an Entity is a key that when queried returns a set of values from one row where each column represents component data (and each entry in the row represents component instance data), then a Manager is just ONE of the column headers, containing references to every entry beneath it.

By using managers in conjunction with systems, “queries” return only relevant data and the returned values need not be filtered, or searched before utilization.

“you invariably have to implement Managers”

I don’t see why this is the case? You seem to be adding complexity where none is needed.

“completely skip the step of Querying each entity component”

Why would you ever want to “skip” referencing a variable? We’re typically talking about a single direct-memory access here, or at worst a single pointer indirection.

Hello Adam,

First off, thank you very much for taking the time to write these posts about entity systems. It’s nice to have someone actually describing them in detail, as much of the other info I’ve found on them has been very vague.

Given that, I have a question about the interconnections between components. Your renderable component needs the position from the position component for example. I’m thinking that having a copy of the needed data or a pointer to the needed data would be a bad thing.

How then do you do the actual communication and interconnections between components. (This is the area which most other posts seem to avoid completely). I’m working on developing an ES in C++ with a java wrapper for the Android platform, and have been hung up on how to do this efficiently while keeping the thread safety between systems.


No, Components never “need” anything – if you have source code, that code is NEVER part of a component.

The component is pure data, nothing else.

It is impossible for a component to “communicate” with another component, because communication implies source code.

re: Android, c.f. the separate post on “entity system for android” that I did, it contains java source code for an entity system that you may find useful


Sorry, What I meant was how the sub-systems communicate with each other. Say the input sub-system gets the input to move an entity forward. Does it just broadcast a MoveEntity message with the specifications of the movement, or how does this happen?

Pretty much how does the messaging system work so that everything can interact without compromising the thread-safety if you have different sub-systems running on different threads.


All these articles cover single-threaded systems only, to keep things simple.

So, each system changes the data directly.

In a multi-threaded setup – without going into detail – you have several options, the simplest probably to serialize any accesses to a given component. Since you know in advance which aspects each system is reading, and which ones its writing, it’s not particularly hard to programmatically ensure this.

i.e. just like a fine-grained locking system in a traditional MT OS or large scale MT application.

Hi adam!!

great posts, got me thinking a whole new way…

I have a question regarding where the components live, I understand that this will differ depending on your game design/implementation, however due to my lack of game experience im a little unsure of where to start…

is there one big nasty array somewhere storing all the components?? or is there a more OO based level class above the ES system storing these objects?? in know OO is taboo but I thought it cant hurt to ask :D

Start with the array … it’s good enough for many games … and change it later if/when it becomes problematic. Look at the ES on Android post for an example of doing it in Java using HashMaps-of-HashMaps.

By that point, you’ll know what you need instead.

So if an entity is only a name and nothing else (list of components), what’s the point in creating one? Does anything have a reference to it?

The problem I see with not having a list of components is that when we add the components to the systems, they’re entirely dissociated. When we want to destroy an entity, how else will we know which components to remove from which system?

I don’t understand your question then. what do you mean by “creating”, what do you mean by “have a reference to” and what do you eman by “nothing else”?

Basically, I want to know how you plan on removing entities from the game world.

AFAIK, Adding an entity to the world involves adding its components to their respective systems. If an entity is only an id, constructing it is absolutely useless unless components or something else contain a reference to it.

Now, when an entity is to be destroyed, we’re going to remove it’s components from the systems, right? So we have the entity, but we have no idea which components it contains, or which systems they belong to.

Since the entity contains nothing, we know nothing. Maybe I’m missing something crucial here.

If there are no components that refer to a given entity-id, then that entity doesn’t exist. There’s nothing to remove, because there was nothing that existed in the first place. The entity is just a *name*, it doesn’t exist in memory

Different games do different things.

Most games would remove the “movement” component, and change the data in whatever “rendering” component(s) to replace the player’s avatar image with a corpse image.

If the game has multiple lives, they’d transfer some of the components – e.g. score – to a new entity, the new player avatar.

(or vice versa: make the corpse the “new” component, and change the existing entity to be alive again – although IMHO letting the old entity become a corpse is conceptually cleaner)

I see. So it’s really a case-by-case thing, and shouldn’t be abstracted?

How would the game know which movement component was the player’s?

The entity is the “name” that each component is mapped from.

Some implementations have an entity field in each component (usually an integer ID)

Other implementations make the mapping invisible to the main game, e.g. I hide it inside the EntityManager described in this series of posts: it’s implicit that every Component is mapped (in practice, I describe storing each component as a value in a Map somewhere internally)

Ahh ok I see now. Thanks for clearing that up.

On a separate note, would you recommend making those systems global then? The health system would need to know how to kill something.

Hello. Thanks for posting these explanations, but I’m afraid that they only confused me more…

I thought that entities are actual objects, which are created by combining a base Entity class with different components, which would also be objects with both data and methods.

For exanple, the base entity class would have a “components” array, and some methods to apply said components to the entity. A component, say a position one, would include the data (x, y), and methods that provide a specific way of changing the data. In the case of a position component, it would pretty much be just a Vector2D class (with add, sub and normalize methods).

A system would be just an algorithm that invokes these changes upon components, for example, a Scene system would call the “move()” method of all entities that actually have the movement component.

What is wrong with this approach? Why would you transfer all the functionality to the systems?

Also, I think that you need to give more concrete explanations and examples. You simply state that an entity is “just a name”, and I believe that many people are confused by that. An abstract example of an entity, say two components, and a system would be prefered!

Also, how general should the systems be? For example, I thought that I could turn my Scene class into a system, but now it is clear to me that it could only finction as a container of entities, because it holds many types of entities (objects, lights, particle emitters, 2D sound emitters, etc).

This has been covered in depth in the other articles, and the followup articles with examples from real games.

If you click the “Entity systems” tag on this post, you’ll get a bunch.

Hi adam!

Thanks to you and people at Gamedev SE, I understand Entity Systems much better.

The only problem for me now is actually implementing a game engine in Javascript that supports these ideas, and that is mainly due to my obsessions with details and not the actual inabillity to make an ES (or at least I tell myself)…

I still have one uncertainty, though… What do you actually mean by “query”? That would be asking a “something” that stores all the component instances for all the entities that have some specific set of components?

I plan to implement some kind of a Storage class, that would house all created entities in an array-of-arrays, and then I’d create an API for it with a method that would allow me to retrieve the required entities by passing a string, for example, “position sprite”.

By doing this, I’d abstract the actual implementation of the Storage, and could later change it to an SQL database.

Is this OK? Or will it be too performance heavy to do these queries all the time for each system? Should systems have lists of entities that they’re already interested in?

Thanks for your time!

You say that if you implement components as classes, then you “MUST implement them as flyweight objects”. Wikipedia says that “Flyweight objects must be immutable”. Taken together, this implies that components can only contain read-only data. While this sounds efficient and desirable, it seems highly unlikely in practice. Thoughts?

Hey Adam,

I just thought that actually ECS can also be used for game menus right? I’m not that good at programming (not much experience) so I now created an entity representing a button (components: position, sprite, boundary) but I’m stuck at the point when the user clicks the button. If I understood it correctly the components should only contain data, no logic. My initial idea was to add a component ‘Action’ (I’m using java) which just contains an action that is performed on click but I think this is the wrong way. Can you give me some thoughts how I should approach this or is it actually a bad idea to use an ESC for that purpose?

Greetings and thanks for your efforts,

Hello Adam, I think i understood your message through these posts about ES and it all seems to make a lot of sense. There are only a fewpoints I’d like to ask about:

1) How do you implement component dependencies and handle parenting of entities? I can imagine that transforms are effectively dependent on each other for updating; do you parent entities in other way than having each transform know its parent? Do you allow an arbitrary number of components of the same type in a single entity at all? If yes, then how do you do the coupling between each mesh or physics object and their transform, for example?

2) If systems will be iterating over entities, querying if they have the desired components every frame, is this still efficient? Or do you cache in the system a list of entities / components that are eligible for updating, to prevent the hashmap/dictionary/other lookups?

3) I fully agree with the systems purpose, but while making games, we usually write gameplay code that isn’t very fit for serial processing in a system. Do you still write a system to handle the logic for that very specific case (may involve looking up a single entity in the entire world just to perform something in one or two of its components), or do you write additional logic somewhere else than in the systems?

4) How do you encapsulate really complex world objects, so they can be created/removed/updated cohesively, like a human character with tons of configurations, multiple skeletal meshes, clothing, attached weapons, particle emitters and so on? As you said in a comment answer that if you have two meshes, that’s two entities, this means a potentially big set of entities, with complex parenting hierarchies that are replaced in runtime during gameplay. So, my question is, in your gameplay code, where would the utility code to swap clothes/weapons/etc in the character go? Would this be a system too, which would on demand, rebuild the entire entity hierarchy for that character to accomodate the changes?~


From your choice of words, sounds like you’re coming from Unity background? Their choice of hardcoding “parenting” (marking one object as being a sub-transform of another) is interesting, but is often very stupid in real games. It scales surprisingly well in the editor, but it’s really a hack: associating things (gameobjects) that have no real association (only their transforms do).

In general, you shouldn’t really have “component dependencies”. Components don’t depend, Systems (aka Processors) do. A Processor may decide that it neesd a Postion AND a Velocity; the Velocity on its own may not mean much, but a Velocity has no code, so it CANNOT care about this.

And in fact: you may temporarily hve a Velocity but no Position, e.g. because you just blew up and became part of a full screen blur that only relates to your final velocity, and is independent of your Position.

Hello Adam, I don’t come from an Unity background, but Unity in fact doesn’t parent GameObjects either, it parents transforms directly; Each transform has a pointer to its parent, if applicable.

I agree with you in that different GameObjects have no real association; In my architecture, I don’t have the concept of parenting, but instead the concept of attachment, where one object can optionally have attachment sockets for weapons and accessories, and here we assign other independent objects so they transform together with the main body.

About component dependencies, you need to either decide if you will allow multiple components of the same type, in which case they need to be linked together, or just allow one, and everything becomes simpler, as we can make the lookups exactly like your posts recommend. I wasn’t sure, but it seems your way simplifies it, one component per type only. My argument over this is that if you had one entity with multiple rigidbody/transform pairs, they needed to be linked together, to make sure the physics system doesn’t update the wrong stuff. But with multiple entities, instead of multiple components in the same entity, this is solved with no hardcoded linkage between components, so I guess its the way to go.

Hi Adam,
first of all, good article!
Currently I’m trying to migrate my engine code to use an entity component system (guess why ;-] ), but what I really don’t grasp is how a system can retrieve data from another to perform its task.
For example: I have a system that deals with all the transform components, it arranges those components in a packed array and use handles to allow the user to access/query them with a level of indirection (so the transform array remains without holes). This system can rearrange its transform in memory whenever it needs (a transform is destroyed, is attached to another, etc)… and now, for example, it’s time to rendering all object to the screen…
Obviously there is another system, a rendering system, that needs to know where to render what, but how can collect all the data it needs from the transform system (e.g the world matrix) in a correct manner? because obviously the rendering components aren’t in the same order (in memory) of the transform components, and so, I can’t use the same array index to access sequentially the two arrays for better performance, so, every frame I need make a copy and reorder the transform components for the rendering system… is this the correct way? because there is also a clipping system, and so on, and all they needs a different layout…

Comments are closed.