The IF Beta Site Info Page
This page is intended to be an exhaustive compendium of all the
information you need to be a beta-tester for the games we have at this
site, and for authors who want to submit games. If you've been a
tester here or somewhere else before, chances are you already know or
can figure out most, if not all, of the information presented. But if
you're new to IF or to testing games, or if you simply want
clarification about something, chances are the information is here. If
it's not, send me an e-mail (firstname.lastname@example.org) and I'll include
How To Submit A Game
Once you've written a game (either for the Annual IF
Competition or a non-competition game) and want to submit it to the
site, I'll need
two things: A copy of your game, and a brief readme file detailing
anything in particular you want your testers to know. You can
send these to me as an e-mail attachment (email@example.com), or (in some cases)
let me know where to download them.
After that, I'll send a note to the testers telling them a new game has
been added to the list. As a new game, yours will be first on the list
for a while, until it gets more downloads than some other game. Testers
are instructed to e-mail you directly; feel free to correspond with
anyone who sends you a report, asking for clarification, etc.
Once you fix the submitted bugs, you may want to let the testers have
another go at the game. Feel free to submit a revised version, as
above, and I'll replace the old one on the site, and inform the testers
that a new version has arrived (the vote counter gets reset at that
That should be about it! You may also want to read the instructions for
the testers, below, to get a sense of the kind of reports you might
How To Be A Tester
- 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
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, firstname.lastname@example.org) 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
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
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.
- 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:
- 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
[the game will usually prompt you for a file to save the script as here]
[the game will usually tell you the name of the game and the release
number, etc. If not, try 'ABOUT' or 'INFO']
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
- 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.
- 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
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.)
- 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.
This line last updated June 25th, AD 2002