Hi
When creating an enemy information display, I need to get all components on an entity. Now the [java]ed.getEntity(EntityId arg0, Class … arg1)[/java] returns only the components I ask for right?
Could I go with a component interface, to get all components implementing a certain interface (say ‘IEnemyComponent’) ?
I’d like to follow best practice, so I’m asking preactively instead of discovering later on that I’ve done it all wrong 
Kind regards,
Asser
Why do you have multiple EnemyComponents?
That kinda looks like a wrongfully split component.
Please explain your components in a bit more details.
I have components such as health, speed, damage etc. These components are used not only by enemies but by my own units as well.
But an enemy may have any number or even just one of these components (i have maybe 50 different components defined right now).
Systems should ask for the components that they will deal with. Asking for all components is a sign of a major design problem (there could be hundreds of components that are irrelevant to the system asking). So you may need to explain more.
If a system knows how to deal with health, speed, damage (kind of unlikely) then it should ask for those.
You probably want a enemy Component then,
You should know in the system taht you need all entitys with enemy component,
and then all health, all armour ect.
To me “enemy” seems like a completely human concept. It would have to be explained why a system cares what “enemy” is… and then yes, it probably deserves a component.
…still, I’m looking very skeptically at the whole idea.
A little clarification seems in order 
Systems should ask for the components that they will deal withI agree. All my systems to handle game logic only uses 1 or 2 components.
The ‘system’ that is troubling me here is not a system to handle game logic per say. I simply want to display all available information about a unit, to the player. If he selects his own units, all information is displayed, if he selects an enemy, only a subset is displayed.
Does that make more sense?
I know it goes agains the whole ‘entity system’ design, but the use case is still valid I think.
Anyone have any idea of how to accomplish this without breaking the design ?
Also, I know I have to keep track of which components to display to the player, somehow, because not all components are ment to be known by the player. But the issue is still valid.
Well just make it a whitelist then, as else you might leak information later when new components get added, solves both problems.
(This could be automated by using annovention, reflections or simililar frameworks that can scann for classes based on interface or annotations)
@asser.fahrenholz said: Also, I know I have to keep track of which components to display to the player, somehow, because not all components are ment to be known by the player. But the issue is still valid.
Hmmm… you just described why it’s not valid and then say it’s valid.
You want to display certain components to the user… so you display those components. Better to display only the components you wish to display and not the 100 odd random components you might add later.
So I don’t see how the issue is still valid since there are no valid use cases presented to “get all components for an entity”.
@pspeed said: Hmmm... you just described why it's not valid and then say it's valid.You want to display certain components to the user… so you display those components. Better to display only the components you wish to display and not the 100 odd random components you might add later.
So I don’t see how the issue is still valid since there are no valid use cases presented to “get all components for an entity”.
Okay, so as I see it, I have to ‘hard-code’ a list of components that may or may not be on the entity I select.
That is, if I choose not to go with Empire Phoenix’s suggestion.
@asser.fahrenholz said: Okay, so as I see it, I have to 'hard-code' a list of components that may or may not be on the entity I select.That is, if I choose not to go with Empire Phoenix’s suggestion.
Yes, because you’ve already admitted it is a subset of the actual components.
Fair enough. My confusion came from the fact that this subset is very dynamic - thank you for your help.
Just to clarify
https://code.google.com/p/reflections/
allows you exactly what you requested in the beginning,
Getting all classes wich inherit from an interface.
[java]
final Reflections reflections = new Reflections(“de.visiongamestudios”);
final Set processedComponents = reflections.getSubTypesOf(IVisiblecomponent.class);
//all implementing
final Set<Class<? extends ProcessedInterface>> casted = processedComponents;
for (final Class<? extends ProcessedInterface> subType : casted) {
if (subType.isInterface()) {
//traverse interfaces that extend the interface
this.traverseInterface(subType, reflections); //-> basically do the same ask reflections for the subtypes of this new subInterface, and repeat recursivly
}
//add to visible list
}
[/java]
@Empire Phoenix said: Just to clarify https://code.google.com/p/reflections/ allows you exactly what you requested in the beginning, Getting all classes wich inherit from an interface.[java]
final Reflections reflections = new Reflections(“de.visiongamestudios”);
final Set processedComponents = reflections.getSubTypesOf(IVisiblecomponent.class);
//all implementing
final Set<Class<? extends ProcessedInterface>> casted = processedComponents;for (final Class<? extends ProcessedInterface> subType : casted) { if (subType.isInterface()) {//traverse interfaces that extend the interface
this.traverseInterface(subType, reflections); //-> basically do the same ask reflections for the subtypes of this new subInterface, and repeat recursivly
}
//add to visible list
}
[/java]
Just to clarify, if you use extension and interfaces for your components you do something severely wrong.
This would just be to find a certain subpart, don’t worry we already told him this in the posts before ^^
However for this problem using a marker interface might be a somewhat elegant solution.
If its a different kind of component its a different kind of component.
Did you read the thread even? As then you would understand where this comes from.
When building dynamically a gui for a subset of components
one could either hardcode them
or tag them with an interface and let code generate that list.
There are a few other similar use cases btw,
eg flagging all components that should be network synchronized in a networked ES, flag all components that need to be persistable (eg table creation,schema validation ect in background)
Yeah, different components are different components, not the same component with different flags.