This file is part of the TADS 2 Authors Manual.
Copyright © 1998 - 2002 by Michael J. Roberts. All rights reserved.
Edited by NK Guy, tela design.
Starting with version 2.2.4, the TADS text-only (character mode) interpreter provides a degree of compatibility with games written for multimedia TADS. This allows you to write a game using some of the new HTML features, and still play the game on text-only versions of the interpreter. So, players that use systems where multimedia TADS is not yet available can still play your game to some extent.
Although the text-only TADS interpreter doesnt understand most HTML formatting sequences, it does recognize a few HTML markups, and it removes any that it doesnt recognize from the text, so that players wont see HTML source code in the output. This wont let you get the full effect of games written for multimedia TADS, but you can at least run HTML games and see the plain text that they display. For games that make moderate use of HTML formatting features, the degradation can be quite reasonable. Note that HTML interpretation only occurs when the game displays a \H+ sequence, which only an HTML-enabled game would do, so non-HTML games are not affected by this processing in any way.
The text-only version supports all of the character-code markups (the sequences that begin with an ampersand, such as &). Note that most character-mode consoles and terminals dont actually support all of these characters; the text-only interpreter will try to provide a suitable system-specific rendering of the markups when possible, and will replace any unrenderable markups with a system-dependent missing character glyph.
The DOS US character set (code page 437), for example, is capable of displaying about half of the standard ISO Latin-1 character markups correctly, uses approximations for about 30% of these, and uses blanks for the remaining 20%. DOS code page 437 does not contain many of the characters beyond the basic ISO Latin-1 character set, so most of the mathematical symbols and Latin-2 characters cant be displayed in this character set.
In addition, the text-only interpreter supports the following tags:
The text-only interpreter also recognizes the <TITLE> and <ABOUTBOX> tags. The interpreter simply hides all of the text and markups between these tags and their corresponding end tags (</TITLE> or </ABOUTBOX>). So, although TITLE and ABOUTBOX dont actually contribute anything to the display formatting in the text-only version, they are harmless, so you can use them in your game without worrying about which type of interpreter is being used.
Note: version 2.2.3 of the text-only interpreter recognized HTML markups when \H+ was in effect, but simply ignored all markups. Starting with version 2.2.4, the text-only interpreter provides the limited support described above.
Note that if you embed HTML resources into your .GAM file, text-only interpreters older than version 2.2.3 wont be able to read your .GAM files. Text-only interpreters version 2.2.4 and later will simply ignore embedded HTML resources. See the resources documentation for details.
When youre designing your game, you may want to consider trying to make the game as compatible as possible with the standard TADS interpreter, since this will maximize your games portability. The multimedia TADS interpreter is not available on as many platforms as the standard interpreter (in fact, as of this writing, multimedia TADS is only available on Windows32 and Macintosh).
Of course, some authors wont be concerned about compatibility. If you want to write a game that takes full advantage of the new features that multimedia TADS offers, you wont want to limit yourself by trying to maintain compatibility with the standard interpreter. These guidelines are only for authors who want to offer some amount of compatibility.
There are two strategies that you can employ when writing a game for compatibility: you can use features that degrade gracefully in the standard interpreter, or you can use special-case code to support the two different interpreters.
Regardless of the approach you choose for compatibility between multimedia TADS and the standard TADS interpreter, you should test your game frequently on both systems as you develop it. This will help you catch compatibility problems quickly as they arise, which has two benefits: first, you wont accumulate a huge and daunting pile of extra work at the end of your game development process; and second, youll quickly develop a sense for what sorts of things to do and what to avoid, which will make it easier to write for maximum compatibility as your game progresses.
Many HTML markups can be used in such a way that they wont be too badly missed if simply omitted. For example, most of the text style markups (such as <I> for italics and <FONT> for setting typeface characteristics) can be omitted without losing too much of the meaning of the text. If you are careful about the formatting markups you choose, and use them with an awareness of how the text will look if theyre ignored, standard TADS users will be able to run your game without noticing any big changes, except that the text styling may look less interesting.
Similarly, SOUND and IMG markups can often be used purely for atmosphere. If you use your sounds and images to add detail and audio and visual impact to your game, rather than to provide essential information, the standard TADS interpreter can omit these and still leave the game fully playable.
You should be careful of the more complex formatting tags, such as <TABLE> or <BANNER>, the omission of which would substantially alter the layout of your text.
If you need to use markups that cannot be harmlessly omitted, you can still provide standard TADS interpreter compatibility by including a separate version of your code for the text-only and multimedia versions.
You can do this either by using precompiler symbols and #ifdef directives, to produce two different versions of your .GAM file at compile-time, or you can use the systemInfo function to determine if HTML is supported at run-time. (Note that systemInfo always indicates that HTML is not supported for the standard interpreter, even though the standard version does support a limited subset of the HTML features.)
For an example of both of these techniques, refer to the status line code in adv.t. First, this code uses conditional compilation to define either the traditional status line code, or a new version that uses the <BANNER> tag to implement a status line. Second, the HTML version of the code checks at run-time to see if the full HTML feature set is supported, and if not, it falls back to the old status line code.
|Appendix F||Table of Contents|