I have used Microsoft Word for so many years and yet clearly have only ever scratched the surface of it’s functionality.
Today I created a new document and needed to add a table. The table was added to the top of the page and, as is often the case, I then realised I wanted to add a paragraph above it.
The number of times I have been in this position in the past is ridiculous and on every occasion I would spend an inordinate amount of time trying to get around the problem.
The solution in most cases would be to use the table’s drag handle and slide it down the page slightly, only to then find that it hadn’t slid perfectly on its vertical axis. This subsequent problem would then lead me to spend an inordinate amount of time trying to line everything back up horizontally.
I think it’s fair to say that the fault here does not lay with the software, it is very much a problem with both the user and his lack of reading a manual.
Today, I read the manual! Or rather I Google’d “word how to insert carriage return before table”. I always feel a slight sense of relief when Google’s auto-completes my search criteria and my inner voice says, “See, you aren’t the only one!” in a reassuring tone.
The first search result was expanded and displayed exactly what I needed. “Place the cursor in the first empty cell, or, in front of the first word in the first cell and then press CTRL+SHIFT+ENTER.”
My mind was blown!
I have no idea why I didn’t try to find an answer to this before but assume it was probably because it never felt like it was a big enough issue to waste the time on. All of those little amounts of time wasted however far outweighed the amount of time needed today to finally search, learn and address the problem correctly.
There’s probably a life lesson here somewhere. Perhaps I’ll look it up, at some point.
It’s not much, but for a first attempt at anything with new software I didn’t think it was too bad.
I took the time to re-position the transform on the main object so that it would align nicely in a game engine. The handles are also separate components and have their own transforms which should allow for easy animation.
The main menu for the game is currently quite underwhelming, but then the original game didn’t have a main menu or title screen, you just went straight into the action by pressing the big yellow START key.
Atari 800 Function Keys
This evening I added a key press sound effect for the buttons on the game’s main menu. The pitch of the sound effect a little lower than a standard keyboard key press which is ideal as these buttons where large and chunky and the lower pitch reflects this.
To remove the monotony of having the exact same sound each time a button was pressed, I randomised the pitch of the AudioSource component between negative 0.1 and positive 0.1, adding the result to the default value of one. The end result provides a subtle and realistic button press.
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.
In the early 1980’s I was fortunate enough to experience our first home computer, the Atari 800.
We had only a few games to begin with, but over time this collection grew and included notable games, many of which are now deemed to be classics.
This evening I set myself the personal challenge of recreating one of the first games I ever played with nothing more than my own memories and two YouTube game-play videos totalling less than 10 minutes…
