|
>EXAMINE GAME
HOW I BUILT IT
notes from eighteen months of evenings
[ about the game ] [ transcript ] [ hints ] [ how I built it ]
>WHY TADS?
There are two big systems for writing text adventures right now, and both are free. Graham Nelson's Inform makes story files in the same format Infocom used, so the old Infocom interpreters can play them. Mike Roberts's TADS, the Text Adventure Development System, has its own format and its own interpreters. People argue about which is better on the newsgroups the way other people argue about Macs and PCs, and you should ignore all of them, including me.
I picked TADS 2 because its language looked a lot like the C I use at work, because it comes with a standard library (a file called adv.t) that already knows how doors and containers and light sources ought to behave, and because the manual is good enough to read on the bus. You write your game as plain text files in any editor, run them through the TADS compiler, and get one game file that anybody with an interpreter can play.
The finished game is about 9,000 lines of source in six files: one for rooms, one for objects, one for the janitor, one for the clock and the timed events, one for the endings, and one I named misc.t that I'm not proud of.
|
>SHOW ME SOME CODE
|
In TADS, everything in the game is an object, and you describe it by listing its properties. Here's the microfilm reader from the Film Room, trimmed a little so it fits on the page. The words in single quotes are what the player can call it. The words in double quotes get printed on the screen.
|
/* The reader-printer in the Film Room. */
microReader: fixeditem
location = filmRoom
sdesc = "microfilm reader"
ldesc =
{
"It's a gray steel reader-printer the size
of a console television, with a hooded
screen, two spindles for reels, a hand
crank, and a red button marked PRINT. ";
if (self.isLit)
"The screen glows a dim, even yellow. ";
else
"The screen is dark. ";
}
noun = 'reader' 'machine' 'screen' 'printer'
adjective = 'microfilm' 'gray' 'grey' 'steel'
isLit = nil
verDoTurnon(actor) =
{
if (self.isLit)
"It's already on. ";
}
doTurnon(actor) =
{
if (spareBulb.location <> self)
"You click the switch. The fan starts
up with a whir, but the screen stays
dark. ";
else
{
self.isLit := true;
notify(self, &bulbWarning, 40);
"The fan whirs, and after a moment
the screen comes up a dim yellow, like
a window at the end of a long hall. ";
}
}
; |
A few notes for the curious. fixeditem is a class from adv.t for things too heavy to pick up, so I didn't have to write the message for TAKE READER myself. The verDo method runs first and decides whether an action even makes sense; if it prints anything, TADS stops there. The do method actually does it. TADS 2 uses := to set a value and <> for "not equal," which tripped me up for about a month, because at work it's the other way.
That notify() line is the one way to lose that the hints page warns you about. It sets a timer. Forty turns after you turn the reader on, the bulb starts to flicker, and the game tells you so. If you still leave it on, it warns you again, and then it's gone. A playtester asked me why I'd be so cruel. I told her I once left a borrowed slide projector on overnight in college, and I've never forgotten the smell.
|
>HOW DID YOU TEST IT?
I test software for a living, so I tested this the way I'd test anything, which is to say with a spreadsheet and no mercy.
1. The object list. Every one of the 140 objects got a row, and every reasonable verb got a column: examine, take, open, read, smell, look under, look behind, push, pull, eat. Every empty cell was a bug until I'd decided what should happen. Most of them just print a polite no. But the polite no has to be there, or the player feels like they've walked into a cardboard set.
2. The walkthrough. I kept a plain text file of every command needed to win, start to finish, and fed it to the game after every change I made. If the ending stopped happening, I knew I'd broken something, and I knew it that night instead of three weeks later. At work we call this a regression test. At home my girlfriend called it "the thing that beeps at midnight."
3. Real people. Four volunteers I found through rec.arts.int-fiction played it and sent me their transcripts, every command they typed. Between them they found 212 bugs. Reading somebody else's transcript of your own game is the most humbling thing I've ever done, including asking someone to the prom.
|
>WHAT DID THE TESTERS FIND?
A few favorites, all fixed now:
* You could put Book 214 inside Book 214. The game said "Done." and the book vanished from the universe. (Strictly speaking, no tester found that one. A player did, a week after Release 1, and wrote to tell me very politely.)
* You could give the razor blade to the janitor, and he'd thank you and shave, and then the evidence was gone for good and you couldn't get the best ending.
* EAT CIGAR BAND worked. It was worth no points and nobody should have tried it, but two testers did, separately, which tells you something about testers.
* If you waited long enough, the clock went past 11:59 P.M. to 12:00 A.M. and then to 13:00 A.M., which is a time that has never existed in any county.
* The big one: three out of four testers, in their first ten minutes, typed LOOK UNDER DESK. Every desk. Over and over. There was nothing under any desk, and every time the game said so, they got a little sadder. So for Release 1, I finally put something under one. If you've read the hints page, you know which. That's the best design advice I can give anybody: watch what people try, and then make some of it work.
|
>WHAT I'D DO DIFFERENTLY
Write the ending first. I didn't know how it ended until month fourteen, and I had to go back and change half the clues.
Make fewer rooms. Twenty-three is too many for a game this size. Five of them are only hallways, and nobody ever said "I wish there were more hallway."
Give the janitor more to say. Everybody who wrote to me wrote about him. I wrote him in one weekend, almost as an afterthought, and he's the only character people remember. I think there's a lesson in that, too.
|

Questions about TADS, the game, or bugs:
[email protected]
Last updated September 17, 1999
|