XYZZYnews
March/April 1996 Issue #8
+++++++++++++++++++++++++++++++++++++++++++++
HOLLOW VOICE
+++++++++++++++++++++++++++++++++++++++++++++
Whatever happened to the old Infocom implementors? How long does it
take to write a text adventure? What's involved in testing these games
anyway?
These are some of the questions that show up in my XYZZYnews mail
repeatedly, and I'm happy to report that we have some partial answers
in this issue.
First up is a where-is-he-now interview with Dave Lebling, co-author of
the original mainframe Zork and creator of numerous other Infocom
titles. I'm happy we were able to track him down, and even happier that
he was good-spirited enough to share his thoughts on IF gaming today.
This issue also includes Stephen Granade's blow-by-blow description of
how his game Waystation came to be written over the course of five
years. Whew! Next, C.E. Forman offers some good guidelines for aspiring
beta-testers, with a sidebar from Neil deMause about the making of his
game Lost New York.
I should point out that some of the other more frequently asked
questions that come my way are answered in the XYZZYnews FAQ at
http://www.interport.net/~eileen/design/xyzzyfaq.html. If you have a
question and don't see it answered there, please continue to send your
questions my way via e-mail. :)
On a highly unrelated note: I recently began working on a book (it's
about Adobe Photoshop, that wonderful mainstay of graphic designers
everywhere) for Prima Publishing. If I have time and am truly inspired,
I hope to extend my renewed interest in the graphic arts to revamping
the print version of the 'zine! :)
Until next issue, happy gaming!
Eileen Mullin
[email protected]
+++++++++++++++++++++++++++++++++++++++++++++
TABLE OF CONTENTS
+++++++++++++++++++++++++++++++++++++++++++++
Contents:
Top 10 Picks for IF on the Web
Letters
Interview with Dave Lebling
Tales From the Code Front:
Interactive Fiction in Five Easy Years!
Oh No...Beta!: Tips and Techniques for
Beta-Testing Games-in-Progress
Beta-Testers I Have Loved
Game Review: The Light: Shelby's Addendum
What's on the Disk
+++++++++++++++++++++++++++++++++++++++++++++
LEGALESE
+++++++++++++++++++++++++++++++++++++++++++++
XYZZYnews is published bimonthly by Bran Muffin Communications,
160 West 24th Street, # 7C, New York, NY 10011, USA. Email:
[email protected]. Send all inquiries, letters, and submissions to
the address above.
Contents (c) 1996 XYZZYnews.
All rights reserved. Published in the United States of America.
Electronic versions: There are currently three versions of XYZZYnews
made available online. One is in ASCII and can be viewed with any text
reader. You can also download a .PDF file that mirrors the layout of the
print version. Use the Adobe Acrobat Reader (available for Windows, Mac,
DOS and UNIX) to view the .PDF file; no special fonts or linked graphics
are needed. You can obtain Acrobat Reader from ftp.adobe.com in the
pub/adobe/applications/Acrobat folder, or
http://www.adobe.com/Software.html. Thirdly, you can also read this
issue of XYZZYnews on the World Wide Web at
http://www.interport.net/~eileen/xyzzy.8.html
Subscriptions: Both electronic versions are available at no cost. You
can obtain either one by FTPing to ftp.gmd.de. To be added to the
mailing list, please write to
[email protected] and specify text-only
or .PDF version. The print version includes a 3.5" Mac or PC disk and is
$21 (U.S.) for one year (6 issues) or $3.50 for a sample issue. For
print subscriptions outside the U.S. or Canada, please email or write
for rates.
All products, names, and services are trademarks or registered
trademarks of their respective companies.
Editorial deadline for Issue #9 is April 30, 1996.
Editor:
Eileen Mullin
Contributors to this issue:
Stuart Beach
Neil deMause
C.E. Forman
Stephen Granade
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
March/April Top 10 Picks for IF on the World Wide Web
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Jeff Mallett's Games Page
http://www.cruzio.com/~tao/games.html
Revenge of the Z-Machine
http://wanda.pond.com/~russotto/zplet/ifol.html
Neil Bowers' Interactive Fiction page
http://www.khoros.unm.edu:80/staff/neilb/intfiction/index.html
The Economist Review / Multimedia feature: Interactive Fiction
http://www.economist.com/review/1rt14/review.htm
BrymmStone's Dark Tower
http://w3.one.net/%7Ebrymstne/homepage.htm
Veritas: A Harvard Game of Interactive Fiction
http://www-leland.stanford.edu/~jreese/veritas.html
Games For The Non-Illiterate
http://ourworld.compuserve.com/homepages/doe/int-fict.htm
Faye's Shrine of Zork
http://www.bf.rmit.edu.au/~s9205250/Zork_Shrine.html
Welcome to the Kingdom of Zork!
http://ampere.scale.uiuc.edu/~boraski/zork/
Infocom Pictures Index
http://yallara.cs.rmit.edu.au/~s9406702/if/infocompics.html
+++++++++++++++++++++++++++++++++++++++++++++
LETTERS
+++++++++++++++++++++++++++++++++++++++++++++
Dear Eileen:
I first encountered bits and pieces of your magazine after a friend
sent me some excerpts downloaded from Peter Scheyen's Infocom home page.
I found the complete version of XYZZYnews while wandering around GMD's
IF archive, and downloaded the ASCII versions of the first 3 issues.
I was a bit frustrated with the double-spacing, but I was fascinated by
the content. Then I downloaded a .PDF version of Issue #4 and printed it
out.
(Insert lengthy pause here to indicate prolonged speechlessness.)
..I am in AWE. I had no idea there was anything like this available.
Your magazine's layout is breathtaking, but the relevance of the
contents far outstrips mere superficial attractiveness. Granted, the
download time for the .PDF format is about 3 times greater than the text
version, but I'll just have to ration my online time next month to get
the other back issues.
Please send me XYZZYnews in the .PDF format. I'm hopelessly hooked, even
though I have to endure the relative eternity required to print it out.
; )
Jay A. Goemmer
[email protected]
------------------------------------------------------
To: XYZZYnews:
In Issue #7 of XYZZYnews ["Interface Changes: A Brief Look at the
Evolution of the Adventure Game Engine," by C.E. Forman], you talk about
Mystery House and parenthetically state "I'd recommend that IF history
buffs pick up a copy if you can locate one."
Mystery House was released into the public domain by Roberta Williams on
Sierra Online's 10th Anniversary. (I seem to remember it being '87, but
you state it was released in '79.. Whatever, it's public domain now.)
You can find it at
ftp://ftp.gmd.de/if-archive/games/appleII/mystery.dsk.
Other stuff: Tass Times in ToneTown is available for many platforms,
including the GS. It can still be bought from Bill Heineman who did the
GS version.
The ICOM series also was done for the GS, and may still be available.
Matt Ackeret
[email protected]
------------------------------------------------------
To: XYZZYnews:
Just found out about XYZZYnews and have been reading back issues to
catch up. I read in issue #4 about your difficulties with IF, commuting,
and balancing a coffee cup at the same time.
This is something in which I have some experience. I'm an engineer, and
do some traveling. I carry a laptop most places, and usually end up
using up my battery on one IF adventure or another.
For me, half the fun of adventures is mapping everything out. I maintain
a master copy of my current adventure map in Autosketch, and work off
the latest printout. Any new areas I discover, I draw by hand and add on
the computer later on. I keep a file in my briefcase with my latest
notes and scribblings. All this I can fit on the surface of my briefcase
or on an airline tray.
Sorry, the cup of coffee doesn't fit with the above scenario. I found
that out the hard way.
Great job, keep it up, and I'm looking forward to the next issue!
Don Vande Polder
[email protected]
------------------------------------------------------
To: XYZZYnews:
It was only recently that I discovered the sizeable coterie of people
who continue in their devotion to text adventures. I remember playing
Adventure back when those who had 512K RAM were thought of as show-offs.
What a joy to find that people still play (and, better still, write)
interactive fiction.
I just read issue #5 of XYZZYnews and loved it. Nothing gives me more
pleasure than the knowledge that there are other eccentrics out there,
who, though not unimpressed by DOOM, nonetheless persist in their
attachment to the GUE and its cousins. Imagine! Other people out there
who will not finish their PhDs because they insist on procrastinating
with text-games!
Thanks for your devotion. Stephen Ramsay
[email protected]
------------------------------------------------------
To XYZZYnews:
I just discovered your XYZZY homepage and let me tell you.... IT'S
AWWWESOME. They should definitely have more pages like this one. I have
been a fan of Infocom games since the early '80s and anything else I
could get my hands on. I even would settle for the graphics/text games
like Amazon. I have just began playing around with computers again
(sparked by interest when I wandered through the software department and
saw The Zork Anthology and the Infocom compilations) and couldn't
believe some of the cool stuff I found when I entered in a search for
Infocom on Yahoo. Also do you have any suggestions on text-based games I
might want to try out since I've been away for so long? I used to love
Enchanter, Sorcerer, all the Zorks, and Hitchhiker's guide to name a
few. --
[email protected]
If you haven't yet discovered it, let me suggest you check out Carl
Muckenhoupt's Baf's Guide to the Interactive Fiction Archive (at
http://www.tiac.net/users/baf/if-guide.html.) -- EM
------------------------------------------------------
Infocom Bugs List Update
------------------------------------------------------
To XYZZYnews:
Saw that you created/maintain the Infocom bug list, and I have two
contributions.
Bug #1: You can steal the thief's stiletto. When the thief is in the
room, TAKE STILETTO. He'll swing it out of your reach. Type AGAIN or G.
Keep doing this until you're dead or he leaves the room. If he leaves,
do it again and you'll see the message
Taken.
If you check your inventory, you'll find no stiletto. Type LOOK AT
STILETTO to check out your ghost stiletto, which you can drop, pick up
and otherwise use, though it will never show up on room descriptions or
inventory lists.
If the thief meets you in the dungeon after you do this, you'll see a
message something like:
You feel a light-fingered touch, and turn around to see the thief
smiling at you.
He has stolen back his stiletto. However, if you go to the Treasure Room
while you have the ghost stiletto, he won't be able to steal it back. He
will still attack you with a stiletto (which can kill you), but if you
attack him (with any weapon) while holding the ghost stiletto you'll see
the message
The unarmed thief cannot defend himself: he dies.
Entertainingly enough, if you give the thief one of the game's other
weapons, he will be able to dodge and parry your attacks, though the
game will still insist that the thief is attacking with a stiletto.
After giving the thief a weapon, though (except the stiletto), you can
always simply TAKE it back -- while he's in the room! -- and kill him as
though he is unarmed again.
AGAIN may be buggy elsewhere throughout Zork; it doesn't make the same
checks full commands do. I know for a fact that I can't use it to take
anything from the unicorn or Wizard, though both attempts resulted in
the game behaving as if they were still in the room when they weren't.
Bug #2: in Beyond Zork, you can get a grue in a lighted room.
Kill the Ur-grue, but leave the other grues alive. Don't take the
coconut. Wander around the Underground and wait until a grue enters the
room. Then LIGHT LANTERN. You will be able to examine, fiddle with, and
otherwise harass a helpless "lurking presence" (which does nothing
entertaining, but oh well). If you attack the grue in a lit room, it
will register damage but will not counterattack and will not run away
when slain. Turning off the lamp or leaving the room will allow the grue
to flee if it has received its deathblow. Continuing to attack a grue
after dealing it a decisive blow generates no response.
Both of these work with LTOI.
I always hated grues and I always hated the stupid thief. Killing that
lean-and-hungry not-so-gentleman with his own stolen stiletto is one of
the more satisfying things I've ever done with my computer.
David Gildemeister
[email protected]
------------------------------------------------------
To XYZZYnews:
I noticed a very minor bug in Enchanter, version: Release 29 / Serial
number 860820
When the adventurer gives you something, no check is made to see whether
you are carrying too much already, so you can end up carrying more than
you would be able to normally.
For example:
>get pencil
Your load is too heavy.
>ask adventurer for pencil
The adventurer, not seeing any use in keeping the badly worn pencil
anyway, hands it to you gladly.
Neil B.
[email protected]
+++++++++++++++++++++++++++++++++++++++++++++
INTERVIEW WITH DAVE LEBLING
+++++++++++++++++++++++++++++++++++++++++++++
[Delve into the annals of adventure game history and you'll soon run
across the works of Dave Lebling. This prolific Implementor co-authored
mainframe Zork, Zork I, Zork II, Zork III, and Enchanter, and also wrote
Starcross, Suspect, Spellbreaker, and The Lurking Horror. In our
interview, we asked for an update on his post-Infocom activities and his
thoughts on the current state of the gaming industry.]
Q. How and when did you get involved in programming, and what led you
to coding adventure games?
I got involved in programming due to a fortuitous hole in my schedule in
the first semester of my freshman year. My advisor said, "Why don't you
take a programming course? It might come in handy." Well, I was
more-or-less hooked from the start, and always had an interest in games
and other fun stuff. I remember coding a version of the old Spacewar
game, for example. I also was co-author of the first -- that I know of
-- multiplayer MazeWars-style game; we just called it Maze. I helped
Marc Blank and Tim Anderson [later fellow Zork implementors] write a
Trivia game that maintained a user-contributed Trivia database of over a
thousand questions. I had also written for my own use some Dungeons and
Dragons "Dungeon Master Assistant" code that was still in a fragmentary
state when Adventure hit MIT and changed everything.
Q. Could you please summarize your post-Infocom activities, and what
projects you're currently working on? What kind of work do you do at
Avid?
Well, I first worked on a cross-platform GUI spreadsheet. A very boring
thing compared to Zork, but I learned a lot about C, Windows, X, Motif,
and other nasty topics. It was also a great development group, so
professionally it was a Good Thing, even if it wasn't gaming. At Avid,
well... I could tell you, but I'd have to kill you afterward, if you
catch my drift. Avid is a leader in software for producing and editing
video, audio, and multimedia for the professional and broadcast
marketplace. For example, "Home Improvement" is edited using Avid
systems.
Q. Do you still frequently hear from Infocom game fans? What kinds of
things do they still ask you about most often?
I wouldn't say "frequently," compared to how often I used to hear from
them. In the old days I'd get strange phone calls a lot. When I started
posting occasionally to rec.arts.int-fiction I began to get a reasonable
amount of email, but it's nothing excessive.
Q. Do you still keep in contact with any of the other Implementors?
I see Tim Anderson, Steve Meretzky, and Stu Galley with some frequency
-- we all still live in the Boston area. I haven't actually seen any of
the others in quite a few years, although I get Christmas cards or email
every now and again.
Q. How would you describe your involvement with the world of text
adventure games these days? Do you still do any game development as a
hobby?
My involvement these days consists of reading r.a.i-f and r.games.i-f,
browsing the Web, reading the magazines (such as Computer Gaming World),
etc. I haven't actually done any game development in quite a while --
I've got a fairly large number of game ideas, but not a great deal of
time!
Q. Do you keep up with the rec.*.int-fiction newsgroups and play the
current games-under-discussion from GMD?
I keep up with the newsgroups, but I haven't played any of the games. I
feel bad about that, because some of them sound really fun. Perhaps I'll
make time, but then, that's what I always said at Infocom, too -- I
eventually played all our games, but it often took a long time to get to
them. I've now gone so far as to download a bunch of the new games. This
is progress!
Q. Do you have a favorite Infocom game? Of the ones you worked on,
which one did you have the most fun developing?
There are things I like about every Infocom game, even Shogun (which
was, I think, both my worst and our worst). I've always been fond of
Spellbreaker and Enchanter from my own list. I think I had the most fun
writing The Lurking Horror, although I wish (we all wished) that it had
been an "Ezip" (meaning larger-size) game. A lot of lovely shivers had
to be cut out of the design, and some stuff out of the almost-finished
product. It was a labor of love, set as it was at a thinly-disguised
MIT, with lots of real places and a somewhat-accurate geography. Aside
from the actual monsters, the course of the game duplicates "Institute
Exploring" adventures I went on when I was a freshman.
Q. In retrospect, are there any design changes you would have liked to
have been able to make to your games, for example, different solutions
for overly difficult puzzles?
You know, one of the nice things about a game is that you usually do one
version of it, and don't have to think too much about changing anything
later. Still, the baseball puzzle in Zork II has always annoyed me. It
arose from my hatred of mazes -- I was always looking for ways to write
mazes that weren't mazes if you guessed the "trick," but that one was
pretty lame.
Q. What are your thoughts about the current state of the computer
gaming industry and the proliferation of blockbuster multimedia CD-ROM
games?
I think the biggest change since the Infocom days is the rise of
expensive-to-develop titles. The sheer size of the budgets and
development teams for today's adventure games (I won't call them
"interactive fiction") is astonishing. It has made the industry more
like the movie industry -- a few big hits, a few mid-range successes,
and a lot of dreck. Today, a lot of the titles that are
fondest-remembered from the Infocom days, such as Trinity, would never
be made -- too esoteric, non-commercial, unlikely to make money.
Q. What advice do you have for IF fans who say they wish they could
make money writing and producing adventure games?
I think it's unlikely anyone is going to make big bucks anymore writing
text adventures. On the other hand, there's a CD-ROM adventure industry
out there that could use an infusion of the enthusiasm for plot,
character, internal consistency and so on that I see on the Web. There's
no reason why graphic adventures have to be hoary old logic puzzles
connected by video sequences. There's also plenty of opportunity to make
money in that industry. The video and audio state of the art has
advanced enormously in the last ten years, but the basic storytelling
skills are in dire need of some new ideas. Maybe some of the IF fans out
there will provide those ideas.
+++++++++++++++++++++++++++++++++++++++++++++
TALES FROM THE CODE FRONT:
Interactive Fiction in Five Easy Years!
+++++++++++++++++++++++++++++++++++++++++++++
by Stephen Granade (
[email protected])
Write Your Own Interactive Fiction! v1.0 by Stephen Granade
Developed with TADS, the Text Adventure Development System.
Beginning game time: November 1989
--------------------
Enthusiasm, Part I
--------------------
November 1989. The idea of writing an adventure game came to me while I
was a high-school senior. It began life as an idea for a Sierra Online
game. I had solved "Hitchhiker's Guide to the Galaxy" and played
"Ballyhoo" and "Infidel," but didn't know much about Infocom's other
games. On the other hand, I had solved almost every game Sierra produced
from King's Quest II through Space Quest III. I had grand visions of
creating games for Sierra, a consequence of my surfeit of free time and
lack of experience.
Despite these grand visions, I didn't give serious thought to writing a
game until I fell sick during Christmas break. Chained to my bed by
illness, unable to sit in front of my computer, I was reduced to
doodling on a pad. At one point I sketched a gauntlet which, when worn,
would teleport the wearer to different locations. I began thinking about
the consequences of such a device, how it could be used and abused. I
suddenly realized that I had the concept for my game.
After that breakthrough, ideas began pouring forth. I decided to spread
the game out over three worlds to give the game a feeling of space. The
worlds would be connected by Waystations -- teleportation booths
resembling Dr. Who's TARDIS. Naturally, the hero would have to save the
universe, but from whom?
Humans, that's who. I had just finished reading several dystopian
novels, so the idea had a certain appeal. I pulled out my well-thumbed
copies of "Writing Basic Adventure Programs for the TRS-80"[1] and
"Creating Adventure Games on Your Computer"[2] and began work in
earnest. Within a week I had the basic outline for Waystation completed.
Then I got well.
I belatedly discovered that being bedridden is one of the best ways to
get work done. Waystation remained nothing more than fevered scratchings
on paper for the next several months.
--------------------
Enthusiasm, Part 2
--------------------
April 1990. With the coming of summer, I decided to finish Waystation
and send it to Ken Williams, president of Sierra Online. I began by
deciding what each world would be like, and deciding how the player
would save the universe. Next came the map. I started with blank
squares, wrote a two or three-word name for each room, then began
designing puzzles for each room. After two months, I had the game
designed. The final step was to write general descriptions for all of
the rooms, a task which proved more daunting than I expected. One month
and many thousands of words later, it was finished and sent via
registered mail.
By August I had my reply. An anonymous Sierra secretary sent me a
generic form letter. It contained about six paragraphs, ranging from
"We loved your letter!" to "I'm afraid that Sierra Online does not give
hints through the mail...." Each paragraph had a small blank in front of
it; the paragraph which best answered your letter was checked. The
checked paragraph in my letter said, "We are sorry to inform you that we
cannot use your game ideas. Although we are constantly amazed by our
customers' inventiveness...."
With a loud thud, all of my Waystation notes were tossed in the back of
a closet.
--------------------
AGT Rears its Head
--------------------
November 1991. A college friend showed me the copy of AGT he had
downloaded from a local bulletin board. "You can write adventure games
with this!" he told me excitedly.
Waystation is reborn. I hauled out my old notes and began work
programming the game in AGT. I was able to take the room layout from the
maps I had made. Writing the long descriptions of the rooms took some
time, since my original descriptions were never intended to be actual
printed descriptions. By January, the rooms were ready.
The puzzles were the stumbling block. AGT's metacommand language was
quite sufficient for the simpler puzzles, but when I reached
Waystation's kitchen area I was stumped. The next several months were
spent trying to program and debug that one room. After a while, my
enthusiasm dwindled away once more, leaving me with reams of AGT code
and little else.
In my infinite wisdom, I decided to write my own interactive fiction
language. It was modeled after AGT, the only language I was familiar
with. I worked on it beginning in September of 1992, forgetting all
about Waystation in the process.
--------------------
TADS to the Rescue
--------------------
February 1993. The friend who introduced me to AGT handed me a copy of
TADS. After perusing the documentation for one hour, I tossed the notes
for my programming language in the closet and pulled out my notes for
Waystation. For two weeks I played with TADS, getting a feel for the
language.
April 9, 1993. Waystation is reborn. Again. The first rooms went slowly:
I was learning the language as I went while I waited for my manual to
arrive. The kitchen and cafeteria took a week to code. My coding
experience is best typified by what I went through in creating the
kitchen and cafeteria.
* Write the room descriptions for the two connected rooms of the
kitchen. 1 hour.
* Add the conveyor belt, rails, and other decorations to both of the
kitchen rooms. 2 hours.
* Create the turnstile in the kitchen. Realize that a new class is
required, one which will print out "Beyond the xxx you see..." 30
minutes.
* Go back and change all of the "==" to "="; TADS 2.1 doesn't support
full C syntax yet. Repeat after every step. 2 minutes each
repetition.
* Debug the "beyonder" class. Discover that the showcontcont()
function (which displays the full contents of an object) must also
be rewritten to handle the "beyonder" class. 1.5 hours.
* The second time the kitchen is visited, it is closed. Write all of
the code to handle that case. 30 minutes.
* Move any item left in the kitchen so that it is not seen upon
return visits. 20 minutes.
It took 7 hours of coding spread out over three days before I had a
working kitchen. After that, though, I knew that TADS could handle any
puzzle I could dream up. I finished the first half of Waystation by May
of 1993. A summer research job squelched my momentum, and Waystation
languished until the spring of 1994. At that point I decided that I had
to finish the game. In a burst of frenetic energy, I wrapped up
programming in two months and rounded up ten betatesters.
--------------------
Squashing the Bugs
--------------------
August 1994. The betatesters began uncovering bugs two minutes after I
mailed them their copies of Waystation. Within two days I had over
twenty pages of bugs, typos, and suggestions, half of it due to Michael
Kinyon alone. Debugging is a long, frustrating process. In Waystation's
case, it took from late August until December before I had it in a form
that I felt was ready for release. In early January, I uploaded
Waystation to GMD.
--------------------
What I Learned, or How Not To Write IF
--------------------
Five years of off-and-on work taught me a lot about the process of
writing interactive fiction. Hopefully others will find the following
advice helpful:
* Design everything you can on paper before you ever begin
programming. It's much easier to toss out unworkable or silly
sections if they're only written down. Once you've programmed a
section of your game, you'll want to keep it no matter what.
* Choose the programming language which best suits your needs. TADS
dovetailed nicely with my C programming experience; for others,
Inform, AGT, Hugo, or any of a dozen other systems may be best.
* Work EACH day, even if you only spend five to ten minutes some
days. Like water wearing away a stone, you can make the colossal
task of writing IF manageable if you keep your momentum going. My
constant starting and stopping delayed Waystation by over a year,
just considering when I started working with TADS.
Thanks for playing Write Your Own Interactive Fiction!
Elapsed game time: 5 years, one month.
Footnotes
[1] Dacosta, Frank. "Writing Basic Adventure Programs for the TRS-80."
Tab Books: Blue Ridge Summit, PA, 1982.
[2] Hartnell, Tim. "Creating Adventure Games on Your Computer."
Ballantine Books: New York, 1984.
+++++++++++++++++++++++++++++++++++++++++++++
Oh No! Beta!
Tips and Techniques for Beta-Testing Games-in-Progress
+++++++++++++++++++++++++++++++++++++++++++++
by C.E. Forman
Any author who has written a work of IF of medium size or larger should
be wholly familiar with the process of playtesting the game, discovering
bugs and parser problems, making certain that the game is as clean as is
reasonably possible before its official release to the IF archives. The
key issue, though, is whether the game's testers themselves possess the
same degree of familiarity.
The beta-tester's goal is not to play a game solely for leisure and
escapism, but to willfully risk his or her own spoilage of the fantasy,
with the intent of using it to prevent such disastrous results from
reaching a broader audience. This is the price to be had in exchange for
becoming a part of another author's world and exerting a certain degree
of one's own influence upon the final outcome.
Testing, in its own way, is as much an art as the creating of the game
world itself. To playtest effectively, one must come to understand the
link between tester and game, and further, between game and author, in
order to draw across the third and final gap between author and tester.
Bridging the gap is the most mutually constructive manner is the goal of
the IF beta-tester.
--------------------
Offering Your Service
--------------------
Most game authors recruit the assistance of playtesters via a Usenet
post, or by personal e-mail inquiries to testers whose names they are
familiar with (possibly through recommendations from other authors). It
is important at the outset to establish the amount of time you, as a
tester, will be able to spend on the project. If you don't think you'll
have much time (or any at all), either warn the author ahead of time so
s/he can make arrangements with other testers, or don't sign up at all.
If, once you've begun, it turns out that you have far less time than
you'd anticipated, let the author know as soon as possible so that
replacement testers can be found. Under no circumstances should you
leave the author hanging as to whether or not you're still with him/her.
--------------------
Structure of the Playtester's Report
--------------------
My typical beta-testing report is a standard plain-text file, divided
into four sections, with a header at the very top identifying the game,
the report number (numbering reports makes it easier for both authors
and testers to identify and organize later), and the beta version the
bugs came from. You may want to include your name here as well.
These four sections serve as a good method for breakdown and
classification of bugs:
1. Programming bugs. These deal with significant errors found in a
game, be they logical errors or outright crashes.
2. Parser problems. These consist of minor annoyances you've had when
trying to select verbs, nouns, phrasing, et cetera.
3. Cosmetic bugs. Typographical errors, extra line-feeds and spaces,
and the like. These are not true errors, but are important to the
overall appearance of the game.
4. General feedback.
The first three sections should consist of appropriate segments of a
game transcript (beta-testers should _always_ keep transcripts)
cut-and-pasted in, with the unnecessary steps edited out to reduce
clutter. If the bug in question can be explained in only a few words, a
transcript segment is not necessary. When using my own words rather than
the game's, I prefer to surround comments with square [] brackets to
make it easier for the author to identify where the text is coming from.
In any case, include a line of dashes or asterisks to separate one bug
from the next, to keep the report easy to read. Also, when dealing with
typos, it's helpful to use a carat (^) symbol below the offending word
to point out just where the error is.
Structuring reports in this format makes the author's job far easier, as
it enables him/her to select the type of bugs to correct, based on the
author's current mood. This stage of game development can be frustrating
at times, and on some days an author simply may not feel up to tackling
more complex bugs. It's more reassuring for the author to have an
organized group of typos and parser quirks to work at during these
times, rather than having to read through a jumbled report and pick out
appropriate bugs on his/her own.
The fourth section, general feedback, should serve as a means of input
from tester to author, and is used to cover anything that doesn't fit
into the first three categories. This is the place for a tester's own
personal evaluation, covering any plot holes, comments about the puzzles
and overall layout, and general praise and (constructive) criticism.
It is of the utmost importance that a tester provide a good deal of
positive feedback here as well. Playtesting is the absolute last thing
an author wants to do after spending months on writing and coding. By
the time a game reaches the testing stage, the author's morale can be at
its all-time low, and it's likely to stay there if the only feedback
received about the game is a long list of everything that's wrong with
it.
Following these guidelines, here's a fictional sample report using some
early bugs found in my own game, "The Path to Fortune" (but now fixed):
"The Path to Fortune" Playtesting Report #1
-------------------------------------------
=====================================================
1 - Programming Bugs ================================
=====================================================
[I can unlock the abandoned shed with any object in the game.]
----------------------------------------------------
>cash
You're broke.
>w
Borthur's Smithy
>cash
You have 12 gold Renkin, the standard unit of currency in the
[I haven't asked for the gold yet.]
=====================================================
2 - Parser Problems==================================
=====================================================
>make a roll
You'll have to specify what you want to make.
[I've tried every verb I can think of, and can't get this to
work. Are you sure the code is reachable?]
=====================================================
3 - Cosmetic Bugs ===================================
=====================================================
>x gold
Something about the unshaped nugget of gold unnerves you. When
you hold it up to the light, the nugget sines very brightly,
^^^^^
[Should be "shines."]
=====================================================
4 - General Feedback ================================
=====================================================
[...and so forth.]
Make certain that your messages are clear enough for the author to
determine the problem, and don't send blatantly derogatory messages of
any sort.
--------------------
Followups to Reports
--------------------
It's quite likely that an author will elect to give feedback on your
feedback, whether to explain his/her reasoning behind a choice of
implementation for an aspect of the game, to request further details
regarding a bug, or to assure you that a particularly nasty problem has
indeed been conquered. In instances where an author needs to clarify a
problem, it's important to leave enough of the previous message to allow
the author to see what the original issue was. Don't edit the old parts
out just to save space! (This is one of the few times on the net where
you want repetition for reinforcement.)
Also on the subject of feedback, opinions differ, and authors may not
agree with everything you say. They may have very good reasons for not
wanting to implement some of your suggestions -- some parser quirks may
be more trouble to deal with than they're worth (particularly in the
case of first-time authors); some solutions may contradict other parts
of the game (which you may not have seen yet). Ask if you're not sure,
but don't pressure authors too much -- if they refuse, and offer at
least a fairly reasonable explanation, let it go at that.
--------------------
Discovering Bugs
--------------------
This is the heart of the playtester's job, and the most difficult aspect
to learn to do effectively. It's also the most difficult to put into
words, so here is a set of common methods I use to break a game:
* Scanning text. Personally, I can't stand reading my own text. As a
result I don't look very closely for typos and extra spaces, instead
relying on playtesters to hunt them down. Read all game text
carefully.
* Scenery. A player should be able to examine almost everything the
game mentions in the text.
* "Reversing the solution." It's quite common for an author to
unintentionally implement a one-way puzzle. That is, one in which
the solution could logically be reversed or recreated, but no code
for it exists. An example of this would be breaking one of the
mirrors in "Enchanter," then fixing it with the krebf spell (which
works, by the way).
* "Do It twice." AGT games in particular award points for players
repeating the same action more than once. Try solving puzzles twice
to be sure.
* "Parser probing." IF language tools sometimes use two verbs that
mean the same thing, yet behave differently ("move" vs. "push" is a
good example). Try performing actions using every possible method
of phrasing you can think of.
* Containers and surfaces. Objects that can hold other objects can
cause a lot of trouble (as evidenced by the famous (infamous?)
axe-in-the-bucket bug in Unnkulian Underworld). Make sure that
players can't sneak objects into places they shouldn't be able to
through the use of a container or surface, and make sure that all
such objects only hold the size and number of items they would in a
"real world" setting. (Large containers used for inventory
management, such as the rucksack in "Curses," are exempt from this
last rule.)
* Animate characters. Even simple NPCs tend to have potential for
bugs, so try out all the major NPC interactions ("kiss," "kill,"
"show," "give," "tell," "throw," "ask about" and "ask for"). Make
certain that you give each character an order or two as well.
* Flammables. Adding a torch or matchbook to an in-depth game can
geometrically increase complexity. A default message is commonly
put to use for most items, but many times special responses will be
needed. Pay particular attention to effects such as lighting a
match with a torch, vs. a torch with a match, and lighting one
torch with a second.
* Liquids. IF liquids should be drinkable (or have a special message
if you try), and able to be spilled out onto the ground, poured into
other containers (assuming they'll hold liquids), and so forth.
Check to confirm that a liquid can not be carried in a player's
hands.
* Multiple-step puzzles. Recent games no longer resort to the "one
object = one puzzle" format of early IF. It is often necessary to
solve problems via a step-by-step process. As a tester, make
certain that the objects' states change when one part of the puzzle
is solved, to avoid nonsensical repetition. An example of this type
of bug might be a vending machine that drops a bag of chips into a
bin after a player inserts a coin and pushes a button. Check to
make sure that, if the player pushes the button again, the text for
the chips does not appear a second time.
* Daemons. Puzzles involving timing are the most complex to
implement. Test for redundant actions -- doing the same thing twice
to start the daemon twice. Also make sure that the daemon in
question only prints text when its object is in scope to the player
(i.e., a player shouldn't be able to see or hear a car running
after s/he's left the room it is in).
As a final note, keep your old reports and re-check all the bugs later,
after the author has sent an update. Make sure the bug fixes work
without causing further bugs, and that they don't disrupt the overall
logic of the game in any serious way.
--------------------
Playtester Ethics
--------------------
Finding bugs is not the only concern of a beta-tester. Believe it or
not, the job can also raise concerns about proper ethical behavior. Game
authors put a lot of trust in their testers, and it's important that the
testers not betray that trust. Keeping that in mind, here are some
simple (if you think about them) guidelines that I adhere to, and that I
advise other testers to follow as well:
* First, and most obviously, never distribute a game you're
playtesting. If the author wanted this, s/he'd have released it
already, without your help.
* Keep your playtesting experiences confidential. It's okay to confer
with other people beta-testing the same game, but once the game has
been released, don't tell players about bugs you found in the beta
versions. Authors don't want to appear sloppy or stupid to the
gaming public, and indiscriminate discussion of bugs that have
already been fixed can make them feel that way. (Again, let the
author initiate this sort of talk if s/he wants to.)
* Don't write zine reviews of games you've beta-tested. Like the
authors themselves, you've probably been working too close to the
project to give an effective, unbiased evaluation.
* Don't give out hints over Usenet to games you've tested...at least,
not for awhile. Out of necessity, you've already seen the solutions,
but other players have not. Give them time to figure things out on
their own and to help each other out first, rather than spoiling
the game and the author's hard work right at the outset. (By the
same token, wait a good time before writing a walkthrough or hints
for a game. And even then, make sure you have the author's
consent.)
--------------------
Conclusion
--------------------
Playtesting can be a very painful process for an author...but it doesn't
have to be. With a little extra effort on the part of the playtester, it
can be an enjoyable and rewarding experience for both parties.
+++++++++++++++++++++++++++++++++++++++++++++
BETA TESTERS I HAVE LOVED
+++++++++++++++++++++++++++++++++++++++++++++
by Neil deMause (
[email protected])
"I found a bug in your game," goes the kind of e-mail I've been getting
lately. "I get a TADS error message whenever I try to take more than 201
napkins from the napkin dispenser."
Messages like these pour into my mailbox with alarming frequency. But I
don't mind -- I don't tell their authors to quit nitpicking and get a
life. Because these are my beta-testers. I count on them to be insane.
Yes, insane. C.E. Forman has laid out quite a nice list of guidelines
for play-testing in his article ("Effective Playtesting"), but he fails
to mention the most important requisite for a successful beta-tester:
you must be absolutely, stark raving mad.
Look at it this way: Say you're an interactive-fiction author. (I say it
all the time, it shouldn't be too difficult for you.) As soon as your
game is ready for debugging, you painstakingly walk it through all its
paces, taking every logical step and ensuring that it works properly.
Once you're done, you release the game to your battalion of beta-
testers, secure in the knowledge that you've accounted for all but a few
sensible actions.
What a fool you are! (This, too, I say to myself all the time.) You may
have accounted for every sensible action, sure, but those who play your
game are likely to be anything but sensible -- they may try odd things
because they're stuck, because they're contrary, or just because they're
plain lame-brained, but there's no way they're going to behave as
expected. Which is why the best beta-testers are those who can routinely
do the unexpected. Which is where the insanity comes in.
Take, for example, one of my favorite beta-testers. He has an odd
compulsion, when he plays IF games, to close doors behind him. It's a
bizarre fastidiousness, not even remotely useful for an IF player, but I
love him for it, because he has uncovered bugs in this way that I never
would have found by my own, door-opening self.
And then there's my napkin-thieving friend (whose initials,
incidentally, are CEF). It's a wonder he can ever finish a game, he's so
busy scouting out blind alleys and trying to interact with the scenery.
Without his help, I never would have known how my game responded if you
tried to push on an NPC, or talk to a brick.
But that's what good beta-testers do: they command NPCs to walk through
walls, flip coins that they aren't holding, pour pepper on goats. Give
them a fork in the road, and they will likely take neither path, but
attempt to EAT SPAGHETTI WITH FORK.
I've tried to learn from my beta-testers. When I play-test my own games
now, I flip, prod and manipulate every existing object (and even some
that aren't there) in an attempt to find illogical behavior -- which is
never a good thing in an IF game, even in response to an illogical
action. There may be no good reason for a player to type GIVE PIANO TO
ORANGUTAN, but if the game replies "The orangutan tosses the piano about
in its hands for a bit, then gives it back to you," it tends to break
the spell of realism.
But I know I'm doomed to failure in my attempts. I'm simply too close to
my game to see all the possible actions, and I'm naturally more inclined
to look for things that do work than those that don't. And so I happily
put up with bizarre midnight messages about napkins and one-way doors,
give my beta-testers nice big thanks in the game credits -- and all the
while hope and pray that nothing ever happens to make them accidentally
go sane.
+++++++++++++++++++++++++++++++++++++++++++++
GAME REVIEW
+++++++++++++++++++++++++++++++++++++++++++++
-----------------------------
The Light: Shelby's Addendum
release 1.1
Parser: TADS
Author: C.A. McCarthy (
[email protected])
Availability: ftp.gmd.de/if-archive/games/
Requires: TADS run-time interpreter; platform-specific standalone
versions are also available at GMD
Response to the XYZZY command: "A hollow voice says, 'Wow! You must be,
like, really old.'"
-----------------------------
You're an apprentice to the keepers of the Lighthouse, who have a very
important mission -- protecting a phase modulator, the only preventative
measure against a world-destroying dimensional shift -- and who are
conducting research for a compelling project called EUNICE. As you
return to the lighthouse after a short journey, you discover that
something terrible has happened: charred bodies are strewn over the road
to the village, the sky seems to be on fire, and a creeping mist is
slowly but surely completely enveloping the land.
What's going on here? Reading your employer Holcroft's diary will offer
much background material: while working on the EUNICE project, your
other supervisor, Barclay, appears to have made a discovery that caused
him to lose his senses and take a series of actions that now jeopardize
the planet's safety. Barclay has stolen the phase modulator -- the
Lighthouse's light -- and gone to a distant retreat. You must learn as
much as you can about the situation, prepare a submersible for your
travels, then track down Barclay and stop him.
Players must solve a timed, potentially fatal puzzle early in the game,
which consists of finding and wearing an anti-phase bracelet within the
first 100 turns of play, or your body will turn transparent and you'll
die. This was an interesting variation on the timed-starvation puzzle,
but I wish the ill effects of the dimensional shift kicked in much later
-- say after 200 or 300 turns instead. Before I stumbled across that
puzzle's solution quite by accident, I was frustrated by not being able
to explore very much of the game's surroundings before that 100-turn
limit kicked in.
I really like puzzles in adventure games that include what I think of as
many interlocking parts -- for example, in such a puzzle you'd need an
object from one area of the game to access another whole section, but
you need yet another object first to make the first one functional...I
mention this because I think The Light: Shelby's Addendum has a good
variety of this kind of interlocking, scavenger hunt puzzles. Your
mileage may vary, though, if you don't particularly enjoy traipsing back
and forth throughout a game! :)
Although many of the parsing problems that were in the original version
of this game have been fixed in version 1.1, I still noticed several
bugs that significantly affected play. For example, I'm quite sure that
the way I managed to obtain the anti-phase bracelet was a lucky break
from a coding error; even after playing Shelby a good deal I'm not sure
what the correct steps for the solution are. I was also confused about
the logic of a couple of puzzles even after I solved them -- for
example, exiting from the secret chamber with the concentric circles.
The room and object descriptions are very well detailed, which
contributes a lot to the atmosphere. Very often using the EXAMINE ALL or
SEARCH ALL commands is key to finding a missing crucial object or
discover how to solve a certain puzzle. There are also many nice touches
that add an air of sinisterness, such as the blood-covered mophead or a
lingering bad smell.
During the early part of the game, there are not too many interactions
with NPCs, except for a scared workman and a chicken. I very much liked
the character development of Holcroft and Barclay, especially as you
discover the extent of Barclay's actions. The unfolding of this
malevolent behavior reminded of Jack Nicholson's character in "The
Shining"!
The game contains no online help, but hints are available from the
author for registered users (US$10). This is certainly the author's
prerogative; I think I've just been spoiled by the number of other
shareware and freeware games that do include some form of mild spoilers.
I try not to resort to hints of course, but would have liked to have a
peek while working out my own parser problems. Without online help -- at
least for the beginning timed puzzle -- I think fledgling players are
likely to get frustrated and abandon play fairly quickly. To the game's
credit, I found it wholly absorbing once I was able to overcome the
initial obstacles and get drawn into the drama of the adventure.
-- Stuart Beach
+++++++++++++++++++++++++++++++++++++++++++++
WHAT'S ON THE DISK
+++++++++++++++++++++++++++++++++++++++++++++
The companion disk for XYZZYnews #8 contains the following game files.
It's a good deal for people who have slower modems -- at 2400 bps, it'd
take a heck of a long time to download the contents of the companion
disk. It's also a good deal for people with limited or no access to FTP
sites or online services as a source for new games. If you're reading an
electronic version of this issue, you can obtain this games disk with a
print copy of XYZZYnews #8 by enclosing $3.50 for postage and handling
with the coupon on the bottom of this page. If you play and enjoy these
games, please pay the shareware fees as applicable.
THE BROKEN STRING -- Being part of the punk scene and pursuing anarchy
was the best time of your life. Can you start your own band and help
bring back the good old days? This TADS game is e-mailware; that is, you
should send the authors an e-mail if you enjoy playing it.
LOST NEW YORK -- In this shareware TADS game, you're a visitor to the
city with some time on your hands. Your trip to the Statue of Liberty
begins ordinarily enough, but when you find yourself thrust in the past,
you're forced to discover for yourself how to interact with a diverse
cast of characters and find your way home.
MAGIC TOYSHOP -- In search of a birthday present for your young niece,
you decide to stop in at a particularly intriguing-looking toyshop to
see what you can find. There you'll meet Catharine, the proprietor's
daughter, who presents you with a number of unusual gadgets and
brainteaser puzzles for you to solve. See overview, XYZZYnews #5.
LETHE FLOW PHOENIX -- Out on a campling trip and awakened by strange
noises at night, you venture into the night and accidentally pitch
yourself over a cliff. When you awaken, you find yourself in a grassy
field, left to discover both how to maneuver about this completely
unfamiliar environment and your purpose here. See review, XYZZYnews #7.
+++++++++++++++++++++++++++++++++++++++++++++
XYZZYnews Magazine/Disk Order Form
+++++++++++++++++++++++++++++++++++++++++++++
Checks and money orders preferred. Please send coupon with
payment to: Eileen Mullin, XYZZYnews, 160 W. 24th Street, Ste. 7C,
New York, NY 10011.
O Please send me a copy of the print version and companion games disk
for XYZZYnews Issue #8. I have enclosed $3.50 for postage &
handling. (Check one: Mac disk ___ or PC disk ___ )
O I need just the companion games disk for XYZZYnews Issue #8. I have
enclosed $2.50 for postage & handling. (Check one: Mac disk ___ or
PC disk ___ )
O Sign me up for a 6-issue subscription. I have enclosed $21 for
postage and handling. (Check one: Mac disk ___ or PC disk ___ )
O Please send me a copy of the upcoming XYZZYnews Issue #9. I have
enclosed $3.50 for postage & handling.
(Check one: Mac disk ___ or PC disk ___ )
Full Name (please print): _____________________________________________
Street Address: _______________________________________________________
City: ________________________________ State: _________________________
Zip/Postal Code: _______________ Country: _____________________________
Email Address: ________________________________________________________
