Should components have sub-components in a component-based system like Artemis?

I am designing a game using Artemis, although this is more of philosophical question about component-based design in general. Let's say I have non-primitive data which applies to a given component (a Component "animal" may have qualities such as "teeth" or "diet"). There are three ways to approach this in data-driven design, as I see it:

1) Generate classes for these qualities using "traditional" OOP. I imagine this has negative implications for performance, as systems then must be made aware of these qualities in order to process them. It also seems counter to the overall philosophy of data-driven design.

2) Include these qualities as sub-components. This seems off, in that we are now confusing the role of components with that of entities. Moreover out of the box Artemis isn't capable of mapping these subcomponents onto their parent components.

3) Add "teeth", "diet", etc. as components to the overall entity alongside "animal". While this feels odd hierarchically, it may simply be a peculiarity of component-based systems.

I suspect 3 is the correct way to think about things, but I was curious about other ideas.

• Not sure but i think you are confused with the Artemis terminology. An Aspect is a component combination used by Artemis system to determine if a given entity should be proceeded by a System. "Component "animal" may have aspects such as "teeth" or "diet" makes no sense to me. – nathan Oct 29 '12 at 19:26
• I'm not using aspect as artemis terminology here. I'll edit the question about to note that. – Daniel Ingraham Oct 29 '12 at 19:29
• What is Artemis? – jhocking Oct 29 '12 at 20:24
• @jhocking Artemis is a entity/component framework written in Java. – MichaelHouse Oct 29 '12 at 20:28
• @DanielIngraham Your example is very contrived. Having "Animal" as a component is very strange. I'm not sure what "teeth" as a component would do either. "Diet" I suppose I can see, but again it's odd. Perhaps if you use a reasonable example you'll be able to see more clearly. See this answer for a better idea on what you're dealing with. – MichaelHouse Oct 29 '12 at 20:39

The combination of components is what makes the entity. Giving entities certain components just so they can be categorized does not seem very useful. For example, consider two entities: A bear and a horse. They're both going to have pretty much identical components, just the data the components contain is going to differentiate them. A simple example would be:

            Horse           |  Bear
Component
Position:   10,32           |  10, 43
Health:     100/100         |  243/300
Attack:     Hooves          | Claws,Teeth
Sprite:     Horse.png       | Bear.png
Diet:       Hay             | Horse meat
Info:       Horse, rideable | Bear, run.


As you can see, they have identical components. However, the components have different data. You could expand on the information component, but it's likely going to contain common information for all the entities of that type. So it's probably better to just have it stored someone common and just have a reference to it in the component.

I would recommend keeping your components more general and use a different data structure for querying your entities, something outside of your entity framework. When you create an entity you can store its ID in a table for that type of animal. Then when you want to look up all the animals with teeth, you only need refer to your table and you'll get all the entity IDs that have that attribute.

Alternatively, Artemis has a tag system for entities you could utilize. Which is essentially what's described above. It allows you to add tags to entities and query all the entities that have those tags. Though, last time I looked at the source it wasn't implemented. So you may have to implement something yourself.