Preface

TADS is a computer programming language system created especially for writing text adventures. The syntax and structure of the language are designed to make sophisticated adventure games simple and convenient to implement. TADS provides a complete run-time system with all of the features required for a professional adventure game, so the game author can concentrate on his adventure and not on the underlying software.

This section provides an overview of TADS, of text adventures in general, and of this manual.

The first text adventure game was called, appropriately enough, Adventure. The game was an interactive simulation of a cave. The player interacted with the game by typing commands such as "north" and "get rod," and the game responded by describing the consequences of the commands.

In many ways, Adventure was quite rudimentary; each player command was limited to one or two words, and the range of possible actions was quite small. However, Adventure was different from any game that had gone before it, on a computer or otherwise, and it quickly attracted a large following. The game became so popular, in fact, that it spawned an entire genre of games, called "adventure games" after the first of their kind. As the genre has matured and computer hardware has become capable of supporting more sophisticated programs, many improvements have been made to adventure games, but the basic ideas have remained largely unchanged.

Adventure games appeal to a wide audience. Unlike most arcade-style games, an adventure can be won, and it can take many days, or even weeks or months, to finish a game. At their best, adventure games are rich stories in which a player can become immersed.

Many people are so intrigued with the adventure game genre that they'd like to write adventures themselves. Most people who start writing these games, though, quickly become overwhelmed by the large amount of code that must be written. To write an adventure, a potential author must first write a parser to read player commands, write code to save and restore games, set up data structures to simulate the objects in the scenario, and write many other complicated routines. Not all imaginative people are computer experts, so many potential adventure authors are discouraged from trying their hand at the genre.

Fortunately, the most complex operations that an adventure game must perform are the same, or very nearly so, in every game. Some people interested in adventure game development have discovered that these common operations - displaying messages, checking and setting states of game objects, saving and restoring games, and so forth - could be done by common subroutine libraries that are shared by any number of games. Others have taken this idea further, realizing that a special-purpose language designed specifically for text adventure implementation could simplify game authoring. TADS is such a language.

Authors writing games with TADS will realize several benefits over writing games in a general-purpose language. Some of the advantages of using TADS are:

• A great deal of code is already written for you: a full player-command parser, which supports multiple objects in a single command, multiple commands on a line, use of the word "all," and many other sophisticated features; file manipulation code to save and restore games; code to save a transcript of a game to a file; string compression logic that reduces the disk and memory space required for a game; user-interface code; and many other functions that would be time-consuming to write from scratch. Hence, the game author can concentrate on the game, and ignore the low-level utility code that supports it.

• TADS source code requires no modification to be compiled on any computer where the TADS system runs. TADS is available on many computer systems, which means that games are automatically portable to many computers with no effort beyond file transfer. Furthermore, with TADS version 2, the compiled binary game file is fully portable, so you don't even need to recompile your game when moving it to a new system. While porting a game written in a general-purpose language generally requires substantial work, TADS programs will always run the same way in every environment without any changes.

• It is much easier to write a game in TADS than in a general-purpose language, because TADS is specifically designed for text adventures. The language has several constructs aimed at making adventure games convenient to write, and the object-oriented nature of the language makes game design natural. Furthermore, the standard object classes provided with the system are designed so that common components of adventures can be implemented with practically no coding. So, even if all of the support code and portability that TADS offers were available in a general-purpose language, the syntactic and structural efficiency of TADS make it superior for text adventure implementation.

TADS Version 1 was a very successful and useful piece of software, but there's always room for improvement. We wanted to make TADS even more flexible and powerful, and we wanted to address many of the suggestions that users of version 1 made for enhancing the system. Some of the more important features that are new in version 2 are listed below.

• Virtual Object Cache: one of the most important new features in version 2 is a virtual memory subsystem that allows your game to be bigger than available memory. Instead of requiring your game to fit into memory all at once, as version 1 did, TADS version 2 only requires the objects that are being used at any given time to be in memory. Other objects are stored in a disk file. This new feature makes it possible to run an enormous game on a computer with little memory, and makes the capacity of TADS version 2 effectively unlimited on all computer systems.

• Undo: the run-time system now allows a player to "undo" commands. Unlike some adventure game systems, TADS keeps large amounts of undo information, allowing the player to undo many turns (over a hundred in the default configuration). Undo should make games a lot more fun to play, because it will remove the tedium of having to save and restore frequently when trying dangerous things.

• Additional C-like Syntax: TADS version 2 adds many new constructs from the C language. The for, do-while, switch, and goto statements are now supported, exactly as in C. Local variables can be initialized in their declarations, and you can have multiple local statements at the start of a block. The operators `+=', `-=', `*=', `/=', `++', `-', and `,' (the comma operator) have been added, and behave as in C (with the extension that += can be used with lists and strings, and -= can be used with lists).

• Implicit self: when evaluating or assigning to a property of self, you can now omit the "self." prefix on the property - the property name can simply be used as though it were a local variable.

• Property and Function Pointers: you can now store a "pointer" to a property or function in a variable, and then use it to call the property or function.

• Status Line Customization: you can now display whatever you want in the score portion of the status line. You can display any text string in this area, allowing you to display the time of day, the player's rank, or whatever else you want in place of the standard score and turn-counter display.

• Highlighted Text: games can display text that is "highlighted." On some systems, this text will appear in a different color, while on others it will appear with a different typeface (bold or italic).

• Version 2 is a nearly complete rewrite of TADS. Fortunately, we only wanted to improve TADS, not replace it, so we made sure that games written for version 1 will continue to work with version 2. Games written for version 1 will automatically take advantage of many of the new features in version 2, such as the Virtual Object Cache and run-time Undo. Authors of new games written with version 2 will have access to even more, such as additional C-like language syntax.

This document is intended for game designers who wish to implement games using TADS. This manual will try to describe the system in such a way that no prerequisites are imposed on a potential author, but you'll have the easiest time learning to use TADS if you're already familiar with a traditional structured language such as Pascal or C. Familiarity with the concepts of object-oriented programming will also help.

Here's an overview of the contents of this book:

• Chapter One leads you through a sample game, so you can see the big picture of how a TADS game works.

• Chapter Two explains object-oriented programming in general. TADS has been heavily influenced by this style of programming.

• Chapter Three is a detailed introduction to the language.

• Chapter Four describes the run-time environment of a TADS program; in particular, this chapter describes the player command parser.

• Chapter Five is a reference to the TADS language.

• Chapter Six describes the process of writing a game with TADS, from inspiration to implementation.

• Chapter Seven describes how to implement a variety of common adventure game elements, and includes many examples of how to write TADS programs.

• Several Appendices provide additional details on several topics: using the compiler, error messages, the standard adventure definitions, and how to design a good adventure game.

To use this manual to learn TADS, you should start with Chapters One and Two, but just to get the flavor of the system; don't worry about understanding all of the details right away. You should then proceed to Chapter Three to become familiar with the language. While you are reading this chapter, it may not seem immediately clear how to write an adventure with the language; for now, just try to get an overview of the language. Then, read Chapter Four, which describes how you use the language to write an adventure; this chapter explains the TADS run-time environment in general, and the player command parser in particular. While learning TADS, you will almost certainly find it useful to refer frequently to the lengthy sample game provided with the TADS software, since it has many examples of how the TADS language constructs are used in an actual game.

Chapter Five is reference material, describing the TADS language in detail. This chapter is not intended to be a tutorial, but is designed to provide easy access to the details of writing a TADS game. Likewise, the several Appendices document the microscopic details about the darker corners of the system, such as compiler options and error messages.

The Text Adventure Development System represents many years of work, not the least of which was the preparation of this documentation. I wish to thank the many people who have contributed to this project. Jim Cser used an early version of TADS to write the now-classic High Tech Drifter, and Steve McAdams worked with me on Deep Space Drifter; the experience gained in implementing these full-scale games was invaluable. I also wish to thank the several people who reviewed this manual and play-tested the sample game that is included with the system, and the many other people who have offered advice in the course of the project.

I want to thank the many users of version 1 for their comments and suggestions, and for encouraging me to continue supporting and improving the system. Special thanks to David Baggett, Chris Nebel, and David Leary, authors of the Unnkulian series of TADS games, for their help in testing TADS Version 2, as well as their enormous contribution to the popularity of TADS by demonstrating how good a TADS game can be; and to Andy Miller for the awesome Mount TADSmore cover art.