Level building has been a big part of the work that I have been doing lately. But that’s starting to wind down a little now and it’s time to go over everything that has been created and make sure that it actually works!
So this week I’m going to talk a little bit about Quality Assurance (QA), what it is, why it’s important, and how I go about doing it.
QA is the process of internally testing your game to make sure it’s ready for play testing. It is the process of playing through your own work to make sure it is doing what it should be doing. Basically, it’s the same as reading over a piece of writing before releasing it to make sure it’s saying what you mean, and that you haven’t left out any words.
Importantly, QA isn’t the same as play testing. They are two different processes, and they can’t be used in place of each other!
Play testing is putting your game in front of players and seeing how they interact with your game, and whether the systems that you have created result in your intended play. And whether that play is enjoyable.
QA is making sure that the systems that you have made work and have been implemented properly.
One thing I learned last year – if you don’t do QA properly, then you can’t do play testing properly. Because all the feedback that you will get is that the game is broken and that things don’t work. If you’d gone through you would have noticed this very easily on your own. And as a result, you don’t get any useful feedback on how the game makes players feel or if they find your systems enjoyable.
So, to summarise: QA is very important. QA is not the same as play testing.
What I’ve been doing this week, is playing through the levels that we have built and trying to catch and identify as many broken game elements as I can.
That second part is important too. Good QA doesn’t just identify that something is broken. It should really examine the problem, work out exactly how to replicate the problem and make sure that it is clearly documented so that whoever’s job it is to fix the issue can easily re-create the problem and work out what is causing it.
A well-documented QA report can save hours in bug-squishing time by narrowing down exactly where and when a problem occurs.
Here’s one of the issues I found last week. I noticed that in some circumstances, the player wasn’t able to complete projections properly. Instead of a proper projection completing like this:
It was failing to complete the projection, leaving a transparent copy where the projection should had been placed, like this:
Eventually I was able to narrow down the circumstances that would cause this to happen:
- The player had progressed to the point that they had learned to undo projections
- The player had died at least once within this level.
And from these notes the programmers were able to narrow down the cause of the issue and fix it.
This was something that wasn’t apparent while building levels, and yet would have resulted in a play test being totally wasted as players would have been unable to complete many levels. So it was very good that we found and fixed this!
So that’s a quick rundown on QA. It’s not as glamorous or as flashy as some design work, but it is 100% vital to making a good game.
And I can tell you that it can feel super satisfying to finally work out exactly what is causing your game to bug out at some point and pass on a really good bug report to your development team. And they will appreciate being able to quickly identify and fix a problem too! So everyone’s a winner!