# ECS: Should Systems access only one component-type [duplicate]

Let's say I have a Transform-component-type, and a Color-component-type (to keep things simple). I also have an entity E that is assigned both of these component-types.

To render E, my engine will internally have to bind a uniform-buffer containing both a mat4-transformation-matrix, and a vec3-color.

Now I think I heard conflicting opinions about whether there should be a strict 1-to-1 component_type-to-system relation, or whether it is considered more appropriate to have systems which act on multiple component-types.

In the latter case I'd know how to do things. I would have a RenderSystem, which only considers entities which have both a Transform, and a Color component.

For the first case I don't have a solution though.. Both the TransformSystem and the ColorSystem wouldn't know how to render the entity, since they only hold a subset of what is required by the shader.

So I would just jump head-first into implementing my ECS as having one system potentially acting on multiple component-types, but I first wanted to hear from people having more experience with ECSs.

Are there good solutions in an ECS that maps systems 1-to-1 to components to achieve behavior that is the effect of the presence of multiple different component-types, or is a solution in which one system requires the presence of multiple component-types generally preferable?

• The original, purist approach in C/C++, by one of the coders on Tony Hawk: cowboyprogramming.com/2007/01/05/evolve-your-heirachy Sep 4 '20 at 6:28
• I've linked this question to existing Q&A that explains why ECS approaches often have a many-to-many relationship between components and systems, not a strict one-to-one. tl;dr: if you want a component A to be able to affect or be affected by anything in your game outside of itself, then at some point a system will need to consider it and at least some other component B. If you still have uncertainty after reviewing this, please feel free to edit your question to clarify what you need that's different from what's already answered. Sep 4 '20 at 6:34
• I'd also recommend keeping in mind that ECS is just a tool to help you do your work. We see a lot of users get stuck in a rabbit hole of contorting themselves to meet an idea of ECS purity, stalling their progress and making their own code less clear to them and harder to work with. Your game does not get points for ECS perfection. It gets points for shipping, and having a satisfying experience. So focus on what lets you achieve that, and give yourself permission to make your ECS that suits your needs, not "THE" ECS. Sep 4 '20 at 6:38
• Nonetheless, the purist approach remains the single best source by which to educate yourself on first principles. Sep 4 '20 at 6:55
• @DMGregory on my search I didn't find the linked post.. I will review it and edit if I consider my own questions different from the ones answered in your post. On your other comment: Yes, I'm aware that there is probably not a one-fits-all, or THE best solution. Still, before committing to a certain architecture I want to make sure I don't incorporate any unfortunate design-decisions right at the start, which could have been avoided if having been more educated.. Thus I preferred to ask rather than immediately trust my own intuition. Sep 4 '20 at 7:26