At 10/9/13 06:16 PM, Rustygames wrote:
It certainly does sound interesting to have the systems automatically pick up on which VO's (components) have that data and then act upon them if they do. Presumably any changes would either be polled or the system would just fire some update event notifying the view components to redraw etc.
I can see the systems becoming somewhat hard coupled though. Allow me to use wikipedias example to illustrate a scenario:
"Another system could be a collision detection. It would iterate through all entities that have a physical component, as it wouldn't care how the entity is drawn. This system would then detect arrows that collide with monsters, and generate an event when that happens. It shouldn't need to understand what an arrow is, and what it means when another object is hit by an arrow.
Yet another component could be health data, and a system that manages health. Health components would be attached to the human and monster entities, but not to arrow entities. The health management system would subscribe to the event generated from collisions and update health accordingly. This system could also now and then iterate through all entities with the health component, and regenerate health."
The problem I foresee here is that you instantly have a hard coupled dependency between the health system and the collision system. The health system must update it's components on certain collision events.
Suppose the angle you hit a wall at is relevant to how much health you lose. That data would need to come in a payload from the collision event.
Now what if I want to take my health system and move it to another game where collision is not the system which health events are interested in, and damage is no longer calculated based on angle, it's based on how sharp the enemies sword is. I'm going to either add methods to health and leave some unused redundant code in there (very bad) or write a new health component (meaning the code isn't reusable).
Also I was wondering about systems editing many components and potentially conflicting since it's a bit of a free-for-all on them.
Please forgive me if I'm talking rubbish since I've never used the pattern before :)
In a proper design, you should only really have 1 system modifying components, but you can have several systems reading them.
Wikipedia's example is bad design :P
What I would do is the same up until the Collision. The CollisionSystem would add a CollisionComponent to both entities that just collided. Then, an ArrowSystem would be listening to entities that have a CollisionComponent and ArrowComponent, and then calculates the inflicted damage. It then creates a new entity, that only has a DamageComponent, which holds the amount of damage, and a reference to the target entity. Yet another DamageSystem picks up entities with DamageComponents, and then inflicts that damage to the target entity (who has a HealthComponent).
Which means in this case the DamageSystem is completely independent, it only needs entities with a DamageComponent, and target entity. Anything can generate damage at this point. The specific implementation comes in the ArrowSystem, which can be removed, and not affect anything, or in another game, you create a new System that would generate the entities with the DamageComponent based on different factors, w/e.
Btw, about several systems modifying several components, it either just naturally doesn't happen (if it does, it's usually just bad design), or if it happens to happen at some point, it doesn't really matter much.
In response to your example, the SwordSystem would take entities with a CollisionComponent, and SwordComponent, and then the SwordComponent would probably have a sharpness property you can use.
If something seems coupled, you just take an axe and chop it up until it's not coupled anymore!