Preparing a game for testing

Shamus Young has some interesting comments on parsing in IF and how he thinks it could be improved; Mike Rubin has a response. Partly this comes down to an argument in favor of juiciness in IF games, with some crowd-sourcing ideas for how to accomplish that juiciness. Eric Idema’s ifrotz project seems actually fairly relevant to all this, since it looks as though it might enable some of the things Shamus imagines, in terms of group testing.

This is all potentially valuable. It touches on only part of the quality-assurance problem, though, as this year’s comp crop reminded me. We tell authors to have their games tested thoroughly and to give themselves lots of time for the testing process (all of which is good advice), but in my experience it is difficult even for diligent testers to get a game up to an ideal state of polish if the author hasn’t done a certain amount of anticipation to start with.

It’s especially bad if an author hands off a game that he realizes has a bunch of flaws in it, when he’s just been too lazy to correct those flaws before the beta-test. (There’s a certain amount of judgement involved. I’m guilty myself of putting stuff into testing that had known problems — but most of the time [I like to think] there were reasons to do so: I wanted tester feedback on how best to amend the problems I saw.)

Nonetheless, the general principle here is the same as the general principle when I’m working with a student on the draft of a paper. If the student’s first draft is a B effort, there’s a fair chance we can work together and wind up with a final version in the A- or A range. If the first draft is a D effort, it’s unlikely it will come out as an A even with revision. Worst of all, if the student brings me a draft that doesn’t represent his best work — it’s a D paper from a B student — then any feedback I offer is going to consist of me wasting my time telling him what he already knows. This is annoying to me and bad for the student. I might want to offer the kind of advice that would take the paper to the A piece the student could potentially write — but there’s just nothing there to work with, no way to give him substantive guidance when he hasn’t let me start from a plausible draft.

Testing is a little like that. Beta-testers, like teachers, tend to focus first on the most severe problems. If you give a tester a game riddled with typos and basic implementation gaffes, those errors are likely to absorb the majority of his time and attention — even though the same tester might well be competent to offer much more interesting feedback on a more honed project.

So how do you get a game into a good state to be beta-tested? Play it a bunch yourself — that’s part of it. Spell-check the output text. Proofread as well as you can. But it also helps to think as systematically as possible about the material that’s in your game. What are the obvious commands that every player is going to use on this object? How can you give interesting and entertaining responses to these? What sorts of interaction do you actively want to encourage? How can you guide the player towards puzzle solutions?

Once you’ve written a moderate amount of IF, you start to have an instinctive feel for the kinds of items that are going to require extra implementation beyond simply creating the object and its description. Off the top of my head, here are some of the most common:

1. DOORS AND KEYS. You have doors and keys and they don’t open and shut themselves in a non-annoying fashion. “Locksmith” or else Eric Eve’s “Implicit Actions” extensions are your friends. Players are getting less and less tolerant about this stuff. (You may ask why the behavior of Locksmith isn’t built into Inform mandatorily, to which my answer is, well, sometimes you don’t want it.)
2. TREES AND OTHER LARGE PLANTS. The player will try to CLIMB the plants.
3. FOODSTUFF. Can you eat it? Then you can probably TASTE and SMELL it as well. (Conversely, if you have a really nasty object like a poison or foul-tasting substance, you’ll want to handle both TASTE and EAT with some kind of snappy refusal.)
4. CLOTHING. Make sure that it at least can be worn and taken off again. This will seem painfully obvious, but I have run into hats that told me “That’s not something you can wear.”
5. CONTAINERS. Think through: does it open and close? Does it lock? I’ve run into sacks that I wasn’t allowed to put anything into and boxes I was told contained things, but which I wasn’t allowed to try to open.
6. FURNITURE. Make sure all your sofas and chairs can be sat on (“enterable”, in Inform parlance; other languages use other techniques), even if you regard them only as scenery. If you have a BED, you may want to add some more crafted response to SLEEP when the player is on it.
7. RANGED WEAPONS. You have a gun, a bow and arrow, or any other weapon that acts at a distance? You’re going to need to implement all the variant syntaxes for SHOOT THING, SHOOT GUN, SHOOT GUN AT THING, SHOOT THING WITH GUN; perhaps even SHOOT DARTS FROM BLOWGUN. (The guess-the-syntax problem is the ugly step-sister of guess-the-verb: it gets less attention but is actually more complicated and interesting.) “Technological Terror” demonstrates this for Inform 7.
8. FLAME SOURCE. The player will try to BURN things with it. You can go with some kind of general refusal, or you can implement a whole burning simulation (the latter being rather harder), but you should at the very least acknowledge BURN, and probably add syntax to understand BURN thing WITH source.
9. EDGED WEAPON. The player will try to CUT things with it. The same general rules apply as apply to flame sources.
10. FRAGILE THINGS. The instant you say or hint that an item is fragile, some player will want to smash it. Prepare for THROW, DROP, ATTACK, and (possibly) KICK.
11. ATMOSPHERIC SOUNDS. Do you mention a noise to the player in order to provide some atmosphere? Make sure that it’s also mentioned in response to LISTEN, in that case. For bonus points, allow the player to LISTEN TO TRAFFIC (or whatever it is) as well as just listening to the environment.
12. PASSING PEDESTRIANS AND OTHER TEMPORARY SIGHTS. Similarly, you may have things that are described briefly with the intention that they be passing through the environment. Unless you make them gone again immediately, though, the player may try to look at them. For Inform users, “Uptown Girls” offers one way to make a temporary character visible for further examination until she is supplanted by another passerby.
13. BOOKS. Implementing a book depends a lot on what you expect the player to do with it (read right through? look something up in an index? turn to a page whose number he finds elsewhere in the game?), but at a bare minimum I expect READ to work, and ideally to deliver some information that is different from the information I get from EXAMINE. OPEN BOOK is also a nice touch. For Inform users, there are several different examples in the Recipe Book on readable materials.
14. COMPUTER DATABASES. In the age of Google, more and more modern or SF games feature some kind of computer data search. You’ll want SEARCH FOR topic ON/IN computer, LOOK UP topic ON/IN computer; you’ll want to provide sensible defaults if the player more lazily types LOOK UP topic, SEARCH FOR topic; in a modern setting you may want GOOGLE topic.
15. SWAPPABLE STORAGE MEDIA. DVDs, tapes, datacubes. Make sure they can be put into their device and taken out again; make sure that the device fails sensibly when empty.
16. LARGE BODIES OF WATER. Be prepared to handle DRINK and SWIM, as well as FILL container WITH liquid — even if only with generic refusals.
17. NON-STANDARD ROOMS. Your player is floating in space or swimming in a location that has no floor? You’re going to want to modify JUMP.
18. BONDAGE. You’re writing a scene where the player is confined, strapped to a table, paralyzed from the neck down, etc. You’ve probably already thought of trapping commands like GO, EXIT, and so on, but you’ll also want to appropriately modify JUMP, WAVE, and WAVE (thing). If you have a system that builds in KICK, you’ll want to handle that as well. (Inform does not have KICK as a built-in verb, but I seem to recall that TADS does.)
19. DISTANT OBJECTS. You coded something distant (like the sun) or intangible (like a smell or a shadow): the player needs not to be able to come in physical contact with that object. In I7 there are extensions that will take on this problem for you, if you’re not sure how to code around it; or you might be interested in the examples “Electrified” (fairly simple) and “Frizz” (fancier).
20. CHANGES TO THE PLAYER CHARACTER. You’re making the PC into a rabbit, or an ogre, or an immovable giant space polyp? Expect to overhaul all the actions. Look through the whole library and make sure that you have character-appropriate responses to all the actions the player might try. (For Inform users, this is a good time to haul out one of David Fisher’s extensions to replace default messages.) There’s lots of potential for funny or charming responses here — juiciness galore — but on the other hand a single uncaught default message can snap the player out of the illusion you’re trying to create.

The more general rules here are:

Go through each of your objects and consider: is there a kind/class in the standard library for the language I’m using, to which this object really ought to belong?

Go through the standard library of actions and ask yourself: are there times in my game when this action won’t make sense? (If so, add error-catching.) Conversely: are there actions in my game that the player needs to do frequently in order to solve puzzles? In that case, I should lavish extra attention on those actions in order to make them very responsive. Default library responses should be replaced, even for failures. (For instance, if I have a game where the player needs to burn a lot of items, BURN FOO should NEVER produce a default “This dangerous act would achieve little” sort of response. If the particular thing the player is trying to burn cannot ignite, then say so — but encourage the idea of burning stuff in general.)

If you’re creating a new action for the first time, protect yourself against guess-the-verb problems by thinking systematically about equivalent ways to express the same thing. It doesn’t hurt to look up your word in a thesaurus, and include all the synonyms that sound plausible. In fact, it also doesn’t hurt to look up your word in a regular dictionary — yeah, I know that sounds redundant, but a decent dictionary will list all the variant usages of the word in question. That lets you capture guess-the-syntax problems (as with “SHOOT” in the list above).

Speaking of the IF Competition: voting for IF Comp 2008 ends on November 15; you must rate a minimum of five games for your vote to count, which means there is still time to participate, even if you haven’t gotten to many of them yet.