BUG #16: Player projectile causes double collision
This bug became apparent after I noticed the sound effect associated with an invader being destroyed, randomly, got much louder. Initially, identifying the cause wasn’t overly obvious. I decided to capture some video whilst playtesting and then review it, looking specifically at the events where the audio became louder.
It transpired that at the same time the sound effect’s volume increased, two invaders were being destroyed, seemingly, at the same time. Each invader played it’s sound effect so close together that it sounds as if it is a single sound effect with an amplified volume.
In the video below the left hand side of the screen shows Unity’s Scene View, whilst the right hand side shows the Game View. The green outline around each invader in the Scene View indicates it’s BoxCollider2D component. At 00:13 a single player projectile causes multiple collisions.
To resolve this issue I considered, and tried, several approaches to prevent multiple collisions between the player projectile and the invaders, however the success rate of these didn’t prove to be overly reliable.
As a temporary solution I opted to reduce the volume of the BoxCollider2D component on the player projectile. This had the effect of reducing the chance that a player’s projectile could cause a collision with more than one invader.
Player Projectile – BoxCollider2D Volumes
I plan to revisit this issue and further refine a solution, as despite the frequency of this issue being significantly reduce, on occasion, it does still occur and nobody gets Two For The Price Of One on my watch!
With quite a significant amount of Space Invaders working, I thought I would take the opportunity to have a sprint for playtesting and resolving the bugs this process identified, along with a few issues I had already spotted but only logged to date.
Whilst the following issues were not huge, they did have an overall negative impact on the game and it felt good to get these resolved.
BUG #26: Game Over – When the player loses all of their lives the menu doesn’t appear until the remaining invaders have landed on the planet.
Space Invaders’ end condition is met when the invaders reach the lunar surface, one could argue that the player losing all of their lives is also an end condition, this is true, but primarily because the player then loses their ability to stop the invaders from reaching the lunar surface.
My initial efforts had focused on the lunar surface end condition, if a player lost all of their lives, they had to sit there and wait until the invaders finally arrived on the lunar surface, an unlucky (noob) player could have quit a wait before being able to play again!
The issue was resolved by having the UIController listen for an additional event which would be triggered when the player lost their last life. Whilst the menu now appears immediately, the invaders continue to march back and forth in the background until they land on the lunar surface, this is in keeping with the original game and makes the end condition experience slightly more enjoyable, or at least, more interactive.
BUG #24: When the player loses their last life, the Command Ship, if present, continues to fly off the screen but has no audio.
As it happens, this was not a bug but intended behaviour. In the original game, when the player loses their last life, all of the sound effects in the game stop playing, the command ship continues to move off the screen and the invaders continue to march until they reach the lunar surface.
BUG #22: CommandShip stops moving when the InvaderFormation lands, but the CommandShip audio continues to play.
This was quite possibly one of the most irritating bugs found to date. When the invaders arrived at the lunar surface, the end condition was met, the command ship movement was being stopped but its flying sound effect was not, this would continue until a new game was started.
The issue was resolved by not stopping the command ship’s movement when the end condition was met, this allowed the command ship to move out of the visible playspace and then be reset which, thankfully, stopped the flying sound effect. This behaviour is now in line with the original game.
BUG #20: InvaderFormation continues to play marching sound effect even when the player has been hit/destroyed.
Whilst the invaders stopped moving whilst the player’s death sequence played, the marching sound effect continued to play, this provided quite an odd experience as the player’s eyes and ears were telling two different stories.
The resolution to this issue was to stop the sound effect being played once the player was hit and was handled by triggering an event and having the invaders’ InvaderFormationAudioController listening for it.
BUG #21: InvaderFormation continues to animate when the player has been hit/destroyed.
On a personal level this issue didn’t bother me too much, I thought the invaders actually looked quite cool poised ready for action whilst the player’s death sequence played and continued animating themselves, but having checked the original, this wasn’t how it was done. When the player is hit, the invader’s animations should also stop, just like the sound effect issue above, the same approach was taken.
BUG #23: Stutter sound effect is too quite.
I have yet to find a better way of describing this sound effect. When the last invader is destroyed in a wave there is a little stutter sound effect that plays. Initially I thought this was supposed to represent the engines on the rocket ship as it descended on the left hand side of the screen at its timing seemed to fit perfectly (41-43 seconds in the clip below);
However, through playing the original game I discovered that this sound effect plays even when the rocket ship has landed on the lunar surface. With this in mind I came to the conclusion that the sound effect was supposed to represent something else, although, to date, I’m not sure what.
Having introduced this sound effect at the correct moment during the game play I noticed that it was far too quiet compared to the other sound effects in the game.
The issue was resolved by normalising the audio clip using Audacity, which I had done with the other sound effects but must have missed this one.
On a related note, if anyone has any thought as to what this sound effect is supposed to represent I’d be glad to hear from you. I still wonder if it is the engines on the rocket ship after all and perhaps the fact that it still played after the rocket ship lands was just a bug in the original game but I’m not 100% convinced on my theory.
Over the years I have seen various applications where having a dark mode or theme was an optional extra. Something which could be charged for as a desired feature. This feature had never really interested me, I felt that it was primarily just a fad, something to make a developer look, or perhaps just feel like they looked, that little bit more cool. This was certainly something I could manage without, being comfortable with my own level of coolness.
At present, my IDE of choice is Visual Studio, I have used different versions of it for a number of years and feel comfortable with it. I have probably used no more than 10% of its features and I’ve certainly never invested any significant time customising it. For myself, out-of-the-box seemed good enough.
Perhaps it has come with age, or perhaps just wear and tear, too many long days and late nights, staring and an overly bright screen with a white background, but recently I had noticed I was struggling to differentiate some of the styles being applied to my code within the IDE. Code blindness!
With my recent upgrade to Visual Studio 2019 I thought perhaps it was time to take a few moments to customise the IDE for my personal preferences. I will confess, I didn’t know that I would even have the option for the dark theme but there it was, so, hesitantly, I selected it.
Whilst it is still early days and I may find reasons not to like it, I have to say that the higher contrast between font and background colours is of huge personal benefit.
It’s just so pretty… and visual…
I plan to remain in my little bubble of ignorance, not wishing to know how long this feature has been available to me, or how much easier things could have been for all of these years, as my eye-sight progressively worsened. I’ve been using Visual Studio since .Net 1.0 was released, rather scarily, that was 17+ years ago. It’s quite incredible how long some people will just make-do.
My transition to the dark-side so far has been an easy one, I hope it will come with acceptance from those cool kids who already use this feature, those with a superior desire-to-fiddle mentality – and 20/20 vision.
