Why have your game tested?
Let me tell you about testing my first IF game. When I had almost finished with what I thought was fairly solid work I went to rec.arts.int-fiction looking for beta-testers. I was a bit embarrassed to send the game to the testers because, well, there weren't any bugs there.
Yeah, right. The reality struck pretty hard when the first transcripts from the testers started to come in. After a lot of fixing and tinkering there was still a show-stopping bug left in the final version.
If you are an author working on your first game it's very easy to think that your game doesn't need testing. You've played it through yourself maybe hundreds of times and it works fine, so what's the point? The problem is that you know too much of the game to objectively test it yourself. You know the solution to every puzzle and every conversation topic the NPCs respond to. The point is that you need someone who doesn't know and therefore naturally tries everything they can think of.
The fact is that if we ignore the most trivial "Hello World" examples there is not one piece of software that would not have a single bug. And even if we would have a game that would be completely technically bug-free, there's always the question of playability. Do the puzzles work, are they hinted well enough? Is the prose good? Are there any spelling errors? Are the NPCs realistic and respond to reasonable discussion topics? There's more to gametesting than just hunting technical errors.
Testing a competition entry
Let's look at the entries in IFComp 2008. Out of the 35 entrants only roughly half were beta-tested (or at least credited betatesters in-game), but out of the top 10 games eight were beta-tested – namely all those that finished in places from 1 to 8. This doesn't mean that having your IFComp entry beta-tested will automatically guarantee placement in the top 10 but if you have the game tested (and modify/repair it according to the feedback from the testers) you are guaranteed a higher score than what the game would get if it were untested.
If you read some IFComp reviews or any other IF reviews for that matter, there's always one thing that the players pay attention to: does the game have bugs or not. It's an aspect that is always easy to notice and easy to focus on. If a judge finds the game bug-ridden or even a couple of annoying bugs, they will give a lower score than what they would otherwise give. And if a player finds so many bugs that it gets in the way of having fun with the game, they will quit the game and never return to it again.
The player judges the end result, not the development
Another easy mistake to do is to think that the player will "forgive" the bugs in the game. Maybe you have a list of things that need to be fixed, or you have spent months working on the game. You've fixed 99 % of the bugs you've found, surely the player won't mind just the measly 1 percent?
This is another case where the player's viewpoint is different from the author's. The player doesn't know anything about the 99 % of the bugs you've already fixed or the overnight coding sessions while rushing to meet the deadline. They will only see the finished product as it is. When they start playing they have no history with it and all the work spent making it is opaque to them.
The point here is that the players don't appreciate the amount of work used making a game – they appreciate a good game, period. I'm not saying that there wouldn't be a correlation between hours spent making the game and the end quality, but if you spend 500 hours making a game and it sucks because you didn't use another 10–20 hours finding beta-testers and fixing the issues they find, you've basically thrown the 500 hours down the drain.
Sometimes the game's author acknowledges that the game isn't finished and promises to release a fixed version later. Again, the players don't care for this kind of promises. They play the version they have at their hands now, not some hypothetical future version.
Summary
To sum up: always have your game tested. There are always bugs, and this is not to diminish your programming or game designing skills. It is a hard fact. Nobody writes flawless code or designs flawless games. Thorough testing can squash enough of the bugs so that the players find the end result playable.
Don't assume that players will forgive the mistakes in your game. Fix everything you can, and if you're working against a deadline and you can't make it in time, don't release the game yet. There's always a new competition around the corner or coming up next year. If you release an unfinished game you will get such crushing reviews that the chances are you won't ever feel like making another game.
As authors our goal is to make good games. While testing doesn't automatically guarantee a good game, it is nearly impossible to make a good game that isn't tested.
