Roger Firth's IF pagesHome
But I'm not a programmer...Email
Close window

Extracted from a response by David Librik on 26 November 1999 to the rec.arts.int-fiction thread "Do you need to know a programming language before using TADS?":

Not at all. There's a great deal of nonsense slung around about this subject. TADS is, in fact, exactly as simple as any of the ballyhooed "easy" adventure creators. It's only because it optionally lets you do more that it gets a reputation for complexity.

90% of what you'll be doing in writing a simple adventure is stuff like this -- some room descriptions:

terminal: room
    sdesc = "Terminal"
    ldesc = "You are in the airport's main terminal.  To the east, you
             see some ticket counters; to the north is the main concourse."
    east  = ticketCounter
    north = securityGate
;
securityGate: room
    sdesc = "Security Gate"
    ldesc = "You are at the security gate leading into the main concourse
             and boarding gate areas.  The concourse lies to the north,
             through a metal detector.  The terminal is back to the south."
    north = concourse
    south = terminal
;

... and so on. This is the pattern. You learn the pattern, you write all your rooms this way. Item descriptions are similar. No system really makes this any simpler (what could be simpler, anyway?). Of course, a lot of people think that if their application uses Windows, pull-down menus, dialog boxes, and all that stuff, that everything is just so totally obvious that they're under no obligation to provide any manual beyond a Windows Help file. Such an adventure-writing package is harder to use than a text-based one with a detailed printed manual, like TADS.

What you do have to learn about are the types of things you can have in your game -- these are the built-in TADS object types, or "classes" -- such as rooms and items, and their "sub-classes," or more specific types, like keys, buttons, lights, foodItems, etc. The TADS manual will explain this to you. Each of these things has built-in "properties". For instance, rooms have short descriptions (sdesc), long descriptions (ldesc), and possible exits (north, south...). You set these to be what you want, as you can see in the example above.

So far this is nothing you couldn't do in a stripped-down "easy" system like AGT. Where TADS makes things better is the ability to create your own item types by adding more specialized properties to existing ones, or by combining two existing types. For instance, in the game "Unkuulian Unventure", Dave Leary made a "cheez key" by combining a key item with a food item. Or in my port of "Dog Star Adventure", I decided to make a FlightDeckRoom, which is a kind of room whose description is always "You're out on the flight deck, which stretches away in all directions." Then I could create a bunch of flight deck rooms -- it's kind of a maze -- and not have to specify the description on each one. Here's my FlightDeckRoom specification:

/* This is a general "class" of rooms; a template to knock off copies from.
    This sort of thing is very useful for mazes and other confusing identical
    bunches of rooms -- to help the confusion, it's a "verboseRoom", which
    means that it always prints the full description every time you enter it,
    making it harder to figure out. */
class FlightDeckRoom: verboseRoom       /* somewhere on the flight deck */
    outondeck = true        // out on the flight deck (possibly airless)
    sdesc = "Out on the Flight Deck"
    ldesc = "You're on the Flight Deck of General Doom's battle cruiser,
             which stretches away in all directions. "
;

This is getting close to programming. But it's not programming in the sense of BASIC or Pascal or C. There's no coding of algorithms, variables, or any of that. However, notice that I did get to invent a new property, outondeck, which is "true" for these sorts of rooms.

When people say that "TADS is like C," what they're actually talking about is syntax. For instance, in both TADS and C or C++, comments are written /* inside these slash-star symbols */ or // after two slashes. But TADS discards all the things about C that make C hard: there are no pointers, there is no memory allocation, there is no typedef, etc. And it definitely avoids all the C++ garbage except for the idea of classes. It also uses as many syntax features from Pascal (a more readable language) as from C. You don't need to know any Pascal or C or C++ to use TADS for basic game writing.

Now, the more complicated you want your game to be -- the more complex its behavior -- the more you're going to inch closer to programming. The strength of TADS is that, when you need it, programming fits in neatly into the whole system. After all, 'programming' is really nothing more than detailed specification of behavior, described so simply and mechanically that a computer can carry out the instructions. As an author of interactive fiction, you are gonna run up against this sooner or later -- nobody gets to write these games like novels, because their structure is different: player types something, game responds. You have to tell your story by having the game give good responses, and that requires taking care of allll the picky details.

So, here's a picky detail to add. Somewhere else in my game Dog Star Adventure, let's suppose I have an item I call "FlightDeckWindow". Suppose the FlightDeckWindow could be either open or closed. I do this by giving FlightDeckWindow a property, isopen, which can be either true (it's open) or false (it's closed). I won't show that. But, given all that, here's how I could rewrite the FlightDeckRoom I listed above, so it shows the stars if the FlightDeckWindow is open.

class FlightDeckRoom: verboseRoom
    outondeck = true
    sdesc = "Out on the Flight Deck"
    ldesc = {
        "You're on the Flight Deck of General Doom's battle cruiser,
         which stretches away in all directions.  ";
        if (FlightDeckWindow.isopen)
            "Overhead, you can see a million unblinking stars.  ";
        }
;

The string that was the ldesc is now replaced with a little program block, enclosed in braces {...}. That's the pattern that you'll follow when writing your own bits of programming. Also, you can see that every line of code in a program block ends with a semicolon (;), whereas ordinary property definitions (like the sdesc above) don't.

To be honest, I don't think any interactive fiction writing system is going to let you do all that TADS does, but somehow be "easier." If you want to be able to do generally powerful things in describing your game, you have to have some sort of generally powerful programming language. If you don't want to do anything beyond the adventure basics, you could use a simple system like AGT -- but you could also use TADS without any complicated constructs, just as easily.

Copyright © 1999 by David Librik