Return to Answer

My point is: if the Systems are the ones responsible for the actual game logic update (practically speaking, the game logic code is written inside the system), is there a 1:1 relation between every component and every system ?

There are few ECS frameworks, like Svelto.ECS, where there isn't a direct correlation between Systems and Components. I first saw this concept in the Ash ECS and I extended it in my Svelto.ECS. In Svelto.ECS Entities group components, but Engines know the entities components only through a node mapping. So it would be absolutely wrong to write a System for each component. Usually Systems query entities (and you can get the components from the entities), but with nodes you can do even better.

A similar question was asked before and someone actually gave a very good answer that I now use to save time:

It is common for "systems" (or "engines" as they are known in svelto) to need to access multiple components per entity. For example an EnemyEngine might need to access a Health component, an Ammo component and a Positioning component. This creates at least a 1-to-many relationship between Engines and Components. (In fact once you share components among several engines that turns into a many-to-many relationship - but only the 1-to-many side of it need be modeled).
Their solution to this problem is the Nodes concept. They represent that 1-to-many relationship as a Node object and that object might hold several components within it. Then they simply have a 1-to-1 relationship between Engines and Nodes. It also means an Engine need only manage a single object which fully embodies the relevant aspects of an entity.

I wrote a lot of articles about Inversion of Control and how ECS is the definitive pattern to exploit the principle. If you have the time, you may want to have a look a these articles. If you have questions, I will be happy to answer:

//Dissertation on how to exploit the ECS pattern to achieve Inversion of Control

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-i-dependency-injection/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-ii-inversion-of-control/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-iii-entity-component-systems/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-iv-dependency-inversion-principle/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-v-drifting-away-from-ioc-containers/

//how my ECS framework works in practice

http://www.sebaslab.com/ecs-1-0/

http://www.sebaslab.com/svelto-ecs-svelto-tasks-new-example-plus-whats-coming-and-optimization-related-thoughts/

My point is: if the Systems are the ones responsible for the actual game logic update (practically speaking, the game logic code is written inside the system), is there a 1:1 relation between every component and every system ?

There are few ECS frameworks, like Svelto.ECS (which I wrote), where there isn't a direct correlation between Systems and Components. I first saw this concept in the Ash ECS and I extended it in Svelto.ECS. In Svelto.ECS Entities group components, but Engines know the entities components only through a node mapping. So it would be absolutely wrong to write a System for each component. Usually Systems query entities (and you can get the components from the entities), but with nodes you can do even better.

A similar question was asked before and someone actually gave a very good answer that I now use to save time:

It is common for "systems" (or "engines" as they are known in svelto) to need to access multiple components per entity. For example an EnemyEngine might need to access a Health component, an Ammo component and a Positioning component. This creates at least a 1-to-many relationship between Engines and Components. (In fact once you share components among several engines that turns into a many-to-many relationship - but only the 1-to-many side of it need be modeled).
Their solution to this problem is the Nodes concept. They represent that 1-to-many relationship as a Node object and that object might hold several components within it. Then they simply have a 1-to-1 relationship between Engines and Nodes. It also means an Engine need only manage a single object which fully embodies the relevant aspects of an entity.

I wrote a lot of articles about Inversion of Control and how ECS is the definitive pattern to exploit the principle. If you have the time, you may want to have a look a these articles. If you have questions, I will be happy to answer:

//Dissertation on how to exploit the ECS pattern to achieve Inversion of Control

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-i-dependency-injection/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-ii-inversion-of-control/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-iii-entity-component-systems/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-iv-dependency-inversion-principle/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-v-drifting-away-from-ioc-containers/

//how my ECS framework works in practice

http://www.sebaslab.com/ecs-1-0/

http://www.sebaslab.com/svelto-ecs-svelto-tasks-new-example-plus-whats-coming-and-optimization-related-thoughts/

My point is: if the Systems are the ones responsible for the actual game logic update (practically speaking, the game logic code is written inside the system), is there a 1:1 relation between every component and every system ?

There are few ECS frameworks, like Svelto.ECS, where there isn't a direct correlation between Systems and Components. I first saw this concept in the Ash ECS and I extended it in my Svelto.ECS. In Svelto.ECS Entities group components, but Engines know the entities components only through a node mapping.

A similar question was asked before and someone actually gave a very good answer that I now use to save time:

It is common for "systems" (or "engines" as they are known in svelto) to need to access multiple components per entity. For example an EnemyEngine might need to access a Health component, an Ammo component and a Positioning component. This creates at least a 1-to-many relationship between Engines and Components. (In fact once you share components among several engines that turns into a many-to-many relationship - but only the 1-to-many side of it need be modeled).
Their solution to this problem is the Nodes concept. They represent that 1-to-many relationship as a Node object and that object might hold several components within it. Then they simply have a 1-to-1 relationship between Engines and Nodes. It also means an Engine need only manage a single object which fully embodies the relevant aspects of an entity.

I wrote a lot of articles about Inversion of Control and how ECS is the definitive pattern to exploit the principle. If you have the time, you may want to have a look a these articles. If you have questions, I will be happy to answer:

//Dissertation on how an IoC container could be damanging to use and why the ECS pattern is in reality a much better tool

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-i-dependency-injection/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-ii-inversion-of-control/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-iii-entity-component-systems/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-iv-dependency-inversion-principle/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-v-drifting-away-from-ioc-containers/

//how my ECS framework works in practice

http://www.sebaslab.com/ecs-1-0/

http://www.sebaslab.com/svelto-ecs-svelto-tasks-new-example-plus-whats-coming-and-optimization-related-thoughts/

My point is: if the Systems are the ones responsible for the actual game logic update (practically speaking, the game logic code is written inside the system), is there a 1:1 relation between every component and every system ?

There are few ECS frameworks, like Svelto.ECS, where there isn't a direct correlation between Systems and Components. I first saw this concept in the Ash ECS and I extended it in my Svelto.ECS. In Svelto.ECS Entities group components, but Engines know the entities components only through a node mapping. So it would be absolutely wrong to write a System for each component. Usually Systems query entities (and you can get the components from the entities), but with nodes you can do even better.

A similar question was asked before and someone actually gave a very good answer that I now use to save time:

It is common for "systems" (or "engines" as they are known in svelto) to need to access multiple components per entity. For example an EnemyEngine might need to access a Health component, an Ammo component and a Positioning component. This creates at least a 1-to-many relationship between Engines and Components. (In fact once you share components among several engines that turns into a many-to-many relationship - but only the 1-to-many side of it need be modeled).
Their solution to this problem is the Nodes concept. They represent that 1-to-many relationship as a Node object and that object might hold several components within it. Then they simply have a 1-to-1 relationship between Engines and Nodes. It also means an Engine need only manage a single object which fully embodies the relevant aspects of an entity.

I wrote a lot of articles about Inversion of Control and how ECS is the definitive pattern to exploit the principle. If you have the time, you may want to have a look a these articles. If you have questions, I will be happy to answer:

//Dissertation on how to exploit the ECS pattern to achieve Inversion of Control

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-i-dependency-injection/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-ii-inversion-of-control/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-iii-entity-component-systems/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-iv-dependency-inversion-principle/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-v-drifting-away-from-ioc-containers/

//how my ECS framework works in practice

http://www.sebaslab.com/ecs-1-0/

http://www.sebaslab.com/svelto-ecs-svelto-tasks-new-example-plus-whats-coming-and-optimization-related-thoughts/

My point is: if the Systems are the ones responsible for the actual game logic update (practically speaking, the game logic code is written inside the system), is there a 1:1 relation between every component and every system ?

There are few ECS frameworks, like Svelto.ECS, where there isn't a direct correlation between Systems and Components. I first saw this concept in the Ash ECS and I extended it in my Svelto.ECS. In Svelto.ECS Entities group components, but Engines know the entities components only through a node mapping.

A similar question was asked before and someone actually gave a very good answer that I now use to save time:

It is common for "systems" (or "engines" as they are known in svelto) to need to access multiple components per entity. For example an EnemyEngine might need to access a Health component, an Ammo component and a Positioning component. This creates at least a 1-to-many relationship between Engines and Components. (In fact once you share components among several engines that turns into a many-to-many relationship - but only the 1-to-many side of it need be modeled).
Their solution to this problem is the Nodes concept. They represent that 1-to-many relationship as a Node object and that object might hold several components within it. Then they simply have a 1-to-1 relationship between Engines and Nodes. It also means an Engine need only manage a single object which fully embodies the relevant aspects of an entity.

I wrote a lot of articles about Inversion of Control and how ECS is the definitive pattern to exploit the principle. If you have the time, you may want to have a look a these articles. If you have questions, I will be happy to answer:

//Dissertation on how an IoC container could be damanging to use and why the ECS pattern is in reality a much better tool

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-i-dependency-injection/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-ii-inversion-of-control/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-iii-entity-component-systems/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-iv-dependency-inversion-principle/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-v-drifting-away-from-ioc-containers/

//how my ECS framework works in practice

http://www.sebaslab.com/ecs-1-0/

http://www.sebaslab.com/svelto-ecs-svelto-tasks-new-example-plus-whats-coming-and-optimization-related-thoughts/

My point is: if the Systems are the ones responsible for the actual game logic update (practically speaking, the game logic code is written inside the system), is there a 1:1 relation between every component and every system ?

There are few ECS frameworks, like Svelto.ECS, where there isn't a direct correlation between Systems and Components. I first saw this concept in the Ash ECS and I extended it in my Svelto.ECS. In Svelto.ECS Entities group components, but Engines know the entities components only through a node mapping.

A similar question was asked before and someone actually gave a very good answer that I now use to save time:

It is common for "systems" (or "engines" as they are known in svelto) to need to access multiple components per entity. For example an EnemyEngine might need to access a Health component, an Ammo component and a Positioning component. This creates at least a 1-to-many relationship between Engines and Components. (In fact once you share components among several engines that turns into a many-to-many relationship - but only the 1-to-many side of it need be modeled).
Their solution to this problem is the Nodes concept. They represent that 1-to-many relationship as a Node object and that object might hold several components within it. Then they simply have a 1-to-1 relationship between Engines and Nodes. It also means an Engine need only manage a single object which fully embodies the relevant aspects of an entity.

I wrote a lot of articles about Inversion of Control and how ECS is the definitive pattern to exploit the principle. If you have the time, you may want to have a look a these articles. If you have questions, I will be happy to answer:

//Dissertation on how an IoC container could be damanging to use and why the ECS pattern is in reality a much better tool

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-i-dependency-injection/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-ii-inversion-of-control/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-iii-entity-component-systems/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-iv-dependency-inversion-principle/

http://www.sebaslab.com/the-truth-behind-inversion-of-control-part-v-drifting-away-from-ioc-containers/

//how my ECS framework works in practice

http://www.sebaslab.com/ecs-1-0/

http://www.sebaslab.com/svelto-ecs-svelto-tasks-new-example-plus-whats-coming-and-optimization-related-thoughts/