#Implementing buttons in a level

9 messages · Page 1 of 1 (latest)

torn bronze
#

Hello! I have stumbled on one of many designing problems in my game and I am not sure how to tackle it, because I am still quite inexperienced with any gamedev (let alone ECS one)...

Basically, I have a level, there are some buttons in that level and they open some doors and activate some traps. Basically trigger something. Sometimes there are several buttons which can trigger the same group of objects.

I have no idea how to represent with bevy's ECS... At first I thought about storing that information in a Resource, but there's also an option of creating a special "helper" entity, which stores information about such relation, so the solution would work as follows:

// Component carried by the buttons (we don't store the entities to activate directly, because different buttons might be explicitly configured to trigger the same set of objects)
struct ButtonsGroup { info_entity: Entity }

// Component carried by the entity that encodes the relation
struct InfoEntity {
  entities_to_activate: Vec<Entity>,
}

// The event posted by the button when the player steps on it.
// Some system later picks up this event, directly queries the `InfoEntity` and then iterates over the `Vec` it carries
struct ButtonPressedEvent { buttons_group: Entity }

Is that any good? Am I overengineering? Is there a better more idiomatic approach?

topaz umbra
#

I think the key thing you are missing is that you can store entities in a component.

#

Say you have

#[derive(Component)]
struct Door;

#[derive(Component)]
struct Opens {
  what: Entity,
}

You can add the Opens { what: door_entity } to your button entity, and have a system that checks activation events on entity, check their Opens component and then maybe fetch some component on the what entity and modify it.

#

hmm, now that I read the second half of your question, seems like you already thought about something similar

#

I'm missing something here though. Why would you introduce an intermediate entity? This seem to indicate the relation between the buttons and traps/doors is more complex that a simple trigger.

#

Ok I see. So the relation is n-to-n. That's why. Dang reading questions is really useful to answer them correctly

#

Hmm, you could go the reverse way and just have a TriggeredBy component that holds a list of entities to check for a trigger.

torn bronze
torn bronze
#

Also this solution technically consumes more mem