Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I've been reading a lot about entity components and systems and have thought that the idea of an entity just being an ID is quite interesting.

However I don't know how this completely works with the components aspect or the systems aspect. A component is just a data object managed by some relevant system. A collision system uses some BoundsComponent together with a spatial data structure to determine if collisions have happened.

All good so far, but what if multiple systems need access to the same component? Where should the data live? An input system could modify an entities BoundsComponent, but the physics system(s) need access to the same component as does some rendering system.

Also, how are entities constructed? One of the advantages I've read so much about is flexibility in entity construction. Are systems intrinsically tied to a component? If I want to introduce some new component, do I also have to introduce a new system or modify an existing one?

Another thing that I've read often is that the 'type' of an entity is inferred by what components it has. If my entity is just an id how can I know that my robot entity needs to be moved or rendered and thus modified by some system?

Sorry for the long post (or at least it seems so from my phone screen)!

share|improve this question

1 Answer 1

up vote 210 down vote accepted

There are a multitude of ways to represent and implement entity component systems, but here is an explanation of one way. Keep in mind there is no concrete definition of entity/component/system architectures, so this is just one implementation.

I'm going to introduce an analogy for entity/component/system architectures that might help. Let's think of an entity like a key.

The Entity

Entity key

Keys also have teeth (dark blue). The teeth of our entity key is the components that make it up. You can tell entities apart by their ID, even if they have the same teeth. So what do keys fit into? Locks. Locks are our systems. For example, a movement system.

The System

Movement system lock

The lock only works if our key has teeth for both position and velocity. This system only processes entities that have a position and a velocity. There are multiple ways to set up how these systems recognize which entities to process, but one way is to use a long. Each bit is reserved for a component type. For our example lets assume a 4 bit type instead of a 64 bit long. Our example entity would have all available components. So it's key would be 1111. Then, the system is looking for any entity that has a 11--. (The - represent don't care, because movement doesn't care if there's a sprite or health). It can check an entity with a simple AND operation. So our entity matches if ((1111 & 1100) == 1100). If I lost you there check out some more about bitwise operations.

As you can see, systems have access to outside resources. They can access the time, graphics, sound and so on. They are simply little processors that take one key at a time, and process data. You see that the movement system takes the velocity, delta time and position; then does some calculations and stores the result back into position.

The entity keys are really easy to generate. You can add or remove them at will. The entity doesn't care, it's just a way to group and hold the components. The components have no interdependence. The closest the components get to interacting with each other is when a system operates on them and uses data from one to update another, like our movement example.

Lets take a look at another system to help solidify the idea:

Drawing system lock

This is our drawing system. It looks for components that match 1-1-. This entity matches because: ((1111 & 1010) == 1010) Additionally, you can see that this system outputs information to the screen, by drawing the entity sprite at its position.

OK, one more. Let's look at another entity and see how it might fit into our example so far.

Non moveable entity key

As you can see, this entity has fewer components attached to it. By looking at the components it does have, it looks like it could be a static item like a rock. It just has a position and a sprite. It's not going to move and it's not going to be affected by any health changes. This entity would produce a key of 1010. So what systems operate on this entity? Lets check:

Against our movement system: ((1010 & 1100) != 1100) Nope. Looks like the movement system doesn't care about this entity, because it doesn't have the components required.

Against our drawing system: ((1010 & 1010) == 1010) Hey, that's a match. This entity will be operated on by the drawing system. The drawing system will draw the sprite at the position defined.


Hopefully you can see how easy it would be to now add another system that would take our components and operate on them. Let me ensure I've addressed your questions:

What if multiple systems need access to the same component? Where should the data live?

Typically, systems operate one after the other. They process all the entities that match their requirements, then the next system does the same and so on. The data lives with the entity. There shouldn't be anything stored in the system, it's just a lock that gets turned, the key is where the information stays and moves from lock to lock.

How are entities constructed? Are systems intrinsically tied to a component? If I want to introduce some new component, do I also have to introduce a new system or modify an existing one?

Entities are just bags of components. They have a unique ID and a list of components. Systems are only tied to components in the way described above. You can have components without systems that operate on them, but that's pretty pointless. Similarly you can have systems that are looking for components that no entities have. That's less pointless, because they may just be waiting for an entity to be created that matches their lock. So, yes, if you introduce a new component, you'd want to make a system that utilizes that component. Otherwise you're just adding teeth to your key for a lock that doesn't exist.

If my entity is just an id how can I know that my robot entity needs to be moved or rendered and thus modified by some system?

I think I answer this with the idea of a long key that defines the components contained in an entity. You know because the key fits the lock.

Phew! That was a long post! (Or at least it seems so from my large monitor.)

share|improve this answer
17  
This key analogy is really helpful for understanding the whole idea now. Brilliant idea! Lol at your last paragraph :) –  bio595 Jul 2 '12 at 2:42
11  
+1 For the greatest and best explanation of the entity-component system I have ever seen. :O! –  knight666 Jul 2 '12 at 6:57
20  
@Kylotan I do say "There are multiple ways to set up how these systems recognize which entities to process, but one way is to use a long." Additionally, I usually reserve the down vote for answers that are not useful (as the hover text says). I think you'd spend a lot of time down voting if you did it for all the answers that didn't cover 100% of the topics they're addressing. –  Byte56 Jul 2 '12 at 13:04
7  
@Kylotan No matter what method you use to implement your entity system, Byte56's post most definitely helps us to "better understand them as a whole". Stop nitpicking and contribute an answer that expands our knowledge with other implementation methods. –  Crappy Coding Guy Jul 3 '12 at 15:34
7  
Understood. gamedev.stackexchange.com/a/4966/1101 –  Kylotan Jul 3 '12 at 21:14

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.