Interview with Michael J Roberts of High Energy Software

TADS, the Text Adventure Development System, has had loads of
mentions in previous issues of SynTax. Grue and I are currently
writing our new adventures using it and having great fun (most of
the time!).  A long time ago, Neil interviewed Mike Roberts of
High Energy Software, its author and developer and I thought I'd
do a second interview, to recap for new readers and to bring the
rest of us up to date on what's happening with TADS.

* * * * *

SM: Hi Mike, welcome to SynTax. Would you like to start by telling
us a bit about yourself?

MR: Okay - I went to school at Caltech (which is probably obvious
if you've played Ditch Day Drifter), where I majored in physics.
Since graduating, I've been working in the software industry in
the San Francisco bay area.  I've worked mostly on software that's
totally unrelated to games -- database systems and programming
tools.  Right now, I'm working on a graphical application
development system for Windows and Macintosh.  Several years ago,
when I was finishing up the first version of TADS, a friend of
mine and I set up High Energy Software as a part-time business.

SM: How did the idea for TADS come about?

MR: I didn't start out intending to design a language; that idea
evolved over several years.

Many years ago, I became interested in writing text adventures.
The first one I wrote was in Basic, and later on I wrote another
in an obscure Pascal-like language.  As I was writing the second
game, it occurred to me that lots of the code could be generalized
to any adventure game.  So, I tried to write a little library of
common functions -- the functions operated on a set of data files
that specified the vocabulary words, room descriptions, and so on.

This was a nice approach in some ways; the idea was that the game
would be described entirely with these data files.  The problem
that I kept running into was that I'd have to write
special-purpose functions for certain rooms, or certain commands
-- you couldn't write an entire game with just the data files,
because you always had to customize the library functions for each
game.  What I really wanted was a way to put programming commands
into the data files themselves, so I didn't have to modify the
library routines.

Once you start putting procedural code into data files, you
essentially have a programming language.  At first, I tried to
avoid the work of writing a real language interpreter by making
the language very limited and easy to parse.  That was better than
just the data files, but it was tedious to write programs in a
limited language; I eventually saw that you really needed a good
language that was easy to use to be able to write decent games.

I do most of my work (other than writing adventure games) in C
(and in C++ these days), so I made the language look a little like
C.

SM: TADS is described as an object-oriented programming language -
could you explain what that means?

MR: "Object oriented" is not a very precise term these days,
thanks to abuse by lots of marketers.  There isn't really anything
really new or different about object-oriented programming; it's
more of a coding style than anything else, although certain
languages make it a lot easier to code in an object-oriented
style.

The main thing about OOP is that you gather together related data
and the functions that operate on that data into an "object."  An
object is really the same thing as a structure (or record, if
you're a Pascal programmer).  The extra thing that OO languages
let you do is associate functions with objects; this is purely a
syntactic convenience, since you can achieve the same effect in a
language like C by using a suitable set of coding conventions.

Another big feature of OOP is "inheritance."  This means that you
can define an object in terms of another object -- the new object
inherits all of the characteristics of the original object, but
you can also add to or change features in the new object.  For
example, you can define a generic "shape" object that has certain
properties, such as a bounding rectangle, a color, center
coordinates, and so on; and then you can define a specific shape,
such as a rectangle, in terms of the generic shape.  The rectangle
inherits all of the properties of the generic shape, but provides
more specific definitions for some of the properties.

All the pundits have their lists of what makes a language object
oriented, but this seems to be the core of it:  the ability to
encapsulate related data and functions together into object
classes, and the ability to derive new object classes from
existing ones through inheritance, with the ability to override
inherited behavior in a derived class.

Object-oriented programming seems to be very useful for
simulations, since it's easy to think about real-world objects in
these terms.  A text adventure is in large part a simulation, so
OOP techniques apply very naturally to text adventure games.

SM: I'm not a programmer but I found TADS quite easy to use once I
got used to it. Is that the general impression you get from
people?

MR: I've heard that from a lot of people.  I didn't really set out
to design a language for non-programmers, but many people have
been able to pick it up without a lot of previous programming
knowledge.

SM: TADS is distributed as shareware. How well has the shareware
system worked for you?

MR: High Energy is a part-time business for us.  On those terms,
the shareware system has been reasonably successful, in that the
business has been profitable, but it unfortunately isn't
successful enough to be a full-time job -- High Energy pays for
itself, but it doesn't pay my bills.  On the other hand, I think
shareware is probably the most effective way we can distribute a
product like TADS.  This is a rather specialized product, and I
don't think it could sustain the kind of volume that would pay for
advertising.  Shareware is a pretty good alternative, since it
lets people hear about the product without big spending on our
part.

SM: I would imagine that most registrations have come from The
States, but have you had many from the UK and Europe?

MR: We've had a surprising number of registrations from people in
the UK and Europe, actually, and we hear from people in Australia
and New Zealand from time to time.  I think it helped a lot when
we started taking credit card orders, since that makes currency
conversions so much easier.

SM: TADS is also available on the ST and MAC with an Amiga version
in progress.  Are you planning to continue with all four versions?

MR: We do plan to continue supporting all these systems, plus
whatever other systems we can.  We only directly maintain the PC
and Mac versions, but we've been working with a number of people
who keep the other versions up to date.  TADS is very portable at
this point -- porting a new version to a system where it's already
working usually doesn't take any more work than recompilation.
The Amiga version has unfortunately been lagging a bit behind the
others, but we hope to bring that one up to date soon.

SM: I had to use switches when compiling my first TADS adventure.
How big a TADS game can be written without using switches and what
factors make you have to use them?

MR: It mostly depends on your memory configuration, and now that
the DOS version can run in protected mode (in extended memory), it
should be much easier to compile a large game.  The cache size
setting (the -m switch) is the main one that is affected by the
overall memory size -- as the game grows larger, you sometimes
have to make the cache size smaller on a DOS machine.  This
probably sounds backwards -- you have to make the cache smaller as
the game gets bigger?  The reason is that TADS divides memory into
"cache" memory and regular memory.  The cache is where the objects
go; regular memory is used for things like the compiler's symbol
table.  Normally, TADS will let both cache and regular memory grow
as needed.  When compiling a large game on a small machine, the
cache can get big enough that there's no memory left over for
something that has to go in regular memory.  Fortunately, TADS can
"overcommit" the cache -- this means that TADS can store more in
the cache than is available in physical memory, by swapping
objects to disk.  So, even if your game is very large, you can
reduce the size of the cache, forcing TADS to swap objects out to
disk as the cache becomes full, but leaving more space for regular
memory allocations.  So, when you run out of memory during a
compilation, you can make more memory available by reducing the
size of the cache with the -m switch; the trade-off is that it's
slower to swap objects in and out of memory, so you want to make
the cache as large as possible to keep compilations fast.

There are several other -m switches, such as -ml, that affect
specific memory areas.  For example, -ml sets the size of the
local symbol table.  These settings generally do not need to be
adjusted according to the overall size of your game -- instead,
they need to be increased only when your game places large demands
on the specific type of memory the switches control.  If your game
has a function with a very large number of local symbols, for
example, you might have to increase the -ml setting.  You can
write a gigantic game without ever having to change -ml, and you
can write a very small game that needs a big -ml setting.  The
most common setting that has to be changed is -mp, which controls
the "parse node" area size; this is a working area that the
compiler uses while parsing expressions, and often must be
expanded because of long strings, large lists, or complex
expressions in your game.

SM: I know you are working on a new version of TADS; when is it
due out and what improvements will it contain?

MR: TADS 2.2 is ready!  It has a number of new features.  First,
you can create new objects dynamically at run-time.  You can
change the vocabulary words for objects at run-time -- for
example, you can add a new word to an object, or delete an
existing word.  The system now supports the idea of "equivalent"
or "indistinguishable" objects -- the user can say things such as
"take 5 coins."  You can read and write files at run-time, which
means you can share information between sessions of a game, or
even between entirely different games; for example, you could
write a character's information to a file and then use the same
character settings in another game.  On DOS, we now provide
protected-mode versions of the compiler, run-time, and debugger
(in addition to the normal real-mode versions), which means you
can use up to 16 megabytes of extended memory if you have a 286,
386, 486, or Pentium PC -- this really speeds up compilations for
big games, because it means there's enough memory that TADS never
needs to swap to disk.  There are a lot of other miscellaneous
improvements, but those are the main new features.

SM: How much do users' suggestions affect future versions of TADS?

MR: Substantially.  I've been especially interested in adding new
features that make it possible to do things that you couldn't do
in the past.  Creating new objects at run-time is a good example
of a feature that many people have requested for a variety of
different reasons.


SM: What are the chances of you adding a 'clear screen' option and
one for a loading screen - say just a PCX graphic?

MR: TADS 2.2 has a clear-screen function, so the chances are
excellent!

SM: Graphics are getting increasing popular in adventures - though
I still prefer to imagine my own 'pictures'. Do you ever see TADS
becoming a text / graphics utility?

MR: Graphics are a somewhat more difficult issue.  We put together
a prototype of a graphical system a couple of years ago, but we
haven't had the time to take it much further.  I'd like to get
back to that at some point, but there's so much that can still be
done in the regular text system that it's hard to know when I'll
find the time.


SM: Do you have any plans for a TADS User Group?

MR: That's an interesting idea -- I hadn't really thought of it
before.  I'd definitely like to hear from people to see if anyone
would be interested.  I've also thought about simpler things, such
as putting together an Internet mailing list for TADS, but so far
I haven't organized that.

SM: Have you got plans for any more adventures of your own and
what are High Energy's other future plans?

MR: I'd definitely like to write some more games.  Now that TADS
2.2 is mostly done, I've been thinking that it might be a good
time to write a game.  I have a few interesting ideas that I'd
like to develop.  I might try to get started over the holidays.

SM: Thank you for taking the time to take part in this interview.

MR: My pleasure!
                              - o -