The IF Beta Site Info Page

How To Submit A Game

How To Be A Tester

Signing up.

To sign up to be a beta-tester for IF games at this site, sign up for the IF Beta Site mailing list at http://plover.net/mailman/listinfo/beta. This will both give you the username and password needed to use the beta site (http://plover.net/~textfire/beta/) and put you on a mailing list to receive updates about the games: when new ones arrive, when old ones are updated, and generally when things happen at the site you should know about.

Downloading the games.

When you visit the above URL and enter the name and password, you'll be presented with two lists of games, one list of submitted games whose authors intend to enter them into the annual IF Competition, and one list of games not intended for competition play. As the competition deadline looms, we ask that you focus more on that list. At other times, or merely for a change of pace, you may select games from the non-competition games.

Each list is sorted according to how many people have already downloaded the games. A game high on the list has not been downloaded as often, so we ask that you select those games first, unless you already downloaded the game in question, or if the game will not run on your system. Selecting the game and clicking on the 'Pick Game' button will take you to an information page about that game, including the author's e-mail address and a note (if any) from the author to their beta-testers (you!). Going to this page will not increment the download counter, so if you find you have misplaced an author's e-mail address, for example, feel free to revisit the page.

At the bottom of this information page will be a link ('Download game') which should download the game in question to your computer. If it does not, please e-mail me (again, lpsmith@rice.edu) and tell me what error message you got, if any. I've made some simple mistakes in the past that can usually be corrected fairly easily, but the faster you mention it, the faster I can correct the problem. (This is the link that activates the counter. If you need to download the game more than once, that's fine, but please send me a note so I can go in and fix the counter to more accurately reflect the number of testers each game has.)

Playing the Game

Hopefully, the information on the info page will be enough to tell you how to play the game. If not, please feel free to e-mail either the author of the game or myself asking how to do it. The two most popular systems for IF, Inform and TADS, produce games that can be played on a variety of computer systems. These games require another program, called an interpreter, which runs the game itself. Usually, you then run the interpreter, and load in the game (rather like if you were to send a Word document to someone, they'd need to first run Word, then load your document into the program.)

A popular interpreter for Inform games for Win95/98 systems is 'Windows Frotz', found at http://ifarchive.org/if-archive/interpreters-infocom-zcode/frotz/WindowsFrotz2002.zip. Interpreters for other systems can be found in that same directory. Once you download Windows Frotz, you can use it to play any Inform game (recognizable by the .z5 or .z8 extension) you later download.

The standard interpreter for TADS for Win95/98 systems can be found at http://ifarchive.org/if-archive/interpreters-other/tads2/executables/htads_playkit_256.exe As with Inform, other interpreters for other systems (and for Win95/98, actually) can be found in the same directory. TADS games usually come with .gam extensions.

These interpreters get updated every so often; if the above links do not work, check the directory and download the latest version.

Providing Feedback

This is the core of your job, obviously. While a variety of approaches to this can be effective, enough people have asked about this that I've provided a general outline of what to do and what to look out for while playing the game to help you provide helpful feedback to the authors. There are a few articles that can help, as well:

• "Oh No! Beta!" by C. E. Forman
• "Beta- testers I have loved" by Neil deMause.
• "Interview with a Player Extraordinaire" by C. E. Forman, interviewing Michael Kinyon, and
• Beta-testing For Fun and Profit by Stephen Granade. (link currently not working)

Scripting

I have come to believe that it is absolutely essential for beta-testers to keep a script of the games they test. In this way, obscure bugs with non-obvious causes can actually be reproduced when scrutinized, and it provides an excellent memory jog when reporting things. In most systems, this can be accomplished by typing 'script' at the prompt. It can also be important to keep track of what version of the game you're playing, so the author knows when you report a bug they've seen before whether it's one that has crept into the latest version as well, or merely indeed the bug they know about. For this reason, when testing a game, I've taken to starting off with the following three commands:

>SCRIPT ON

[the game will usually prompt you for a file to save the script as here]

>VERSION

[the game will usually tell you the name of the game and the release number, etc. If not, try 'ABOUT' or 'INFO']

>RESTART

The final 'Restart' will save to the script any opening text you might not otherwise record.

Recording your impressions

It is important to take note quickly when you find something you want to comment on. In a game I've been testing recently, I've found it convenient to simply take notes within the transcript itself, enclosing them in []'s. The game will probably simply not be able to understand what you're typing, and ignore it:

Over their, you see a button and an umbrella.

>[WHOOPS. 'THEIR' SHOULD BE 'THERE']

I don't understand the punctuation '['.

Other options include having another window open in which you take notes, going over your transcript soon after you play the game, and (goodness!) taking notes as you play using actual paper.

What to look for

C. E. Forman has a list of categories in his article; here's mine:

• Flat-out bugs. The game simply goes awry in response to some input or pattern of input. Illogical situations, the game crashing, weird characters showing up on your screen, even typos--I lump all these things together, because they're the group of things that absolutely need to be fixed before the game is released.

• 'Would be nice' additions. Whenever you tried something and the game gave you a default response or no response at all, if you think it would be a valuable addition, suggest it. When testing 'Sunset over Savannah', one situation involved trying to hold your breath for a long time underwater. Since I would do it in real life, I tried, >HYPERVENTILATE, and the game, unsurprisingly, didn't know that verb. I threw it on my 'would be nice' list, and Ivan went ahead and put it in (not as a solution to the puzzle, but at least gave it a response). In my own game, "The Edifice", one of my testers remarked that the default response to 'jump' ("You jump on the spot, fruitlessly.") seemed a bit incongruous when the player was, indeed, holding a piece of fruit ;-) When I was done laughing at the report, I went ahead and coded in a unique response for that situation. A player later told me that was one of their favorite moments from the game. While it would be no great loss to leave these types of things out, including them can make playing the game a fun experience--and these types of suggestions often come from beta-testers.

• Suggestions/Comments. Here's your chance to make positive comments as well as negative ones. Particularly liked a room description? Mention it! Thought the epic battle scene wasn't exciting enough? Suggest how to make it more dramatic! Comments about how puzzles worked and didn't work for you are also good here. How was a particular puzzle well-clued? Why did you need hints for another? What was your thought process while working through a third, and why did you try the things you did? Was it good or bad that you tried those? Did you have fun?
  All too often, bug reports consist of nothing but, "I enjoyed the game, here are some typos and I crashed it by doing X." If you can, take the time and tell the author why you enjoyed the game. What parts were fun? What parts weren't? Does a particular section not fit the rest of the game, and need to be removed or changed? Does the game concept need to be rethought? These are tough questions, and it can be easy to miss them and loose yourself in the details. But if you can make some good comments here, they can end up making the game ten times better than just correcting some typos.

Corresponding with the Author

It can be helpful to the author if you organize your report in some way, whether along the lines mentioned above, or as in C. E. Forman's article, or in some other way. I also like to ask the author if they would appreciate seeing the entire script instead of just the bits I cut out and sent them; some do, some don't. Be prepared to answer questions the author might have about your report, whether the specifics of repeating a certain bug, or clarification about some of your comments. Don't let the author get too defensive on you--if you need to, remind them that these are only your opinions, and that it's their game, after all. Conversely, don't get aggravated if all of your suggestions aren't included in the next release--it is, again, the author's game, and just because they asked for your opinion doesn't mean they have to follow it. They have to make the best decision they can based on a host of factors including other bug reports and what they consider their ability to implement the various suggestions.

Afterwards

So, you've sent in all your reports, and the game is finally released. When requests for hints start showing up on the newsgroup, it can be tempting to jump in and answer their question, along the way explaining the hidden significance of the whoozit, and did they notice that if they push the fromitz *east* instead of west, you can avoid the...

Resist this urge.

Let the players discover the hidden charms of the game for themselves--the fact that they're hidden is half the reason they're charming. Different authors have different views on whether they want their betatesters answering hint requests, but if in doubt, simply refrain. If you get authorial permission, and some poor soul is really floundering, try to gently nudge them in the right direction. Only when someone has the right idea and none of the command they try work should you go give explicit instructions (>PUSH THE FROMITZ EAST)--and kick yourself for not reporting the alternate way of phrasing the command back when you had the chance ;-)

(As an aside: If you tested a competition game and wish to vote on the games, this is fine, as long as you don't vote for the one you tested.)

Moving on

Now that you've tested the game, you may want to test another, whether from this site or somewhere else, and we'd certainly be glad to have you volunteer again. As you test more games, you'll probably find yourself becoming a better tester--and it can be an absolutely invaluable experience if you ever decide to write your own some day. And if you do, and need testers, you know where to reach us.