Does Specs support multiple components of the same type per entity?

(Johan Verwey) #1


The examples in the Specs book seem to indicate that components are always of a specific type and that there can be only one of that type. For example, there is only one Velocity component that uses the Mass and Force components as inputs.

Is it possible to have multiple components of the same type that are associated with an entity?
Imagine an real-time strategy game where armor components worn by units add to their total damage resistance.
I can add armor pieces dynamically to units and the score component would always reflect the total score of all the armor pieces combined for that entity. The armor components are all of the same concrete class, but may have different configurations based on which buffs it provides.

A ScoreSystem would be responsible for gathering all the ArmorComponents from Storage.
But Storage can only store one value per concrete type. So if I had multiple instances of ArmorComponent, with different configurations, how could I gather them all?

I could probably find a workaround by having different concrete classes for HeadArmor, BodyArmor, LegArmor etc, but I am interested to know whether specs supports having multiple components of the same type per entity.



(Joël Lupien) #2

You’ll want to store a list of armor resistances in a single component type. The component can contain multiple structs inside of it.

To answer your question, no you cannot have two of the same exact type on the same entity.


(Marco Fruhwirth) #3

Entities don’t have to be something material and if you see yourself thinking “I need to assign multiple components of the same type to my entity” it might be possible to introduce new entities (And I think that will always be possible). In your case I would propose a layout like this:

  • An entity player
  • Armour entities
  • A component armour slots, storing a list of armour entities assigned to the player entity
  • A component resistance assigned to the individual armours
  • A component damage assigned to the individual armours

A setup like this will allow you to stay flexible. You will have armour entities that can exist without being assigned to the player. Those entities could be useful to display an armor part that you can buy or so.

1 Like

(Marco Alka) #4

For my personal understanding, how would that compare to creating one armor component, which stores several armor pieces in a vec or slice, where each piece stores its resistance and damage on the piece-struct directly (except for the obvious, that I can have varying flavors of armor with entity/components)?


(Marco Fruhwirth) #5

I think it is mostly preference and it would have barely impact on performance. Personally I like the entity/component approach because it is open to change. If I want to prototype adding something like ‘armor health’ I can just add it to the respective amor piece entities and write systems related to that. Those systems don’t need to be aware of armor damage and armor resistance, so basically they are decoupled.

Another difference would be the ability to parallelize computations. Systems modifying resistances or damages can run independently from each other.