Musical Shooter – A Few Tweaks

As the various features within the game get put in, I’m finding myself playing it more and looking for minor tweaks that can be made. This post will describe a few of these that I’ve made recently as well as, more importantly, fixing the bullet removal issues I’ve been having.

Prior to this update, if I enabled the removal of bullets when the collide with an enemy then there it seemed the system was getting stuck at the point where the bullet was removed and if you kept firing in the same direction no bullet would get past the ‘removal location’, until the player moves. I spent a while scouring the code for references for the player location being used in the removal of the bullets, but there was none… It turns out I was just calling the remove function at the wrong point in the code! We now have ‘proper’ bullet behaviour.

I’ve also been playing around with some of the functions available in the Minim audio library I’m using to handle the playing of the sounds and music. I’ve implemented a basic low pass filter whose cutoff frequency is lowered when the player collides with an enemy and is suffering damage – the idea being that this will provide some audio feedback to the player. I didn’t want to use a sound effect as things are starting to get quite cluttered at times (audio-wise).

The final major tweak I’ve done, is to implement a ‘windowing’ system on the code that checks to see if the enemy has been destroyed. Prior to this, the code was working like this:
if(damage > 15 * dScale && frameCount % 16 == 0 && impactCheck == true)
So, the damage had to be above the threshold, and the frameCount had to be an exact beat, and there had to be an impact. The impact check was put in to ensure that the enemy wouldn’t destroy itself when you’re not actually shooting it as this felt a bit odd.
The problem is that the ‘perfect’ frame count and an impact don’t always align and so it could sometimes take a while to kill a specific enemy which again, didn’t feel right as you were playing.
The windowing code looks like this:
if(impactCheck && frameCount % 4 == 0 || frameCount % 4 == 1 || frameCount % 4 == 3) { if(damage > damageMax * dScale && frameCount % 16 == 0) {
The 2 if statements are nested so the first one is the window and checks the remainder of the modulo operation to see if the frame is 1 either side of the ‘perfect’ frame. If this is true, then the 2nd if statement checks for damage and an impact.
The new system has made the gameplay feel more like it should with enemies dying more reliably, although it’s not quite perfect and needs some more finessing.

I’ve also added in a sound for when the enemy takes damage. Rather than just triggering this sound for every damage instance, I’m checking to ensure that the damage sound only plays at a ‘musical point’. Again, this uses a similar windowing system as the enemy death system and so is not quite perfect yet…

Finally, I’ve implemented a basic game start and end system.

Anyways, here’s a video of how things are looking at this point:

 

Next steps = Creating some kind of scoring system; Looking into reading/writing to files to store the player’s results; Different weapon firing rhythms.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s