Developer Diary #12: Testing
Our last entry focused on YoyoBolo using Workback scheduling strategies to plan tasks for New School Blues’ development. The last task assigned is getting the game ready for online submission. But what comes before that? Why testing of course!
Hahaha! Get it? Also, he’s got glasses.
The purpose of testing is obvious to anybody: we play the final build (or version) of the game like crazy and should anything not work the way it’s supposed to, it’s filed as a bug on a report. We then go back into the code or assets and fix it. Bugs can be anything from a visual glitch, for example the main character’s animation doesn’t play correctly, to a logic error in the code causing it to freeze or shut down
The funny thing about testing that some people don’t realize is how thorough you have to be. We can’t just run through it once doing exactly what the game (and designers) expect you to do and call it a day, we have to try to take into account every possible thing a player might do in the game and make sure it won’t screw things up. Sure if you click on it once it works fine, but what if you click on it three times? What if you the player goes in and out of a room 10 times over and over again? You get the idea.
Whoops… but a heck of an awesome whoops
Some games have long test cycles in their development schedules, leading to game iterations that are more and more polished overtime. At YoyoBolo we don’t have that luxury at the moment and are allotting a week to test the game full-time. If you’re keeping track that means full-time testing begins on the 26th, meaning our final pre-test build needs to be done by the 23rd.
That’s enough schedule talk for now, more on art, code, and audio to come!