7
\$\begingroup\$

I am currently familiarizing myself with the entity component paradigm.

For an example, take a collision system, that detects if entities collide and if they do let them explode.

So the collision system has to test collision based on the position component and then set the state of those entities to exploding.

But what if the "effect" (setting the state to exploding) is different for different entities? For example, a ship fades out while for an asteroid a particle system must be created. Since entities and components are only data, this must happen in some system.

The collision system could do it, but then it must switch over the entity type, which in my opinion is a cumbersome and difficult to extend solution.

So how do I trigger "entity type dependend" updates on an entity?

Improve this question
\$\endgroup\$
1

1 Answer 1

Reset to default
6
\$\begingroup\$

First things first, I would use an event-driven system rather than one based on states. Setting a state to "exploding" is clunky and rather useless, since an explosion is a one-time event.

Secondly, you can make use of what I like to call behaviour components. These components are programmed to react to certain events, like "exploded". Adding these components to an entity allows you to easily change how the entity responds to events. In this case, you could create a FadesOutBehaviour component that can be customized to different event types, fade times, etc. Then, whenever an entity with that component is blown up, it will fade out. The same goes for a SpawnsParticlesBehaviour component.

What I would really do in this case is give entities components that would fit in "real life". For example, I would forgo creating components to enable fading or particle spawning and instead use components like FuelTank (I can't think of one that would work for a spaceship fading; that doesn't even make sense :P). An entity containing FuelTank is susceptible to catching on fire, exploding, and at the same time can keep track of how much fuel it has left. The kinds of data a FuelTank would store would include capacity, damage, name of the mesh it is linked to inside the model, etc. Structuring entities like this makes more sense to me.

Improve this answer
\$\endgroup\$
4
  • \$\begingroup\$ So these components have the logic to fade themselves out or there's a FadesOutSystem to do that? \$\endgroup\$
    – Luke B.
    Nov 22, 2012 at 0:25
  • \$\begingroup\$ Whichever one you like. The way I explain with FuelTank is better suited to a components-as-data approach. \$\endgroup\$
    – jmegaffin
    Nov 22, 2012 at 0:44
  • \$\begingroup\$ Ok, an entity containing a FuelTank is catching fire when destroyed. How and by whom is this decided and the "fire" created? Does the collision system have to test if an destroyed entity contains a fuel tank? \$\endgroup\$
    – Nathan
    Nov 22, 2012 at 6:46
  • 1
    \$\begingroup\$ This is how I would implement the FuelTank behaviours: You have a system that manages the various damages game objects can receive. The system monitors collision events between projectiles and the game objects; the collision subsystem is only responsible for broadcasting collision events. When the damage system receives an entity-entity collision event, it checks if one of the entities has a Projectile component and the other has a FuelTank. If so, the FuelTank is damaged, possibly creating a fire particle system or an explosion. The damage system could also monitor vehicle damage, etc. \$\endgroup\$
    – jmegaffin
    Nov 23, 2012 at 0:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .