I spent all week preparing for a our first major test. My goal was to have 3 game modes, 3 levels, and the character creation menu done. The difference with this test was that there were 4 people playing at once. This is very difficult to do with only two people on the development team. The testing session was scheduled to begin at 2:30pm on Sunday afternoon. I finished everything that I wanted to only a half hour earlier. I was satisfied that the 4 players would be able to play the game relatively bug-free. Well, let me tell something. That is not what happened. Here are the order of events:
1 – Game 1: After everyone has picked their ships, the game is started. None of the ship spawn. We are staring at an empty level.
2 – I make everyone leave the room for 15 minutes while I and a programmer friend (he is the only one I allowed to stay) fix the issue.
3 – I invite everyone back in. They play a Survival match. Eliminated players respawn. There are now zombie ships in my game.
4 – I declare Survival to be broken and I get a notepad in anticipation of more bugs.
5 – They start a Steal The Orb match. I learn that one of the ship types can be destroyed by a single missile. That’s not supposed to happen.
6 – They play another Steal The Orb match. This time we learn that the all green colored ships are invincible.
7 – After learning about all the bugs, they pick a setup that avoids them all. They play a match that is bug-free and it is amazing.
The bugs came hard and fast since the moment I fired it up. Jeff and I were both surprised by how broken things were. What I found interesting was that I after everyone left, I was able to fix every bug they found in about 25 minutes. They weren’t hard to fix, they were hard to find. I learned not to trust anything I’ve done unless it has been thoroughly tested in real-world scenarios. In this case, testing took more time than fixing. This suggest that bug-filled games are likely due to mismanaged time, not lazy programmers.