impromptu brainstorming, or requests for help/advice. But once the game went into
testing, first among the other writers, then with the internal testing group, and then
finally with outside “beta testers,” the game was under the microscope for months on
end. During this time, bugs and suggestions would often run into the thousands.
How fluid and changing was the design of an Infocom game?
This varied from implementor to implementor. My own style was to do a little bit of
on-paper design before starting, mostly in creating the geography and any “background
universe” documents such as a time line in the case ofSorcerer, or the rules of the
deserted planet’s language inPlanetfall. But for the most part I would just jump right in
and start coding with most of the characters and puzzles living only in my head.
The Infocom development system was terrific, compared to the graphic-based sys-
tems I’ve worked with since those days, because just the game writer working alone
could implement an entire section of the game in only a couple of days, and then try it
out and see how it worked. If it had to be scrapped because it wasn’t working, it was no
big waste of time or resources. This allowed for a lot of going back and rewriting big
sections of the game, which is inconceivable nowadays, where such a decision might
mean throwing away a hundred thousand dollars worth of graphics.
Was there a lot of playtesting on Infocom titles?
Lots of testing. Since the development system was quite stable during most of
Infocom’s life, the testing was able to concentrate on game-specific bugs and game con-
tent. There would ideally be about two weeks of “pre-alpha” testing where the other
game writers would play a game, followed by two to three months of alpha testing with
our in-house testers, followed by a month of beta testing with a couple of dozen outside
volunteers. If time allowed, there was also a month of “gamma” testing, which was just
like beta testing except that the idea was not to change a thing unless a really major
problem was found.
Testing for both game-specific bugs and game content went on pretty much con-
currently, although more heavily weighted toward content during the early days of
testing and more toward bugs in the later days, when it became increasingly less desir-
able to make any significant changes to game content.
The early testing period was probably the most fun and exciting time in the game’s
development. For one thing, after months and months of working alone, not having any
idea if a game was any good other than my own instincts, all of a sudden a bunch of peo-
ple are playing the game, usually enjoying it, and giving tons of feedback. It’s a real
rush. Also, we had an auto-scripting feature where our network would automatically
make a transcript of each player’s sessions, which I could read to see what everyone
was trying at every point, so I’d often find things which were wrong, but which testers
didn’t necessarily realize were wrong. Or I’d find things that they’d tried which were
reasonable attempts to solve the puzzle at hand and I’d try to reward such an attempt
with a clever response or with a hint, rather than just a default message like, “You can’t
put a tablecloth on that.”
It was during the testing period that games became great. Going into the testing
period, the game was more like a skeleton, and the testing period, as one of our testers
Chapter 10: Interview: Steve Meretzky 185