Integrating the Explosion effect into Game-play

Now that we have a nice explosion effect (in my opinion), it is time to tie it into our game by first making sure that the enemies can generate the effect when they are destroyed.

But first, let’s do a bit of house work to make things go smoothly as we move forward.

We know that this effect will be being called from multiple objects, the enemies, any variants, and the player. So, it wouldn’t make since to have the individuals spawning the effect in, not when we have a SpawnManager already in place. To make things easier, let’s upgrade that script to a singleton so that we don’t have to add a reference to it in each Object that needs to access it.

Here we have set up the SpawnManager to be a Single Instance just like we did for the GameManager. If we have any references in our other scripts to the SpawnManager, we should go through and replace them with the Singleton Call because the point of having a singleton is not to use up memory with multiple references to a Single Instance Object.

Next, we make a cleanup script to attach to our Explosion prefab. If not, we will end up with Explosion clones cluttering up our hierarchy and being a general waste of resources. It is a simple script and since we may need it for other objects later, we can make it modular by giving the Designers access to the destroy timer through the _cleanUpDelay variable. Just attach this script to any object and set the timer, then poof, no more clone after the time runs out.

Now we go back to the SpawnManager to start bringing the Explosions into the game. First, we need to add a handle for the Explosion prefab. You can see that instead of adding a couple more lines to code, I was able to tack it on to the line with the _enemyPrefab. This is possible since they are both the same type. And doing this is no different from inserting the line underneath this one, as they show in the Inspector as if they are separate items.

Here we create a public method called SpawnExplosion, which follows our previous naming conventions, and set it to receive a Vector3 parameter. Then we run a rather simple Instantiation using the _explosionPrefab handle and the parameter BoomPOS. The addition of extra Vector3 information is due to a minor edge case that you may have noticed in the gif at the beginning of the article. When the Shield is active, the explosion effect runs into and leaves a gap to see the Enemy beneath. By raising the effect 2, this is corrected and since we are using an orthographic camera, there is no apparent change size or position. For now this is hard coded, but when we get into further converting this game to handle both top down and side views, we will have to switch it out with a variable that we can control in the code.

Now let’s look at the collision from the Enemies point of view. To add the Explosion, we just need to add a line calling the SpawnExplosion method in the SpawnManager and giving it our position. But that’s not the only change since we don’t want to the Enemy to pop out of view as the explosion appears. Instead, we want the Enemy to be visible until it is covered by the explosion. This requires a delay and some ‘behind the scenes’ jiggering to make it so the player doesn’t hit the Enemy multiple times when it should already be gone. And delay usually means a CoRoutine, so let’s change SendToPool method into a coroutine. These same changes need to made to the other conditionals in the OnTriggerEnter method so that the Enemy properly spawns the Explosion when needed.

Our SendToPool method has sprouted a few more lines when it became a coroutine, hasn’t it? We create two new variables to help with the illusion of the Enemy’s destruction. First is the Bool _isExploding, we can use this to stop the Enemy from moving so that it doesn’t peek out from the explosion effect. The second, _collider, is a handle on the Enemy’s collider so we can turn it off and on. We use a brief delay of quarter of a second to allow the Explosion to expand enough to cover the Enemy ship. Then once that delay is up, we reset everything and send it to the pool where other methods take over control of it.

And with that, we have a working Explosion effect for the Enemy and one that can be easily added to other GO that need an explosion.