How to handle multiple potential components about apecs HOT 7 CLOSED

You can have a tag that would answer exact this query, irrespective of an entity being a merchant/potion/mob.
Tags are fast, can be cached and are a good option to pre-filter entities before getting into further details.

from apecs.

Merchant, Potion, Mob is an odd enumeration to have. What do they have in common?

from apecs.

You can have a tag that would answer exact this query, irrespective of an entity being a merchant/potion/mob.
Tags are fast, can be cached and are a good option to pre-filter entities before getting into further details.

You mean something like a data IsCollidable ? That would indeed let me do a query, but then I'd be back to the issue "how do I know which are the components of the collided entity". My question is more: "How do I get into the further details, is there a better option that doing a lot of exists ?"

Merchant, Potion, Mob is an odd enumeration to have. What do they have in common?

Agreed on this, obviously I want to avoid this !

from apecs.

how do I know which are the components of the collided entity

But, again, how would the collision (?) system behave differently for different kinds of colliding objects?

How do I get into the further details, is there a better option that doing a lot of exists ?

You can collect Entity ids and then do a per-kind processing in other systems.
Alternatively (perhaps better), you can make collision system add Collided tag, and then run per-kind queries with it.
The answer is basically "decompose your system". Let the colliders collide, then let the mobs mob and items item.

from apecs.

There's another option, the way apecs-physics does it. You put your callbacks into a component and the collision system invokes it blindly, letting the entity sort it out by itself.

from apecs.

This is clearly verbose and unoptimised.

Actually, this looks... okay. You can optimize it later IF it becomes a problem and with an appropriate tool (like spatial indexing) instead of shuffling the syntactic furniture around for a more presentable code. Don't let yourself be pre-blocked (:

from apecs.

This is perhaps also just a case of "ECS are not always a good fit for roguelikes" - a statement I've often read, without knowing if it was true or not.

The callback mechanism from apecs-physics is also interesting, but I'm trying to keep my components as simple as possible and I'm not ready to add callbacks to them right now.

You are right: I'm letting myself be pre-blocked.I think your decomposition principle is sound, and I'm reassured that another pair of eyes find that the multiple cMaps don't look so bad. I'll get on with this and see if this needs any optimisation later on. Thank you for your input !

from apecs.