Michael J. Roberts of High Energy Software

                  Interviewed by Neil Shipman

Readers of the last two issues of SynTax will know how impressed Neil
was with Ditch Day Drifter and Deep Space Drifter as well as with
TADS, the Text Adventure Development System with which they were
written.  Their author and developer, Mike Roberts, kindly agreed to
a postal interview with Neil from sunny California...

@~Perhaps you would like to begin by telling us a bit about yourself.

   I'm 27 and single. My hobbies include text adventure playing and
writing (obviously, I guess), computer programming in general (despite
the fact that I do it professionally), aviation (I hold a private
pilot license), pinball and bicycling. My real job is with Oracle
Corporation, writing database management software.

@~How did you first get interested in computers?

   I started playing with computers when I was about 12, when I had a
chance to do some BASIC programming on a DEC PDP-11. Through most of
junior high and high school I was able to find computers that I could
play with.

@~What were some of the first adventures that you played?

   The original mainframe game Dungeon (which later was rewritten as
the Zork trilogy) was probably the first text adventure I played. I
never really made it that far in it, since I was more interested in
programming than playing, but it got me interested in the genre.

@~Which adventures have made the greatest impression on you?

   Planetfall was probably my favorite. It convinced me that adventure
games should be logical, even at the expense of being difficult. Lots
of other adventure games I've played have very random puzzles that
don't make a lot of sense and aren't particularly motivated. I also
really liked Monkey Island. It was very clever and funny, and it was
very playable. I had the impression that its designers had actually
thought about what they were doing, unlike so many of the other
graphical adventures on the market these days. Both of these games
have convinced me that the best adventures are those where you can
have a feeling that you're making progress throughout the game,
without artificially stalling you with an obscure puzzle where you
just have to guess the one dumb thing that you're supposed to do.
Puzzles should be motivated - you should have some idea of what you're
supposed to do next - and they should make sense within the context of
the game.

@~How did your interest in writing adventures start?

   I became interested in writing adventures mostly to figure out how
they worked. There are a number of challenging programming problems in
designing a simulation of an artificial world and making sense of
"natural language" commands from the player.
     As I've spent time trying to figure out how to program these
games I've grown to like the genre as much for its artistic merits as
for its programming challenge. I think the medium has real potential
and I'd like to see many more adventures written. I've only seen a
handful of adventures that I'd consider really good, but then there
haven't been all that many adventures ever written compared to books
or plays or movies. I hope that TADS makes it possible for more people
to write text adventures. A couple of excellent games have already
been written with TADS and I look forward to seeing more.

@~Whose work has influenced you most?

   The conventional wisdom is that the old Infocom games were the
greatest games ever but I think that some of them were better than
others and these are probably the ones that have stuck in people's
minds. Steve Meretsky wrote some of the best in my opinion. Of the
more recent games the best I've seen are some of the Lucasfilm
graphical adventures. I think the Lucasfilm people are making a real
effort to figure out how to improve the adventure game genre - to make
adventures more playable and accessible - which none of the other
companies producing graphical adventures seem to think much about.

@~Why did you decide to develop an adventure writing system?

   After I'd written one game and wanted to start work on another
I realized that there was a lot of work that would be mostly
duplicated in a new game. I started out putting the routines from the
old game into a library so that future games could use the same
routines. Before long, though, I realized that this didn't go far
enough.
   The big problem with using a general-purpose language for writing
an adventure game is that you end up with information scattered all
over the place. My games at the time had something like five data
files - one had room descriptions (by room number, of course), another
had the vocabulary, another had object descriptions. It was horrible
trying to figure out what room number in the program corresponded to
which exit list in one of the data files. It was clear that everything
had to be in one big file. At first I thought it was good enough just
to combine the data files into one, but this actually didn't help at
all because that made it more difficult to find things within the data
file.

   Instead, what I really wanted was to have everything about each
object - all the text, vocabulary, and even the code - in one place.
Obviously this requires a language interpreter to execute the code in
the file.
   Once you decide to go this far it's a simple matter to find ways to
make adventure game writing more convenient. For example, I noticed
that a lot of what an adventure game program does is display text
strings, so I made the syntax for this especially compact.

@~Tell us about TADS.

   TADS is an entire system for writing text adventure games. The
heart of the system is an object-oriented language which looks a lot
like C but is much higher level; for example, the TADS language
operates directly on datatypes such as lists, strings and objects.
Using the TADS language, an adventure game author implements a
description of the behavior of the objects making up the game.
   One of the things we wanted to do was to improve a lot on the
standard features of most text adventure games, particularly in the
area of the run-time user interface. For example, we provided full
command-line editing and recall. In addition, TADS saves the text that
scrolls off the top of the screen, so you can scroll back and review
text from much earlier in the game.

@~What do you mean when you say that the TADS language is "object-
@~oriented"?

   With traditional programming languages like C and Pascal you tend
to think procedurally: you have some data and you write some code to
do something with it. There's a clear division between code
(subroutines, functions and so forth) and data (variables, arrays,
structures).
     Object-oriented programming brings code and data together.
Instead of breaking up a program into functions and subroutines you
break it up into objects. The implementation of an object contains
everything relevant to the object, including both code and data. For
example, a "room" object has all the descriptive data about the room
(such as its name, the text you see when you are standing in the room,
and a list of exits) plus any code that's associated with the room

(for example, you might want to put some code in the room that defines
what happens when you set off a bomb in the room).
   This wouldn't be all that different from traditional programming
languages if we didn't add "inheritance". This is what makes object-
oriented programming really powerful. Inheritance allows you to say
that one object is pretty much like another, with a specific set of
differences: that is, the new object inherits everything from the old
object except for a few things you're overriding.
   With TADS we've provided the source code for basic objects like
rooms, fixed items, carryable items, doors, vehicles, chairs and so
on. Most of these are fairly complicated. Fortunately, when you're
writing a game, you don't have to do any of that work yourself because
you can just make new objects that inherit all of our work. Of course,
because you can override anything you want, the system is totally
flexible. It's very easy to add a room to your game - all you have to
do is make a new object that inherits everything from the "room"
object and then customize it by filling in the name, description and
exits. That's all you need to do for a basic room; but, if you want
something more complicated, you can override anything you want from
the basic room object and even add new things.

@~How difficult is it to write a TADS game?

   It's very easy to write a simple game. There's a sample game in the
TADS Author's Manual that's about forty lines long and it's fully
working. Of course, it doesn't do much - it's just a couple of rooms
and a couple of objects with a simple puzzle. However, those rooms and
objects are just as flexible as rooms and objects in full TADS games.
The sample game source code is so short and so simple because it
doesn't change much about the basic objects defined in the TADS object
library.
   More complicated games will naturally take more effort. Writing a
game like Zork would be a large effort even with TADS, but much easier
than it would be to write in C.
   But there's a lot in between the two-room sample game and Zork. The
thing about object-oriented programming is that you can start with a
really small, simple game, and gradually add more objects to it,
eventually building it up to a big, complex game.


@~What is the TADS Debugger?

   One of the features we introduced with the new version of TADS is
source-level debugging. With the TADS Debugger you can much more
quickly get a feel for how a TADS game works, and it should be a big
help in getting a game working. The Debugger allows you to step
through the source code of your program as it executes, set a
breakpoint so you can stop execution at a particular point, and
evaluate and even change the values of variables in the game while
it's running.
   You don't have to do anything special to your game to debug it
apart from adding an option to the command to compile your game. The
Debugger is just a separate program that acts like the run-time system
but gives you direct control over the game's execution.

@~TADS runs on several systems. How difficult is it to port a game from
@~one system to another?

   The TADS languages on all of our systems are identical. All you
have to do is transfer the source file from one system to another,
recompile it, and you're done. There's no need to make any changes to
the game source at all.

@~How long did the first working version of TADS take to write?

   It depends on what you consider the first working version. I've
been working on and off on systems like TADS since high school, but it
took a while to hit upon the right strategy.
   I started working on what became the current system about three
years ago. After about a year of work a friend of mine (who was, at
the time, about to go to graduate school and needed a summer project)
wrote a game using that early system. (The game was called High Tech
Drifter, which I think is such a good joke that all of my subsequent
games have been variations on the name.) The game was never really
finished but it gave me a lot of valuable information about what
needed to change. At that point, I reworked the system and we started
working on Deep Space Drifter. That project took essentially forever;
it probably took about a year of part time work, if you take out all
of the time we spent ignoring the project.

@~Many adventurers are put off text adventures because of a poor parser.
@~The TADS parser is extremely good - did you pay particular attention
@~to this?

   One of the big advantages of using a system like TADS rather than
writing adventures in a general-purpose language is that the system
does the hard work of parsing player commands for you. So, one of the
areas we spent a lot of time on with TADS was the player command
parser. When you write a game with TADS, your game automatically
understands multiple objects in a single command (for example, "take
the key, go north, and unlock the door"), special words like "it"
("unlock the door and open it") and "all" ("put everything except the
book in the box"), and a lot more. These things are totally invisible
to a TADS game - the system handles them all automatically, and breaks
them down into simple commands for the game.
   Our goal was to be able to handle any command that any other
adventure game could handle, but we were able to even do a little
better in a few areas. For example, I haven't seen any other games
that can handle plurals properly; with TADS you can say "take the
books", and the system will do just that. Also, TADS understands
"them" properly, which I haven't seen elsewhere. It's also a lot more
flexible with conjunctions, so you can say things like "take the box
and the ball and go north". These are small details, but I felt that
the more flexible the parser could be, the better.

@~The Author's Manual plus the heavily documented data file with Ditch
@~Day Drifter make TADS easy to understand and use. How many years has
@~it taken to put this all together?

   I wrote the manual concurrently with writing the system, so it's
hard to say just how much time went into it. I spent several weekends
cleaning it up and organizing it towards the end of the project.
   Ditch Day Drifter was written remarkably quickly, especially
considering the huge amount of time that DSD took. It took me a few
days to design most of the game and a couple of weeks to implement it.
A few friends play-tested it over the next few weeks and I spent some
more time cleaning it up. It probably took two months in all. Of
course, it's not a very big game.


@~When did you set up High Energy Software with Steve McAdams?

   High Energy Software was set up officially at the point we were
about to release TADS and Deep Space Drifter, which was September
1990. It had unofficially existed for the entire DSD project, but it
didn't have a name during that time.
   High Energy Software is still a "garage" operation. Steve and I
both have real jobs, since at this point High Energy Software barely
pays for its own operations (as long as you don't include our time in
the bill). Despite our small size and hopeless understaffing, we're
trying our best to provide commercial-quality software and support. We
hope that we'll be able to work on High Energy full-time at some
point, but it doesn't appear that this will happen in the near future.

@~Shareware keeps costs low. Do you get a good response from players
@~registering their copies of the Drifter adventures?

   Games don't seem to get very good shareware response. Deep is the
only one of our games that's shareware (Ditch is "freeware"). Given
that games undoubtedly have a wider appeal than the development
system, and looking at download statistics, it's pretty clear that the
user-to-registered-user ratio for Deep is considerably worse than
TADS, which has done reasonably well.
   We think that most of the registrations we've received for Deep
were sent in because the person was registering TADS and went ahead
and added in Deep while they were at it. So, our experience with Deep,
although not that good, has probably been a lot better than that of
most other game shareware authors. This is consistent with what we've
heard from a couple of other shareware game authors. The authors of
the Unnkulian Unnventure games, for example, have said that they're
receiving very few registrations for their games; it's a shame,
because their games are clearly in the same league as Infocom's best,
and I'd like to see more games from them.
   It's kind of unfortunate that more people don't register shareware
games but it doesn't really surprise me. I'm sure the main reason that
anyone registers TADS is that it's a big, complex system, so you
really need the manual to take full advantage of it. With games, you
don't usually get much when you register (we send a hint book and maps
to people that register DSD, but you can get through the game without
them), so there's not much incentive.

@~How much do the improvements in the latest version of TADS reflect
@~user feedback?

   Most of the new features are things users requested. Some ideas we
came up with on our own, like the Debugger, but mostly we were trying
to provide the features that our users said they needed. We certainly
have a lot more on our enhancement request list for the next revision.

@~As animation, graphics, sound and music push adventures from
@~interactive fiction towards interactive movies, what future do you see
@~for the text adventure?

   As far as the computer game industry is concerned, the text
adventure is dead. Steve Meretzky's company is the only one that's
producing anything similar any more, and even their new games are
illustrated - and even with that, I doubt they'd make it to retail
shelves if it weren't for Meretzky's name and track record.
   I think that pure text adventures could still sell - maybe not as



well as Wing Commander XXIV or Space Quest LXXXVII, but enough to keep
a company in business. The reason no one does write text adventures is
that the computer game industry is entirely blockbuster-driven right
now. This is mostly because there's so little shelf space on anything
less than a premium-priced best-seller. This forces the game
publishers to make every game bigger, flashier and sexier than the
last, and encourage them to publish sequels to previous winners rather
than gambling on unknown new games.
   The reason shelf space is so limited right now is that the market
is so small. The last figures I've seen put the disk-based computer
game market at about a tenth the size of the cartridge-based game
market (Nintendo and the like). Presumably, the market will grow as
computers become more common in the home, and with that growth I think
we'll see shelf space become much more accessible to smaller, less
costly products. When that happens, text adventures may make a
comeback. It'll be a while, though.



@~There is a TADS compiler and run-time system for MS-DOS, Atari ST and
@~Apple Mac computers. Will you be developing these for the Amiga?

   We don't have any immediate plans to support the Amiga. Supporting
our three current platforms is already as much work as we can
comfortably handle; it would eat too much into the limited time we
have for new work if we added more. So, while we'd like to add more
platforms, we don't have the resources for doing so right now.

@~Do you have any plans to release source for TADS?

   We have no immediate plans to release source. It may not seem like
it, but doing so would require that we provide a lot of support, and
we have our hands full as it is. In addition, keeping the source to
ourselves lets us make sure that all of the versions of TADS in
circulation are compatible; it also lets us fix bugs more quickly,
because we know exactly what version of the source people are using.


@~What plans does High Energy Software have for the next year?

   We have a number of new projects in the works, although it's always
hard to know when or if any of them will be finished. I'm rewriting
the TADS compiler and run-time system in order to support an
integrated development environment which we think would make it
substantially easier to write a game with TADS. We've been doing some
exploratory work on supporting graphics and sound in TADS games; we
don't expect to be writing any graphical games ourselves because we
don't have the artistic talent to produce the necessary pictures, but
some of our more ambitious users may enjoy being able to add graphics
to their games. We'd also like to write some more games and we have a
couple of ideas that we're developing.
   We've been thinking about installing a bulletin-board system
dedicated to TADS support and text adventure gaming in general. Right
now we're doing all of our support through CompuServe and GEnie, but
it would be better to have our own system. We've also been trying to
find a way of creating a commercial text adventure distribution
channel of our own.

   Our goal is to be working on High Energy Software full-time. We
don't expect that we'll be able to do so anytime soon, unfortunately,
so our projects will have to continue at the same slow pace.

@~How do people get in touch with you for more information about TADS?

   We can be reached at PO Box 50422, Palo Alto, California 94303
(USA). Electronic mail users can reach us through CompuServe (user ID
73737,417) or GEnie (M.ROBERTS10). Internet users can reach us at
73737.417@compuserve.com.