The experience of a first-time author in TADS 3

This is an analysis of TADS 3 analogous to what I did for Inform 7 in this thread.

The game is still the same, The Prize, which I originally wrote in Inform and have now ported to TADS, fixing a couple of bugs in the process. I’ll wait a while for other possible bug reports to come in before releasing a version 2.

On to the analysis then, which will necessarily be comparative this time.

[rant]Overall, again the experience was positive. TADS is very powerful and offers lots of possibilities. Basically, if you’re good enough, you can do anything you want with it. I’m not really all that good yet, so I had to resort to roundabout measures for some things and long dives into the documentation for others.

The documentation is rather extensive, but hard to navigate. Information is split over several manuals/tutorials, which sometimes duplicate each other, but sometimes don’t. The piece of information you’re looking for can be hiding in any one of them and it’s often hard to figure out which one. Leaving the Library Reference Manual aside for the moment, all the documentation except Learning TADS 3 suffers from a lack of index. Similarly, the tables of contents of unindexed documentation are not all that descriptive. But the biggest problem with all the documentation is that it basically describes library capabilities, but doesn’t really discuss how to accomplish various tasks (in Inform this function is served by the Recipe Book). Again Learning TADS 3 is somewhat better at showing how to do things, but it still focuses on just presenting your options. For example, I tried to figure out how to remove the scoring system completely from the game. I think I remember reading about it somewhere, but I never found any documentation on the matter. After diving into the library source code, I finally managed it.

And that leads us to the real issue here. The Library Reference Manual and source diving are pretty much required. Now for me this is not a problem, but I can imagine that a non-programmer would not want to do it. The Library Reference Manual describes most of the properties and methods of the library classes, but it doesn’t show the interconnections between them, leaving you to wonder, what any of the actually do in the grand scheme of things. For example, there are various methods that determine whether an object can be touched, but when I tried to use them, their results didn’t seem to have any effect on anything. I finally found a library class that did exactly what I needed, but it took time.

Let’s look at the world model of TADS. When people say that the TADS world model is more complex than Inform’s, they probably mean that TADS implements more items with different behavior than Inform does. This is true, but it’s not the only thing that contributes to the complexity. In my opinion, the biggest strength of the TADS library is that it’s incredibly self-consistent and foolproof. By this I mean that if you are careful in using the right hooks to add behavior, it will work in all kinds of special cases. In Inform you have to be more careful in taking all cases into account. The fact that the TADS library has more behavior in the first place helps a lot too.

Because of the complexity of the world model, I found it rather difficult to modify specific aspects of default behavior. In Inform, when it’s possible at all, it involves replacing a rule with your own. In TADS, you have to first find the place in the library where the behavior takes place, and then probably replace a whole method, which contains a lot of irrelevant code. Finding the right place is the real difficulty here. That being said, I like the default behavior in TADS quite a bit better than Inform. This includes implicit action handling and reporting, reporting the contents of containers and supporters, handling commands with topics, and so on.

When writing computer programs, you can usually use a library as a black box. You put something in and you get something out, without having to worry about what goes on inside it. Sadly, you can’t treat the TADS library that way. To be effective at using it, you have to understand how it works, sometimes in detail. It feels almost like you are writing a library for the TADS program to use in its own operation.

A few words about the parser. It is really annoying to define any non-standard phrases that a player might use to refer to an object. What in Inform would be a simple understand rule, in TADS takes the form of a lengthy grammar definition. I still don’t really understand, what’s going on there, I just used the technique presented in the Technical Manual as a recipe. On the same subject, I couldn’t figure out a way to add synonyms to existing actions. Instead I had to create a completely new action and just redirect it to an existing one.

But the actual handling of actions makes a lot of sense to me. At its core, action processing has three parts: verify, where you figure out what objects a command refers to and catch obviously unsuitable uses of a command; check, where you forbid a command due to special circumstances; and action, where the effects take place and a report is displayed. In Inform, it’s more nebulous, with verify and check merged together in check and action split in two into carry out and report. That’s fine, but there’s also Inform’s instead rulebook, which seems to duplicate check under some circumstances. In TADS, every part of action processing has its place and purpose.

Now let’s talk about the convenience features. I am using the TADS Workbench for Windows, and even that is lacking compared to the Inform IDE. There is no analogue to spellchecking, index or transcript of Inform. Those are all really useful features, which all help eliminate errors from the code. The Workbench has something resembling the skein in its automatic script recording, but that feature isn’t as developed. TADS is much faster than Inform, both in compilation, and in running a previously recorded set of commands.

Debugging is an area which surprised me. Turns out that debugging in Inform is much easier. Inform provides several very useful debugging commands, which TADS lacks, even with its debug actions extension. I’m talking about commands like SHOWME and RULES, which let you take a peek behind the scenes. TADS provides the standard debugger that can step through the code one line at a time, which sounds amazing, but isn’t actually all that useful. The problem is again the complex library - you’ll invariably get bogged down in the ridiculously deep call stack that the library code generates. You’ll be stepping through the library code with tons of internal variables containing objects you never thought were even involved, while your own code, which potentially contains the actual problem is unlikely to be longer than 5 lines.

And lastly, I have to say that writing complex logic is quite a bit easier in TADS than in Inform. Descriptions, one of the most important features of Inform, are used to select objects from a list according to some criteria. In TADS, the same task can be accomplished with the standard methods for lists, which run a function for each member of the list that decides whether it should be selected. The difference here is that slightly more complex descriptions failed to compile for me in Inform, while the equivalent functions in TADS can be of any complexity.[/rant]

In conclusion, TADS has a lot to offer, but only if you are prepared to learn it well. I feel that an experienced author could write a high quality game in TADS faster than in Inform because of the robust and extensive default behavior and the ability to fine-tune any aspect of it. At the same time, a moderately experienced author would be unable to fully use all the features of the language, which is also true for Inform, but to a lesser extent. I haven’t yet made up my mind as to which system I’m going to stick with. I’m not afraid of looking at the library source code in TADS and the complex world model appeals to me. At the same time, the same extensive model is largely available through Inform extensions, though they probably won’t play too well together. Inform provides a more comfortable authoring and testing environment, but TADS is faster. I guess I’m leaning towards Inform, but TADS is not out of the question for me yet.


Having written games in both systems, I agree with your assessment pretty much across the board.

One item that you left out is Inform’s tendency to get confused about object references in your code. This happens because when you create an object, the words you use create both the code name and the player-accessible vocabulary. (You can override this using “privately named” and “understand,” but it’s a pain to do that over and over.) TADS never confuses code names with vocabulary, and I find that an advantage.

The moment you find yourself wanting to create a room named “On the Muddy Path” you’ll start to appreciate the TADS approach.

Inform’s ability to construct a world map by connecting rooms based on inference is another significant difference. For the novice author, this is a very nice feature. But when you need to create non-standard room connections, you have to arm-wrestle Inform just a bit. With TADS, the issue never arises, because all room exits are created in your code.

Inform uses single inheritance; TADS has multiple inheritance. Multiple inheritance is a potential area of confusion (especially when you start using mix-in classes!), but once you understand it, it will simplify your code in nice ways. In Inform, if you want a switchable vehicle, for instance, you have to make the switch a separate object that’s a part of the vehicle, because a single object can’t inherit from both classes. There are fairly simple ways around this with switchables – I’m just using that as an example.

I wish Workbench was cross-platform, and I agree that a showme command would be nice. (You can write one yourself, by the way. There may even be an extension for it.) The rules command is more or less duplicated by the stack trace in Workbench.

Personally, I prefer T3, but I can see why it’s not everyone’s cup of tea.