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)!
Answer
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
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
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:
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.
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.)
No comments:
Post a Comment