I was gathering video footage for the Hyperspace Pinball trailer when I encountered two bugs:
- If you held the ball in place next to the flipper by keeping it upright, the ball would think it was stuck and then disappear back into the launch area.
- Level 18 only required you to destroy five enemies to advance.
I quickly fixed them and resubmitted the final build to Desura, but it is a grim reminder that I came that close to releasing the initial build with those two issues. These are things that should have easily been detected during full-on testing, but were not. Why? Because I tested my game to prove that it worked. I knew the right approaches, but I didn't do them anyway because I was being too casual:
- When you test a game, your job is to prove it DOESN'T work.
- Treat all untested areas of your program as points of failure.
The game was out in beta for weeks, and while some issues were reported, those were not. I also intentionally left some bugs in the game during the beta in hopes people would find them, and they were never reported.
Back at GDC 2010 I asked a few Indie developers how they got their games tested. The answer was always the same: Friends or other developers with a vested interest in the project just hammering away for hours. Without a community following or even other developers helping out, I seem to be at a disadvantage there; but that simply means I need to work harder at it on my own.
So I'll keep play testing until the release is out; though I seem to have better luck finding bugs when I'm not actually trying to find them. Maybe I should add a third bullet to my testing rules: Making a trailer is a great way to test your game because you're trying to make it look its best while not actively trying to find bugs at the same time.
Oh, and one more from experience both working solo and in teams: A developer is often their own worst tester.
Check out my homepage and news feeds
And my projects!
