Space Short Monthly: Bugs and settings
This month I did 3 things in Space Short (10 levels, two bosses, no distractions… Can you make it?):
- Failed (again) in creating a unit test.
- Bug fixes.
- Settings menu.
Unit Testing in Unity
I’ve consistently failed in creating unit tests. Whether it’s because of problems with the assembly, or outdated packages, or (in this case) my Unity IDE freaking out and not recognizing
TMPro anymore, something always comes up.
I’m usually a strong proponent of testing. It gives a simple, automated method of testing that doesn’t require me to spend a long time playing and stopping and modifying and … you get the idea.
However, the original idea of creating Space Short was to learn Unity, in order to create another game using it. Now, because of this (Unity’s new runtime fee) and that (Flutter’s excellent game options), I’m not sure if I’ll do my main game in Unity. In which case, is it really worth spending so much time on it?
So far, I try for a bit and stop. 🤷♀️
I do use some basic Unity tricks though:
- Set start level: If I want to test the boss (on level 5) I just start on level 5. I don’t need to play the previous level.
- Unkillable: I have a mode (I’m not going to tell you how to enter it!) that makes me impervious to enemy lasers. Obviously, it isn’t useful if I want to test that lives go down when killed, or to test the SFX of player death, but it’s very useful in other cases.
- Unity tools:
Debug.Logprinting, using Scene view during the game to change parameters, etc.
There comes a time in every app where you just need to take time and fix the growing backlog of bugs. You won’t be able to fix them all, of course. As someone said:
There will always be a bug
However, you can fix a good part of the bugs and give a good experience, even if a small percentage will find that one (or two, or 16) bug that you didn’t fix. Here also, the question is one of balance: the complexity of the bug vs the advantage of fixing it. Critical bugs (crashes, major features) should always be fixed. Tiny bugs that occur only in specific rare cases and aren’t part of the main features of your app probably shouldn’t. All the rest of the bugs or on that fine line in the middle somewhere. We all do what we can.
Last Space Short article, I explained how I added SFX and background music. There must be a way to control of the volume of these sounds, ideally separately. I discovered the excellent Rehope Games YouTube Channel, specifically the following:
This caused me to refactor the Audio I did before into an
AudioManager, instead of having various sources in objects (in my player, in the explosion…). It makes it easier to follow and easier to manage when all the Audio is in one place. In addition, I intended to control the volume using the volume parameter in the AudioSource object, but using the above and the ever useful brackeys tutorial, I used an AudioMixer to manage the various sounds: one group for the background music, and one group for the SFX. This is much easier to manage than my original idea, and much less bug prone. Also, apparently the
Play function doesn’t even have a volume parameter, only the
So now I have a bitchin’ Settings menu, that is activated when pressing pause:
I added a bunch of additional SFX to the game. I also added background music to the other screens such as the Start Menu. Of course, this creates a problem: the settings work only for the Game scene, not for all of the scenes. So I (still) need to get the saved values from PlayerPrefs and update them in the other scenes.
But we’re slowly but surely approaching the finish line :)
Have you succeeded in running unit tests in Unity? When do you fix bugs and how do you decide whether to fix them? How did you create volume settings? Let me know in the comments :)