The first time I ran a public test of LexyQuest, the three or four people who joined in quickly found and exploited a bug that, as far as they could tell, wasn't a bug but just a feature. This specific bug arose from the fact that instead of making the attack verb take (mob/m as mob in oview(1)) as an argument, I gave it (mob/m as mob in oview()). Meaning? Instead of being restricted to attacking monsters one square away, players could attack anything they could see. In the absence of descriptive combat messages, everyone just assumed that they were fighting with bows or something.
I'd tested this game several times over the course of a week myself, but I never once noticed that this bug was there, and its possible that I never would have. Do you know why? Because I, the designer of the game, already knew for a fact that it's impossible to attack someone more than one square away. Why on earth would I ever both to check to see if it was possible? The players, on the other hand, didn't know any such thing... they had to find out for themselves, and in the course of finding out, they discovered a highly exploitable error.
Some people wonder why I don't provide clear instructions or documentation on my games when I run tests. Honestly, the above example is a wonderful illustration of why. I already know how the game is supposed to work. The players don't. If they go into the game knowing what I know, knowing what to expect... they'll never find anything that I wouldn't find myself. What playtesting needs is unprejudiced eyes.
BYOND's compiler is pretty clever in the way it parses for errors, but because it can't predict the future, it's still possible to generate a lot of run-time errors, some pretty serious, by feeding the wrong type of argument into a verb or proc.
For instance, imagien a verb that's intended to be only used with a magical flute as a target. The designer might only ever test the verb with a magical flute, perhaps using a non-magical flute as a test case, to make sure it displays the proper response to having the wrong flute. But will the designer think to use the verb on a flowerpot, person, or plot of land? Of course not! The designer knows this verb is for magical flutes, and it's unthinkable to him or her that anyone will try to use it with anything except a flute.
Now comes a player, someone who doesn't know what the verb is for, doesn't know what the difference between flutes and magic flutes is. This player tries to use the verb on the Genie of the Well. INVALID PARAMETER! TYPE MISMATCH! BAD VAR: FLUTINESS! CANNOT MODIFY NULL.FLAUTISTRY! and so on.
The designer never would've caught this error left to his or her own devices... but with the info gleaned through playtesting, the he or she is able to go back through their code and find the verb. By typing the variable representing the magical flute a little more specifically, future errors can be eliminated, and the code continues, better than ever.
In short, the purpose of early playtesting isn't so people can see how good your game is... it's so you can see how bad it is.
ID:154487
 Jul 30 2001, 9:11 am
|
|
On 7/30/01 1:11 pm LexyBitch wrote:
cut... In short, the purpose of early playtesting isn't so people can see how good your game is... it's so you can see how bad it is. Too bad the commercial game makers don't come to BYOND board and read this... Like I always say: "Are the people still buying betas?" | |
I agree. I'm seeing it in a different light, now. I normally provide (and/or, would provide) documentation with my demos, so people at least understand what the heck they're doing, especially in games as complex as the ones I'm making.
Slurpy is a "bit of cheese" kind of game. The documentation that comes with it is a person's own smarts. The Haven Seed, on the other hand, has tons of code and I've hardly scratched the surface of my dream. If people started playing it, they'd quickly find out that the game didn't have standard controls, that there were many subtle nuances, etc. It'd be impossible to find them all out on their own.