



The \Which Authoring System is Better" FAQ



       Bob Newell (bnewell@gobblernet.sputnix.com)



                          Revision 0.1

                       February 17, 1996




Contents


1  The Purpose and Nature of This FAQ                          1


2  What Authoring Systems are About                            1


3  An Evaluation Framework                                      2
       3.1   Categories and Weightings : : : : : : : : : : : : : : : : : :  3
       3.2   Rating the Systems by Category  : : : : : : : : : : : : : :  6


4  The Tiers of Authoring Systems                                6
       4.1   The Tiers Defined  : : : : : : : : : : : : : : : : : : : : : :  6
       4.2   The Population of the Tiers  : : : : : : : : : : : : : : : : :  7


5  The Systems Examined                                         7
       5.1   TADS| Text Adventure Development System  : : : : : :  8
       5.2   Inform  : : : : : : : : : : : : : : : : : : : : : : : : : : : : : *
 *15
       5.3   ALAN  : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 22
       5.4   Hugo : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 27
       5.5   AGT| Adventure Game Toolkit  : : : : : : : : : : : : : : 31
       5.6   Archetype  : : : : : : : : : : : : : : : : : : : : : : : : : : : 37
       5.7   GINAS   : : : : : : : : : : : : : : : : : : : : : : : : : : : : 41
       5.8   LADS| Levi's Adventure Development System : : : : : : 44
       5.9   Gamescape  : : : : : : : : : : : : : : : : : : : : : : : : : : 46
       5.10  Aventuro  : : : : : : : : : : : : : : : : : : : : : : : : : : : 51


6  Final Remarks                                                54


7  Afterword: How Many Systems Are Enough?                  55


8  Interactive Fiction Resources                                  56


9  Disclaimer                                                    56


10 To-Do List                                                    56


11 Comments on this FAQ                                       57


12 Credits                                                       58


13 Revision Log                                                  58


14 Summary Table                                               59




1   The Purpose and Nature of This FAQ


For the prospective author of Interactive Fiction (IF) there is now a wide choi*
 *ce
of authoring languages.  While it is immediately obvious that not all these
languages are created equal, nevertheless the process of choosing a language
can be a daunting task for the new IF author, and is not always simple even for
the experienced author.
   The purpose of this FAQ is to describe at a high level most of the major
and some of the minor authoring languages, presenting a framework for evalu-
ation, and some subjective comparison. This FAQ will not choose a system for
you, but instead has the archetypical aim of having you-go away with sufficient
information to make a decision which is a tad more informed.
   In nearly all cases, the creators of authoring systems are well respected and
highly deserving of this respect. Comments and criticisms directed at authoring
systems within this FAQ are intended to be constructive and no disrespect for,
or lack of appreciation of, the creator of the authoring system is in any manner
intended.
   While numerous people have helped immensely in the production of this
document, I take full and complete responsibility for any deficiencies in its
content.  No opinion expressed herein should be assumed to be or not be the
opinion of any individual contributor to the FAQ, and the presence of their
name in the credits is not an indication of their agreement or disagreement with
any statement made in the FAQ.
   This document is a total rewrite of my older Which is Better, TADS or
Inform?  FAQs, and for the most part replaces and supersedes the older doc-
uments.  That document went into excruciating detail about things such as
operator sets, library function calls, and other such matters which, while they
are important, will not greatly influence the more high-level process of choosi*
 *ng
a system.  Prospective authors who really need to compare the small details
in an in-depth manner should refer to the documentation for the individual
systems and make their own comparisons.



2   What Authoring Systems are About


Drop in on the main Usenet conference for IF authors, rec.arts.int-fiction,
and you'll find that authoring systems are a hot topic.  From time to time
someone, usually but not always a relative newcomer to the newsgroup, will
post a question about writing interactive fiction in Lisp, C++, Basic, or even
Pascal or Fortran. Almost always a response comes back, \Haven't you checked
out authoring systems X, Y, or Z?"
   Indeed, while it is entirely possible and feasible to write IF in a procedur*
 *al
(or even non-procedural) 3rd generation language, object-oriented or non object-
oriented, there seems today to be little point in so doing. Specialized languag*
 *es,



                                 2




created for the main purpose of IF authoring, save the prospective author a
great deal of drudgery, primarily in the area of parsing and natural language
processing.  Except as an experiment or as an exercise in programming, new
authors quickly turn to one of these purpose-built languages for the creation of
their proposed IF work.
   The first purpose of the authoring system, then, is to make the author's life
easier, and much of the discussion in this document will revolve around just
how, and how well, this takes place. A second purpose of the authoring system,
and probably no less important, is to make life easier for the prospective play*
 *er
of the finished piece. (The term player will be used in preference to the term
reader since the works of interactive fiction treated here are invariably prese*
 *nted
in the context of a game.) A good natural language interface and an effective
parser make the work a more pleasant and appealing experience to the player.
   Further to this, and of a more technical nature, the end product or output of
applying the authoring system to the work at hand is some sort of game file or
story file which is then run in some manner by the prospective player on some
computer system.  The wider the type and variety of computer systems upon
which the game or story file will operate closely defines the possible audience
for the work. Therefore, an authoring system which produces game files which
only run on Cray supercomputers will be of considerably lesser value than a
system which produces story files workable on all manner of PC, Macintosh,
Commodore, Acorn, and Sinclair.
   So, in summary, an IF authoring system helps the author create the work;
helps the player experience the work; and defines the possible audience of the
work. These major factors, and a number of minor ones, will form the basis of
our evaluation.



3   An Evaluation Framework


Based on a very much subjective analysis of the traffic on the newsgroup,
rec.arts.int-fiction, and some limited feedback on an early draft version, I
present a set of some nineteen suggested criteria for evaluating IF programming
systems. I've weighted each criterion for importance on a 1 to 5 scale. In an
exercise as approximate as this, I see no point in expanding the scale to allow
for finer gradations of meaning.
   It would be very tempting for the reader, at the end of the paper, to multip*
 *ly
weightings and ratings for individual authoring systems to come up with a
composite score and declare one system to be the \winner" based on these scores.
This would be fallacious, in that the relative importance of the categories to *
 *one
another have not been evaluated.  Two categories of weight 5, while both are
critical, can not be assumed to have the same overall impact on the usefulness
or desirability of a given authoring system. Furthermore, it cannot be argued
that the categories listed form a complete, comprehensive, orthogonal set which



                                 3




would even be an appropriate basis for computing an overall score.
   The reader is therefore strongly discouraged from the computation of com-
posite scores, and instead encouraged to look into individual ratings categories
and so determine for oneself what is important in any particular situation or
environment.
   The evaluation category weightings have the following approximate mean-
ings:
   5 Critical. The usefulness of the system will be severely compromised or
destroyed if this category does not measure up.
   4 Very important. The system does not fully stand or fall based on this
factor, but usefulness will be significantly restricted if it does not measure *
 *up.
   3 Important. A system rating poorly in this area will still be useful but
its quality and ease of use will be somewhat restricted.
   2 Desirable. This area is one that should measure up but is less critical to
usefulness or usability.
   1 Nice. An area that is nice-to-have as a convenience for added utility or
ease of use, but is by no means a necessity in a fully usable system.



3.1   Categories and Weightings

Here are the nineteen categories and weightings which will be used throughout
our evaluations:


  1. Documentation, Weight 5.  A poorly documented system is nearly
     useless, whereas a system has often been chosen over another merely due
     to the quality of the documentation.

  2. Ease of Use, Weight 5. This is a catch-all category which takes into
     account the \feel" of the system to the author and the \comfortableness"
     of use of the system. \Uncomfortable" systems can be virtually useless.
     As this category is rather large, I'll be discussing various aspects of it*
 * as
     they arise.

  3. Parser, Weight 5. As the primary interface to the player of the game,
     the quality of the parser is critical. A system with a poor parser will be
     difficult for the author to work with but will annoy the player so quickly
     that the game will be rapidly set aside. Parser extensibility forms part of
     the overall parser quality rating as well.

  4. Support, Weight 4. How well is the system supported by the author of
     the system? How well maintained is the system? How quickly are bugs
     fixed or workarounds provided?  How much newsgroup support can you
     expect?  For the beginning author, especially, support can often be the
     crucial difference between a work that can achieve completion and one
     that is abandoned in frustration.



                                 4




 5. Language Depth, Weight 4. How extensive is the language in terms
    of functions, operators, constructs, etc.?  How good and useful are the
    default libraries? This rating is 4 rather than 5 as depth can be a mixed
    blessing. A language must have sufficient depth to be useful, and enough
    additional depth to be easy to use. However, great depth can come at the
    cost of complexity, ultimately reducing ease of use.

 6. Portability, Weight 4. Where will the final game run? On how many
    computer systems, of what size and expense? This is a perennial topic of
    debate on the newsgroup. It is clearly of major importance since a system
    producing games running on but few computers will not have much of an
    audience no matter how good it is.

 7. Run Speed, Weight 4. If the game runs slowly and ineffectively, the
    game playing audience, often a fickle and argumentative lot, will desert
    ship quickly.  Witness the discussion of The Legend Lives in mid-1995
    which unfortunately centered for a while not on a fine, artistic work, but
    on how much trouble it was to run on smaller computers or in certain
    computing environments.

 8. Literature Library, Weight 4. Most programmers learn by example.
    If a large library of source code is available, the system will be easier
    to learn and use.  Browsing source code to find the solution to a given
    implementation problem is usually efficient and time saving.

 9. Debugging Features, Weight 4.  What facilities are offered the au-
    thor cum programmer for locating and repairing the bugs that appear
    inevitably in any program longer than two lines?  Lack of a debugging
    facility can make the author's life miserable while a good set of tools can
    greatly shorten the production time for the piece.

10. Future Prospects, Weight 3. What is the outlook for further devel-
    opment of this language in the future? Is the author of the system still
    actively involved with it? How often do new releases come out, and how
    substantial are they? How quickly are bugs fixed? In short, is the language
    living, classical, or dead?

11. Object Orientation, Weight 3. How closely does the system follow an
    object-oriented paradigm? Object-orientation simplifies programming in
    a number of important ways. To rate highly, a system should approach a
    \pure" object-oriented paradigm (which I will not attempt to define).

12. Game Size, Weight 3. How large a game will the system produce? This
    factor might have rated higher except for the fact that most systems can
    produce a reasonable size game- of the kind that most authors have in
    fact produced. Very large games, requiring years of effort, appear much
    less often.



                                5




 13. Distribution Policy, Weight 3.  What sort of restrictions does the
     author of the language impose on distribution of games produced with this
     system? This category would rate higher if it were not for the fact that
     most distribution policies only concern outright commercial distribution.

 14. Programming Skill Required, Weight 3. I weight this as a middle of
     the road criterion since it is either quite important to you or it is not *
 *very
     important at all, depending on your programming skills and experience.
     For a neophyte programmer this could be a critical criterion, whereas for
     an experienced programmer, a more \advanced" language will present no
     barrier. Keep in mind that, despite some representations to the contrary,
     all of the systems require some programming skill (more on this later)
     although there are some marked variations.

 15. Cost, Weight 2. Except in extreme cases, shareware costs have surpris-
     ingly not been very much of an issue. For a few people, the free software
     philosophy has determined a final choice, but this is not generally the ca*
 *se.

 16. Source Code, Weight 2. Is source code for the system (as opposed to
     the libraries only) available? This is of direct importance only to dedica*
 *ted
     hackers or port maintainers. However this can be an indicator of the future
     viability of the system, and the ability of the system to be propagated to
     varied computer systems. Of interest here also is the availability of acti*
 *ve
     porters, which will determine how quickly new releases get propagated to
     the various computing platforms.

 17. Compiler Speed, Weight 2. A fast game compiler is nice, of course, but
     most authors say that it is not a determining factor. In fact, it could be
     perversely argued that a compiler that is too fast might tempt an author
     to write poorly designed code!

 18. Compiler Platforms, Weight 2.  The number of different computer
     systems on which the compiler will run, in contrast to the game itself, re-
     ceives a lot less attention but nevertheless is of interest to those prosp*
 *ective
     authors with lower-end computers.

 19. Dynamic Object Creation, Weight 1.  Perhaps this does not need
     a category of its own, but it has been often discussed as a convenience
     factor. A system will be a little more desirable if there is a means to cr*
 *eate
     and destroy objects during the course of the game, rather than only at
     compile time. One correspondent pointed out quite rightly, though, that
     this feature can be at odds with reliability and portability.


3.2   Rating the Systems by Category

Each authoring system to be studied will be assigned a rating for each category
in the evaluation criteria. I believe the traditional one to ten rating scale w*
 *ill



                                 6




yield an implied precision of rating which is misleading, so I have again chosen
a one to five rating scale with the following meanings.
   5 Superb. A rating at this level means that the authoring system, in this
category, is a sparkling jewel. Although still perhaps capable of improvement
(for perfection is seldom achieved) the rating implies clear and obvious excel-
lence.
   4 Very Good. If not a sparkling jewel, certainly a gold coin. The system
stacks up very well in this category and leaves no gaps.
   3 Good Enough. A well-circulated silver coin. While adequate overall in
this category, there may be some non-fatal gaps or shortfalls which reduce the
luster even while the coin remains of reasonable value. A definite middle of the
road rating.
   2 Needs Work. You can still spend this coin but merchants will give you
odd looks. There are serious gaps or shortfalls in this category which merit a
decidedly lower rating.
   1 Horrid.  No one will accept this coin in trade.  The deficiencies in this
category are fatal. Should such a rating occur in a highly weighted evaluation
category, the system will be rendered virtually useless.



4   The Tiers of Authoring Systems


4.1   The Tiers Defined

Following a model used by some rather expensive and high-powered US-based
computer industry analysts, and in informal collaboration with Jools Arnold
to keep to a consistent categorization, I divide IF authoring systems into three
tiers and one additional non-tier.
   The first tier is that of world class contender.  The very few entries in
this tier are at a stage of development that clearly puts them in a rather elite
category of their own.
   The second tier is composed of a relatively larger number of systems which
may be categorized as a strong candidate. Authoring systems in this category
might be up-and-coming entries with a great deal of promise; a system which
was once very popular but has faded for various reasons; or a system of high
quality but a lesser following for a variety of reasons.
   The third tier is composed of a collection of also-rans. These systems are
categorized as such because they may be very old and outdated; they may be
experimental and undeveloped; or, quite bluntly, they may be just plain inferior
or non-functional.
   The non-tier is the unprocessed tier and is made up of relatively new
systems for which sufficient time and experience has not accumulated to assign
it to one of the three regular tiers. It is expected that an entry will move fr*
 *om
here to the second tier if enough interest in the system arises, and the author



                                 7




continues to develop it. (Direct entry into the first tier would be most unlike*
 *ly.)
The system might drop into the third tier if it is largely ignored or if the au*
 *thor
does not develop it very far.
   Entries in the first tier will receive the most detailed study; entries in t*
 *he sec-
ond and unprocessed tiers will receive complete but less detailed treatment; and
entries in the third tier will receive only representative or cursory evaluatio*
 *ns.



4.2   The Population of the Tiers

The first tier members are Inform and TADS (the Text Adventure Develop-
ment System).
   The second tier members are ALAN, Hugo, and AGT (the Adventure
Game Toolkit).
   Unprocessed tier entries are Archetype and GINAS. Rexx Adventure
would also go in this category, but I am unable to review it at this time as I
don't have an OS/2 system.
   In the third tier are OASYS, LADS, Gamescape, ADL, Aventuro,
AdvSys, and a host of others too numerous to remember. LADS, Gamescape,
GINAS, and Aventuro will be reviewed here. OASYS, ADL, and AdvSys will
be reviewed in a future edition of this FAQ; I've simply run out of time in this
first edition.
   Graphics-oriented systems such as GTAC, DC and others are not included
in either the tier groupings or the study itself.



5   The Systems Examined


What follows is a necessarily lengthy discourse, taken authoring system by au-
thoring system, which includes a summary description of the system (at times
borrowed shamelessly but with permission from Jools Arnold's Rec.Arts.Int-
Fiction FAQ) and a rating with explanation in each rating category. Finally,
salient or unique features and limitations of the system are described. In only*
 * a
few instances are projected future developments discussed; I made an arbitrary
policy decision in this FAQ to only deal with what exists today.
   The impatient might wish to page to the very end where you will find that a
table is given which cross-references ratings by category and authoring system.



5.1   TADS| Text Adventure Development System

Release discussed: 2.2.0.5
Author contact information: Mike Roberts 73737.417@compuserve.com
   Description. TADS, the Text Adventure Development System, is the cre-
ation of Mike Roberts, and has been in existence and has evolved over a period



                                 8




of several years. TADS is an object-oriented system which has a programming
\feel" similar to a Pascal/C hybrid.
   TADS is indeed a very powerful system, and some very large works have been
published or are in progress with TADS. TADS is shareware; the full package,
minus printed documentation and debugger are available from the archive site
and the other usual places. If you ultimately choose to work with TADS, you
should register. No doubt about it.
   TADS is rich in feature and function, with a good basic library and a comples
\alternative" library, called WorldClass, also available. Little has been left *
 *out
of TADS: there is the equivalent of associative arrays, list-tearing functions,*
 * a
complete operator set, and much more than can be described here.
   Ratings. Ratings by category for this system are:

  1. Documentation, Weight 5. Rating: 4. The TADS manual supplied
     to registered users is uniformly considered to be a superb piece of work,
     with few deficiencies and very high utility.  (The TADS documentation
     supplied with the shareware version is barely adequate to evaluate the
     product; however, this documentation is not the subject of the present
     rating.)

     TADS has gone through several updates since the hard-copy registered
     TADS manual has been produced.  The updates have been substantial
     and far-reaching, making the product a ground-breaking leader on several
     fronts. Supplementary documentation has been included with each revi-
     sion in the form of text files accompanying the release. This documenta-
     tion has been of good quality, but the net result is that the documentation
     has become disjointed and scattered among the hard-copy manual and the
     text files.

     I understand the expense and difficulty in reissuing the hard-copy manual;
     at the heart of the matter lies the fact that the hard-copy manual is the
     major registration incentive.  But this does not make the difficulties go
     away.

     At the more fundamental levels, the existing manual will more than suffice,
     and the prospective author will get a good head start by studying this
     clearly-written and extraordinarily helpful work. It is when you want to
     access the newer, more sophisticated and original features of TADS that
     you wish for unified documentation.

     I cannot offer an easy solution. Perhaps at some point Mike Roberts, the
     creator of TADS, might wish to update the manual and offer it to existing
     registered users for a reasonable price (as he has done with supplementary
     documentation in the past). I'd suggest that release 3 of TADS, whenever
     that might come, might be a good point to do this.

     Additionally, I do not feel the TADS documentation will \work" for a neo-
     phyte programmer. Of course, I do not believe TADS is for the neophyte



                                 9




   in any case; see my comments in the appropriate ratings section.

   One other slight personal issue I have with TADS documentation is that
   you can't keep it all on-line. I often like to have my source code in one
   editor window and the manual in another; you simply can't do this with
   something available only in hard-copy.

2. Ease of Use, Weight 5.  Rating:  4.  I must qualify this rating by
   stating that, with sufficient study, ease of use of TADS is quite good. It
   is not reasonable to expect a powerful and complex system such as this to
   be easy to use without doing your homework first.

   There are some peculiarities in TADS that frustrate the newcomer but
   become second nature with experience. TADS has, and indeeds requires, a
   plethora of verification methods which are applied when a verb is combined
   with a direct and/or indirect object. For instance, \attack monster with
   sword" requires that the nouns \monster" and \sword" have methods
   defined which specifically allow (or disallow) usage in the combination
   described with the verb \attack."

   Such peculiarities aside, the clean object-oriented structure of a TADS
   program enhances ease of use to a very great extent. Even fairly complex
   objects and actions can be defined quite quickly and readily by someone
   with a little TADS experience. Objects lend themselves readily to reuse,
   even from program to program, and indeed a collection of such reusable,
   and useful, objects can be found at the interactive fiction archive site.

   TADS is enough like and not like Pascal, and like and not like C, to be a
   bit confusing at the start. Although the most recent version allows for a
   more strictly C-like syntax, the beginner is best advised to work through
   the initial confusion.  It doesn't take long to get comfortable with this
   language.

3. Parser, Weight 5.  Rating:  4. The parser is built-in and very good,
   understanding a wide variety of constructs and long sentences. Multiple
   objects, pronoun antecedents, indirect objects, varied word order, com-
   pound sentences, and much more, are easily interpreted by the parser.
   A number of methods and functions are present by which default parser
   behavior can be modified or overridden, including one routine that allows
   you to fully substitute for the parser should you so wish (this should be
   pretty rare).

   The down-side of the parser is that it is built into the source code, not
   the libraries; and further, with source code not generally available, you're
   going to have to live with the parser and ancillary functions as-is. Some
   authors, particularly those wishing to write in languages other than En-
   glish, have stated that this is a problem to varying degrees.  For most
   authors, and particularly for the prospective new author, this should be a



                              10




   minor concern until a very advanced level is reached| or unless you are
   not writing in English, in which case the issue is a little more serious (but
   hardly fatal).

4. Support, Weight 4.  Rating: 5. Support for TADS can be obtained
   in three ways: from the author by e-mail; via the newsgroup; or via the
   TADS support BBS in California. E-mail support has been reported to be
   a little spotty due to Mike Roberts' busy schedule. The support BBS has
   been successful for the relatively few that have used it, although there are
   some problems here- you can't call at rates higher than 2400 bps, and it's
   a long distance or international call for most people. News group support,
   however, is really good, as there is enough developed TADS expertise
   among people willing to help out that a good source of advice is readily
   available.

   Discussion of TADS in recent months has been significantly less than dis-
   cussion of Inform. Whatever may be the reasons, this does not imply a
   decline in the fortunes of TADS. In fact, the 1995 IF contest drew as many
   TADS entries as Inform entries. TADS expertise, at a high level, remains
   readily available on the newsgroup.

5. Language Depth, Weight 4. Rating: 5. Language depth is extraor-
   dinary.  About the only thing that seems to be missing is floating-point
   numbers, and these are likely to be of limited utility in an IF piece (suit-
   able workarounds are usually at hand).  TADS functions for string and
   text processing are very complete, perhaps approaching the completeness
   of the Perl language. Array and list manipulation is provided. Available
   function calls cover just about everything you might need, from determin-
   ing if an object has a particular property to changing the default behavior
   of the parser.  TADS has a large number of functions which deal with
   direct and indirect objects in a sentence. These are a mixed blessing, as
   will be discussed later.

   Again, with language depth comes inevitable complexity. Having all these
   features available means, if you wish to use them, having to learn how to
   do so. Yet, the features are layered well enough that for the most part,
   the prospective author can learn them one at a time, as they are needed.

   One thing that sets TADS apart from the other systems is that there is a
   choice of \standard" libraries. The libraries supplied with TADS are gen-
   erally considered to be quite good, reasonably adaptive and flexible, and
   in any case can have components easily substituted or modified. However,
   an alternative set of libraries exists, called WorldClass.  These libraries,
   written by Dave Baggett, are very complex and extensive, providing for
   improved environment modeling and character interaction.  It is an un-
   derstatement to say that these libraries require some study; and, since



                              11




   they are very large, they do significantly impact both the run-time perfor-
   mance and the run-time portability of the completed game. Nonetheless,
   a master-work such as The Legend Lives would have been somewhat more
   difficult to produce without these powerful but demanding alternative li-
   braries.

6. Portability, Weight 4.  Rating:  4. TADS runtimes for a number of
   Unix systems, the Mac, and the PC are all up-to-date. Support for the
   Amiga has lagged, and has not been present for other systems.

   In the old days of the pure \TADS vs. Inform" debates, TADS was down-
   rated by some newsgroup correspondents because it would not run on
   some of the less common computer systems, which, despite having small
   market share, still represented a substantial number of potential players.
   I think this case was overstated, but nevertheless I rate TADS as 4 for
   portability rather than 5 because other major systems do support more
   platforms. However, we really must remember that a TADS game can be
   played by a good 98 or 99 percent of the computing public, should they
   have an interest.

7. Run Speed, Weight 4.  Rating:  3.  TADS run-time speed is fine
   for smaller games built with the standard libraries, on most \reasonable"
   computing platforms.  Noticeable problems result, however, with larger
   games, especially games built with the \World Class" libraries (although
   this latter comment is based only on the single example available). Large
   libraries provide large object sets and vocabularies, and while these add
   immeasurably to the depth of the system it is not without a price. Some
   players using lower-end machines have called large games \unplayable" or
   \unbearably slow." I think these criticisms are too extreme and perhaps
   reflect a tendency toward impatient play rather than measured enjoyment
   of an IF work. Nevertheless, there is some truth here. The TADS run-time
   on larger works is very clearly the slowest in its class.

8. Literature Library, Weight 4. Rating: 5. Extensive literature exists
   in TADS (there is a separate document detailing this which appears on
   the newsgroup from time to time). Much literature is available in source
   code format, ranging from Colossal Cave to Legend itself. There is enough
   for the prospective author to be able to find an example for just about
   any sort of programming construct or problem. TADS' strong literature
   library is a very important distinguishing factor.

9. Debugging Features, Weight 4. Rating: 4. The TADS source level
   debugger, supplied with the registered version to PC and MAC users,
   is everything you would expect of a debugger.  Breakpoints, conditional
   breakpoints, expression evaluation, variable modification, branching, etc.,
   are all supported smoothly.



                              12




    The rating would be even higher were it not for two problems which are
    more logistical than technical.  The debugger is not available for other
    platforms (less serious point), but apparently has not been kept up to
    date for the major platforms (serious indeed).

    For registered users, picking up a new debugger version (which must match
    the compiler version) has been a matter of a long-distance call to the TADS
    support BBS, Hi-Energy BBS, in California.  In recent times however,
    more current versions of the system have been placed on the Internet and
    the BBS lagged. I still do not have a debugger for TADS 2.2.0.5, which is
    the latest release.

    Perhaps a better method of updating and distribution can be worked out.
    This is the only real flaw in the debugger, and it has nothing to do with
    its utility or technical merits.

10. Future Prospects, Weight 3. Rating: 3. I am sure to get criticism
    about this relatively low rating for TADS future prospects. While TADS
    is very much alive, very viable, widely used, and well supported, new
    releases have become more and more infrequent. This, I am sure, has to
    do with Mike Robert's busy schedule more than with any lack of interest
    on his part.  Yet, this, coupled with the general unavailability of source
    code, lead me to the conclusion that future developments could be limited.
    Mike has projected some features for an eventual 2.3 release, but there is
    no release date and no one really expects to see it soon.

11. Object Orientation, Weight 3.  Rating:  5.  Object orientation in
    TADS is as \pure" as one might like (although you can quibble about
    things like classes and instantiation of a class object being equivalent).
    TADS supports class definitions, multiple inheritance, overriding, encap-
    sulation of data, messaging in a very general sense, and all the regalia of
    object orientation.

    Reduced to practical terms, this makes TADS very well suited to the
    purpose at hand, very much easier to work with, and very much more
    logical in structure.  Mike Roberts deserves the highest praise for the
    quality of this implementation.

    TADS was, a few years ago, my first experience with object-oriented pro-
    gramming. Predictably, it was a little frustrating until I got the hang of
    it| more than once I wished for my old, procedural systems| but in the
    end, I found myself wondering what the problem really was, and why on
    earth would anyone ever want to do it the old way any longer?

    For the prospective new author, there will likely be some learning neces-
    sary here, but it will stand one in good stead for a very long time.

12. Game Size, Weight 3.  Rating:  4.  TADS can produce very large
    works, yet I rate this category just below top level because the large works



                               13




    carry along significant portability problems which are just now being par-
    tially solved.

    The Legend Lives when it was released was the largest TADS work ever. It
    used the special WorldClass libraries and, on the PC platform, depended
    on a protected-mode version of the runtime in order to be usable. This
    runtime was plagued with so many compatibility problems that newsgroup
    discussion of Legend centered (most unfortunately) on problems with run-
    ning the game rather than with the quality of the game itself.

    It can be argued rightly that DOS compatibility problems are the fault
    of DOS, Windows, the myriad incompatible memory management sys-
    tems used to get around the DOS memory usage limitations, and all those
    problems with which PC users are all too familiar. Nonetheless, the PC
    represents probably 90 percent of the playing platforms, and the IF run-
    time system simply must deal with this.

    A more stable version of the runtime has been released but will not run
    on sub-386 PC models.

    So, TADS can produce very large games, but there will be issues to con-
    sider.

    Of course, as a practical matter, it is still possible to write a large game
    (as opposed to an enormous one) within the limitations of the \standard"
    TADS runtime environment, and this will meet the needs of most authors
    very readily.

13. Distribution Policy, Weight 3. Rating: 4. The TADS license allows
    unrestricted shareware distribution of any TADS game, which will cover
    the needs of the majority of authors. Commercial distribution requires a
    separate arrangement with TADS creator Mike Roberts, which I am told
    is generally quite easy to arrange.

14. Programming Skill Required, Weight 3.  Rating:  3.  Assigning
    this rating is an attempt to reflect the reality of TADS measured against
    its purpose and intent.  TADS does not claim to be intended for novice
    programmers, although I think the documentation understates the amount
    of knowledge necessary. (Professionals in this field, including myself, tend
    to assume that non-professionals are a lot more advanced than is really
    the case.)  But TADS does not claim to be a simple or unsophisticated
    system, and indeed it is not. Quite the opposite is true. TADS is a state-
    of-the-art, Tier 1 system, and this imposes some definite requirements on
    the prospective user.

    I do not believe that a non-programmer can be very successful very quickly
    with TADS. It is not out of the question for TADS to be someone's \first"



                               14




    language; but in that event, the documentation won't do. The documen-
    tation implies a certain level of programming knowledge which is quite a
    bit beyond beginner level.

    I don't rate TADS \4" on programming knowledge required because of its
    complexity for a beginner. Neither do I rate it \2" because a sophisticated
    language of this type cannot be expected to be elementary and easy.

    The prospective TADS user had better bring to the party an intermediate
    knowledge of C or Pascal (not Basic, thank you). Guru-level knowledge
    isn't required, but familiarity with programming concepts and more than
    a little experience using them is highly recommended.

15. Cost, Weight 2.  Rating:  4.  I must admit that in assigning this
    rating I'm making an implicit judgment of price vs.  value.  TADS is
    not free, it is shareware, and the registration is currently US $40.00 plus
    some shipping charges. For this you receive the excellent but somewhat
    out-of-date printed TADS manual, and some extra utilities including a
    source-level debugger, if you are a PC or MAC user.  Nearly everyone
    agrees that the $40.00 asking price for TADS is more than fair, and that
    Mike Roberts treats customers well and fairly. There are a few people to
    whom cost is a major factor, whether on philosophical or \impoverished
    student" grounds, but for most the cost of TADS is a non-issue.

16. Source Code, Weight 2. Rating: 2. Source code for TADS is avail-
    able only upon acceptance by Mike Roberts of your signed non-disclosure
    agreement, and Mike understandably limits distribution of the source.
    Source code, for the majority of authors, can be said to not be available.

17. Compiler Speed, Weight 2. Rating: 5. I did a series of benchmarks a
    while back, comparing TADS and Inform for compilation speed on a num-
    ber of hardware and operating system configurations. TADS compilation
    was extremely fast even on slower systems, and nearly instantaneous on
    new, fast systems.  (The test case was the ubiquitous port of Colossal
    Cave.)  The compile speed on my Pentium 133 running Linux is liter-
    ally breath-taking.  DOS compile speed is about twice as slow but still
    blazingly quick.

    (When I first published these results, I received a number of \so what"
    responses| the point being that run-time speed was far more important
    than compile speed. True enough; yet, I find a lot of advantage in being
    able to compile quickly and quickly eliminate syntax errors and the like.
    Of course, there can then be the afore-mentioned temptation to write
    sloppily: :):

18. Compiler Platforms, Weight 2. Rating: 4. I rate this 4 instead of
    3 because most of the \world" is covered with DOS and MAC compilers



                               15




     readily available (and Linux and Sun as well). I recognize the frustration
     of Amiga users, whose versions have lagged; and I know there are other
     systems which are not covered. But the mainstream is well supported at
     this point.

 19. Dynamic Object Creation, Weight 1. Rating: 5. Recent develop-
     ments within TADS have made dynamic object creation and destruction,
     name-changing, etc., very easy to accomplish.  Distinguishing between
     identical objects (lottery tickets, mailboxes, etc.) is also done quite re*
 *ad-
     ily.


   Summary Comment.  TADS is mature, quite bug free, stable, and has
been in use for some time.  Support is excellent, documentation is good, and
the language is powerful and highly object-oriented. TADS demands study and
some patience in order to unleash its inherent potential. This patience will be
well rewarded. The prospective serious IF author will not go wrong with TADS.
Not at all.



5.2   Inform

Release discussed: 5.5
Author contact information: Graham Nelson, nelson@vax.ox.ac.uk
   Description.  Inform is an interesting creation, in every imaginable way,
and arose from a unique concept: Graham Nelson's inspired idea of creating a
compiler that would produce Infocom format story files, in a sense calling upon
and reviving the greatness of the Infocom era. Along the way, Graham developed
Inform to the point at which it is clearly in the premier tier of interactive f*
 *iction
authoring systems.
   Inform's heritage delineates Inform's peculiarities and strengths at the same
time.  The Infocom story file format imposes limitations; it also ensures high
portability and a well-understood run-time environment.
   Inform has recently been used to produce works such as Jigsaw, which lead
IF in new directions and set new standards. Inform, in a rather short time, has
evolved from curiosity to a preeminence shared only with TADS.
   Inform is not especially like Pascal or C, although probably closer to C than
to anything else. It is an object-oriented like language, in that building bloc*
 *ks
make up the structure of an Inform program; yet it is not \pure" in the way
TADS is. Inform, while it has its own peculiarities, has its own elegance as we*
 *ll.


  1. Documentation, Weight 5.  Rating:  4.  The Inform documenta-
     tion has been the subject of recent newsgroup controversy. Graham has
     published three documents: The Inform Designer's Guide, The Techni-
     cal Manual and Z-Machine Specification, and The Craft of the Adventure.



                                16




   The Designer's Guide is the programming manual for the system.  Eso-
   terica are covered in the Technical Manual, while Craft of the Adventure
   deals with authorship and stylistic matters.

   The second edition of the Designer's Guide is up-to-date with the current
   release of Inform, 5.5.  The Guide is over 200 pages in length, with ex-
   tensive discussion, examples, and exercises, with a good index. Nearly all
   of the omissions of the first edition have been cleared up and the Guide
   as it stands is complete and highly useful.  It is available in all sorts of
   electronic formats, from an ASCII version suitable for on-line use, to a
   TEXversion which formats elegantly.

   The Designer's Guide reflects Graham's eclectic tastes as well as his phe-
   nomenal literary knowledge and depth.  As such, it is very much to the
   liking of some and less to the liking of others, on stylistic grounds.  On
   technical grounds, some feel it is not as \beginner-friendly" as the printed
   TADS manual, and have criticized the exercises as being too difficult and
   requiring knowledge beyond the level the reader is likely to have reached
   at a given point.

   Although I cannot be fully unbiased, having lived with Inform for a long
   time at an intimate level as the maintainer of the DOS ports of the com-
   piler, I feel the criticisms are largely unwarranted.  Separately written
   Inform tutorials are available, and the manual does not in fact purport to
   be a tutorial for beginners (as indeed, it is not). The manual is complete,
   well-written, and filled with useful examples. It is an indispensable refer-
   ence guide which seldom fails the user who has gotten beyond the stage
   of rank beginner. And, for the beginner, a separately written hyper-text
   tutorial of high quality is readily available.

   The Technical Manual will be needed by those few who want or need to
   do assembly-language Z-machine coding, or who are simply curious about
   the internals.  The run time format is well documented and a wealth of
   detailed information is at hand.

   The Craft of the Adventure is well-done and should be read by any
   prospective author regardless of the authoring system finally chosen. The
   paper gives some very good hints, suggestions, and ideas which are highly
   worthy of consideration.

2. Ease of Use, Weight 5.  Rating:  4.  Every language has its pecu-
   liarities, and Inform is no exception. Coding is quite clean and modular,
   with each object (be it location, actor, or material object) having its own
   logically-arranged block of code.  Syntactical peculiarities creep in with
   the need to distinguish between \description" and \describe" and \name"
   and \parse_name", and various conventions about printing strings, return
   values, and other exotica.



                              17




   Verbs are applied to nouns within the block referenced by the noun, similar
   to TADS. Instead of verification and action methods, Inform uses \before"
   and \after" methods, as well as an easy to use grammar table. Objects are
   easily reused; and the coding structure of even disparate objects is enough
   alike to make programming go a lot faster than it would otherwise.

   It is my feeling, not backed by analytical evidence, that the neophyte
   will get more done at an earlier stage with Inform than with TADS; and
   at a later stage, when the language is learned well, there is little differ-
   ence although TADS might have a small edge.  This is not to say (like
   TADS) that Inform is a language for a neophyte. Again, with a powerful,
   broadly-applicable system such as Inform, it is only reasonable to expect
   the prospective author to spend time up front working with the language
   and learning to understand and leverage its many features.

3. Parser, Weight 5.  Rating:  5.  The parser is as good as they come,
   dealing well with compound sentences, antecedents, resolution of ambigui-
   ties and the normal range of parser problems and issues. In these respects
   it is the equal of the excellent TADS parser. The advantage of the Inform
   parser, though, is ease of modification and adaption, since it is largely
   contained in the libraries rather than in the program (as indeed, given the
   nature of the Z-machine, must be the case). Ease of parser modification
   comes up frequently in newsgroup discussions; surprising as this might
   seem to the beginning author, at a rather advanced level, this becomes an
   issue. It is also an issue, as noted once before, to writers wishing to crea*
 *te
   IF in a non-English language. (Off-the-wall irrelevant comment: some day
   I would love to see a parser for Tagalog. With its extensive use of passive
   voice constructions, it would be a challenge. Although, the Inform parser
   already has been translated into Spanish: :):

4. Support, Weight 4.  Rating:  5. Support for Inform is readily avail-
   able on the newsgroup, and Graham, the author, is quite responsive to
   compiler-related questions, although he evidently receives all too much
   e-mail and should not be bothered unless there is no other alternative.
   Newsgroup support is generally very fast and of high quality. There are a
   few really high-level Inform experts who seem able and willing to respond
   to all sorts of enquiries about Inform programming.

   The various ports of Inform seem well-supported also. I jealously protect
   the integrity of the PC ports, and this approach is shared by the other
   porters as well| in fact, the Mac porter, Robert Pelak, is continuously
   enhancing the interface.

5. Language Depth, Weight 4.  Rating:  5.  Language depth is very
   great, nearly as great as TADS; and in fact it is possible to do just about
   anything in Inform that can be done in TADS, and in some cases a few



                              18




   different things, which amounts to a lot of power. Inform offers a good set
   of operators, a library which provides a good set of objects and functions,
   and some unique and powerful features such as \scoping" rules. Scoping
   rules are a powerful and flexible means of determining when an object is
   in-view, \takeable", etc. (A significant part of the TADS \World Class"
   libraries deal with issues that amount to scoping questions.) Inform also
   allows for objects that span multiple locations, a useful feature for imple-
   menting something like carpet, grass, or snow.

   Although this is perhaps more of an ease-of-use issue, I do feel that the
   advanced features of Inform are a bit less integrated than they are in
   TADS. Inform features have a layered feeling; they have been built-up as
   the language and especially the library have grown. You would expect this
   to be the case; we are dealing with the Z-machine and this imposes many
   restrictions. TADS is able to implement a lot more in the compiler and
   in the run-time, giving a better feeling of integration.  (This is a mixed
   blessing, in that you can't directly alter the TADS compiler or run-time
   behavior.)

   For instance, a limitation in Inform is on attributes and properties of an
   object.  These attributes are a predefined set (the library leaves 11 of
   them free); and private global variables for an object are not available
   (you must use public properties). In TADS there are no restrictions. The
   Inform limitations arise mostly from the Z-machine, and largely cannot
   be avoided. An Inform author will often find the need to use a particular
   named attribute for some unrelated purpose; attributes may be reused
   and change their meaning; and all of this leads to the need to take extra
   care in coding.

   But to return to the main point: the power of Inform is in the libraries,
   and the standard libraries are very powerful indeed.

6. Portability, Weight 4.  Rating:  5. Inform games run on more plat-
   forms than any other system, period.  The run-time, unlike the other
   systems, is not part of the Inform package.  Various Infocom story-file
   interpreters are freely available and freely distributable. On the PC and
   Unix platforms, JZIP (John Holder's modification of Mark Howell's ZIP)
   is one of the best, and Frotz is a promising new entry in this field. Sim-
   ilar quality implementations exist for many other platforms, including
   some palmtops! It is safe to say that an Inform game is playable nearly
   anywhere: :w:ith one caveat.

   The new Z8 format Inform games, which allow for really large works such
   as Jigsaw, use a story file which can be as large as 512k. This, combined
   with the memory needs of the interpreter, can impose limitations on some
   machines, notably low-end PCs, with not enough available free memory.



                              19




    However, any of the other formats, such as the common Z5, which still
    allows for a very large game, will run virtually anywhere.

 7. Run Speed, Weight 4. Rating: 4. It is difficult to come up with an
    objective benchmark for interpreter run-time speed, and, with the vari-
    ety of story file interpreters available, results are highly dependent upon
    individual environments. In addition, I have received quite contradictory
    reports from newsgroup correspondents.

    That said, my subjective impression has always been that Inform games
    run faster than TADS games, and I think measurement would bear this
    out. I think this has to do with the way TADS matches verbs to objects,
    but I invite commentary on this from the individual system experts.

    In any event, Inform games, even very large ones, have very good run-time
    performance on interpreters such as ZIP and JZIP.

 8. Literature Library, Weight 4.  Rating:  4.  The Inform literature
    library has developed significantly in the past years.  While the library
    of source code does not equal that for TADS, it is still large enough to
    provide numerous examples of how things are done. The de rigeur port
    of Colossal Cave is available, and smaller examples such as Toyshop and
    Balances were written to illustrate specific Inform features.

    The Inform literature library lacks large source code examples equal to
    Legend and such examples are unlikely to be forthcoming (although Gra-
    ham Nelson is contemplating future release of the source to Curses).
    Nonetheless, there is more than enough presently available to be of great
    utility.

 9. Debugging Features, Weight 4. Rating: 3. Inform has a few built-in
    debugging features, but they are not especially convenient and often more
    oriented toward debugging the compiler rather than debugging the game.
    The archive site has some \wizard" routines which help in debugging, and
    some of the interpreters have useful debugging features, such as watching
    the movement of objects.

    A source level debugger called \Infix" has been on the horizon for quite
    some time, and indeed, support for Infix debugging is built in to the Inform
    compiler. I have no further information about Infix, however.

10. Future Prospects, Weight 3.  Rating:  5.  Inform releases are rea-
    sonably frequent (from my alternate viewpoint as a port maintainer, less
    is better!) and generally of significant content. Graham Nelson retains a
    strong interest in his product. Version 6 is on the horizon as of this writ-
    ing. All of this and the availability of all source code means that future
    prospects for Inform are very good indeed.



                               20




11. Object Orientation, Weight 3.  Rating:  4.  Inform calls itself an
    object-oriented language, and indeed it meets a loose definition of object-
    orientation. It is possible to define classes; multiple inheritance exists,*
 * as
    does overriding and a rather limited amount of data encapsulation (lim-
    ited by the fixed property and attribute arrangement of the Z-machine).
    Methods can be arbitrarily complex and can be deployed in the expected
    places. Cross-calling methods from other objects can be done indirectly,
    although this is somethimes a nuisance.

    All of this lends Inform an object-oriented feel, as opposed to the more
    \strict" definition of object-orientation followed by TADS. I'd make a
    analogy here with the differences between C++ and Smalltalk.  But for
    the author, the main features and advantages of object-orientation are
    fully available.

12. Game Size, Weight 3. Rating: 4. I'm rating this the same as TADS
    for different reasons. Recall that TADS can produce extremely large games
    at the expense of some run-time compatibility.  Games produced by In-
    form probably cannot be as large as TADS games, yet they can be very,
    very large indeed in the Z8 format, and quite large enough in the Z5
    format.  The Z8 format also sacrifices some run-time compatibility (but
    considerably less so than TADS).

    What does this mean? Although I can't see a rating of \5" here for any
    system, until very large games are produced without impacting the run-
    time compatibility of a lot of platforms, still, the prospective author is *
 *not
    going to run into very many limitations here. A game such as Legend or
    Jigsaw can take years to produce. Most efforts won't push the limits of
    Inform's Z5 format, let alone require or be constrained by the Z8 format.

13. Distribution Policy, Weight 3.  Rating:  5.  Graham permits un-
    restricted freeware, shareware, or commercial distribution of games pro-
    duced with Inform, asking only that a credit line appear in the game
    titles.  Since free runtimes of high quality are available, distribution of
    Inform games is virtually without limitation.

14. Programming Skill Required, Weight 3. Rating: 3. As is the case
    with TADS, Inform is not the place to begin to learn how to program (al-
    though there are those few who have actually done just that). Familiarity
    with C would be extremely helpful; a background in Pascal would be the
    next best thing.

    The Inform manuals are not written at the beginning programmer level,
    either, instead implicitly contemplating a good familiarity with the basic
    concepts and constructs of a C-like language.

    Should the prospective new author without programming experience turn
    away from Inform (or TADS for that matter)? Not if the author is willing



                               21




    to take the time to become a reasonably good programmer. (If this is not
    the case, ALAN is an easier starting language.) Inform makes demands
    upon the author, as a powerful system will. Yet, once the learning curve
    is traversed, the rewards become well worth the effort. Inform is not easy;
    neither is TADS, C++, Smalltalk, playing the violin, or reading Aramaic.
    There is no free lunch or free ride; you have to put in your time up front.

15. Cost, Weight 2. Rating: 5. Inform is genuinely free.

16. Source Code, Weight 2.  Rating:  4.  All source code for Inform is
    readily available for every platform on which it runs (actually contained
    in a single version with multiple #ifdefs.) The code compiles on a wide
    variety of C compilers, from the humble Quick C to the powerful GNU
    gcc. However, I rate this category as 4 instead of 5 because possession of
    the source code does not mean you are likely to do a lot with it. I have
    spent a lot of time digging in this code, as the \generic" DOS port was
    at first pretty difficult; and I can say with complete assurance that the
    code is not to be trifled with. (This should not be surprising. Complex
    programs are often made up of complex code.)

17. Compiler Speed, Weight 2.  Rating:  3.  Inform compile times are
    noticeably slower than compile times for other authoring systems; previous
    informal benchmarks showed them to be consistently about twice that of
    TADS. I have not determined a reason for this.

    How serious an issue is this? On a slower platform, using the \generic"
    non-386 PC port of Inform, it could become an annoyance in developing
    a large game. Colossal Cave required five minutes or so to compile on my
    old (now gone) 186 portable.  The same thing, of course, compiles in a
    couple of seconds on my Pentium 133 running Linux, so it's all relative.
    You will have to weigh the contemplated size of your game, your develop-
    ment platform, and your operating system and determine for yourself how
    important this may be. But on a \reasonable" modern machine, compila-
    tion in five seconds compared with compilation in ten seconds is not really
    an important matter.

    Again taking a reverse view, you might argue that slow compilation en-
    courages you to code more carefully in the first place. You decide.

18. Compiler Platforms, Weight 2. Rating: 4. Inform has been ported
    to most all the popular platforms, and with availability of source code
    that is now rather clean, further ports should be no problem. Unix ports
    are trivial; the only platform with a doubtful future is the sub-386 PC
    platform. This port has been really difficult to keep up, and when Inform
    moved from release 5.4 to release 5.5, the libraries and code grew to a poi*
 *nt
    at which the amount of free memory required crossed my \threshold" value



                               22




     of 580k. Much beyond this point, we're starting to talk about special boot
     configurations and a fair amount of hassle to compile even small games.

     I thought this was unimportant| who is still depending on a sub-386
     PC?| and found that there are more prospective authors than I had
     expected who are using older equipment.  So, for this reason, I assign a
     rating below the top level.

 19. Dynamic Object Creation, Weight 1.  Rating:  3.  Well, it's not
     that you can really do dynamic object creation in Inform| but you can
     effectively fake it if you get deep enough into the advanced coding facili*
 *ties
     of the language. But much more importantly, you can easily distinguish
     between many examples of a like object, such as snowflakes.  So I'll go
     with a middle rating here.


   Summary Comment.  Inform has come a very long way and is solidly
in the top tier of today's interactive fiction authoring systems. It has its own
individual programming feel which is different from many other systems.  It
has an excellent library and a good set of facilities.  Support is easily found
and of top quality. While it still reflects limitations imposed by the Z-machine
structure, it goes well beyond anything Infocom ever had for their own use. I
think those folks would be pretty surprised at just how much Graham has done
with their original ideas.
   So, TADS or Inform? My answer is, of course, simply, \yes."



5.3   ALAN

Release discussed: 2.6
Author contact information: Thomas Nilsson, thoni@softlab.se
   Description. I like ALAN (Adventure LANguage) a great deal. I've done
some programming with it, and it is smooth. I admit I am biased, but I think
for an author who is not a somewhat skilled programmer, ALAN is a fine choice,
probably the best choice.
   ALAN has a syntax which is very much declarative English (or Swedish) in
format.  There is an object/block structure which is easy to understand, and
coding within each block is mostly uncomplicated. The ALAN runtime is pretty
robust and not prone to mysterious crashes. Indeed, the authors describe ALAN
as a \safe" language.


  1. Documentation, Weight 5. Rating: 4. ALAN documentation is not
     as extensive as TADS or Inform documentation, but it's nice, complete,
     and quite suitable for a beginner. It is available in text form suitable f*
 *or
     on-line usage, or in Postscript form which makes a very elegant printed
     manual if you can print Postscript. (And, the manual now prints properly
     on American \letter" paper as well as on European \A4" paper.)  The



                                23




   manual includes a brief but highly focused introduction to the art of writ-
   ing a text adventure game. Every prospective author should read this as
   well as Graham Nelson's Craft of the Adventure.

   The documentation could use more examples and sample code, however;
   and I did not find the BNF expression of ALAN syntax to be especially
   helpful (although perhaps this is due to my own ignorance).  But as an
   example of readable, quality documentation, the ALAN manual is very
   good.  I also congratulate the authors on their mastery of English, in
   their having produced something of a literary quality the typical native-
   speaking American couldn't come up with in a lifetime.

2. Ease of Use, Weight 5.  Rating:  4. Let's be certain we understand
   what this rating means. If we are saying only, \is an authoring system easy
   to use" then ALAN would rate at the top of the charts. If on the other
   hand we say, and we do, \is it easy to use and is it easy to accomplish
   some particular reasonable task" then ALAN rates a bit lower. ALAN's
   simplicity provides ease of use; but when there is a complex task to ac-
   complish which falls outside of ALAN's directly available structures, one
   must resort to various tricks and indirect implementations.  The classic
   example is the use of the \description" sub-block to execute procedural
   code which cannot be easily executed elsewhere within an object.

   Nevertheless for straightforward operations ALAN is a snap to use. The
   learning curve is traversed quickly and results appear in short order.

3. Parser, Weight 5. Rating: 4. ALAN's parser is good, make no bones
   about it; it is nearly as good as TADS and INFORM, and correctly handles
   the expected range of conjunctions, prepositions, and so on, with the
   added benefit of handling English and Swedish (and I'd see little problem
   with Norwegian and not much problem with Danish). The drawback, and
   the reason for a slightly lower rating, is that it is fixed within the run-t*
 *ime
   module and there are no facilities at all for altering parser behavior (other
   than the \syntax" constructs which are part of the ALAN language).

   Now, I've been \selling" ALAN as a good first language for a new IF
   author.  A new author really should be learning the basics and not be
   doing much parser modification. So, how much of a drawback this parser
   rigidity is, at the level of operation I'm contemplating, is uncertain.

4. Support, Weight 4. Rating: 3. Thomas Nilsson, one of the authors of
   ALAN, responds eagerly to questions about ALAN. Thomas is a complete
   gentleman, and provides excellent support for his product via e-mail. But
   unfortunately at present that is close to the only source of support. Only
   one expert, Mark Sachs, has appeared on the newsgroup, and Mark's avail-
   ability and presence is uncertain. So, support for ALAN is not available
   through many avenues.



                              24




   I sincerely hope that this situation changes as ALAN becomes better
   known and more widespread expertise develops.

   In my opinion, a major inhibiting factor has been the ALAN compiler dis-
   tribution policy. While the ALAN runtime and documentation are avail-
   able from the archive site, the compiler is exclusively available by e-mail
   or snail mail directly from the authors. The ALAN terms of use specif-
   ically forbid placing the compiler on any BBS or Internet site.  Thomas
   says this is because he wants to track the usage of ALAN, and while this
   is a reasonable wish, the ALAN compiler remains somewhat difficult to
   access. One must combine and uudecode a multi-part e-mail transmission,
   and this is hardly a task for a computing novice; and it is error prone as
   well.

5. Language Depth, Weight 4.  Rating:  3.  There are two classes of
   problems with ALAN's language depth.  ALAN, by design, stresses a
   natural syntax and simplicity. This does not preclude a full set of features
   and a highly capable language; but it does limit how rich the feature set,
   ultimately, can be. I would not call ALAN's feature set sparse, but neither
   can it be called extensive and deep.

   While this requires rating this category lower than some other systems, it
   should not present a barrier to a prospective new author.

   The most serious lack, however, falls not in the design of ALAN but in
   the absence of a standard library. None is provided with the distribution,
   although a basic library, written by Mark Sachs, can be obtained from the
   archive site. Any user of ALAN is strongly advised to obtain this library.
   It is hoped that the library will be extended in the future.

   Actually, the sample games provided with ALAN show that a fair amount
   can be done without standard libraries, but a lot of default actions and
   results will have to be individually hand coded.  This does reduce the
   appeal and utility of ALAN since the author ends up doing substantial
   extra work, all of which could be avoided with a standard library.

   It is my suggestion that ALAN enthusiasts join with ALAN's author to
   produce and document a good standard library.

6. Portability, Weight 4. Rating: 3. ALAN games are playable on most
   of the mainstream platforms: the PC, MAC, and Amiga are all covered,
   as are a few Unix platforms. A Linux port will appear very soon (I should
   know; I'm the porter).

   The version 2.6 PC compiler and runtime is limited to 386+ PCs, since
   they were built with djgpp. Thomas will later be producing a runtime for
   sub-386 PCs, at which time the portability rating should be increased by
   one level.



                              25




    The one slight drawback, which is shared by TADS and many other sys-
    tems, is that a platform specific runtime will need to be available to play
    an ALAN game. The ALAN runtimes can be rather large, especially on
    the PC platform.

 7. Run Speed, Weight 4.  Rating:  4.  ALAN runtime speed is quite
    good, and the subjective feel is that it is comparable to any of the other
    faster-running major systems.

 8. Literature Library, Weight 4. Rating: 2. There really is no literature
    library, and this is very unfortunate. A couple of small examples, which
    don't really show more than the basics, come with the ALAN distribution.
    Mark Sachs has produced a small but extremely useful set of examples,
    which he calls \etudes" and these should be obtained from the archive site.
    Mark's studies do illustrate how to use ALAN's more advanced features,
    and how to do more complex tasks with ALAN, information which is
    otherwise not available.

    One would hope that in the near future, at least Colossal Cave will be
    released in source form for the prospective ALAN author. And one would
    also hope that ALAN finally receives the attention it deserves and that
    ALAN games will begin to appear.

    Recently, a game (in runtime format) has been released as shareware for
    the PC, and other games are supposedly in progress; but source to these
    games is not available.

 9. Debugging Features, Weight 4.  Rating:  4.  ALAN has some very
    good debugging features, ranging from internal tracing to dumping of
    tables.  This forms a fairly complete debugging suite.  The only lack is
    a source level debugger, which is a lack shared by nearly every other
    authoring system.  But even better, the logical structure of an ALAN
    program encourages good, bug-free coding, making the need for a debugger
    less than it might otherwise be.

10. Future Prospects, Weight 3. Rating: 3. A minor release of ALAN
    has just come out after about a year since the previous release. Author
    Thomas Nilsson retains high interest in his product, but has a very busy
    schedule. He has projected a number of features for Version 3 but cannot
    commit to a target release date.  Source code is not generally available
    for ALAN, and therefore future prospects for the language depend upon
    Thomas.

11. Object Orientation, Weight 3.  Rating: 3. I'd say that ALAN has
    a \mild" object orientation; certainly there is no object orientation in
    the technical sense (although this is contemplated for a future release).
    Give ALAN credit for a nice block structure, prearranged objects such as



                               26




    locations, etc. However, there are no notions of classes, inheritance, and
    the rest of the trappings of true object orientation.

12. Game Size, Weight 3. Rating: 4. I asked Thomas about size limita-
    tions within ALAN, since it wasn't possible to determine from the docu-
    mentation just how large a game can be accommodated by this system.
    He responded that internal memory management was efficient and worked
    from a shared memory pool, so you couldn't really assign specific limita-
    tions such as number of locations permitted. \Available memory" is the
    ultimate limitation, and of course this will show up first in the sub-386
    DOS implementation.

    This all means that ALAN should accommodate extremely large games,
    probably as large or larger than a Z8 Inform game, without hitting a limit
    except in the sub-386 DOS version.  But, lacking concrete examples, I
    won't as yet go to the top rating in this category.

13. Distribution Policy, Weight 3. Rating: 4. Non-commercial distribu-
    tion of ALAN games is not restricted, nor is non-commercial distribution
    of the ALAN run-times. I assume this applies to shareware. Commercial
    distribution needs to be arranged with the authors of ALAN.

    For non-commercial distribution, the authors do request, but not require,
    a source code copy of the game.  I encourage authors who complete an
    ALAN game to honor this request and help build a library of ALAN code.

14. Programming Skill Required, Weight 3. Rating: 4. Of the language-
    like systems (in contrast to systems such as AGT or Gamescape) ALAN
    clearly requires the least amount of prior programming experience and
    skill.  This is not to say that no prior experience is required, and hence
    the rating of 4 in this category.

    I continue to insist that there is no system within which non-programmers
    can be immediately productive. Experienced programmers nearly always
    underestimate the difficulties faced by non-programmers and think that
    certain languages or systems require \no" prior experience. It just doesn't
    work that way.

    In order to be successful with ALAN you must know how programs are
    structured, you must understand basic logical constructs, and you must
    be comfortable with a certain amount of syntax.

    But ALAN really goes a long way toward easing this task. For the almost
    neophyte, or even for the beginning IF author with a certain amount of
    programming experience, ALAN is an excellent first choice, perhaps the
    best first choice. The new author can program a small sample adventure
    and learn a great deal about the craft of IF; perhaps the author might even
    continue on with ALAN in the development of later, more sophisticated
    works.



                               27




 15. Cost, Weight 2. Rating: 5. ALAN is a free system.

 16. Source Code, Weight 2.  Rating:  1.  Source code is not available
     in general, although it has been made available to porters (I have it, for
     instance).

 17. Compiler Speed, Weight 2. Rating: 4. The compiler is doing quite
     a bit of work in ensuring a \safe" run-time module, and does this work at
     surprising speed. While my statements here must be subjective, lacking
     a large test case to compile, ALAN compile speed is very good, and this
     speaks well of the internal design.

 18. Compiler Platforms, Weight 2. Rating: 3. Compiler and run-time
     platforms are the same, and cover the mainstream including several Unix
     variations, with a Linux version available in the near future.

 19. Dynamic Object Creation, Weight 1. Rating: 2. As is the case in
     many other systems, you cannot do this directly, but you can imitate the
     effect by moving objects in and out of the player's view. There does not
     appear to be a means of disambiguation of seemingly identical objects,
     although I have not experimented enough to see how this might be done,
     and I invite the reader to clarify this if possible.


   Summary Comment.  Program in ALAN for a few hours, as I've done,
and it's difficult not to be charmed by the simplicity of the language, the ease
with which the simpler tasks can be accomplished, and the overall pleasant feel
of the system.  Going a little deeper, though, one feels the lack of standard
libraries and is somewhat constricted by the relatively small feature set. Stil*
 *l,
the beginning IF author and ALAN seem a natural match. ALAN has received
too little attention in the newsgroup and is too little known among IF authors.
I sincerely hope that this situation will change before much longer.



5.4   Hugo

Release discussed: v2.0
Author contact information: Kent Tessman, tessman@cibc.ca
   Description. Someone looking at Hugo who is familiar with other languages
for interactive fiction authoring will quickly ask if this is Inform's junior s*
 *ibling in
disguise. In fact, it is not, and offers some surprising distinctions and exten*
 *sions.
Hugo may yet be a young and not fully developed language, but it has come
a very long way in a very short time.  Hugo shows great promise.  Time will
tell how much of this promise is realized- although I'm betting that the author,
Kent Tessman, will carry Hugo some day to world-class status.
   A look at a Hugo program will quickly show that the structure is clean,
logical, and appealing. Hugo attempts to meld the straightforward approach of



                                28




ALAN with the power and depth of Inform. Of course, there are compromises
and this unique fusion is partial rather than complete.  But Hugo adds a few
things all its own: a game-memory segmentation system which supposedly al-
lows for very large games, and an actor scripting feature which is so logical a*
 *nd
simple that one wonders why it isn't seen in any other authoring system.

  1. Documentation, Weight 5.  Rating:  3. Documentation is certainly
     complete and pretty easy to follow for the most part, although there are
     some really confusing sections.  I'd advise the prospective Hugo game
     writer to browse code samples while reading the documentation.  The
     manual does lack an index, and its rambling nature makes it harder than
     necessary to look things up. It would be well to keep the manual on-line
     to facilitate keyword searching, or to get busy with a yellow highlighter.

     I'm sure Hugo's author has been very busy with all of the work required
     to develop Hugo to its current state, but when a point of pause is reached,
     a reworking of the manual would really add a lot to Hugo's value.

  2. Ease of Use, Weight 5.  Rating:  4.  Hugo's clean coding structure
     and style appears to lend itself to high ease of use. Most of the input I'*
 *ve
     received indicates that Hugo is somewhat easier to learn and use than In-
     form, even though Hugo has many Inform-like commands and statements.

     The primary factor usually cited here is a lack of \picky" syntax. Inform
     is very sensitive to misplaced commas and semicolons, and requires correct
     usage of both square and curly brackets. Hugo relies almost exclusively
     on curly brackets.  You might or might not feel this is a more logical
     arrangement; certainly you need to take care with your visual formatting
     of your program.  Look over the sample programs and draw your own
     conclusions.

  3. Parser, Weight 5. Rating: 3. The Hugo parser is quite good enough,
     although I am told it is not presently as advanced as the Inform and TADS
     parsers. A significant advantage is that the usually modified sections of
     the parser are contained within Hugo's standard libraries (although the
     computationally expensive parts are in the runtime engine). It is also pos-
     sible to override part of the parser's behavior with a pre-parsing routine,
     without the need to delve into the complexities of the entire beast.

  4. Support, Weight 4. Rating: 3. I am sure this category will rate higher
     in the future, although for the present a few factors lead to a lower rat-
     ing. First, newsgroup support for Hugo has only just now appeared, and
     indeed, there is not very much discussion of Hugo as yet. Also, the author
     of Hugo is quite busy and not always able to quickly respond to inquiries,
     leaving the Hugo game writer with nowhere to turn for immediate, expert
     assistance. A prospective Hugo author is, in any case, a bit of a pioneer
     at this point, and will have to call upon a good deal of self-reliance.



                                29




 5. Language Depth, Weight 4. Rating: 4. I think some reviewers would
    rate this category lower, but Hugo provides all of the necessary language
    features as well as some unique extras. The manner in which objects and
    classes are treated (they are, or can be, equivalent) and the useful and
    straightforward implementation of inheritance lend a great deal of utility.
    The actor scripting feature is a real treasure for someone contemplating a
    game containing important non-player characters. Not only is it easy to
    script single NPCs, but NPC to NPC interaction is also possible.  Even
    better, this scripting is contained within the standard libraries where it
    can be extended or customized.

 6. Portability, Weight 4.  Rating:  3.  Hugo ports beyond the DOS
    platform have begun to appear.  Earlier versions of the source were not
    ANSI-C compliant and made use of Microsoft specific extensions in the
    Quick-C language.  The most recent release has cleaned this up a good
    deal; and Amiga and Linux ports have been completed. Other Unix ports
    should be easily achievable, and I imagine porting to a MAC, Acorn, or
    what-have-you should not be a problem.

    I expect that, by the next revision of this FAQ document, Hugo porting
    will be mostly resolved.

 7. Run Speed, Weight 4. Rating: 4. Hugo run speed is comparable to
    any of the other well-running systems. There are no problems in this area;
    run speed is subjectively very good.

 8. Literature Library, Weight 4. Rating: 3. This middle rating is based
    on the availability of the nearly obligatory port of Colossal Cave and a few
    other samples of code. The author of Hugo has published one substantial
    game in Hugo, and the source code has now been made available. There
    are also a couple of small demonstration games to be had. Beyond this,
    no literature library has yet developed. This would perhaps imply a lower
    rating, but the sample code available illustrates how to do things in Hugo
    pretty nicely, and the larger games are very useful.

 9. Debugging Features, Weight 4. Rating: 4. Hugo has gone about the
    debugging chore by providing a special debugging library called HugoFix.
    This library contains a number of useful debugging features and com-
    mands, and should prove adequate for most debugging work. At present
    there is no source level debugger, and none is anticipated in the near
    future.

10. Future Prospects, Weight 3. Rating: 4. Based on history to date, I
    think Hugo has really excellent future prospects. Kent Tessman has come
    out with a steady series of new releases with significant improvements in
    them, and there is no doubting his serious interest in development of the



                               30




    product. Full source code is available as well. The only reason for giving
    Hugo less than top rating in this category is its current status outside the
    mainstream of newsgroup interest.

11. Object Orientation, Weight 3. Rating: 4. While perhaps not meet-
    ing all the formal definitions of object orientation, Hugo's object nature *
 *is
    as appealing as it comes. Even though TADS meets a more strict formal
    definition, my own opinion is that Hugo's object implementation is really
    easy to use, giving the prospective author all the advantages of the object
    approach without the formality and syntax.

12. Game Size, Weight 3. Rating: 3. It was difficult to understand game
    size limitations based on the documentation and even the source code, so
    I asked the author for clarification. There is a hard limit of 32767 game
    elements, which is no limit at all.  The author says he has cleaned up
    memory management, and he estimates that a game about four times the
    size of Jigsaw would be feasible in Hugo. However, he says that this would
    not run on an 8088 machine, and this is certainly true.

    I finally decided on a middle rating rather than one level higher since
    the existing DOS port of Hugo will reach the same limitations on any
    DOS machine, 8088 on up. The full capability of Hugo on 386 or higher
    machines could be realized should a DJGPP port of Hugo appear. Given
    the existence of a Linux port, such a DOS port should be trivial, but of
    course would exclude older DOS computers.

13. Distribution Policy, Weight 3.  Rating:  3.  My interpretation of
    the distribution policy as stated in Hugo's manual is that there is no re-
    striction on freeware distribution of a Hugo game and the Hugo runtime.
    Shareware distribution, since it might involve transfer of funds at some
    point, appears to require prior arrangements with the author, and this is
    the cause of a slightly lower rating in this category.  Commercial distri-
    bution clearly requires prior permission.  Hugo's author has stated that
    he sees no problem, though, with shareware; he'd just like to know in
    advance.

    One other limitation the author has imposed is that modified libraries
    may not be distributed.  This evidently refers to source modifications,
    since otherwise library hacking would be prohibited in any game that is
    intended for redistribution.

14. Programming Skill Required, Weight 3. Rating: 4. Hugo probably
    requires as much inherent programming skill and background as TADS
    or Inform, yet I think Hugo should rate higher because of its ease of
    learning.  No, Hugo is not the place to begin learning to program, and
    the Hugo manual is hardly intended or suitable for non-programmers.



                               31




     But the learning curve is somewhat less difficult to traverse. Still, prior
     background in C or perhaps Pascal is a necessity.

 15. Cost, Weight 2. Rating: 5. Hugo is a free system.

 16. Source Code, Weight 2. Rating: 4. Full source code is provided and
     the source code is not particularly difficult to work with, although the
     prospective source hacker shouldn't expect an easy go for a system this
     complex.

 17. Compiler Speed, Weight 2. Rating: 3. Hugo, in the version I tested,
     is one of the slower compilers of the group, running about 50% faster than
     Inform (based on Colossal Cave). I did not test the pre-compiled headers
     feature of Hugo, however, and use of this feature would surely speed things
     up a great deal. I have had some correspondence which states that Hugo
     is supposed to be a fast compiler, but I haven't seen this as yet in pract*
 *ice.
     Hugo's author disputes my contention, saying that he has received a lot
     of correspondence saying how fast Hugo has become!  I'll stick with a
     middle rating and let you experiment for yourself, and I welcome any sort
     of objective feedback which would help resolve this issue.

 18. Compiler Platforms, Weight 2. Rating: 2. My comments on porta-
     bility apply here. Hugo has been ported to some non-DOS/PC platforms,
     and moe ports will likely appear in the near future.

 19. Dynamic Object Creation, Weight 1.  Rating:  4.  Hugo supports
     this feature in a reasonable manner; it especially supports dynamic object
     naming, a rather nice idea.  In your game, you might want to create a
     situation where a player names an object, and can then refer to the object
     by that name. Hugo supports this easily.


   Summary Comment.  Hugo is going to be a player in the IF authoring
arena, have no doubts about it. The portability and porting issues need to be
solved, the manual could be refined, and the compiler could be faster. Hugo's
author is dedicated to the success of Hugo, and progress has been very rapid.
Should this continue, Hugo will enter the first tier before too long.
   Hugo's combination of adequate features, including unique actor scripting,
and a logical, appealing program structure, make it a unique system.  It still
needs some work, but check it out and see what you think.



5.5   AGT| Adventure Game Toolkit

Release discussed: 1.83
Author contact information: Mark Welch, markwelch@trivalley.com
   Description. AGT, the Adventure Game Toolkit, is the professor emeritus
of the interactive fiction world. In its heyday, there was nothing to equal it|



                                32




in fact, there was little else, and the aspiring IF author would simply choose *
 *it.
Many, many games have been written with various versions of AGT, and some
of these have been quite good.
   AGT was, for many years, the shareware product of Mark Welch and David
Malmberg; it grew out of Mark Welch's earlier effort called GAGS: Generic
Adventure Game System.  Then, as people do, David and Mark moved on to
other things; AGT was released as freeware and the source made available.
   Most of the mainstream editions of AGT rely on numbering systems; rooms,
objects, messages, and words are all referred to by number. Certain limitations
are hard coded into the system: the maximum number of rooms, etc., is fixed
in advance, and allocation is not dynamic| you cannot trade room table space
for object table space, and so on (although you can't do this in many other
systems, either).
   Games written with AGT can be of two types, \basic" and \professional."
It is claimed that the basic games can be written without knowledge of pro-
gramming, which is incorrect.  Professional games are said to require some
programming knowledge while offering, in return, some supposedly powerful
constructs.
   This all may sound a bit negative, and indeed, AGT does not meet to-
day's highest standards for an authoring system. However, in its day AGT was
clearly the best and this is not without reason. Although AGT really can't be
recommended over TADS, Inform, and ALAN, it should not be cast aside.
   And it hasn't been.  As will be detailed below, some development is still
proceeding which may give new life to this old favorite.
   This discussion will concentrate on AGT version 1.83, updated by a third
party from the last shareware release, 1.7. Version 1.7 was followed by another
shareware release called The AGT Master's Edition. This latter release is con-
siderably different from earlier releases, but as it concentrates new features *
 *in
the areas of sound and graphics, it is somewhat out of the mainstream.

  1. Documentation, Weight 5.  Rating: 5. The excellence of the docu-
     mentation now publicly available for AGT is beyond question.  Suitable
     for beginner as well as expert, the documentation leads the prospective
     author step by step through the process by which an AGT game is written.
     An excellent language reference is provided, as are tips and techniques for
     designing a game and using AGT to bring it to fruition.  Much of the
     Master's Edition manual, available in Word Perfect format, applies to the
     earlier editions as well.  (I have had reports that the Master's Edition
     manual is not to be found. I do have an electronic copy of it and it should
     be generally available.)

     The ASCII text documentation can easily be used on-line.

     While the documentation is not as weighty as Inform's, or as well-written
     as TADS, it does appeal to the complete novice and should be read even
     if you don't plan to use AGT.



                                33




2. Ease of Use, Weight 5. Rating: 3. This category is hard to call. In
   most of the AGT editions, the use of numbers for everything is really a
   nuisance, and storing messages in a file separate from the code in which
   messages are used is very error prone.

   Some of these problems are solved in the Master's Edition; and for the
   other editions, some tools are available to help, such as a preprocessor
   which allows the use of alpha tags and converts them to numbers just
   prior to compilation.

   As a personal matter, I find the style of coding required by AGT to be
   a bit annoying. Actually, the style is pretty simple and straightforward,
   but is enough different from the procedural coding which I learned thirty
   years back to be an irritant. I suspect it would actually provide much less
   of an obstacle to someone with less of an ingrained bias.

   Some things, though, are indeed difficult to keep track of| \if-then-else"
   structures, for instance, require a clumsy structure to implement effec-
   tively, and, unless you fill your program with comments (which is always
   a good idea in any language), bugs are certain to creep in.

   Otherwise, though, AGT must be said to be easy to learn, and its greatest
   ease of use strength is that you can learn the features in layers.  The
   \standard" set of commands and structures allows the prospective author
   to wet the feet and gain some experience, while the \professional" set of
   commands and macros provide a lot of additional power which can be
   learned and applied in increments.

3. Parser, Weight 5. Rating: 4. The AGT parser is criticized frequently
   in the newsgroup; indeed, there are some newsgroup correspondents who
   claim to be able to recognize an AGT game merely from the feel of the
   parser.  I have always thought these criticisms and claims to be largely
   unfounded.  In fact, the AGT parser understands and disambiguates a
   wide variety of English sentence structures. It is perhaps not as developed
   as the TADS or Inform parser, but it is very good nonetheless.

   Why, then, the ongoing criticism? I think the critics are confusing vocab-
   ulary limitations with parser limitations.  The parser understands most
   of what is pitched at it within the limitations of the game's vocabulary.
   And unfortunately AGT does not have the capacity to deal with very
   much vocabulary: there is about a 500 word limit in the Classic Edition,
   and the Master's Edition only takes this to 1000 words. Too, many AGT
   game-writers didn't always make an effort to carefully define synonyms
   and alternative grammatical constructions in their games. (We must re-
   member that these games were written at a time when the \state of the
   art" was less advanced.)

   The one grade lower rating of the parser has to do with its rigidity, as it
   is hard-coded into the runtime module. Since source code is available, it



                              34




   is possible to hack the parser, but this cannot be done conveniently via
   libraries or function calls.

4. Support, Weight 4.  Rating: 2. I won't rate support at the bottom
   because undoubtedly limited support can still be found on the newsgroup.
   The authors, upon converting the system to freeware, have moved on and
   not surprisingly no longer provide product support.  I believe, but have
   not verified, that some discussion of AGT takes place in one of the forums
   of one of the major on-line service providers.

   So, support is probably not zero, but it is not likely to be prompt or plen-
   tiful. There simply isn't enough current interest in AGT among enough
   people (although I do know a few enthusiasts are still out there).

5. Language Depth, Weight 4. Rating: 3. I'll go with a middle rating
   here, although let's say more of a low 3 than a high 3. You can do a lot
   of things with AGT; there are dozens of games out there which attest to
   this fact.

   The \standard level" of AGT is not very feature rich. You have locations,
   messages, a few flags to make use of, and a standard set of verbs. When
   you move to the \professional level" quite a bit more becomes available,
   although it is pretty rigid in structure, and it isn't really feasible to bu*
 *ild
   new, complex commands out of the existing command set. You either like
   the AGT approach or you don't; there isn't much middle ground.  For
   example, if you want to see if a container is open, you use the IsOpen
   predicate.  This keeps the structure simple, but allows for no variation.
   If you want to test instead if an object is from an alien spaceship, you
   can't build an IsAlien macro; you have to use a flag variable instead to
   represent this idea.

   Similarly, the game structure itself is stratified.  There are rooms, ob-
   jects, monsters (similar to actors), and a few other categories; if you want
   something different, you have to substitute one of the pre-made categories
   instead.

   But to repeat, don't be misled. A lot has been done with AGT by clever
   authors, and, since there is a lot of source code around to use as examples,
   \unleashing" the inherent powers of AGT may be easier than doing the
   same on some other more advanced systems.

6. Portability, Weight 4.  Rating:  3.  I could perhaps have rated this
   category a little higher, but read on.  Classic Edition AGT games are
   playable on the Atari ST, the Mac, and the PC. This covers probably 95
   percent of the potential audience.  In order to gain this portability, you
   need to distribute the correct runtime with your game files. Since AGT
   has gone through a number of iterations and versions, you need to make



                              35




    available the exactly correct runtime for each platform on which you wish
    to release your game.

    Other systems require the distribution of a runtime (TADS, Alan, etc.).
    But it's a bit easier for those systems, since the runtimes are more readily
    available and better coordinated.

    The Master's Edition is limited to the PC platform.

 7. Run Speed, Weight 4.  Rating:  4.  A few people think the AGT
    runtime is slow; actually it is quite good, certainly faster than TADS if
    perhaps slower than JZIP. The main objection is an overly-long time delay
    on the title screen which I have always found annoyingly reminiscent of
    shareware nag screens, which just beg to have a binary editor applied to
    them. But once in the game, performance is quite fine.

 8. Literature Library, Weight 4. Rating: 5. Without a doubt there is
    more AGT source code available for browsing than for any other system
    currently available. Ranging from the obligatory port of Colossal Cave to
    a wide range of games of all sizes, there is plenty of code and a very high
    probability of finding an example of the sort of thing an author might be
    interested in coding.

    For a number of years, Softworks, the owners of AGT, sponsored an annual
    game writing contest. These contests drew a significant number of entries
    and helped to build a good sized library of AGT games.  Recently, the
    source code for many of these games has been released, and this provides
    a very valuable resource for the prospective game writer. Something like
    thirty games are available in source form.

 9. Debugging Features, Weight 4.  Rating:  3.  For debugging AGT
    relies on special \wizard" commands in the run-time, which allow you to
    track objects, jump to locations, etc.  While certainly very useful, this
    does not tackle the question of program logic debugging in anything but
    an indirect manner. AGT's debugging features don't give you a means of
    looking at internal tables, such as can be done in Inform; and of course,
    there is no source level debugger available.

10. Future Prospects, Weight 3. Rating: 2. AGT isn't dead yet. There
    is the prospect of future releases by a third party| one of these has
    already appeared| and the source code has been published, although it's
    in Pascal, which is hardly a plus.  A tiny bit of newsgroup discussion
    continues to take place.  One can hardly rate AGT's prospects as very
    high, but they are at least non-zero.

11. Object Orientation, Weight 3.  Rating: 2. AGT doesn't meet any
    sort of formal object oriented definition. I'll go a little above the bottom
    rating, however, since at least you code rooms, objects, etc., in blocks.



                               36




    AGT's handling of verbs takes the reverse approach of TADS, Inform, and
    ALAN: a verb is coded and the objects and situations to which it applies
    are listed under the verb blocks.  This is certainly not object oriented
    coding, but it's easy to see what goes with what.

12. Game Size, Weight 3.  Rating:  3.  There are some real limitations
    in AGT, particularly with respect to vocabulary size. Of course, the au-
    thors struggled with the need to make things run within the DOS memory
    limitations of the time (and indeed, which still are with us today). \Clas-
    sic" AGT handles about 500 words.  There are also limits of about 100
    locations, a handful of interactive \questions" and so on.

    There is a variant of AGT called \AGTBIG" which increases these limits
    somewhat at the expense of more memory usage. The original packages
    were set up this way to accommodate some earlier PCs which didn't even
    have a full 640K of lower memory.

    Some medium-sized games have been produced with AGTBIG, and the
    \small" AGT is still capable of handling shorter \snack-sized" games, or
    better; after all, 100 locations is really quite a few. But AGT simply is
    not the vehicle for large or especially very large games.

13. Distribution Policy, Weight 3. Rating: 5. AGT is now freeware and
    there are no restrictions on game distribution whatsoever.  (Even in its
    commercial days, game distribution policies were very liberal.)

14. Programming Skill Required, Weight 3.  Rating: 4. AGT claims
    that \Standard" games require no programming skill.  This is untrue.
    Standard-level games do not require knowledge of a formal procedural
    programming language; it isn't similar to some other languages, where
    you'd best know some C or Pascal before you begin.

    But, in writing an interactive fiction work, you are in every case, with ev*
 *ery
    authoring system, writing a computer program of one type or another, and
    that is completely inescapable (unless someone takes your ideas and does
    it for you). To use AGT, you must understand at least something about
    logic structures, branching, testing, etc., even if it's called another nam*
 *e.

    AGT makes a valiant and somewhat successful effort to reduce the burden.
    But you can't make it go away. AGT requires only a limited amount of
    prior programming knowledge and experience, but that amount is non-
    zero.

15. Cost, Weight 2. Rating: 5. AGT is freeware.

16. Source Code, Weight 2.  Rating:  4.  Full source code to AGT was
    made available when the system became freeware.  The source code, at
    least in my estimation, isn't at all difficult to read and work with. There



                               37




     is one major exception, though, and the reason for a slightly lower than
     top rating:  it is completely written in Pascal.  I don't know about the
     availability of Pascal compilers on all supported platforms, but unless you
     have the right compiler, which will be a commercial product, the source
     code will do you little good.

     Side note: I did attempt to compile AGT with the free GNU Pascal com-
     piler, and about an hour of work produced no results.  And, there have
     been comments on the newsgroup about using the GNU p2c tool to try to
     convert the system to a portable C format and make it work. This would
     surely breathe new life into the package.

 17. Compiler Speed, Weight 2.  Rating: 4. I had expected AGT to be
     a slow compiler, working from memories of experiences from years back.
     In fact, AGT proved a rather speedy compiler. Using Colossal Cave as a
     test case, AGT is noticeably faster than Hugo and Inform. The biggest
     delay seems to be in one or two \press enter to continue" screens which
     are really unnecessary.

 18. Compiler Platforms, Weight 2. Rating: 3. Leaving aside the Mas-
     ter's Edition, the mainstream AGT variants work on the PC, the MAC,
     and the Atari ST. There is no version for any flavor of Unix or the Amiga,
     or any of the other computers out there. The omission of Unix is proba-
     bly the most serious lack, yet it is understandable in a former shareware
     product targeted mostly to the DOS market.

 19. Dynamic Object Creation, Weight 1. Rating: 2. As I do elsewhere,
     I don't rate this at the bottom because this sort of thing can be imitated.
     But true dynamic object creation and deletion, and disambiguation of
     multiple copies of a similar object, are simply not part of the system.


   Summary Comment.  AGT has a long history as a successful product
and has the literature library to prove it.  It has fallen out of favor as it h*
 *as
fallen behind. This does not mean it is a poor system or even necessarily a poor
choice. It simply means that the newer systems have more capability.
   But the last word may not be in. Recent uploads to the archive site have
included this newest version of AGT, version 1.83, which has had extensions
added by a current-day AGT enthusiast. More of this may come later; and if
the aforementioned project to convert the system to portable C is ever brought
to a successful conclusion, we may have to some day reevaluate the prospects
of the AGT system.



5.6   Archetype

Release discussed: 1.01
   Author contact information:  Derek Jones, dtj@rincon.primenet.com



                                38




   Description. Archetype is a modern example of an experiment in minimal-
ist, object-oriented design. As an experiment, it succeeds well; well enough, in
fact, to move out of the laboratory and into the field of practice.
   Archetype programs have a unique look and feel. Like Hugo, that look and
feel is one of simplicity and streamlining. Archetype is not as well developed,
though, as some tier 2 languages, yet it is at a point where it can serve a use*
 *ful
purpose. Archetype assumes a certain amount of computer literacy, but with
some background I believe the prospective author can start coding nearly at
once.

  1. Documentation, Weight 5. Rating: 3. Archetype's manual is com-
     plete, if spartan. It is available in both text and RTF formats, which is *
 *an
     interesting choice. Two documents are presented. One of them is a rather
     nice elementary tutorial on writing adventure games, with the bonus fea-
     ture that it zeroes in on working with Archetype.  The main Archetype
     manual is nicely laid out but rather brief. Everything necessary is covered
     but not in much detail; it is a minimalist manual for a minimalist system.
     The brevity of the manual is surely a reflection of author Derek Jones' la*
 *ck
     of time; I would expect that the manual will develop in future releases.

  2. Ease of Use,  Weight 5.   Rating:  4.  Although I have not used
     Archetype beyond simple experimentation, I did not have any real diffi-
     culties in jumping right in, based on the manual and the coding examples
     present in the distribution package.  Programming is pretty straightfor-
     ward and nearly intuitive.  Of course, we are talking about performing
     basic IF tasks; Archetype really doesn't as yet have facilities for very
     complex tasks (although these could be built up from the basic features).
     I have also received one direct report from a newsgroup correspondent
     who found Archetype especially easy to work with and extend.

  3. Parser, Weight 5.  Rating: 3. I'd rate the parser as average to ade-
     quate. My use of the sample games and review of the code did not find the
     parser to be spectacular, but neither could I say that it is not up to the
     task. A distinct advantage, of course, is that the parser is fully exposed;
     a disadvantage is that most of it is in the source code rather than in the
     libraries.

  4. Support, Weight 4. Rating: 2. This rating is mostly based upon the
     fact that there is almost no newsgroup discussion of Archetype.  I have
     had no input as to how support is from author Derek Jones, although he
     apparently takes an interest in his product as his schedule allows.  But
     I think at present any kind of significant support would simply not be
     available.

  5. Language Depth, Weight 4.  Rating:  3.  A minimalist experiment
     such as Archetype would not be expected to have great depth of features,



                                39




    and Archetype does not. This does not mean the language is unsuitable
    for serious work, but it simply doesn't have the depth of Inform or TADS,
    or even Hugo. This same comment applies to the standard libraries, which
    are adequate but not more than that. Archetype in its present form is a
    framework rather than a fully-finished product.

 6. Portability, Weight 4.  Rating:  2.  Why are so many things in the
    DOS world written in Pascal?  Portability, unfortunately, has been seri-
    ously reduced by this choice of language, and until Archetype enters the
    mainstream of authoring systems, I can't see the likelihood of it being
    ported to other platforms. This limits an otherwise appealing language in
    a most unfortunate manner. The rating of \2" reflects DOS as a viable,
    widespread platform.

 7. Run Speed, Weight 4.  Rating:  4.  Run-time speed is really very
    good. The sample games moved forward without any noticeable slowdown
    or difficulty.

 8. Literature Library, Weight 4.  Rating:  2.  The literature library
    consists of two sample games. These are not at all bad, and illustrate the
    features of the system quite well. (There is as yet no Colossal Cave port.)
    Unfortunately there is as yet no literature library beyond this; hopefully
    this will develop in the future.

 9. Debugging Features, Weight 4.  Rating:  3.  Debugging features
    consist of a small group of debugging directives which produce various
    quantities of output. This is no different than Inform or Hugo, although
    Inform and especially Hugo produce more, and more useful, output.

10. Future Prospects, Weight 3.  Rating:  2.  Perhaps this rating is
    lower than it ought to be, but I base it on several factors.  There has
    been no release of Archetype beyond 1.01, and apparently the author,
    while retaining an interest, has only a little free time to devote to the
    effort. Other doubtful factors include the Pascal source code and complete
    absence of newsgroup discussion. Archetype has a fair potential but as of
    now, not much is happening.

11. Object Orientation, Weight 3.  Rating:  4.  Archetype by its very
    nature meets a high object orientation standard. Objects, object types,
    methods, etc., are all present and behave mostly as expected.  The one
    lacking is the ability to pass parameters with messages. An object receiv-
    ing a message knows where the message came from, but no more than
    this. In some situations this can be a handicap.

12. Game Size, Weight 3.  Rating:  3. In the absence of any real infor-
    mation about game size, I'll go with a middle of the road rating.  DOS



                               40




     memory limitations will come into play at some point, but as with ALAN,
     I am not sure where that is. It is my subjective impression from brows-
     ing the code that a reasonably large game could be accommodated by
     Archetype.

 13. Distribution Policy, Weight 3. Rating: 4. No statements are made
     anywhere in the distribution package about licensing or game distribu-
     tion. I am assuming the typical arrangement that shareware distribution
     is acceptable and commercial distribution requires permission. However I
     have no facts or statements to base this on, and the author should clarify
     this important matter.

 14. Programming Skill Required, Weight 3. Rating: 3. Prior coding
     experience and knowledge of a modern programming language is essential.
     Prior familiarity with object-oriented programming concepts is also highly
     recommended. While Archetype's reasonably clean structure and syntax
     do not put undue demands on the prospective author, and the learning
     curve does not appear to be very long, this is not something for the novice
     programmer.

 15. Cost, Weight 2. Rating: 5. Archetype is free.

 16. Source Code, Weight 2. Rating: 4. All source code is present in the
     distribution package. The only reason for a slight downgrade to the rating
     is that the source is Pascal, limiting its utility somewhat. My impression
     is that the code is pretty easy to read, and is well commented.

 17. Compiler Speed, Weight 2.  Rating:  3. Archetype's compiler isn't
     all that fast. Subjectively, based only on the 3000 line Gorreven Papers
     test case, it is faster than Inform and Hugo but slower than all the rest *
 *of
     the compilers.

 18. Compiler Platforms, Weight 2.  Rating:  2.  My comments about
     portability apply here. The Pascal source code is a barrier to porting the
     system beyond its current DOS platform.

 19. Dynamic Object Creation, Weight 1.  Rating:  5.  Archetype has
     full built-in features for dynamic object creation and destruction.

   Summary Comment.  Archetype is billed as a general system, with li-
braries supplied to gear it to interactive fiction. This appears to be true, and
the generality of Archetype is greater than that of many other systems.  The
depth and development, though, is less, and it is hoped that the language will
develop further in future releases.  Archetype does have a sound, interesting
underlying concept which embodies an easy to understand object-oriented ap-
proach combined with simplicity in coding style. Let's hope author Derek Jones
has the time to work more with this system and bring it into the mainstream.



                                41




5.7   GINAS

Release discussed: 0.4
Author contact information:  Jeff Standish, jestandi@cs.indiana.edu
   Description. This little authoring system will warm the hearts of all Elisp
programmers. (Elisp is the lisp-like programming language at the heart of the
Emacs text editor.)  Although still very much in the beta stage, with its fair
share of bugs (\take all" causes a seg fault under Linux), the system promises
to be, at the very least, of theoretical interest in the future.
   The system appears to be in the nature of an elaborated experiment by the
author in the creation of a Lisp-like interpreter tailored to interactive ficti*
 *on
authoring and play.


  1. Documentation, Weight 5.  Rating: 3. The manual formats to ap-
     proximately 30 pages and is serviceable and adequate for most purposes,
     if at times a bit brief. There is enough content to allow you to dive into
     GINAS. The manual assumes familiarity with Lisp and object-oriented
     programming.

  2. Ease of Use, Weight 5. Rating: 3. This rating represents an average
     which hides the truth.  GINAS is probably impossible for someone not
     well versed in Lisp, but as I said above, could be the dream language for
     the experienced Lisp hacker.  All of that aside, ease of use is somewhat
     limited by the small libraries, hard-wired parser, and the general need to
     \do it yourself" pretty often.

  3. Parser, Weight 5. Rating: 2. It's not that the parser is particularly
     bad (or especially good) but it's buggy, and limited by the fact that it's
     hard-wired into the source code without the ability to override it in the
     game file. The author himself admits that this is one of the weaker points
     of the system. I suspect that future releases will show real improvement.

  4. Support, Weight 4.  Rating: 3. Although I have had little real con-
     tact with the author, the tone of the documentation indicates his genuine
     interest in ongoing improvements to the system, which would likely trans-
     late into adequate support.  This category would rate higher except for
     the fact that there has been no newsgroup discussion of the system, and
     newsgroup support would be probably hard to come by.

  5. Language Depth, Weight 4.  Rating: 3. The language is not espe-
     cially deep, although it supports a pretty reasonable, if small, subset of*
 * a
     typical Lisp language. This makes the language self-extensible if you have
     the time, talent, and inclination to develop it further.

  6. Portability, Weight 4.  Rating: 3. GINAS compiled with no fuss at
     all on my Linux system, which means that it will probably work on any



                                42




    reasonable Unix system, and would work under DOS or Windows via the
    DJGPP compiler.  The code looks quite clean and probably would port
    to sub-386 DOS machines as well; and similar prospects for other systems
    would be good.

    Of course, none of these ports have been done, so a prospective author
    would have to compile and distribute the run-time with the finished piece,
    for each intended target system. This certainly lowers the convenience of
    distribution across multiple platforms.

 7. Run Speed, Weight 4. Rating: 4. It is amazing that an interpreted
    language runs so well.  Perhaps this is due to the small libraries and
    limited vocabulary presently implemented. But Colossal Cave, a supplied
    test case, ran quite nicely on my test system.

 8. Literature Library, Weight 4. Rating: 2. The author has supplied
    the standard Colossal Cave port, some 4700 lines of code, and some other
    small examples, including Gold Skull from the TADS manual. But there is
    no other literature available| after all this is a new, experimental system.

 9. Debugging Features, Weight 4. Rating: 3. The debugging features
    include the ability to run an interactive Lisp shell and a debugging sub-
    shell.  In practice these again require a lot of familiarity with Lisp, and
    they are not especially well documented.

10. Future Prospects, Weight 3. Rating: 3. Perhaps I am being generous
    with this rating, but source code is available, and the author is actively
    pursuing improvements and fixes for a new release.  Newsgroup interest
    has not yet developed, but nevertheless my instinctive feel is that GINAS
    does have at least some future prospects worth mentioning and watching
    for.

11. Object Orientation, Weight 3.  Rating:  5.  The system meets any
    reasonable definition for object-orientation.  Class creation, inheritance,
    overriding, etc., are all supported. This would of course be expected in a
    language of this type, and adds greatly to its appeal.

12. Game Size, Weight 3. Rating: 3. A quick examination of the source
    code seems to indicate that game size limitations are probably controlled
    by available memory. This would allow for rather large games on a Unix
    systems and reasonable sized games under DOS. I've assigned this a middle
    rating in the absence of further information or experimentation, which
    perhaps a reader might be able to provide.

13. Distribution Policy, Weight 3.  Rating:  3.  The distribution pol-
    icy for the interpreter and completed games is not stated. However, the



                               43




     (uncompiled) package is available readily, and I would imagine that distri-
     bution of game files would not be a problem. Still, the author of GINAS
     should clarify this matter.

 14. Programming Skill Required, Weight 3. Rating: 2. A great deal
     of programming skill and knowledge of Lisp is required, in my opinion,
     to work with GINAS. If you have it, GINAS will be a very interesting
     product. (As mentioned above, Emacs Lisp hackers will love it.) If you
     don't have the skill and background, GINAS is not for you.

 15. Cost, Weight 2. Rating: 5. GINAS appears to be freeware.

 16. Source Code, Weight 2. Rating: 4. All source code is available. The
     rating is 4 instead of 5 because it is not especially easy code to follow
     (although these things seldom are).

 17. Compiler Speed, Weight 2. Rating: 4. Since there is no real compi-
     lation required in the present version, compilation speed and interpreter
     speed are equivalent.

 18. Compiler Platforms, Weight 2. Rating: 4. I've just said that there
     is no real compilation, so why would \Compiler Platforms" rate higher
     than \Portability"? Simply because anyone with the requisite skills to use
     GINAS almost surely has the skill and ability to build an executable for
     any reasonable platform.

 19. Dynamic Object Creation, Weight 1. Rating: 4. There should not
     be a problem in creating and destroying objects with the available Lisp
     interpreter. However I rate this below the top rating since, lacking some
     examples, my first look convinced me that there would be a lot of coding
     to do and that this would not be straightforward.


   Summary Comment. There are some weaknesses in GINAS, such as the
parser, a clumsy system for saving and restoring game states, bugs in the code,
and a high skill requirement.  All of these things make GINAS less desirable
at present. But keep in mind that this is, after all, a beta version, and is an
apparent experiment in Lisp-like authoring system design. GINAS has a lot of
potential, even if it could not presently be recommended for most prospective
authors. But I like the system for its innovative approach, its potential, and *
 *for
its appeal to the inner hacker within me.
   It might have been interesting had GINAS been implemented within the
framework of Emacs lisp. This would have made some very powerful features
available, although it would very severely limit the potential audience for the
system.



                                44




5.8   LADS| Levi's Adventure Development System

Release discussed: 2.1
Author contact information:  Peter F. Levy, 4209 Longmeadow Way, Forth
Worth, TX 76133.
   Description. This is a rather old system, which has survived and even been
modestly improved upon. It started life on a TRS-80 and is now available in
both source code suitable for use with the QBASIC or BASICA interpreters,
and also in an executable format. The only viable platform is DOS at this point.
   LADS seems deliberately designed to produce games with a distinct \Scott
Adams" look and feel. Even the op codes seem much the same. Perhaps there
is in fact a relationship of which I am unaware: : :
   LADS is the minimalist approach to interactive fiction. The state of the art
is today well beyond this, yet LADS is interesting both from the standpoint of
nostalgia as well as being a workable, if primitive, system in its own right.

  1. Documentation, Weight 5.  Rating: 3. The documentation is bare-
     bones but quite complete and relatively easy to read.  One nice feature
     about these docs is that you can read them over a couple of times in an
     hour, and then be ready to go to work on your piece. The docs would rate
     higher were it not for the extreme brevity.

  2. Ease of Use, Weight 5.  Rating:  2.  Some might rate ease of use
     even lower.  It depends on your background and what you are looking
     for.  The use of numbers for everything, and the need to keep track of
     numbers for everything from objects to messages certainly lowers ease of
     use a great deal. The method of programming actions also requires a lot
     of careful planning, and actions of a complex nature are likely impossible.
     The rather cryptic action codes and instruction formats certainly add to
     the problem. No, this system is not very author-friendly.

  3. Parser, Weight 5. Rating: 2. Parser format is rigid and built into the
     source code, and would be very difficult to change. The parser is, at leas*
 *t,
     of the three word type, which always must be verb-noun-object (which is
     really an indirect object, but the Scott Adams style grammatical lapse is
     preserved here). Vocabulary limits are also pretty severe (99 verbs and 99
     nouns) so the player is likely to encounter guess-the-verb a little too of*
 *ten.

  4. Support, Weight 4. Rating: 2. I'd rate this even lower, since there is
     little to no support on the newsgroup and I doubt if the author could even
     be located; but there actually are a few people interested in this languag*
 *e,
     with whom I've exchanged e-mail once or twice. Someone was interested
     enough to build an executable and clean up a few bugs, at least.

  5. Language Depth, Weight 4.  Rating:  1.  Not to be insulting, but
     there is no language to have depth, just a small series of action codes
     which would not be especially easy to modify or extend.



                                45




 6. Portability, Weight 4.  Rating:  2.  The only supported platform is
    DOS (I'm not counting the TRS-80). Ports to the Mac or Amiga should
    be possible. I made a feeble attempt to port it to Unix, using a BASIC
    interpreter available for Linux, and decided it would be more work than
    it would be worth.

 7. Run Speed, Weight 4.  Rating:  4.  No surprise that the compiled
    version runs pretty well; it isn't really doing all that much and it ought *
 *to
    run quite fast.

 8. Literature Library, Weight 4.  Rating:  1.  Well, there really is no
    literature in LADS that I have been able to find, although undoubtedly
    there are some games somewhere.  The system comes with some small
    examples which are useful, but that's all there is.

 9. Debugging Features, Weight 4. Rating: 1. There aren't any debug-
    ging features. You have to do it the old-fashioned way; sweat it out.

10. Future Prospects, Weight 3. Rating: 1. LADS isn't going anywhere.
    In the past year, LADS has been made to work on the PC platform, but
    that's all we're ever likely to see. In any case, why would anyone develop
    this system any further? There's no point in it.

11. Object Orientation, Weight 3.  Rating:  1.  In a language of this
    vintage, object orientation wasn't even heard of, let alone implemented.

12. Game Size, Weight 3.  Rating:  2.  A game with 99 rooms and 99
    nouns, 99 verbs and effectively 99 objects (you can have 255 objects but
    only 99 can be referenced by the player) you might wish to rate this
    category even lower. Actually, though, the Scott Adams games fell well
    within these limits.  You can write a decent mini-game within the size
    limits of LADS.

13. Distribution Policy, Weight 3.  Rating:  3.  In the absence of a
    formal policy statement by the author I automatically rate this category
    as middle of the road, but in fact I really couldn't envision any barriers
    to at least non-commercial distribution of works created with LADS.

14. Programming Skill Required, Weight 3.  Rating:  2.  How good
    are you with assembler language? You're dealing with op codes, operand
    fields, and all that stuff that \real, two-fisted" hackers eat for breakfas*
 *t.
    If you're a mere mortal, this is not so easy. I'd rate it even lower except
    that the number of op-codes is manageably small.

15. Cost, Weight 2. Rating: 5. It's free.



                               46




 16. Source Code, Weight 2.  Rating: 3. Source code is freely available.
     I reduced the rating by two grades for the following reasons: the source
     code is in BASIC, and is difficult to work with. Programs of this vintage
     are not exactly works of art; in an effort to get them to function within
     the memory and interpreter limitations of the time, many compromises
     were made, and clarity, maintainability, and comprehensibility were the
     first things to go.

 17. Compiler Speed, Weight 2. Rating: 4. The compiler (the executable
     version) is quite speedy, which again is understandable considering the
     relatively small size limitations on the game files.

 18. Compiler Platforms, Weight 2. Rating: 2. The compiler runs under
     DOS; it might be portable to a Mac or Amiga; but ports to Unix appear
     problematical. Portability is not a strong suit for BASIC programs.

     Ideally, if there were enough interest and a reason to do so, a port to C
     would be the best answer. But I can't imagine why anyone would do this
     except as an exercise.

 19. Dynamic Object Creation, Weight 1. Rating: 1. You can't do it,
     and you can't really fake it either. No surprise here.


   Summary Comment.
   Given the low ratings of this system, its lack of portability and difficulty*
 * of
use, the low-end type of game it produces, and all the other limitations, you
might wonder if you should bother with this system at all. In one unusual sense
you would be wrong. Here's why.
   A system of this type absolutely forces you to do advance planning for your
game.  You simply must map it out carefully, defining all the rooms, objects,
and actions in advance. If you do not you will have no chance of ever coding it
successfully. If you do lay it out well (and if you are comfortable with assemb*
 *ler-
level coding), you have a very good chance of producing a completed game.
   The conclusion I draw, then, is that using this system as an exercise in
learning to plan a game in detail will serve the new author well when it comes
time to plan and produce a larger, more serious work with one of the higher-tier
authoring systems. (Of course, the flaw in this argument is that few prospective
authors will want to deal with low-level coding.)
   If you do nothing else, read the LADS manual some day, just to get an
appreciation for how things were. And then realize that Scott Adams produced
some interesting games with just such as system.



5.9   Gamescape

Release discussed: A.4



                                47




Author contact information:   Dennis Drew, PO Box 101, Joplin, MO,
64802.
   Description. No discussion of interactive fiction authoring systems is com-
plete without a discussion of Gamescape, the system which bring us to the
zenith of hyperbolic advertising. Gamescape is the creation of Dennis Drew, a
professional programmer and a rather good comedian.
   Gamescape has appeared in a number of versions, and it is the latest (and
presumably last) version which is discussed here.  This release made possible
hi-res graphics as an option in the registered version.
   Gamescape might possibly be called \AGT Lite" for it has a number of
superficial similarities to the AGT system. Bu, it features a two-word parser, a
strictly numerical coding scheme, and other trappings of a rather primitive and
outdated authoring system, and falls far short of AGT in nearly all respects.

  1. Documentation, Weight 5. Rating: 3. The shareware documentation
     is pretty good as far as it goes, but it doesn't go anywhere. Several sect*
 *ions
     are deleted and marked \registered only." Registration promises to reveal
     to you the \secret" and \powerful" commands which will allow you to do,
     it seems, great and glorious things.

     The documentation that is actually present is loaded with hype and adver-
     tising, but it does include a rather good short tutorial on how to constru*
 *ct
     an adventure game.  This tutorial is worth reading no matter what au-
     thoring system you may use. Similarly, the explanations of how to use the
     unregistered version of Gamescape are well done and easy to follow, and
     have enough in-line examples to be really useful.

     I'd rate the documentation a little lower except for one factor. Nearly all
     of the \secret" commands are documented in earlier shareware versions of
     the product. If you are evaluating Gamescape it would be useful to look
     around for the earlier versions and study the more complete documen-
     tation which used to be provided.  This earlier documentation explains
     \linking" of modules which is necessary to produce anything but a small
     game, and is now considered a \registered" feature.

  2. Ease of Use, Weight 5. Rating: 3. Gamescape's ease of use is similar
     to AGT| although AGT has a structure which is easier to deal with.
     Locations and objects are all referred to by number, as are messages, and
     they all go in different sections of the input file. As with AGT, you'd be*
 *tter
     have an editor that allows you to work in multiple windows; otherwise
     you'll need some good notes on paper.

     One of the earlier versions of Gamescape had an input editor which helped
     you construct some of the locations and objects.  This seems to have
     disappeared; perhaps it's moved to the \registered only" category.

     Otherwise, Gamescape should be no harder or easier to use than AGT. One
     unfortunate difference is that, while AGT would allow complete coding of



                                48




   a logic test (\is flag greater than 5" and things of that nature) on a single
   input line, Gamescape's primitive compiler can only handle one token per
   line. So, the aforementioned flag test would take three lines in the input
   file. This greatly impairs readability of Gamescape code and seems to be
   error-prone.

3. Parser, Weight 5.  Rating:  1.  The Gamescape parser is abysmal,
   understanding only subject and verb. There is no notion of adjectives or
   indirect objects.  Adjectives must be attached to nouns with a hyphen,
   and the player must then type in the whole construct, such as \red-stone"
   or \small-box." Indirect objects are by implication only. If you need to
   distinguish between weapon categories in combat, for instance, you will
   have to resort to using signal flags and forcing unnatural actions upon the
   player (such as dropping all but the correct weapon for a given situation).

4. Support, Weight 4. Rating: 1. Perhaps this bottom-of-the-pile sup-
   port rating is unfair, but let me explain the situation. First, newsgroup
   discussion is nonexistent| I've never seen a single posting dealing other
   than incidentally with Gamescape.  Second, author support is only for
   registered users, and I don't know if that support is still available (I have
   no e-mail address for Dennis Drew). And, consider also a few statements
   in the documentation.

   We are told that if you are not a registered user, you will be \completely
   ignored" even if you submit a legitimate bug report. On the other hand,
   registered users are promised \full support" but with a warning about
   submitting bug reports. First, Mr. Drew informs us, that a system such
   as Gamescape which has produced \very complex" games, is unlikely to
   have any bugs in it. Second, he says, if you submit a bug report and it
   turns out that there was no real bug, but an error in system usage, he'll
   have to bill you for his wasted time.  In other words, Mr.  Drew does
   not seem to wish to hear very much about bugs in his bug-less system.
   (However, if you do find a real bug he promises to send you a \nifty
   adventure" in return.)

   Judge for yourself.

5. Language Depth, Weight 4. Rating: 2. There is little depth to the
   Gamescape system. You can do all of the typical Colossal Cave things, but
   there are really no advanced features, and static graphics in the registered
   version doesn't truly increase the usable feature set.  Probably the best
   feature is that the system will deal with up to 1100 vocabulary words,
   which is a pretty good allotment for primitive authoring systems.

6. Portability, Weight 4. Rating: 2. Gamescape is a DOS only system. I
   rate portability above the lowest level not because there is any portability
   but because DOS covers probably 90 percent of the possible audience.



                              49




    Also, Gamescape seems to be fairly simple in structure, relying on disk-
    based files rather than extensive use of memory, and will likely run on just
    about any DOS system.

 7. Run Speed, Weight 4. Rating: 4. Run speed is quite fine. It ought
    to be; the run-time isn't really doing very much.

 8. Literature Library, Weight 4.  Rating:  1.  A couple of small sam-
    ples are provided with the system, and that is the entire extent of the
    Gamescape literature library. To my knowledge no other source code has
    ever been released for this system. In fact, I am aware of only two games
    written with Gamescape, both of them by author Dennis Drew.

 9. Debugging Features, Weight 4. Rating: 1. There are no debugging
    features. You do it the hard way.

10. Future Prospects, Weight 3. Rating: 1. No source code is available,
    no newsgroup interest or even prospective author interest appears to exist,
    and it seems that even Dennis Drew has finally given up. No loss here.

11. Object Orientation, Weight 3.  Rating:  2.  Let's give Gamescape
    some credit for a certain amount of block structure, but as far as true
    object-oriented features, they are not here.

12. Game Size, Weight 3. Rating: 3. It is possible to write games that are
    arbitrarily large with Gamescape. But, in fact, there are some problems
    with this.

    First, the \linking" feature needed to build large games is now only doc-
    umented in the registered version, although it was documented in earlier
    shareware releases and still seems to work in the same manner.

    Second, large games are written in segments.  These segments cannot
    exceed 64k in size, which is fairly small. The segments must be \linked"
    together. Play in one segment can transit to play in another segment, and
    inventory and a few flags can be carried across.  Other than this, there
    is no communication between segments, so messages, locations, objects,
    etc., that reside in one segment cannot be accessed by another segment.
    This is a very severe limitation. On the other hand, you can have as many
    segments as you wish| they are all disk-based| so, as long as your game
    can be written in more or less independent 64k units, the game can be as
    large as you wish.

13. Distribution Policy, Weight 3. Rating: 2. Gamescape's distribution
    policy has improved in the latest release, but it is still not very good.

    Freeware distribution of a Gamescape game is now permitted, along with
    distribution of the run-time engine, provided you don't use any of the



                               50




     \registered" features such as linking. This precludes distribution of any
     game over 64k in size. Shareware or commercial distribution is permissible
     only to registered users, in which case it is permitted without further
     restriction.

     Dennis Drew imposes the ridiculous and probably unenforceable condition
     that, should you distribute a Gamescape game in violation of this policy,
     the game immediately becomes his property and you lose all rights to the
     game. I'm not a lawyer, so I suppose I shouldn't try to judge if a game is*
 * a
     derivative work and if derivative works can be confiscated, but the whole
     approach seems in tune with the way Mr. Drew attempts to do business.

 14. Programming Skill Required, Weight 3.  Rating: 4. I'll rate this
     the same as \standard-level" AGT, although AGT ease of use is greater.
     Again, familiarity with programming and program structures is needed,
     but prior experience with just about any language will serve. There is no
     need here to understand C, Pascal, or anything of that nature.

 15. Cost, Weight 2.  Rating:  1.  The cost of Gamescape is $95 for reg-
     istration plus $5 for shipping, or a total of $100, making this the most
     expensive system reviewed here by a factor of more than two. I wonder
     if anyone has ever registered this product. I certainly don't know what
     would possess them to do so.

 16. Source Code, Weight 2.  Rating: 1. No source code is available for
     this system.

 17. Compiler Speed, Weight 2. Rating: 3. Compiler speed seems aver-
     age; the sample cases are so small that a meaningful measurement really
     can't be obtained, however.  But, given the simplicity of the system, I
     wouldn't expect any issues with compile speed.

 18. Compiler Platforms, Weight 2. Rating: 2. Comments under porta-
     bility apply here.  The system is DOS only, but that does cover a large
     part of the market.

 19. Dynamic Object Creation, Weight 1. Rating: 2. No real facility for
     dynamic object creation exists, however, this can be simulated by moving
     objects in and out of view.


   Summary Comment.  I include this review of Gamescape here only to
show just how far things can go in the world of blatant commercialization,
hype, and inadvertent comedy. I don't know why anyone would ever consider
using Gamescape. It's primitive, limited in scope, and very expensive for what
you get. Enough said.



                                51




5.10   Aventuro

Release discussed: 2.1
Author contact information:  Wim Koolhoven, Rembrandtlaan 125, 7545
ZJ Enschede, Nederlando.
   Description. There is probably no real reason to include a review of Aven-
turo in this document other than to recognize its unique character and its at-
tempt to internationalize| perhaps, denationalize| interactive fiction. Too, I
am a language hobbyist| I've inflicted my brand of German on Volker Blasius a
little too often| and this sort of thing fascinates me. So, bear with me as I u*
 *se
up ink/CRT space/bandwidth to expound a bit on this interesting authoring
system. (Believe it or not, in 1994 my encounter with Aventuro was inspiration
for me to buy some books and learn enough Esperanto to do at least simple
reading.)
   Aventuro was conceived to enable creation and play of interactive fiction
in the Esperanto language.  Esperanto is an \invented" language, created by
Polish scholar Emile Zamenhof in the late 1800s.  Esperantists propose it for
an international language, and it is the only serious international language to
have really taken hold (Interlingua is less known, and Klingon cannot be called
a serious attempt at an international language, even though it now may be
more widespread than Esperanto.) The appeal of Esperanto is its completely
consistent grammar and pronunciation, and relatively simple structure.
   If you cannot read basic Esperanto, Aventuro will be of no use to you. This
will, I suspect, leave out 99.9 percent of interactive fiction authors and play*
 *ers,
but still, here are my comments.


  1. Documentation, Weight 5.  Rating:  2.  The documentation, all in
     Esperanto, of course, is sketchy and lacking in examples.  The language
     is laid out in something that looks like BNF, and with enough study, a
     prospective author could probably put something together.  But better
     documentation would be very helpful.

  2. Ease of Use, Weight 5. Rating: 3. Ease of use for the author looks
     about average for a smaller system. A single input file, with a number of
     sections, comprises the game source file. Rooms, adjectives, direct object*
 *s,
     monsters, text strings, phenomena (actions), etc., are listed by number,
     section by section in the input file. The layout of each item in each sect*
 *ion
     is quite logical, although some rigidity is present leading me to think th*
 *at
     doing complex actions could be fairly difficult.

     A goodly amount of attention was given to allowing for proper expression
     of Esperanto grammar, such as correct gender and plural endings.

  3. Parser, Weight 5.  Rating:  2.  The parser works, which is about all
     you can say. It accepts three word input, subject, verb, and object. It is



                                52




   hard-wired into the code and there is no way to change it at all. If you
   need a flexible or adaptable parser, it's not here.

4. Support, Weight 4. Rating: 1. There is no e-mail address given for
   the author, the system was written in 1988 and the snail-mail address is
   likely invalid (although I haven't checked).  There is no support on the
   newsgroup, although I suppose there is a slim chance of reaching someone
   who has used this system on the newsgroup soc.culture.esperanto.

5. Language Depth, Weight 4.  Rating:  2.  The language is a very
   basic one for interactive fiction design.  A number of verbs and actions
   are hard-wired into the system, although making additions is quite easy.
   The system has a fixed directional movement system which does not allow
   for intermediate directions such as northeast or southwest. Objects may
   have numerous properties but these are all pre-defined, and there does
   not appear to be any means of changing these or adding to them.  (It
   might be possible to do as is done in other languages, namely, using an
   otherwise unused attribute to represent something quite different from
   what the property name describes.)

   The language depth is adequate for smaller, less-complex works. But you
   aren't going to write Jigsaw or even Trinity with this system.

6. Portability, Weight 4.  Rating: 2. There is no portability, period. I
   rate this 2 instead of 1 because the executables work on DOS systems,
   which comprise something like 90 percent of the potential audience. But
   beyond this, forget it. And the audience is limited to people with reason-
   able Esperanto fluency. (This assumes you write your game in Esperanto.
   There is nothing to stop you from using this system to write a game in
   English, but this would be a rather odd system choice in such a case.)

7. Run Speed, Weight 4.  Rating:  4.  No problems here.  Again, a
   relatively simple system should not have execution speed difficulties.

8. Literature Library, Weight 4.  Rating: 1. There is no source code
   literature available, and the sample data file which was supposed to be
   part of the distribution archive was missing, and I could not find it any-
   where on the Internet or elsewhere. This is a really major handicap; given
   the terse documentation, examples are really necessary and there are none
   whatsoever. A compiled game, La Insula Texel, is included with the dis-
   tribution, but there is no source code provided so as an author's example,
   it is not useful.

9. Debugging Features, Weight 4. Rating: 1. There are no debugging
   features. You do it the hard way.



                              53




10. Future Prospects, Weight 3.  Rating: 1. No source code, no news-
    group interest, no literature available; written for Esperanto speakers onl*
 *y;
    no e-mail address for the author; what more need be said? Aventuro was
    a nice idea, but it's pretty much a dead system.

11. Object Orientation, Weight 3. Rating: 2. Although there is no im-
    plementation of an object-oriented paradigm, the manner in which things
    are grouped in the input file gives at least a little of an object-oriented
    flavor. There is limited cloning and inheritance in certain situations; see
    the section below on Dynamic Object Creation.

12. Game Size, Weight 3. Rating: 3. I could not readily determine the
    limitations on game size; the documentation is silent on this point (and on
    a lot of other points too). The games run memory-resident so the outer
    limit is of course free DOS memory.  Internal limitations probably exist
    but were not tested. I solicit input from any reader of this FAQ willing to
    construct some tests.

13. Distribution Policy, Weight 3.  Rating:  4. Non-commercial distri-
    bution of games and the run-time is explicitly permitted, and I imagine
    that, as is usually the case, this covers shareware as well. Commercial dis-
    tribution specifically requires the written permission of the author. Good
    luck trying to find him.

14. Programming Skill Required, Weight 3. Rating: 4. An \average"
    amount of programming skill is required to use this system. It differs litt*
 *le
    in skill requirements from AGT and similar number and group oriented
    systems. This is again not to say that no programming skill is required.
    Such a system simply doesn't exist. But Aventuro doesn't require prior
    knowledge of C, Pascal, etc.; just familiarity with programming concepts.

15. Cost, Weight 2. Rating: 5. It's free.

16. Source Code, Weight 2.  Rating: 1. Completely unavailable; might
    not even exist any longer!

17. Compiler Speed, Weight 2. Rating: 4. Well, honestly, I didn't test
    this, since there are no test cases and I didn't want to take the time to
    develop one. Any interested reader is invited to help out. But from the
    looks of the language I don't think compilation speed can be an issue.

18. Compiler Platforms, Weight 2.  Rating:  1.  It runs under DOS,
    period, with no possibility of creating other versions.

19. Dynamic Object Creation, Weight 1.  Rating:  3.  Here is some-
    thing really amazing: the phenomena choices (hard-wired actions) include
    creating new adjectives and monsters, including making modified copies



                               54




     of existing ones.  Of course, these have to be defined in advance, so in
     one sense it isn't truly dynamic object creation; nevertheless, this is an
     unexpected feature.

   Summary Comment. Even putting aside the question of fluency in Es-
peranto, this would not be a system which would be a reasonable choice for a
prospective author. There is simply not enough documentation and no examples
to guide the way. And, returning to the language question, if you did manage
to complete a game, who would play it? Perhaps Esperantists would all play
it merely because it exists, but there would be little other opportunity to have
your work enjoyed by the public.



6   Final Remarks


In choosing an authoring system, it is unlikely that one will err in choosing e*
 *ither
of the Tier 1 systems, TADS and Inform. Choosing between them comes down
to determining which individual criteria are important to you, your writing and
programming style, and the particular work you might have in mind.
   Perhaps you believe strongly in the free software philosophy, or wish to
undertake a commercial project without seeking further licensing. Inform might
then become your choice. Or, perhaps strong object orientation, sheer speed,
and a choice of libraries may be your main concern, and in such an instance you
may choose TADS.
   But it's quite clear, and rec.arts.int-fiction postings seem to show with-
out much doubt, that you will not go wrong with either of the Tier 1 systems.
It's very much a matter of choosing one, staying with it until you are comforta*
 *ble
and learn it well enough, and carrying through to produce your work.
   Still, it is not out of the question to choose one of the better Tier 2 or U*
 *n-
processed Tier systems. ALAN, a traditionally under-appreciated entry, offers
ease of learning and a kind of classic elegance at the expense of richness of f*
 *ea-
tures; but for someone with a less technical programming background, or for
projects which are more straightforward, ALAN could indeed be a fine choice.
One might wish, in fact, that it were used more than it is today. AGT, although
older and with more limitations, has been the vehicle for countless excellent IF
works, and would still serve today for many projects. Hugo is an up-and-coming
language and deserves watching, and, perhaps, a good look to see if it meets
your needs. Archetype also has possibilities and one can hope that the author
finds time to develop it further.
   Choosing a Tier 2 or Unprocessed Tier system does, of course, mean that the
prospective author is assuming some increased risk, particularly in the areas of
run-time compatibility and feature sets. Whether that risk is sufficiently offs*
 *et
by ease of use or some other criterion again becomes a personal choice.
   Choosing a Tier 3 system is not recommended for most authors or projects.
Yet, it is not out of the question on an experimental basis or for some special



                                55




reason. GINAS provides a fascinating framework and it might be interesting to
attempt a piece with it just for fun.  LADS, while a primitive system by any
standard, produces games which have a \Scott Adams" feel, and it might be
interesting to try it as an exercise in minimalism. But, beyond this, most of t*
 *he
Tier 3 systems are simply too limiting in too many dimensions to be a logical
choice over a Tier 1 or Tier 2 system. In a few cases, the systems are downright
bad news.
   So, if you've read this far expecting to have the choice of authoring system
made for you, you're at the moment of disillusionment. You won't go wrong in
Tier 1, and you may find something that fits you and your project in Tier 2 or
the Unprocessed Tier. And now, the rest is up to you.



7   Afterword:  How Many Systems Are Enough?


In this paper we've looked at a considerable number of interactive fiction au-
thoring systems, and we certainly haven't covered all of them. There are easily
ten more publicly available systems, and there are probably just as many pro-
prietary systems which were developed at one time or another.  Infocom had
their own Lisp-like language, ZIL; and the trivia award goes to anyone who can
place the King Edward Adventure Language. The list goes on.
   The last year or two has seen the appearance of Hugo, Archetype, and GI-
NAS. Another language, Snack, is reportedly in preparation. Hardly a month
goes by without a newsgroup posting which starts, \I'm writing a new adventure
game language, what would you like to see in it: :?:". Are we reaching the point
of too much of a good thing? Is enough indeed enough? How much attention
will the new languages get? Are we fragmenting the IF author community?
   The current \marketplace" has two front-runners, Inform and TADS. These
are so far ahead of the rest of the pack in terms of usage and attention that
there is little contest. Yet, Hugo promises to deliver and ALAN has its place.
And so on for a few of the others.
   I can't help but feel that if someone wants to develop a new language which
achieves some special purpose, even if purely experimental, or deals with some
perceived lacking of the other authoring systems, then they should be encour-
aged to do so. In the long run I think the generation of new ideas benefits the
IF community, even if a new language is never used by someone other than the
author. GINAS, for instance, isn't going to be a mainstream choice. Yet, the
very existence of GINAS makes available another view into the problem, a view
decidedly different from many of the others.
   There is, though, a most relevant caution raised by one correspondent: you
should be familiar with what has already been done if you wish to do meaningful
new things.
   Interactive fiction is an appealing blend of art and technology. For those to
whom it appeals, there can never be \too much" of any of it.



                                56




8   Interactive Fiction Resources


I'll not try to list the numerous Web pages which are now accessible. Instead,
I'll just mention the major Usenet newsgroup, rec.arts.int-fiction, which
is dedicated to interactive fiction authoring issues.  (Questions about actual
game play belong on rec.games.int-fiction). Electronic magazines about IF
include Eileen Mullin's excellent XYZZY News, copies of which can be found
on the archive site, and Whizzard's SPAG, which concentrates on game reviews
and can also be found on the archive site.
   All of the authoring systems listed here and a wealth of other material,
including games, articles, and newsgroup archives, can be found at the inter-
active fiction archive maintained by Our Hero in Sankt Augustin, Germany,
Volker Blasius.  Access is via anonymous FTP to ftp.gmd.de, subdirectory
if-archive.  Volker has done us all a tremendous service in organizing this
archive and keeping it up to date.
   Finally, I can't pass by the opportunity to give a plug for my own IF resour*
 *ce
on my dial-up bulletin board system, GobblerNet Adventure Games. Located
in Bismarck, North Dakota, the home of the eternal frost, GobblerNet has on-
line most of the resources of the Internet archive site, and many other materia*
 *ls
including a very large ZZT collection. GobblerNet can be reached at 701-222-
0429. This is, of course, a long-distance call for just about everyone!



9   Disclaimer


The author of this FAQ document has made a good faith effort to provide
accurate information, but assumes no responsibility of any kind for any damages
of any type arising out of errors or omissions in the document, nor for any
damages of any kind arising from the usage of this information in any manner
whatsoever. You must evaluate this information for your own purposes, and you
assume all risks and liabilities in conjunction with its use. The author may not
be held liable for direct, indirect, special, consequential, or any damages of *
 *any
type under any legal theory whatsoever, even if the author has been made aware
of the possibility of such damages. If your house collapses, get it fixed. If y*
 *our
dog dies, give thanks, and cook it and eat it. If fluctuations in the geomagnet*
 *ic
field disturb your rest, consult your physician or psychiatrist.



10    To-Do List


Wishing to release this first version of this FAQ, some things were left undone,
both large and small. I hope to include as many as possible in future versions
(expected to be about twice annually).



                                57




   fflAnother rating category should be added which deals with the \profes-
     sional appearance" of a game produced by a certain system.  Does the
     screen format nicely? Are there special features, such as bolding of text?
     How is the display organized?

   fflReviews of other, older systems such as ADL, AdvSys, etc., should be
     included. I'll be adding one or two of these at each new FAQ revision.

   fflReviews are needed of newer systems for platforms to which I don't have
     easy access, such as Rexx Adventure for OS/2, etc.

   fflAn effort is needed to make the document less PC-centric. I've been told,
     quite correctly, I fear, that my view is a bit myopic here.

   fflI'd like to publish objective measurements of compiler speed, runtime
     speed, and game size limitations.

   fflI'd really like more input from real experts for the AGT review.

   ffl:a:n:d so much more!



11    Comments on this FAQ


Comments, corrections, additions, suggestions, and constructive criticism on
this document are more than welcome, earnestly solicited, and will be gratefully
received. It is only with your help that the document can be improved and made
more useful. Please email bnewell@gobblernet.sputnix.com. If this doesn't
work please try bnewell@btigate.com, bnewell@delphi.com (which may soon
disappear), or post to rec.arts.int-fiction.
   Snail mail, if you really want to send it, goes to:


      1825 North Grandview Lane
      Bismarck, North Dakota
      USA 58501


   Please include some sort of electronic contact address, as answering snail
mail is likely to be glacially slow, if I even get to it!
   I am always interested in having coffee, a beer, a glass of wine, or even lu*
 *nch
or dinner, with other newsgroup correspondents.  I've met a few of you, and
hope to someday meet more of you when the opportunity presents itself.
   And now, choose your system, write your game, and publish it. We're all
waiting, you know.



                                58




12    Credits


Thanks for assistance of all sorts with this FAQ go to many people, but espe-
cially to Jools Arnold, who suggested I expand my old FAQ; Kent Tessmann,
Cardinal Teulbachs, Thomas Nilsson, Graham Nelson, the correspondents on
rec.arts.int-fiction, and Volker Blasius for all-around inspiration (and also
for being the only fellow on the newsgroup older than I am!).



13    Revision Log


0.1 February 20, 1996. Initial publication.



                                59




_______________________________________________________________________________*
 *_________

|_|___________1|||2_|3_|4_|_5_|6_|7_|_8_|9_|10_|_11_|12_|13_|14_|_15_|16_|17_|_*
 *18_|19_|_|_

|_|_TADS______|4||4_|4_|5_|_5_|4_|3_|_5_|4_|_3_|__5_|_4_|_4_|_3_|__4_|_2_|_5_|_*
 *_4_|_5_|_|
|_|_Inform____4|||4_|5_|5_|_5_|5_|4_|_4_|3_|_5_|__4_|_4_|_5_|_3_|__5_|_4_|_3_|_*
 *_4_|_3_|_|
|_|_ALAN_____|4||_4_|4_|3_|_3_|3_|4_|_2_|4_|_3_|__3_|_4_|_4_|_4_|__5_|_1_|_4_|_*
 *_4_|_2_|_|
|_|_Hugo______3|||4_|3_|3_|_4_|2_|4_|_3_|4_|_4_|__4_|_3_|_3_|_4_|__5_|_4_|_3_|_*
 *_2_|_4_|_|
|_|_AGT_______|5||3_|4_|2_|_3_|3_|4_|_5_|3_|_2_|__2_|_3_|_5_|_4_|__5_|_4_|_4_|_*
 *_3_|_2_|_|
|_|_Archetype_3|||4_|3_|2_|_3_|2_|4_|_2_|3_|_2_|__4_|_3_|_4_|_3_|__5_|_4_|_3_|_*
 *_2_|_5_|_|
|_|_GINAS_____|3||3_|2_|3_|_3_|3_|4_|_2_|3_|_3_|__5_|_3_|_3_|_2_|__5_|_4_|_4_|_*
 *_4_|_4_|_|
|_|_LADS______|3||2_|2_|2_|_1_|2_|4_|_1_|1_|_1_|__1_|_2_|_3_|_2_|__5_|_3_|_4_|_*
 *_2_|_1_|_|
|_|_Gamescape_|3||3_|1_|1_|_2_|2_|4_|_1_|1_|_1_|__2_|_3_|_2_|_4_|__1_|_1_|_3_|_*
 *_2_|_2_|_|
|_|_Aventuro__2|||3_|2_|1_|_2_|2_|4_|_1_|1_|_1_|__2_|_3_|_4_|_4_|__5_|_1_|_4_|_*
 *_1_|_3_|_|_


                 Table 1: Ratings by Category Matrix



14    Summary Table


Evaluation categories by number:

   1 Documentation

   2 Ease of Use

   3 Parser

   4 Support

   5 Language Depth

   6 Portability

   7 Run Speed

   8 Literature Library

   9 Debugging Features

  10 Future Prospects

  11 Object Orientation

  12 Game Size

  13 Distribution Policy

  14 Programming Skill Required

  15 Cost

  16 Source Code

  17 Compiler Speed

  18 Compiler Platforms

  19 Dynamic Item Creation



                                60
