How to handle multiple potential components

[Raveline]

Apologies in advance if this question has been asked already, I did numerous search but couldn't find a proper answer - also I think this could contribute to a "how to" section in the documentation.

I'm trying to make a simplish roguelike using apecs, and I'm unsure how to proceed on a basic issue. When the player moves, I want to detect if they go on the same tile as any other entities; but the result might differ depending on the entity. If it's a mob, there should be some combat mechanism; if it's a merchant, it should trigger a trade menu; if it's a potion, it might automatically pick it up, etc.

There are several ways to go at it, but I'm unsure what to pick and I'd like to know if there is an idiomatic way.

Here is a simplified view of the problem:

• Player has a Position component over a (x,y) coordinate, and a IsPlayer component;
• All entities (Merchant, Mob, Potion in the example above) also have it, plus their own components;

I'll start from the collision logic in the shmup example, implemented with two cmapM_ composed:

  cmapM_ $ \(Target, Position posT, etyT) ->
    cmapM_ $ \(Bullet, Position posB, etyB) ->

It's fine for the first cmap, since I know what entity to look for (Position and IsPlayer). But for the second cmap, I don't know exactly what I'm going to find.

I could go to a bruteforce approach:

  cmapM_ $ \(Player, Position (posA) ) ->
    cmapM_ $ \(Merchant, Position posB, etyB) ->
      -- check collision and do merchanty stuff if so
    cmapM_ $ \(Potion, Position posB, etyB) ->
      -- check collision and do collection stuff if so
    cmapM_ $ \(Mob, Position posB, etyB) ->
      -- check collision and do fighting stuff if so

This is clearly verbose and unoptimised.

I could also use a lot of exists and get:

  cmapM_ $ \(Player, Position (posA), etyPlayer ) ->
    cmapM_ $ \(Position posB, etyB) ->
      when etyPlayer /= etyB $ do
        isMerchant <- exists (Proxy @Merchant) etyB
        isPotion <- exists (Proxy @Potion) etyB
        isMob <- exists (Proxy @Mob) etyB
     case (isMerchant, isPotion, isMob) of
       -- And process stuff here

(Though a getMaybe would really be better here and let me use stuff like <|> to make the code more pleasant; I'm surprised apecs doesn't come with it supplied - though I suppose getMaybe is easy enough to write).

Or I suppose I could wrap Merchant, Potion and Mob in a Sum type and decide upon the behaviour depending on the sum-type, but it seems like defeating the very purpose of an ECS.

Or perhaps there is another, more sensible way of doing it that I didn't think of because I'm still unfamiliar with apecs (and not very experienced with ECS). So, are there ways of doing this I didn't consider ?

[dpwiz]

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.

[dpwiz]

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

[Raveline]

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 !

[dpwiz]

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.

[dpwiz]

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.

[dpwiz]

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 (:

[Raveline]

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 !