2
\$\begingroup\$

This question already has an answer here:

I kind of stucking at my current plattformer protoype for learning the component based entity system pattern.

I have CollisionComponent and a CollisionSystem. The CollisionSystem checks every frame all entities with CollisionComponents for intersection. Then it marks inside the CollisionComponent the entities which are colliding with this entity. So if an entity A collides with Entity B then they both have a the other as a reference inside their CollisionComponent as data.

This works absolutely fine and I can tell which entity is colliding with something/someone.

Now I have the problem how to use this information properly. I have a MovementSystem and it moves entities with a MovementComponent based on the velocity and the acceleration.

Who is now responsible for NOT moving a entity or do something else on a collision. Should the MovementSystem check if the entity has a CollisionComponent and if there is one, should the MovementSystem handle the NOT movement?

Let's say I have this situation. I have an entity (player) with a MovementComponent and a velocity to the right (because the player presses the right arrow) and the usual downwards velocity due of gravity influences. The player entity collides with another entity. A GroundComponent entity. Now which system should put entity A (the player) upwards so that he does not colliding with the ground anymore? The MovementSystem? At the same time, the player entity collides with another entity, an enemy. Which system should now handle the damage, or the knockback or whatever that enemy does to a player unit?

I really like the CBES but it really does not get into my mind how everything glues together.

I want to threat the components as pure data, so no logic in there (besides of ScriptComponents, but this is another type of problem)

Now my question is, which system handles which cases and how to treat passes of system (e.g. Movement pass one then the other systems then movement pass 2 and so on? How many systems do I really need and should a system only handle one type of problem? MovementSystem -> pure movement no matter what. CollisionSystem -> pure collision registration no matter what, DamageSystem -> damage handling based on component data

\$\endgroup\$

marked as duplicate by Anko, FxIII, Josh Dec 2 '14 at 17:50

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • \$\begingroup\$ @Byte56 I did not find a solution on your posted link. But no problem, I ask somewhere else \$\endgroup\$ – Ello Nov 23 '14 at 8:41
  • \$\begingroup\$ @Ello If you want to raise additional attention for an existing question, we have bounties for that. In what ways do the existing answers fail you? (You should also post a comment asking to clarify an unclear answer.) \$\endgroup\$ – Anko Nov 26 '14 at 12:41
3
\$\begingroup\$

I'll try to explain with an example:

Let's say we have an RPG where you can enchant your weapons with elemental damage. The weapon still have a "physical" attack power, which is reduced by the enemies "phyical armor". But now we have elemental damage, and thus the enemies might have elemental resistances.

This is perfect for Entity Component System, because we can normally attach WeaponComponents on the weapon to describe physical damage, and ArmorComponents on the enemies to describe physical defense. To add the elemental mechanics, we simply add the elemental counterparts of the Weapon and Armor Components and Systems.

Thus, when resolving the damage of an attack, both Weapon/Armor and Elemental/Resistance components and systems will add gross damage to the net, final damage dealt.

In regard to your Movement/Collision problem, I would try to make a "MovementBlockingCollisionSystem", where the system will check for collisions and the direction of collision and hard set the position of the entity in a way it will be right on the collision surface without overlapping with it. You might still want to keep your CollisionSystem so you can check for collisions without blocking movement (useful for triggers or "ghost" enemies).

By the end of the day, it all really depends on how you model your data and how willing you are to write several, specialized Systems.

\$\endgroup\$
  • \$\begingroup\$ thank you. As I understand it now, it does not matter how you model your systems and they depend on so many things that it is more important rather to just do it in the system than to over design it in the first place \$\endgroup\$ – Ello Nov 26 '14 at 16:25

Not the answer you're looking for? Browse other questions tagged or ask your own question.