# Best practice for handling “dead” objects and their particles

I'm developing a side-scrolling run'n'gun game (but with planes! :P). I'm an experienced coder, but new to game development.

When an enemy plane collides with a friendly missile, I start an explosion particle emitter on the enemy plane. The emitter is accessible as a private property of the plane object and its flow is controlled by the plane's update function (which is called from the game update function). The particle emitter's "render-update" method is called directly from the game renderer class.

I don't like these things:

• When the enemy plane is destroyed, I can't simply remove the object from my game's "enemyPlanes" array, as this would result in the particle sequence not completing itself.
• If I continue with this scheme, I have a very complex if statement in every execution of the render function, that will (a) check if the enemy is not shot down (b) check if the emitter is active (c) remove the plane as well as the emitter (if both previous conditions are met)
• The particle system is both accessed from the GameRenderer and from the plane object. I mean, I call something like plane.getParticleEmitter().update(blabla).

Is there a better way to do this?

EDIT: The library I'm using is libgdx (Java).

• There are lots of ways you could handle this. The easiest/best way for you is going to depend on what language/engine you're using. "private property" suggests you might be using C# (Unity?) but you should tag your question with the language and/or engine you're using. – bcrist Apr 7 '14 at 20:48
• P.S. Welcome to Game Development! – bcrist Apr 7 '14 at 20:54
• You might also want to try the Code Review section: codereview.stackexchange.com – glampert Apr 8 '14 at 3:36
• Thanks, I'm using libgdx and I can't find a library-specific way to handle this. Also, I thought that it was a generic game developmentquestion and that's why I didn't give specific info. – The Dart Code Apr 8 '14 at 13:00

The particles themselves associated with a particular effect shouldn't be tied directly to the object. While there is never a 100% use-case scenario, this still applies to most situations. Your object itself shouldn't be managing the life-cycle of a particle effect, though it may be the instigator for spawning particular effects in the world.

So, in your situation you have an object (a plane) that is constantly emitting a particular particle effect via an attached emitter object. In this situation, the only thing that should be dependent on the plane object being alive is whether or not your emitter object would choose to spawn particles as a part of an effect sequence during that frame.

For example, say this is your code. (Lets assume your real code is more thorough than these extremely lacking implementations)

class Plane : public Actor
{
public:
Plane();
~Plane();

void Update()
{
ParticleEmitter.Update();
}

bool IsAlive()
{
//return whether alive or not
}

private:
EmitterClass ParticleEmitter;
}

class EmitterClass
{
public:
EmitterClass();
~EmitterClass();

void Update()
{
if( ShouldSpawnEffect() )
{
//Tell particle system to spawn effects
}
}

bool ShouldSpawnEffect()
{
return Parent->IsAlive();
}

private:
Actor* Parent;
}


In this situation, the particle emitter is responsible for spawning the effects by itself, but is not responsible for managing the individual particles. A separate system would perform any allocations, and behavior updates for the effects queued up. This decouples your effects from the object itself, and allows for a singular system to manage the resources associated with a potentially complex and expensive system.

edit A final thought is that this isn't necessarily the "Best practice", as the implementation that is best for you is entirely dependent on your context specifics. Therefore, the reality is that there is no such thing as a universal best practice. Hopefully this helps.

• So, basically a nice way would be to subclass my ParticleEffect classes (that's the way they are in libgdx) and handle it from there, right ? Also, to see if I understand correctly, using your implementation, I would still access the particle emitter from my Renderer class, via the plane object, right? – The Dart Code Apr 8 '14 at 13:06
• This particular example I threw up would be a game thread tick, with nothing related to rendering. Also, the particle emitter itself (in this example) is only responsible for telling the particle system to spawn a particular effect. The actual effect itself would be resource managed and rendered by either a completely separate system, or system's depending on your overall architecture. – Evan Apr 8 '14 at 14:23
• This is also in a situation where you have complete control over what you are doing. If you are using an existing framework that doesn't provide that much flexibility, then you will have to make do with what they provide. – Evan Apr 8 '14 at 14:27

A small hack would be to set enemy to not visible on collision, and when the explosion finishes then remove it. But then you need to have a callback that is triggered when explosion finishes.