ONLamp.com    
 Published on ONLamp.com (http://www.onlamp.com/)
 See this if you're having trouble printing code examples


Choosing a Language for Interactive Fiction

by Liza Daly
11/24/2004

Interactive fiction (IF) has variously been called "text adventures," hypertext fiction, or simply "adventure games," and for most people familiar with the genre, it evokes fond memories of brain-teasing puzzles at the dawn of home computers. Zork, Colossal Cave, and hundreds of other similar products defined early computer gaming much like Pong and Pac-Man did for the arcade. Twenty years later, the state of the art in game programming has moved on, but IF has thrived in non-commercial form on the internet. By resurrecting "dead" technologies and expanding the pool of authors and audience, the interactive fiction community has made IF one of the most accessible means to enter the game authoring world.

Maybe you know all of this already. You've read Nick Montfort's scholarly (but accessible) recent book on the topic, Twisty Little Passages. You know all about the annual Interactive Fiction Programming Competition, now in its 10th year, offering dozens of prizes (including $500 in cash). You've played a lot of games and have your masterpiece fully realized in your head. Now you're ready to choose an interactive fiction programming language.

What Is an IF Language and Why Would I Want to Use One?

The other thing you already know is a dozen programming languages, half of which you'd like to forget. Besides, the challenge of writing a natural-language parser and implementing a fully-realized world model could be fun. Why learn a new language so specialized that one can hardly use it for anything else?

IF languages have various structural and syntactic optimizations for writing games. Turn-based time (or even, in some cases, real time) is a built-in. It's easy to define conditions on which the game can be won or lost. An IF language already knows not only that GET HAMSTER means the player would like to perform an action called GET on an object called HAMSTER, but it also knows that PUT HAMSTER ON TABLE is an entirely different matter than PUT TABLE ON HAMSTER and that PUT NORTH ON HAMSTER is something altogether nonsensical. While it's not always the first thing on one's mind when composing the greatest interactive fiction work of all time, it's great that an IF language will handle the dreary work of allowing your users to save, restore, or quit the literary experience of a lifetime.

Related Reading

Gaming Hacks
100 Industrial-Strength Tips & Tools
By Simon Carless

Managing the game loop, parsing the input, and handling the meta-game are all great assets in IF programming, but the big win for the developer is in using the languages' standard libraries. Programmers are familiar with the benefits of using a GUI toolkit and its built-in model of windows, buttons, and sliders. IF libraries are great at modelling the real world. They arm your development environment with the nitty-gritty details of physical existence that your computer otherwise knows nothing about: that dropping an object means it falls to the floor or that leaving a room means the player can't still pick up something in it (but that she may still be able to see it). By providing a coherent built-in virtual reality, the player (and an infinite variety of non-player characters) can have a fair shot at experiencing a predictable world where a door once opened can't be opened again. For you, the game author, it means that you can stop worrying about gravity and get to the heart of your game: its story. Of course, if you've set your story in zero-g you'll need a language flexible enough to give gravity a pass.

Choosing a Language

Ever since the first adventure games, there have been toolkits and languages with which to build them. Early commercial attempts, aimed at non-programmers, were generally too primitive to produce quality output. Hobbyists have since gone much further, recognizing that IF games of merit will always have a certain degree of complexity and that the languages will need to reflect that complexity. This doesn't mean that the language's syntax need be opaque, although that did not stop the giant of 80's commercial IF, Infocom, from producing classic games in their own language (ZIL):

<ROUTINE TRAP-DOOR-F ()
    <COND (<AND <VERB? OPEN>
                <NOT <FSET? ,TRAP-DOOR ,OPENBIT>>>
           <FSET ,TRAP-DOOR ,OPENBIT>
           <COND (<IN? ,TORCH ,PLAYER>
                  <MOVE ,TORCH ,HERE>
                  <SETG P-CONT -1> ;"flush inputs"
                  <TELL "Your torch slips out of your hands as       
                         you open the heavy trap door." CR>)
           (T
             <TELL "Oomph! You open the trap door. It 
                    sure is heavy!" CR>)>)>>

Lisp hackers might be comfortable with such syntax, but ZIL had no objects, no libraries, and these days, no compiler. There are better ways.

Although authors have pushed the boundaries of the genre for years, there is a core set of features that a work must have to claim the title of interactive fiction. To that end, the game Cloak of Darkness is a kind of reference implementation for any language purporting to handle IF conventions. "Darkness" is not a game in any meaningful sense except that it exercises basic features of the IF world: rooms which may be lit or dark, takable or immovable objects, and a winning state. The project allows the comparison of wildly different languages across a common standard. If you understand just one IF language, it becomes easy to see how others approach the same problem. That is, if you don't mind studying 17 more languages.

Narrowing the Field

There seem to be a lot of choices, but for prospective authors who are already programmers and who will want some measure of flexibility, choosing is easier. First, an IF language should be object-oriented. OO is a natural choice because IF is largely about manipulating objects. An object-oriented IF language (or more commonly, its standard library) will model the real world in terms of classes and subclasses which help to build the "stuff" of the game world. C++ or Java can do this too, of course, but an IF author rarely wants to write some kind of abstract class when a singleton would work just as well. Although there are times when you might want the game to be able to produce an infinite number of identical monkeys, it is convenient for you (and no doubt for the player) that the IF languages assume when you create a "slavering man-eating troll," you're creating just one of them.

A logical assumption is that great languages can produce great games. At the very least, it demonstrates that such languages make great games possible. The Interactive Fiction Ratings site provides a wealth of such data: three languages produced all of the top 50 games. For the purposes of brevity, we'll narrow that a little further and consider popularity.

Of the games entered in this year's competition, 31 out of 35 used one of two language systems, Inform (by Graham Nelson) and TADS (by Michael J. Roberts). TADS was the first IF language to gain wide acceptance and has remained popular ever since. Released six years later, Inform has consistently attracted a wider audience. Examining them in detail can be instructive.

From Cloak of Darkness, a description of a hook on the wall:

TADS 2

hook: fixeditem, surface, item
  sdesc = "small brass hook"
  ldesc =
  {
    "It's just a small brass hook, ";
    if (cloak.isIn(self))
      "with a cloak hanging on it. ";
    else
      "screwed to the wall. ";
  }
  noun = 'hook' 'peg'
  adjective = 'small' 'brass'
  location = cloakroom
;

The first line defines the object (hook) and lists its superclasses from the TADS standard library. The remaining lines are unique properties of the hook object, including its long description. When the player types EXAMINE HOOK, the description changes depending on whether another object, the cloak, is hanging on it. The other properties tell the game parser which words the player can use legally in referring to it (noun, adjective) and which room contains it (location).

The equivalent code in Inform is similar in many respects:

Object  hook "small brass hook" cloakroom
  with  name 'small' 'brass' 'hook' 'peg',
        description [;
            print "It's just a small brass hook, ";
            if (self == parent(cloak)) "with a cloak hanging on it.";
            "screwed to the wall.";
            ],
  has   scenery supporter;

The first line describes the parent class (Object, although multiple inheritance is possible), the name of the object, its short description, and the object's location. The Inform directive has lists attributes of the class that describe its behavior. Properties, declared following with, include both nouns and adjectives used by the parser as well as the hook's long description.

The Inform syntax is, depending on your viewpoint, highly approachable or overly baroque. Its English-like lexicon is one reason why Inform has generally dominated the field in terms of use. However, its flexibility and powerful world model have also enabled some of the genre's best works; in eight years of the IF competition, an Inform game has failed to place first only once. Inform has tended to appeal to authors from more humanistic or literary fields, a bonus for games consisting largely of text.

Inform's other appealing quality is that it compiles to the Z-machine, the same virtual machine originally developed by Infocom and later reverse-engineered by enthusiasts. Designed with the 80's 8-bit computers in mind, the Z-machine is extremely portable, playable even on PalmOS. That portability can come at the expense of scalability; even with ever-larger versions of the Z-machine, Inform authors often find themselves bumping into memory limitations in the virtual machine. The introduction of Glulx, an alternative virtual machine with multimedia support, has ameliorated this problem somewhat, but Inform reflects in its basic design some limitations of the Z-machine which programmers may find restrictive.

TADS compiles to a virtual machine as well but one without historical restrictions. There are TADS interpreters for any imaginable computer operating system but not for small devices. Most support TADS's multimedia capabilities; they're based on HTML and easier to approach than Glulx's more advanced system.

TADS is programmer-friendly in several ways: the developer kit includes a fantastically useful graphical debugger, and the syntax will be more familiar to developers with a background in C-like languages. Compare the syntax for generating an array (Inform) or list (TADS) of numbers:

TADS

my_list = [ 1 2 3 ];

print my_list[1];  // evaluates to "2"

my_list[3] = 4;    // the list can be dynamically enlarged

INFORM

Array my_array --> 1 2 3;

print my_array--> 1;  ! evaluates to "2"

my_array-->4 = 4;     ! returns an error; array sizes must be predeclared

It may come as a surprise, but until recently, I was an Inform programmer. Inform has always been freeware; TADS was originally shareware. Graham Nelson's manual for Inform, "The Inform Designer's Manual," is unlike any other language reference, highly literate and freely intermixing design theory and language definition. TADS 2 has several serious limitations: the parser and library are inseparable, making non-English games nearly impossible, and no game can compile without a standard IF game loop in place, limiting the possibility of true experimentation. The forthcoming TADS 3 addresses these issues.

Coming Soon

The current official release of TADS is version 2, but version 3 is in the last stages before final release. It's largely stable. It is a complete rewrite of the core language, VM, and library with features present in no other IF language: automatic garbage collection, structured exception handling, and Unicode support. The world model is the richest in IF yet; in most libraries, objects are generally "seen but not heard," but TADS 3 allows them to be fully realized by all senses and for sense properties to propagate in a realistic manner. If you are interested in exploring TADS, I recommend jumping directly into TADS 3.

Inform development has been incremental since the 1996 release of Inform 6, but Inform 7 is in the works. It is not clear what direction the language will take, but it is likely that the new version will overcome some of the limitations derived from the Z-machine. More radical changes may unite some of the rigor of TADS with the approachability of Inform, an appealing synthesis for authors of all skill levels.

Dive into Interactive Fiction

Enough comparisons. What advice do you need to know before you start in on your masterpiece?

Liza Daly is a software engineer who specializes in applications for the publishing industry. Currently Liza is an independent consultant and the founder of threepress, a platform to produce open source publishing tools. She has been programming interactive fiction since she was nine but no longer recommends Commodore 64 BASIC or the color pink.


Return to ONLamp.com.

Copyright © 2009 O'Reilly Media, Inc.