Over the weekend, I released the oh-so-clever and distracting game Dragon Fire. The game probably took me a total of 12 hours to program thanks to the awesome suite of tools in the Flixel game engine and the Flixel Power Tools. (I seriously cannot stress how awesome these are). However, even when programming something as trivial as Dragon Fire, it is always important to do thorough testing.
I have already updated the game on the site,
but if you managed to play the game before today but if you play the old version which I listed second on the game page, you would notice that sooner rather than later, your dragon lost the ability to spit fire. From a fresh load of the page, you would not have noticed this. This bug only reared its head if you selected the “Play Again” option in the game over screen. During my program and testing modes, I never really tested this extensively and so never noticed the bug.
It was only after I uploaded what I thought was the finished build of the game that it was noticed by my brother and co-developer Willis. He told me that certain dragons could not fire. This confused me initially as I did not program the game to have specific fire capabilities for specific dragons. So I started really looking into it and found that bug in the game. Once I found it, it came time to fixing it.
This is where things can get hairy. I am still learning Flixel and the Power Tools, and so my ability to debug games based on it is still building. So it took me probably around 4 hours of Google searching and code crunching to find it. If you really care, the problem came about by me forgetting the line “FlxControl.clear();” in my play state’s destroy function. This function has the exciting purpose of cleaning up the keyboard controls when the game is ended. Without it, the game gets confused and muddled and loses the ability to function properly.
All that is beside the point though. The point is, that no matter how simple a game is, it is always important to play test it. Not just you, however. You should try to get a third party in to test as well. Someone who is not as close to the project as yourself. Someone who will play the game in a way that you would not. As you see, while I tested to make sure the game started over upon selecting “Play Again”, I did not properly test that the game continued to play as expected upon playing again.
Of course, this is all avoiding the most important aspect of play testing, the impact on you the gamer. You have all played games recently, whether browser based, PC or console, that have glaring bugs that only a blind, deaf and mute person could miss. These bugs that break your immersion in the gaming experience and drive you nuts. Proper play testing helps avoid all that. It is up to us the developer to make sure that you the gamer has the best experience possible when you pick up our game. Our paying (or in some cases non-paying) customers should never be forced to participate in a beta-testing experiment. Unfortunately, many game developers force you into that role. That is a disservice to you. It is one thing to invite you into a beta experience, but a completely other thing to trick you into one under the guise of playing a finished product.
Final verdict, play test and play test again. When you think you are done, play test some more. Only then can you release the best game possible, which gamers deserve.