Questions about the details of implementing a component-based entity system

Question

I started reading about component-based entities, and overall it seems like a good idea, but many of it seems to skip over a lot of details and not give many real examples, so there are things that don't really make sense to me. Note that I'm also mainly talking about the architecture where components only hold data and act as keys that trigger systems to be run for that entity, but this still mostly applies with each component having an update method that's called by the entity.

• When to think if it, many entities have things in common (like, for example, enemies with collision and physics), plus behavior that's specific to only that one kind of entity. Do I need to create lots of systems that are only good for one kind of entity, and are not at all generic/reusable?

• How should components interact with each other? I heard of using message queues, but that seems like it would be slow, plus how would I stop it from queueing messages that will never be read? Or is just setting fields in the component (to be checked by the other system) considered good?

• What's the best way to handle collision detection? A system that checks for collisions and sends events/stores the colliding objects in a component? Would just giving the world/entity manager a method (that would freely be used by different systems) to find colliding entities that have a certain component be a good idea? Or is there another way?

• How to handle animations changing based on events? if I have a component telling the animation component to switch to a certain animation, doesn't that make it so that the component can't be used with a different animation?

• In 2D, how would drawing order be handled? Especially if there are multiple kinds of drawing systems?

• With OOP you can store a reference to an object in another object, and call methods on it. How would the equivalent be done with an entity/component system, considering entities are not guaranteed to have certain components?

So how are these issues normally solved? Or am I thinking about this completely the wrong way?

Answer 1

When to think if it, many entities have things in common (like, for example, enemies with collision and physics), plus behavior that's specific to only that one kind of entity. Do I need to create lots of systems that are only good for one kind of entity, and are not at all generic/reusable?

If you put together all your different entity designs, you'll probably realize that there's a lot more behaviour than you think that you can generalize. If not, it's fine to create systems specific to certain types of entity.

How should components interact with each other? I heard of using message queues, but that seems like it would be slow, plus how would I stop it from queueing messages that will never be read? Or is just setting fields in the component (to be checked by the other system) considered good?

This depends on how you are going to structure your framework. I prefer keeping components as pure data and defining behaviour through systems. If you need two components to interact, just make a system that operates on those two component types.

What's the best way to handle collision detection? A system that checks for collisions and sends events/stores the colliding objects in a component? Would just giving the world/entity manager a method (that would freely be used by different systems) to find colliding entities that have a certain component be a good idea? Or is there another way?

I'd personally store contact information in the collision component itself. This way, many different systems can access the collisions and use the information. For example, the damage system could check for collisions with certain weapons and deduct the appropriate amount of health.

How to handle animations changing based on events? if I have a component telling the animation component to switch to a certain animation, doesn't that make it so that the component can't be used with a different animation?

This type of logic should be done in systems. I'd add an extra layer of abstraction, so the system only needs to decide the "purpose" of the animation. The animation data stored in the component maps "purpose" to the given animation. For example, the "run left" purpose could map to a series of frames that show the sprite running left, but this data could be different for each sprite.

In 2D, how would drawing order be handled? Especially if there are multiple kinds of drawing systems?

Just give the sprite component a depth field. There should be a central renderer that knows how to render a sprite with a given depth, and the rendering systems should just issue commands to the central renderer, not straight to your graphics library.

With OOP you can store a reference to an object in another object, and call methods on it. How would the equivalent be done with an entity/component system, considering entities are not guaranteed to have certain components?

This is why I make components pure data and constrain logic to systems. Basically, each system has a "mask" that states its required component types. For example, the rendering system requires both a position component and a sprite component. Each entity is also associated with a mask that states the component types it has. When the rendering system is invoked, it only loops through the entities that have masks that are compatible with its mask.