Interactive Fiction Main Page My IF Games Return to MusicWords Home Page

TADS 3: A Few Observations

After writing a couple of games in a programming language called Inform (Inform 6, to be precise -- a very different kettle of fish from Inform 7), in December of 2006 I switched to a language called TADS 3. Recently I received an email from another Inform user inquiring about how I would compare the two. But wouldn't you know it, the spam filter at his office wouldn't let my response through. (Do you suppose all those references to ... no, you'll have to use your imagination. Anyway, there weren't any.)

So I figured, as long as I'm having to employ an alternate methodology for information delivery, maybe somebody else would wonder the same thing. Here's an edited version of my response. Opinions are strictly my own, many are based on ignorance, and all are subject to change without notice.

If you're not familiar with IF programming, this page will make no sense to you whatever.

TADS 3 is what I'd call an "expert system." What I mean by that is, first, that there's a lot of stuff to memorize. For example, when do you use initDesc, specialDesc, or initSpecialDesc instead of desc? Those four description properties are all defined in the library, and they're used in different situations, as are things like stateDesc.

Another example: What's the correct way to format an illogicalNow macro? Learning TADS means letting tons of stuff like that sink into your brain. This is not going to happen within a few days.

Related to the memorization issue, TADS 3 is extremely declarative. It's loaded with classes, templates, and macros, which you will often use instead of writing your own code. Situations that in Inform 6 or TADS 2 would call for writing a few lines of procedure (lines ending with semicolons, let us say) are often handled in T3 by grabbing a macro. You need to understand when to use a given macro, how to format it, and what its results will be.

With library classes, it's of prime importance to understand which class to declare first in the list when defining an object. For example, this declaration:

bookcase: Container, Fixture

...will not necessarily produce the same results at run-time as this one:

bookcase: Fixture, Container

The logic of multiple inheritance is clearly spelled out in the documentation, as are the details about which library classes inherit from which other classes but when applying that logic and information to specific situations such as this particular bookcase and how it will respond to specific verbs, you're on your own.

The documentation makes a valiant attempt to wrangle three tons of information into useful form, but there are gaps. The fact that there are four or five separate manuals means that there's a lot of flipping back and forth looking for stuff. Quite often, the way to figure out what's going on is to look at the library source code. The good news is, the source code is packed with comments. The even better news is, the source is exhaustively cross-linked from the Library Reference Manual, so you can find almost anything with a few clicks. But even here there's a gotcha: The links to the library macros only show you the definition of the macro. The definition doesn't tell you what the macro will do.

After a month working with the system pretty much every day, and asking at least two dozen questions on rec.arts.int-fiction (all of which, I might add, have been quickly and patiently addressed by people who know TADS inside out), I'm starting to feel that I have a grasp of what's going on. There are still gaps in my understanding, but it's getting better.

So that's the bad news. The good news is that TADS 3 is an extremely powerful system. It's capable of effects that would be much harder to implement in any other language -- not just adding italics to text (though a serious writer will find that indispensable) but creating a more immersive game experience. The whole business of ActorStates, which I've barely started to look at, makes it pretty easy to create NPCs who can respond to what's going on around them: They're not just static objects. TravelConnectors let you do subtle things that, again, would be so awkward in Inform that you'd probably give up, if you thought of doing them at all. The ShuffledEventList is a big improvement over a random list of outputs.

In sum, I like TADS 3 a lot -- but I wouldn't recommend it for everyone. It requires a level of commitment in terms of spending time learning it. And arguably its complexity would make it a poor choice for someone who had no previous knowledge of programming.