TADSINFORM FAQ REV.1.1


Wed, 12 Apr 95 13:59:51 -0500

The "Which Is Better TADS or INFORM" FAQ
Edition 1.1
April 12, 1995

1.0 Introduction

Correspondents on the Usenet news group rec.arts.int-fiction
have long debated the merits of various systems for the
production of interactive fiction, usually in the form of
"text adventures" (see Nate Torkington's FAQ for better
explanations of what this all means). Although the
Adventure Game Toolkit (AGT) once had its day in the sun,
for some time now, the vehicle of choice for most
correspondents seems to be either Mike Roberts' TADS (Text
Adventure Development System) or Graham Nelson's INFORM.
The question is posed time and again by newcomers to the
newsgroup (and often by veterans): Which is better? Which
one should I use, and why?

This short paper will not give you a definitive answer to
this question. To do so would be as unfair as it would be
impossible. The paper will give you a comparison, in as
unbiased a form as possible (which is, given human nature,
less than absolute) which hopefully will help you to make
your own decision, on basis which will be a tad more
informed.

I must tell you at the outset that I have high regard for
both TADS and Inform, and their respective authors. I have
personally used both products from time to time, making a
selection based on specific project needs as well as sheer
whim.

In fact, the whole premise and title of this FAQ is a little
suspect, since I don't view TADS and INFORM as particularly
being in competition. Head and shoulders above anything
else in today's interactive fiction world, they are
alternatives to choose between, rather than being locked in
a Pepsi/Coke advertising and market share competition.

I have had input from a number of newsgroup correspondents
(see credits). However, I take full responsibility for all
opinions expressed herein, and full responsibility for any
errors or omissions. But how you use this information is up
to you, and I assume no responsibility for any damages of
any type whatsoever which you may or may not suffer arising
from the use of this information or any inaccuracies within
it. Be empowered and control your own destiny.

There is a lot of detail in this FAQ. If you'd rather skip
it, just go to the bottom and read the final "bottom line"
section (section 16.0).

2.0 Overview of TADS and INFORM

As of this revision, TADS has moved on to release 2.2.0.4
and INFORM is on the verge of going to 5.5. Since the first
edition of this FAQ some eight months ago, significant
improvements have taken place in both systems, removing most
major complaints about the systems, and making a choice
between them all the more problematical.

Both TADS and INFORM are systems for the development of text
adventures, and both take a similar fundamental approach. A
text adventure is written, effectively, in the form of a
computer program. This program is compiled to produce a
game file or story file, which is analagous to an unlinked
object code module. This module, which for both TADS and
INFORM is completely independent of computer platform, is
then fed (by the player of the game) into a platform
specific interpreter or run-time program. TADS has
available its own run-time programs for a number of
platforms. INFORM does not provide a run-time, relying
instead on a number of publicly-available run-times for its
specific story file format.

(Strictly speaking the compilers produce an intermediate
"P-code" module, which the interpreters further translate to
the target machine's own machine code.)

TADS programs are generally said to have a high-level,
Pascal-like format, and a "feel" something like a cross
between Pascal and some features of C (and now there are
options to make TADS look very C-like indeed). INFORM
programs are called "low-level, C-like" in nature. It is
safe to say that both of them have a "modern" programming
language feel, and that some skill and prior experience in
programming C or Pascal is very helpful to prospective
authors.

It's often asked if you need to be an experienced programmer
to use TADS or INFORM. My feeling is that the answer is
"yes"- these are non-trivial languages and build on a prior
base of knowledge. Non-programmers just learning to program
might consider an I-F language such as ALAN (not discussed
in this FAQ; see the materials in the reference section for
more information).

3.0 Program Philosophies

TADS is a "shareware" system; most of it is available for
free trial. Registration, currently about US $40, brings
you a source-level debugger (on the IBM/PC and Macintosh
platforms, at least) and an excellent printed manual. Many
correspondents feel that this manual is a necessity for
effective use of the program, and I tend to agree, as the
documentation in the evaluation package is sketchy. The
manual is supplemented by copious notes describing the many
changes since the manual was printed, and a whole new
replacement chapter discussing the command parser.

TADS is self-contained in that specific compilers and
run-time programs are a part of the complete system.
Compilers and run-times are currently available for the
IBM/PC, the Macintosh, the Amiga, and some Unix platforms.

The philosophy underlying Inform is much different. INFORM
is free (although legally speaking not public domain). All
source code is provided with the system, as is a set of
three reasonably comprehensive manuals. INFORM provides
only a compiler. What is unique here (and a source of both
praise and criticism) is that the story files produced by
the INFORM compiler are in the classic Infocom Z-machine
formats. (I will not attempt to explain this further; refer
instead to the FAQs and other materials in the reference
list). Z-machine interpreters (run-times) are widely
available for a very large number of platforms, from the
most common to the most obscure, and most of them are also
freely available. (Mark Howell's ZIP, version 2, is
generally regarded to be the best of these.)

The interesting result of the INFORM philosophy is that
games are produced in a recognized classic format, and are
widely portable. Of course, maintenance of this philosophy
means that all of the limitations inherent in Z-machine
games become a "given" for anything written in INFORM. Most
correspondents have not found this to be a serious current
limitation, however. But they do add that this can impact
future extension and development of the INFORM language.

The free vs. shareware issue seems to make a difference to a
few people, and having at one point myself been a
poverty-stricken student, I can appreciate that the $40
entry fee could be a barrier to a few potential users of
TADS. But to most people this does not present a major
issue, and no one has argued that TADS is not worth many
times the nominal $40 fee. The source code availability
issue appears to be more substantial, and this will crop up
again in the discussions which follow.

4.0 Program Feature Comparison

4.1 Operators

TADS offers a somewhat larger set of operators than
INFORM; TADS includes pretty much all the usual C
operators including Booleans, while INFORM has a few less
(and are not properly documented in the manuals).
However, the INFORM operator set is adequate, and capable
of doing most anything that TADS can through the use of
slightly longer constructs.

4.2 Functions

TADS has more built-in function calls than INFORM.
INFORM offers a basic set of calls, adequate to do most
jobs. Some things are a little more convenient and fast
to code in TADS due to the built-ins. Of course, the
same things can be hand-coded in INFORM, and many
functions are included in the standard INFORM libraries
(rather than in intrinsic form in the compiler).

4.3 Libraries

The INFORM libraries seem constantly to be improved and
have moved forward by great steps since the previous
edition of this FAQ. Most of the previously mentioned
objections to the libraries have disappeared, and
although not but free, the INFORM libraries can be said
to be in a highly developed state.

The standard TADS libraries previously seemed to have a
form and function edge. They have not developed as much,
and at this point I'd estimate that the INFORM libraries
have taken the lead. They seem to be more complete and
sophisticated, especially with the introduction of
scoping rules, multi-location objects, and other advanced
features.

But the picture is hardly so simple. An alternative TADS
library is available, which is a substitute for the
standard libraries. This library is from David Baggett
and is called "WorldClass". It is freely available and
redistributable in shareware games, and an excellent
WorldClass manual has been written by Paul Gilbert.

WorldClass is incredibly comprehensive and detailed, and
in feature and function easily exceeds anything else.
Indeed, this is a drawback as well as a strength, as it
is very complex and has a long learning curve despite the
documentation. WorldClass also seems to significantly
slow down game play, especially on older machines. Yet,
it surely represents the state of the art today, and
perhaps is a bit ahead of its time. As "old" 286/386
PC-class machines fade away and Pentiums predominate,
WorldClass speed issues will diminish. But for now, it's
the subject of controversy.

One additional advantage of the INFORM libraries is the
presence of the parser, and the deliberate design
decision by Graham to put many of the necessary functions
in the library where they can be more easily modified.
Indeed, much of the central loop of the game is in the
library, so really radical game play modifications are
possible. (This should be at the cost of play speed, and
probably is. But the penalty does not seem large.)

Both languages provide a means for modifying library
objects without actually changing the library source
code, and this feature is appreciated by all. TADS, in
addition, provides a means for dynamic creation and
destruction of objects during run time. The limitations
of the Z-machine architecture make it impossible to do
this directly in INFORM, although indirect methods have
been demonstrated.

At this point, then, the bottom line is that INFORM has a
small lead in the standard libraries; if you are willing
to tackle WorldClass and pay the speed penalties, give
TADS the lead.

4.4 Parsers

The TADS parser is built-in to the runtime. Some
correspondents feel it has a rigid structure, with no
option to change that structure. (This is not strictly
correct; TADS users can provide a "preparse" routine
which preempts the parser, but in practice this would be
long and laborious for all but simple uses.)

The INFORM parser is supplied as a source library file,
and can be customized or replaced at the whim of the game
designer. Correspondents praise this flexibility and
openness, while generally stating that the parser as it
stands is quite good.

Give INFORM the edge here for the freedom to redesign the
parser. But in practical terms, this may not be a major
issue. Few users are going to seriously hack the parser.

4.5 Debuggers

The registered version of TADS comes with a superb
source-level debugger, at least for the PC and Macintosh
versions. The debugger is a bit reminiscent of GDB,the
Gnu debugger, and works very effectively, with a rich
command set and all the tools and functions you would
expect.

INFORM has some built-in, non-interactive debugging
features, which I have found to be quite useful. This of
course cannot compare with a full source-level debugger.
A source level debugger for INFORM call INFIX has
reportedly been in the works for a number of months, and
support is within INFORM itself for just such a thing;
but no product has appeared as yet.

I must conclude, then, and my experience supports this,
that run-time debugging with TADS is much easier than
with INFORM.

4.6 Object Orientation

This is discussed in detail in a later section. Suffice
it to say at this point that TADS fits a stricter
object-oriented model than does INFORM.

5.0 Size Limitations

Most existing text adventures are of an "intermediate" size,
and I will deliberately leave the terms vague. But, to give
relative orders of magnitude, I consider my own "Pesach
Adventure" to be small; games such as "The Sound of One Hand
Clapping" and "Spectre Towers" are also small. "Trinity"
and similar games are intermediate, and this covers many,
many other examples. "Unkuulia Zero" qualifies as a large
game, as does "Curses." Dave Baggett's latest effort, "The
Legend Lives" surely must be called very large or even
enormous.

The limitations on game size in TADS are driven primarily by
the limitations inherent in the MS-DOS 8088 real-mode
architecture, which may well be the lowest common
demonimator for major operating systems. Apparently, the
major run-time limitation is that no more than 64,000
objects can be active at any one time, which is by present
standards unlimited. But under DOS, it was pointed out to
me that the practical limit is about 1200 complex objects,
or game files of about 500K in size on DOS machines running
in real mode. Beyond this, despite TADS ability to swap
objects in and out of memory, the tables needed to manage
this become too large. On non-DOS systems this is not so
much of an issue, but the option of writing a large game
which DOS users cannot play is not very attractive.

The latest version of TADS has available a protected-mode
variation, enabling it to address extended memory areas on
286 or higher DOS machines. Games built in this manner,
such as Legend, will not run on sub-286 machines. In
addition, the extended memory manager utilized appears to be
incompatible with many DOS configurations, and often needs
to be run in a DOS session under Microsoft Windows. This
ranges from an annoyance to a fatal problem, and clearly
needs more work. (There is a similar, if less severe,
problem with memory management on the port of INFORM
intended for use on 386+ class PC machines. The number of
reported memory configuration incompatibities is lower but
non-zero. This, however, affects only compilation, not
run-time; and the non-386 port of INFORM for the PC seems to
be very stable, if somewhat slow.)

Also, I have heard of difficulties in compiling large to
very large games with TADS. I have had some trouble with
this myself, but have been always able to set compiler
options (with some experimentation) to work around this.

TADS has no expressed limitations on vocabulary size,
property lists, etc. It appears that, with a little effort,
TADS is completely capable of producing very large games,
and Legend is an example of this.

INFORM, on the other hand, inherits all the limitations of
the various versions of the Z-machines. INFORM 5.5 allows
for production of Z-machine version 6 code, which can be
quite large, but existing public domain interpreters don't
handle it.. The more common format produced by INFORM,
Z-machine version 5 story files, are limited to 256k in
size, and have rigid internal limitations on various table
sizes. The use of text compression and abbreviation
optimization allow for the inclusion of more than might be
expected, but the ultimate limits are still there. Graham
Nelson's own game "Curses" in version 12 pushes the limits
of INFORM and the Z-machine version 5 size limitations- but
of course it's a goodly production. Something with the text
density of Legend, though, could not be gotten into a
version 5 story file.

What is the practical effect of this? INFORM is never going
to produce the very large games that TADS can produce,
because of the limitations of the Z-machine. (Having spent
a lot of time with the INFORM compiler while doing an IBM/PC
port, I can express the opinion that there do not seem to be
fatal flaws or limitations within the compiler which would
preclude its extension to produce very large story files.
However, a separate run-time would then be required, as the
existing Z-machine interpreters would no longer be able to
handle the story files. There would be a major impact on
portability in such a case.)

Also, INFORM authors must be more cautious than TADS
authors, and more conscious of some of the tighter limits
iherent in the system. But reality is that most author's
aren't going to attempt enormous games which push the limits
of INFORM. A "Curses" or even a smaller "Trinity" is a
major undertaking, but both of these fall within the
capabilities of INFORM. If you're going to write another
"Legend" or your project requires enormous vocabulary,
you'll be using TADS, but you will have to deal with the
very unpleasant world of DOS memory management. But for
most undertakings, either system will work.

6.0 Ease of Use

Correspondents report mixed opinions on ease of use. I
think familiarity is the leading factor here; those familiar
with TADS are comfortable with it, and likewise for INFORM.
Nothing more than an obvious conclusion, it would seem.
And, one person's feature is another person's problem.

Some think that the "C-like" nature of INFORM is at too low
a level of coding. Others have no problem with it, and some
even state that TADS code is too simple in structure. TADS
ease-of-use complaints aimed at earlier versions have been
laregely dealt with in the latest release; easy workarounds
for strange mixtures of upper and lower case library
keywords, mixed C/Pascal syntax, and a few other things, all
are now present. Ease of use criticisms now seem limited to
the usage of verification methods for verbs and some
difficulties sorting out the behavior of the parser and the
exact manner in which things are processed. (I think TADS
ease of use would be greatly enhanced by making verb
verification methods optionally. If they aren't there, and
the verb has an action method, assume that the verb is
valid!) Earlier problems with names and disambiguation have
been eliminated.

TADS was considered by one person to be a "safer" language
than INFORM, given its overall higher-level nature. Perhaps
this means that INFORM's assembler features can get you into
trouble. I'm not sure, though, that it isn't possible to
get into trouble in any language.

On another front, one correspondent reported that the INFORM
parser and libraries were written around the game "Curses"
and therefore require inconvenient extensive customizing for
other projects. Graham, though, says that the libraries
were really written around what would be needed to implement
"Zork" and that he made them as general as possible. In any
event, the INFORM libraries have progressed a great deal
since the previous issue of this FAQ and appear quite
complete.

There has not been much said as to how easy or difficult it
is to code any specific game or game function in either TADS
or INFORM. It is not difficult to construct cases which
might be a problem for one system or the other- or both- but
this is somewhat artificial. The section in this paper on
object orientation addresses some usability and convenience
issues which provide a little more insight.

A good comparative case for the interested reader to browse
is the classic game Colossal Cave, which has been
reimplemented in TADS by Dave Baggett, and in INFORM by
Graham Nelson (see reference list). While my own browsing
of the code hasn't lead to a clear conclusion, prospective
users of each system might find this to be a worthwhile
checkpoint.

7.0 Object Orientation

Both TADS and Inform profess to be, or have features of,
object-oriented languages, and this is of great interest and
importance to most correspondents.

There is general agreement that TADS comes a little closer
to some sort of "pure" object-oriented model (which I most
certainly will not attempt to define). The only deviation
noted is that the notion of instances is not explicitly
present, but this seems to be of only theoretical
importance. Inheritance, encapsulation, and messaging are
all there. This seems highly pleasing to TADS users, and I
certainly find it easy and convenient to work with, and
particularly suitable to the text adventure game.

INFORM seems to fit a looser object-orientation model.
Classes and inheritance are present, as are embedded
methods. Encapsulation is incomplete; global variables have
to be used for many purposes. Messaging is also incomplete;
objects use their own methods and global methods but only
through subterfuge are capable of calling methods in other
objects (but you still can get the job done). This poses
some problems in coding in some instances, although
work-arounds are nearly always possible. Still, the overall
object structure is helpful, and enough of the
object-programming paradigm is implemented to be useful.

Most, but not all, feel that object-orientation is a
positive feature; but one person thought the TADS
object-oriented paradigm was confusing and preferred INFORM
for this reason.

But TADS has a theoretical edge here in adherence to the
object-oriented programming model. The practical edge is
but slight.

8.0 Peculiarities

Every language has its own quirks. Indeed, one
correspondent called INFORM a quirky language, based on the
limitations and requirements of the Z-machine model.

Verb verification methods are cited as a "quirk" of TADS;
there is a requirement that a method be present for allowing
a verb to act upon a given direct or indirect object. This
provides both flexibility and coding overhead; and there are
specific rules which have been a pitfall for some authors.

TADS once had a problem disambiguating multiple objects of
similar description; this is no longer the case in the
latest release. And, both TADS and INFORM can now do things
such as select one numbered object from a thousand identical
objects, and similar feats. (You can pick a match from a
matchbook, select a certain mailbox from many identical
mailboxes, etc.)

Another correspondent called the TADS interface between the
run-time, game file, and the libraries somewhat haphazard.
There was not enough detail given to be able to explain this
further.

Overall, I'd rate TADS as a bit less picky and perhaps a bit
less quirky, while having a bit more coding overhead than
INFORM. TADS seems to shorten the learning curve a little
in that what you already know about C and Pascal is applied
a little more easily; INFORM's syntactical requirements need
to be absorbed first. But once again, the choice is
anything but clear.

9.0 Odds and Ends

Bitwise operations have now been added to TADS, although
these can be handled in INFORM by working at the assembly
lanaguage level. INFORM actually has quite an edge here
since there is no assembly language equivalent in TADS.
INFORM lets you work with the heart of the Z machine if you
feel so inclined. But perhaps more important is that this
shouldn't be important. TADS and INFORM have reached a
state at which this low-level hacking is seldom if ever
really necessary.

Neither system offers floating point computation, which
would be of little practical value in any case.

10.0 Compilation Speed

In the previous release of this FAQ, I published compilation
benchmarks. I have not repeated these in detail, but I'm
finding the speed ratios remain similar.

It is difficult to do a speed comparison directly. These
are not C compilers where both can be fed the same code and
timed. Instead, I took the ports of Colossal Cave to TADS
and INFORM and timed compilation of those on various
platforms.

What I found was that on a platform to platform comparison
basis, TADS is about twice as fast as Inform; Linux is about
twice as fast as DOS; and the Inform/PC-Generic version is
pretty slow.

What does all of this mean? Clearly, that you should run on
a fast machine, and that the compiler and operating system
make a noticeable difference. TADS under Linux wins hands
down when it comes to speed, although INFORM under Linux
doesn't do badly at all.

These comparisons consider only the standard libraries.
WorldClass for TADS is a lot larger, and will slow the
compilation correspondingly.

In practical terms, though, this all means less than it
appears. Except perhaps for brief periods of very intensive
debugging, on any reasonable machine, the speed differences
won't hamper the game writer very much. TADS is clearly
faster. But compilation time is such a small part of game
development time, that a choice based purely on speed
wouldn't make much sense.

11.0 Run-Time Speed

If comparing compilation speed is difficult, comparing
run-time speeds is nearly impossible. Yet, run-time speed
is what every game player is going to see, and is arguably
much more important than compilation speed.

As before, I do present objective numbers, and in the case
of INFORM, these will vary with the interpreter used. It is
generally thought that Mark Howell's ZIP is the best and
fastest of the publicly-available interpreters, so I used
that one in my highly subjective evaluation.

On a fast machine, there is really no appreciable difference
in the speed "feel" between TADS and INFORM, unless you are
playing Legend, in which case the sheer size of WorldClass
imposes a noticeable speed penalty. (I didn't find it all
that bad, but a number of correspondents thought it was far
too slow.)

The commercial interpreters from Infocom are often
noticeably faster than ZIP, provided that the intended
interpreter is used with the right game. This is not
especially surprising since ZIP needs to have code to handle
all conceivable formats while the specific interpreters can
be leaner and more optimal.

It is my impression that for code of comparable complexity
ZIP is a little faster than the TADS runtime. It has been
suggested that this is because the TADS parser loops over
all objects under certain conditions. I have not had
specific confirmation of this, and I am into a realm so
speculative that any further statements would be a
disservice. You would surely notice this is in a game built
with WorldClass, however.

12.0 Game/Story File Size

This might be a minor point. But INFORM story files, for
comparable cases, tend to be about half the size of the
equivalent TADS game file. And, the INFORM compiler and
common interpreters are perhaps two-thirds the size of the
TADS compiler and runtime. (I'm basing this on MS-DOS
executables which have been processed by some sort of
compaction program such as COMPACK.) From the point of view
of distribution, this gives INFORM a minor advantage, I
suppose.

13.0 Existing Literature

TADS as a product has existed in usable form for some time
longer than INFORM. TADS version 2.0 or better has been
around about two and a half years; INFORM 5 for perhaps a
year or more as of this writing. So, it is not surprising
that there is a fair amount of TADS literature and less
INFORM literature.

Another FAQ (see references) lists currently published TADS
games; there are perhaps twenty or more of these. They vary
in size from quite small (The Pesach Adventure) to very
large (Unkuulia Zero) to medium size, incredibly complex
(GC)- and of course, there is the enormous Legend. Source
code for a number of games is available, either for free or
with game registration. Notably, source code for Crystal
Cave, Ditch Day Drifter, and GC are all freely available,
and these together provide a superb set of examples and
sample code.

For INFORM, there are just a few games currently available.
Toyshop is a very small test game supplied in source form
with the package. Balances is another small test game which
is quite good in and of itself and demonstrates many
features of INFORM. ADVENT, Graham's port of Colossal Cave,
is also available, and provides a very useful source code
example. Unfortunately, it doesn't cover a lot of the
features of INFORM, although Toyshop, Balances, and the tiny
"A Nasal Twinge" make up the difference.

TADS coding has naturally gotten more hostorical discussion
on the newsgroup, and a paper with TADS programming hints
has been written (see references). INFORM coding is now
getting at least equal discussion, however.

So, give TADS the nod on available literature and source
code, although perhaps give INFORM the nod for deliberately
thought out example code. This, though, is likely to be a
dynamic situation as INFORM authors produce and publish
games in the coming months.

14.0 Documentation

This issue was talked about briefly under the Philosophy
section, concerning the free vs. shareware question. Most
correspondents feel that the documentation that comes with
the TADS shareware package is pretty sketchy and probably
inadequate for serious game writing. On the other hand,
they unanimously agree that the printed manual supplied upon
registration is excellent in quality and utility, although
it now must be supplemented with a large quantity of update
notes which make usage more difficult.

The INFORM manuals are freely available. The main manual is
available in a variety of formats. Thw two supplemental
technical manuals are in TeX format, which is a possible
problem for users with no access to a Unix system.

Correspondents have said various things about the INFORM
manuals. While a few have said they are difficult to
follow, most have called them an excellent piece of work.

My own opinion is that the original TADS manual is as good
as they come, but now, with the large supplement required,
the overall usability has been reduced or at least diffused.
The INFORM manuals are quite good, although in going form
one large manual to three smaller ones, and completely
rewriting the "Designer's Guide" Graham has dropped a few
things out- most incredibly, the list of supported
operators! At this point, I'd rate the registered TADS
documentation and the INFORM documentation as pretty close
in quality. For evaluation purposes, though, TADS shareware
documentation doesn't really work out.

There is one other factor, though. If you wish to have your
documentation on-line while you code, INFORM is the clear
winner. (My home-brew workbench has a "help" facility which
relies on on-line documentation.) With INFORM you can
easily keep all the manuals on-line. With TADS, you're
limited to the shareware documentation, since the registered
manual is supplied only in paper form.

15.0 Other Considerations

15.1 Portability

The portability debate raged for a time on the newsgroup,
and centered more upon run-time portability than compiler
portability. The argument is perhaps that it is less of
an issue as to where the games are written and compiled,
but more of a consideration when it comes to the
potential audience for a game. If an interpreter or
run-time is not available for a particular platform,
users of that platform will not be able to play your
game.

There is sharp disagreement on this subject. At the
heart is the proprietary nature of TADS; Mike Roberts is
(understandably) cautious about releasing his source code
to others for the purpose of porting the compiler and
runtime to new platforms (although obtaining source cod
is by no means impossible). INFORM source code is
publicly available, as is the source code to the major
Z-code interpreters. So, in theory at least, TADS games
face a limited audience while INFORM produced story files
serve an unlimited audience.

Theory and practice do not, as usual, converge. TADS
runtime is not available on every platform, but it is
widely available on the major home computer platforms
(one correspondent pointed out that it is not available
on many large commercial machines). Various estimates as
to the percentage of home machines "covered" by TADS
run-time have been given; 98eems to be a common figure
but I have no real basis for this. But, with the PC,
Macintosh, and Atari/ST platforms covered (with a beta
version available for Amiga), this is just about all of
the US home market. This leaves out Acorn in the UK and,
I suppose, a few European brands, but this surely
represents a small percentage.

The situation is different with both larger machines and
much smaller machines. Some workstation size Unix
machines have TADS ports available. But larger machines
such as VAX and IBM midrange and mainframes do not have
ports available.
And, it was pointed out to me that Infocom story file
interpreters are available for many of the older 8-bit
home computers, which are still in use by many of their
devotees. And, in fact, Graham reports that Curses is
being played on Psion hand-held calculators. How
important all of this this might be is for you to decide.

The latest portability wrinkle is posed by the TADS game
Legend, which in the DOS world relies on a memory
extender that has serious compatibility problems.

There is a reverse side to all of this, too. Since so
many different Infocom interpreters are in existence on
so many machines, and the implementation completeness and
quality is so variable, one author said that he didn't
have confidence about his games running successfully in
each instance.

INFORM ports have been made to the Macintosh, the PC, the
Amiga, the Acorn Archimedes (the "home" machine of
INFORM), the VAX, and Unix machines. Z-machine
interpreters are available for all of these. So, the
potential audience of an INFORM produced game is larger
than that of TADS. In practice, though, this must be an
incremental difference.

15.2 Stability

The TADS compiler and runtime (without memory extender)
are very stable, and I have had few reports to the
contrary. (I am talking about crashes as opposed to less
severe bugs in possibly producing spurious error messages
or inappropriate P-code.) The memory extender changes
all that, and problems and crashes have been very common.

The INFORM compiler is also quite stable, and although it
was never highly crash-prone, it has improved in recent
releases. The interpreters also seem a little less stable
than the TADS interpreter, although ZIP is the best of
these. What I have often observed is that INFORM will
produce code from a source file that is not quite right
from a logical standpoint, and then the ZIP interpreter
will crash without much indication of what went wrong.
While the same thing can and does happen with TADS, the
problems are generally easier to trace.

15.3 Source Code Availability

I've noted that all INFORM source code, as well as the
source code for the common Z-machine interpreters, is
freely and easily available. This includes libraries,
parser, the whole works. TADS source code, both compiler
and run-time, is not available due to its proprietary
nature.

There are several impacts of this, all of which
marginally favor INFORM. Many correspondents are unhappy
that the TADS parser is inherent in the run-time module,
and therefore not accessible for modification (although
TADS does provide several function stubs for use in
effectively modifying at least some of the parser
behavior). The INFORM parser is a library file, easily
modified without changing any of the compiler or
interpreter code. This provides additional flexibility
to deal with special (probably infrequent) situations) in
a straightforward manner. (TADS can probably handle many
of these via less obvious workarounds.)

Troubleshooting is probably (to me) the largest issue.
If you run into any sort of difficulty with INFORM, the
source code is there, and with patience, you should be
able to unravel it and possibly deal with it. With TADS,
you either need to find a workaround, or contact the
author or some other TADS expert for help. In all
fairness, support from High Energy Software is uniformly
viewed as excellent; and quick availability of help on
the Internet has been quite good. But the element of
self-reliance is not there. If you encounter a problem
at 3 AM Sunday morning, you have no choice but to post a
message and await a reply. You can't tear into the
source code and find out what's wrong.

Again, practicality may be that early morning debugging
of INFORM may not be so easy, and perhaps not within the
grasp of everyone.

Compiler portability is not a big issue. Most
correspondents don't seem to have a problem locating a
platform on which to do TADS or INFORM development.

15.4 Cost

I've discussed some of the cost issues in the "Philsophy"
section and won't repeat all of it here. The $40 cost of
TADS is an entry barrier to a few people, and for them
that is a serious issue which decides the question by
default. But for most people, cost is not a major
consideration- at least not to a serious author who
intends to do more than just dabble with the product.

There is, of course, no guarantee that TADS will never
cost more than $40; there is no expectation that major
upgrades will be free. High Energy Software has, though,
treated its customers very fairly, so I cannot suggest
that this is a concern of any magnitude. Similarly, we
cannot say with utter certainty that Graham Nelson will
continue to offer INFORM for free. But his philosophy
certainly indicates that this will be the case; and he
has (wisely, I think) retained the copyright in order to
prevent others from taking INFORM and selling it.

At least as important as the issue of up-front cost is
the sometimes difficult issue of distribution rights.
When you use TADS or Inform to produce a game or story
file, who owns it, and what rights do you have to
redistribute it? Both TADS and Inform seem to take a
similar (but not identical) approach. It is fairly clear
that the author owns intellectual rights to the game or
story file. TADS allows redistribution of the game file,
and the runtime interpreter, without restriction on a
shareware basis. High Energy Software, the owners of
TADS, ask that any commercial distribution be negotiated
separately with them. INFORM allows for any recreational
use of the compiler, and the commonly available
interpreters are freely distributable. Graham has
specifically granted permission for shareware and
commercial use of story files produced by INFORM.

15.5 Future Outlook

At present, INFORM is Graham Nelson's product, and TADS
is Mike Roberts'. What does this mean into the future?
New releases of TADS are dependent upon Mike Roberts'
interest, inclinations, and available time. Although
there is no indication that the moment is soon coming,
nothing goes on forever, and I can envision a point at
which Mike will no longer wish to work on TADS. At that
juncture, he would either discontinue the product, turn
it over to someone else, or possibly make it public
domain. (This happened with the Adventure Game Toolkit,
AGT, which recently became freeware, with source code
availability.) In the meanwhile, development and
enhancement is solely in the hands of Mike, and on his
timetable. Of course, there is a large TADS community at
this point, and it would appear most likely that someone
else would take over the reins should Mike retire from
the field. So I don't think we need to worry about this
unduly.

INFORM has been called a one-man project by one
correspondent, and there is some truth to this. Graham,
too, may someday tire of INFORM and work on it no longer.
The major difference, though, is in the free and easy
availability of all source code. Any user of INFORM with
enough ability can enhance INFORM any way at all to meet
any need or wish. This will remain true whether or not
Graham continues his interest in the product. Similarly,
ports of the program can be make, by anyone so inclined,
to any new machine which might come along at any point.

I must conclude, then, that INFORM potentially has
somewhat greater future prospects than TADS, but this
does not at all mean that TADS has poor future prospects.
The practical meaning of this will only be known over a
period of years.

16.0 The Bottom Line

Here is a simple uncorrelated summary of "plusses and
minuses" for both TADS and INFORM. Please do not tally up
plus/minus indicators to get a score and declare a winner.
It doesn't quite work out so easily.

16.1 TADS

+ Overall ease of use very good
+ Documentation excellent in registered version
+ Large published literature
+ Rich set of operators, functions, features
+/- Will handle extremely large games but with speed and
compatibility problems
- Parser "closed"
- Source code not generally available
- Verb verification methods can be a nuisance
+/- State of the art WorldClass library available; usable
at a speed penalty
+ Compiler is very fast
+ Very complete object oriented paradigm
- Shareware with some game distribution restrictions

16.2 INFORM

+ Completely open with all source code available
+ Excellent documentation and example code
+ Compatibility across a very wide platform range
+ Very good standard libraries
+ Run-time generally fast
- Compiler can be slow on some platforms; almost always
twice as slow as TADS
- Some language constructs not straightforward, giving
less of a "known language" feel than TADS
- Fewer functions and operators than TADS
+ Freeware with no game distribution restrictions

17.0 Final Observations

As I said at the outset, I can't choose, and recent releases
and enhancements have made the choice even more difficult.
Both of the products are wonderful, and I am grateful to the
authors of each of them. I have used both TADS and INFORM
in the past, and will continue to do so.

I previously listed circumstances under which I personally
choose TADS or Inform for certain projects. I've altered
this position somewhat. There is a learning curve with each
product. Getting started is pretty easy, becoming
comfortable takes a while, and becoming an expert takes a
long while. I'd suggest that you pick one product and stick
with it. At the present moment, I happen to be using just
one of the two systems. (No, I won't tell. And it will
probably change from project to project.) You can pick
either one, and you will not go wrong. The important thing
is to get started.

I can only hope that the information in this paper will give
you something more to go by in making your choice. Assess
your own needs, review the facts, and decide. And then
write and publish your games. There are still a lot of text
game fans out there!

18.0 Credits

My thanks to the group on rec.arts.int-fiction, many of whom
provided direct, personal input to this FAQ, and many of
whom provided indirect input via the newsgroup. I'm no
longer listing all the names because it's too easy to forget
one, and I don't want to imply that anyone necessarily
agrees with anything I've said herein.

My sincere thanks to Mike Roberts and Graham Nelson for
their dedication to their wonderful products. If they both
had not done such a great job, we wouldn't have anything to
choose from, or between.

19.0 References

The following materials can be found on the Internet ftp
site ftp.gmd.de:

Several FAQs on Interactive Fiction, systems and games
TADS Shareware Packages with shareware documentation
"WorldClass" TADS libraries
INFORM Packages with complete manual and libraries
Paper on hints for getting started with TADS
Listing of published TADS games

The following is available upon program registration:

The TADS user's manual.

20.0 Feedback and Improvements

This FAQ contains a lot of opinion, much of it my own, and
it is all subject to debate. If you have a viewpoint which
you would like included in a potential revision of the FAQ,
please let me know. If you find errors or omissions, please
e-mail me right away. While I've been reasonably careful, I
don't pretend to have gotten everything completely right.

Please contact BNEWELL@DELPHI.COM. Or call my BBS, the
GobblerNet Classic Games BBS, at 701-222-0429 in the USA.
It's a BBS dedicated to the great classics of computer games
and there is a large text game file section.


Bob Newell
Bismarck, North Dakota
April 12, 1995

(Hopefully, this week's snowfall was the last of the
season.)