Skip to main content
added 132 characters in body
Source Link
jmegaffin
  • 4.9k
  • 2
  • 26
  • 46

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.

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. Structuring entities like this makes more sense to me.

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.

Source Link
jmegaffin
  • 4.9k
  • 2
  • 26
  • 46

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. Structuring entities like this makes more sense to me.