Hi Inferiarium,

Thanks for the response.  I'll address the questions below:

I wrote that as a comment to the journal entry, but I guess it does actually make more sense to add it here:

Why does the damage System handle the collisions? I would rather let a physics system handle collisions and send a message on collision which can be hooked by other systems.

The Damage system I showed was just an example, but it doesn't really "handle' the collisions.  The collision component is added to an entity when it is in contact with another entity.  This example Damage handles entities with a Health component that have collided with another entity, so it can add damage to that entity. You could create another system, say StickyBombSystem, which, when a bomb entity (which has a stickybomb component) has collided with another entity, the StickyBombSystem would start a count down on the StickyBomb and permanently attach itself to the entity in question until the timer expired, which would cause the Stickybomb to explode.

Also, what does the input component do? Of course you have an input system (or maybe better player control system which gets input from the input system). Now lets say a key is pressed which should change the velocity. You should change the velocity i guess. What i want to say is that some systems work on the data which is already there, this is also why I do not like the idea of determining the systems used based on the components.

In the example, the Input component just signifies which entity the user can control.  In typical games, the user can certainly control the Main Player, but there are times when the user will want to control different characters.  If you have a "party" game, you might have 5 different characters the user can control.  Being able to move the Input component from one entity to another allows you to do this (I actually do this in the example app TestEcs.cpp in the DeathSystem).  Realize, as well, the user will have to control Menus, and the Input Component could be added to those Menu Entities.

It should be the other way round. For each entity you define which systems it uses and the systems add the components needed (if not already added by another system)

I don't think that's the right way to go about it.  It's the components that make the entity, and typically, all components will be acted on the same way by the same System.  For example, the RenderingSystem operates on the GraphicalObject Component, and it does the same thing for all of them: Get the position and angle of the entity (from the PhysicalObject Component attached to the entity), get the sprite from the GraphicalObject, and draw the sprite, with the correct rotation at the correct position on the screen.

edit: Another more general thing is that I am not sure what the application is of being able to remove and add components on the fly (other than maybe for testing). The way I see it the goal of the component based design is to make the creation of new entity types easier and more flexible and not making the entities themselves 'more flexible'

As I've noted below, being able to move Components around entities is a major part of an Entity Component System.  What happens when a Player picks up Armor?  He needs to have an Armor component added.  Or a Jetpack?  And, I've described how I switch Input Components.

Thanks for the comments!

Hi Inferiarium,

Thanks for the response.  I'll address the questions below:

I wrote that as a comment to the journal entry, but I guess it does actually make more sense to add it here:

Why does the damage System handle the collisions? I would rather let a physics system handle collisions and send a message on collision which can be hooked by other systems.

The Damage system I showed was just an example, but it doesn't really "handle' the collisions.  The collision component is added to an entity when it is in contact with another entity.  This example Damage handles entities with a Health component that have collided with another entity, so it can add damage to that entity. You could create another system, say StickyBombSystem, which, when a bomb entity (which has a stickybomb component) has collided with another entity, the StickyBombSystem would start a count down on the StickyBomb and permanently attach itself to the entity in question until the timer expired, which would cause the Stickybomb to explode.

Also, what does the input component do? Of course you have an input system (or maybe better player control system which gets input from the input system). Now lets say a key is pressed which should change the velocity. You should change the velocity i guess. What i want to say is that some systems work on the data which is already there, this is also why I do not like the idea of determining the systems used based on the components.

In the example, the Input component just signifies which entity the user can control.  In typical games, the user can certainly control the Main Player, but there are times when the user will want to control different characters.  If you have a "party" game, you might have 5 different characters the user can control.  Being able to move the Input component from one entity to another allows you to do this (I actually do this in the example app TestEcs.cpp in the DeathSystem).  Realize, as well, the user will have to control Menus, and the Input Component could be added to those Menu Entities.

It should be the other way round. For each entity you define which systems it uses and the systems add the components needed (if not already added by another system)

edit: Another more general thing is that I am not sure what the application is of being able to remove and add components on the fly (other than maybe for testing). The way I see it the goal of the component based design is to make the creation of new entity types easier and more flexible and not making the entities themselves 'more flexible'

As I've noted below, being able to move Components around entities is a major part of an Entity Component System.  What happens when a Player picks up Armor?  He needs to have an Armor component added.  Or a Jetpack?  And, I've described how I switch Input Components.

Thanks for the comments!