# How to avoid “Blob-Systems” in an entity component system?

Currently I am facing the following problem:

I am trying to write a pong clone by using an entity component system (ECS). I wrote the "framework" all by myself. So there is a class which manages the entities with all the components. Then there are the component classes themselves. And last there are my systems which just get all the entities which have components which the system needs.

So for example my movement system looks for all entities which have a position component and a movement component. The position component just holds the position and the movement component holds the speed.

But the actual problem is my collision system. This class is like a logical blob. I have so much special cases in this class.

For example: My paddles can collide with the borders. If this happens their speed is set to zero. My ball can as well collide with the borders. But in this case its speed is just mirrored at the normal of the border so it is reflected. To do this I gave the ball an extra physics component which just tells: "Hey, this thing does not stop, it reflects." So actually, the physics component has no real data. It is an empty class which is just there to tell the system if an object reflects or stops.

Then there comes this: I want to render some particles when the ball collides with the paddles or the borders. So I think the ball has to get another component which tells the collision system to create particle on collision.
Then I want to have power ups which can collide with the paddles but not with the borders. If that happens the power-ups have to disappear. So I would need much more cases and components (to tell the system that some entities can only collide with certain others, bot not with all even if some others are actually able to collide, furthermore the collision system had to apply the power-ups to the paddles, etc., etc., etc.).

I see that the entity component system is a good thing because it is flexible and you do not have problems with inheritance. But I am totally stuck currently.

Am I thinking too complicated? How should I cope with this problem?

Sure, I have to create systems which are actually responsible for "post-collision", so the collision system only tells "Yes, we have a collision in the last frame" and then there is a bunch of "post-collision" systems which all require different (combinations of) components and then change the components. For example there would be a movement post-collision system which stops things which have to stop when collision happens. Then a physics post-collision-system which reflects things, etc.

But this does not seem to be a proper solution to me either, because for example:

1. My movement post-collision system would need entities which have a position component, a movement component and collision component. Then it would set the speed of the entity to zero.
2. The physics post-collision system would need entities which have a position component, a movement component, a collision component and a physics component. Then it would reflect the speed vector.

The problem is obvious: Movement post-collision needs entities which are a subset of the entities in physics post-collision system. So two post-collision systems would operate on the same data, the effect being: Although an entity has a physics component, it speed would be zero after a collision.

How are these problems solved in general in an entity component system? Are those problems even usual or am I doing something wrong? If yes, what and how should it be done instead?

Yes, you're thinking too complicated.

It sounds like a lot of your problems could be solved with a messaging system and some additional attributes that allow you to specify some filters, and finally not worrying about being so strict with entities/components.

Messaging will help you with some aspects like triggering particles, powerups, and so on. For example, you could have a world object that subscribes to particle events and creates particles at the position described in the event.

Filters will help you a lot in collisions. Filters can define if an object collides with another, and what response it will have. You add some attributes to your physics component that defines what type of physics body it is, what other types of physics bodies it collides with and what the response should be. For example, a ball physics object collides with a paddle physics object and responds with reflection and particles.

Finally, don't be so strict about your implementation. If you can find a way to make it work, but it's not really EC system, do it. Like in my example above, the particles to not need to be managed by a system or part of the EC system at all. It's more important to finish the game than it is to strictly follow a method that's already pretty poorly defined.

• Thank you very much. I wanted to build a game by using an ECS just to look how it scales and if it is really that nice to use as I read in articles and tutorials. My problem was that I thought: "I have an ECS now and everything has to be managed by this." So I planned as well to write the particle system in connection to the ECS. Also, I read in some articles that every component should really only have some basic data and nothing more. That is often my problem... I think too complicated. – M0rgenstern Jun 7 '13 at 4:40
• I wanted to build a game by using an ECS just to look how it scales and if it is really that nice to use as I read in articles and tutorials. If that is your goal, I recommend you look at existing Component/Entity systems instead of building your own. Download Unity3D, which is probably "as pure Components as it can get" and play around there. Much faster insights, IMHO. – Imi Jun 7 '13 at 9:43
• @lmi: Unity isn't an Entity Component System though it is component-based. ECS has some rather stricter guidelines (never think of a pattern as rules) than simply having and using game object components. Due to a series of articles ECS is popular with some segments of game developers right now so there's a lot of questions on ECS specifically rather than component-based design in general. – Sean Middleditch Jun 7 '13 at 21:02

You are over-complicating things. I would go so far as to say that even using component-based design is just overkill for such a simple game. Do things the way that makes your game quick and easy to develop. Components help with iteration in larger projects with a huge variety of behaviors and game object configurations but their benefit to such a simple well-defined game is more questionable. I did a talk last year about this: you can build fun little games in a few hours if you focus on making a game instead of adhering to an architecture. Inheritance breaks down when you have 100 or even 20 different types of objects but it works just fine if you only have a handful.

Assuming you want to keep using components for learning purposes, there's some obvious problems with your approach that stand out.

First, don't make your components so small. There's no reason to have fine-grained components like 'movement'. There is no generic movement in your game. You have paddles, whose movement is tightly tied to input or AI (and don't really use velocity, acceleration, restitution, etc.), and you have the ball, which has a well-defined movement algorithm. Just have a PaddleController component and a BouncingBall component or something along those lines. If/when you get a more complicated game then you can worry about having a more generic PhysicsBody component (which in 'real' engines is basically just a link between the game object and whatever internal API object is used by Havok/PhysX/Bullet/Box2D/etc.) that handles a wider variety of situations.

Even a 'position' component is questionable though certainly not uncommon. Physics engines typically have their own internal idea of where an object is, graphics might have an interpolated representation, and AI might have yet another representation of the same data in a different state. It can be advantageous to just give let each system manage its own idea of the transform in the system's own components and then ensure there's smooth communication between system. See the BitSquid blog post on event streams.

For custom physics engines remember that you are allowed to have data on your components. Maybe a generic Pong physics component has data indicating which axes it can move on (say, vec2(0,1) as a multiplier for paddles which can only move on the Y axis and vec2(1,1) for the ball indicating it can move however), a flag or float indicating bounciness (the ball would typically be at 1.0 and paddles at 0.0), acceleration characteristics, velocity, and so on. Trying to split this up into a bazillion different micro-components for each piece of highly-related data is counter to what ECS were originally meant to do. Keep things that are used together in the same component where possible and only split them up when there is a large difference in how each game object uses that data. There's an argument to make that for Pong the physics between the ball and the paddles is different enough to be separate components, but for a larger game, there's little reason to try to make 20 components to do what works just fine in 1-3.

Remember, if/when your version of ECS gets in the way, do what you need to actually make your game and forget dogged adherence to a design pattern/architecture.

• Really, thank you! I know, that a ECS does not scale very well for a small game like pong. But I used it just to see how such a thing is actually implemented and how it works. I made the components so small, because that was what I read mostly in some articles. To have many components and each component only holds elementary data. So, do I understand you right, that you suggest to use a mix between inheritance and ECS? As you say "the ball and the paddles is different enough to be separate components". So for example I give them both a Movement/Position component (maybe as one component) and – M0rgenstern Jun 7 '13 at 4:42
• Whatever works. Focus on making the game. I would literally just have a component called Ball that contains all the logic for the ball like movement, bouncing, etc. and a Paddle component that takes input, but that's me. Whatever makes the most sense to you and gets out of your way and lets you make the game is the "correct way" to do things. – Sean Middleditch Jun 7 '13 at 6:25
• I would literally just have a component called Ball that contains all the logic for the ball like movement, bouncing, etc. and a Paddle component that takes input, but that's me. And that's why there is one opinion for each programmer about "what is an component system about". I recommend NOT to do it like this suggestion, except you are totally thinking in classic Entity systems and are forced to use a Component system but don't want to look what the differences actually are. – Imi Jun 7 '13 at 9:47
• @lmi: having worked on a few big games/engines with components and seeing first-hand why we use components, no, overly granular components are just more trouble than they're worth. Components aren't a magic bullet; they're one of many tools in a game developer's toolbox. Use them in a way and place that they help and not in ways that they just add more mental and runtime overhead to the system. If the only thing that has ball-physics is the ball, there is zero advantage to separating it from other ball properties. If and when that changes, split it up then and then only. – Sean Middleditch Jun 9 '13 at 22:00
• I agree the principle of being pragmatic and not letting a particular patter get in they way. BUT if ECS is unable to handle this trivial game without deviation, what hope is there for a large game. I too am trying to learn how to use ECS effectively, but I am trying to stay as close to the ECS philosophy as possible, otherwise, once I start making exceptions and special cases, I know I'll end up with an unmaintainable mess. – Ken Jun 4 '15 at 14:44

Edit: I posted this answer below back in 2013. Now, as I learned more about the "S" in an ECS, I came to the opposite conclusion. So treat my answer below as an "historical statement". ;)

In my opinion *), your biggest problem with Components is this: Components are NOT here to tell anyone else what to do. Components are here to DO things. You don't have a component just to hold the memory of some thing and then have other components operate on this. You want components that DO stuff with the data they got.

If you see yourself testing for the presence of other components (and then call functions there), then this is a clear sign, that either one of two things are true:

• You actually want to invert the dependency: The other component should listen to events/messages/broadcasts/hooks/howeveryounamethem to execute their logic in response of your current component. The current component does not even have to know that there is an "other" component. This is most often the case, if you find yourself calling different components (even in different else/case blocks) with functionality that is not really connected to your current method. Think of all these Invalidate() or SetDirty() calls to other components.
• You may have too many components. If two components just can not live without each other and constantly need to retrieve data and call methods to each other, then just merge them. Obviously, the functionality they provide are so entangled, that its actually really only one thing.

By the way, these applies to all kinds of systems, not only Entity/Component systems, but also to classic inheritance with simple "GameObject"s or even library functions.

*) Really only mine. Opinions heavily vary about Whats Da Real Component Systemz (TM)