TADS Overview: The Object Library
TADS includes an extensive collection of pre-built objects designed for writing IF. This is known as the Adv3 object library. The library objects are written in the TADS language, so you can readily examine and customize everything in the library.
Adv3 serves two main functions. First, it provides a "world model" for your game world. This is a set of classes for common things you find in an IF setting - locations, characters, containers, light sources, items that can be carried, items fixed in place, doors, things that can be opened and closed, keys, things that can be locked and unlocked, chairs, beds, vehicles, dials, switches, buttons, levers, clothing, food and drink, things that can be read. The classes are extensively implemented, with a sophisticated physical simulation model for light and other sensory data. Adv3 also includes a sophisticated conversation system for character interaction.
Second, Adv3 provides the framework for parsing and executing commands from the player. The library's parser includes about 150 pre-defined verbs, and has a highly modular design that lets you add new verbs and new command syntax of your own. The benchmark for IF parsers even today was set by the later Infocom games, and the Adv3 parser easily clears this bar; it handles automatic resolution of ambiguous nouns, intelligent defaults, multiple nouns per command, complex noun phrases, multiple commands per line, commands to other characters, "again", abbreviated words, pronouns, reflexives, numbers, quoted strings, "all", "all but", possessives, locational qualifiers ("the box on the table"), and a lot more.
The parser uses a powerful grammar processor that can handle the inherent ambiguity of natural languages. Consider "put the coin in the jar on the desk". The parser isn't fazed by the structural ambiguity of this command: it recognizes that this could mean either that we wish to take hold of the coin that's already in the jar, and put that coin on the desk, or that we intend to put some coin into a jar that is itself on the desk. The parser can actually hold both of these possibilities in its head at once, and defers making a decision until determining whether there exists a coin inside a jar, or a jar atop a desk. This sort of resolution of ambiguity isn't a special case for coins in jars; it's a generalized mechanism that the parser uses all the time. When you add custom grammar, you don't have to worry about whether you're creating a syntactic ambiguity, because the parser just deals with it if you do.
The command execution framework is pretty sophisticated in its own right. It includes a mechanism that can automatically carry out "implied" commands, and even chains of implied commands: opening a door in order to walk through it, unlocking a door in order to open it, taking a key out of one's pocket in order to use it to unlock a door, putting a leaflet in one's backpack in order to make room in one's hands for a key one wishes to take out of one's pocket...
Simulation vs storytelling
Adv3 is heavy on physical simulation. Some IF designers see simulation and storytelling as opposite ends of a spectrum in IF design, and see Adv3 as most useful for people writing simulation-oriented games, and less useful for those writing IF more focused on narrative. Just to be clear, that's not the way we see it. The real goal of Adv3's simulation approach is to support your storytelling, by making it easier to get your game to produce the right story text.
How does simulation help produce the right prose? It helps by
automatically figuring how the things in your world model interact,
and producing the right text for those interactions, so that you don't
have to account for every possible situation yourself with
special-case code. For example, the library has extensive modeling
for how light is transmitted through containment levels. Suppose you
have a flashlight, a wooden box, and a room with no other light
source. What happens if the player puts the flashlight in the box,
then closes the box? The room goes dark, obviously, but in a system
with no physical model for light, you'd have to anticipate this case
and write special code for it. Adv3 figures it out for you
automatically. That's the point of the simulation: to produce the
right text output with less special-case coding.
Overview Main | Next: Tools