| ModuleIDclass | modid.t[37] |
| Superclass Tree | Subclass Tree | Global Objects | Property Summary | Method Summary | Property Details | Method Details |
An easy way to implement a CREDITS command is to define a ModuleID object for the game itself, and override the showCredit() method to display the text of the game's credits. The module object for the game itself should usually have a listingOrder of 1, because the author usually will want the game's information to be displayed first in any listing that shows each included library module (such as the VERSION command's output).
class
ModuleID : object
ModuleID
MetadataModuleID
GameInfoModuleID
GameID
byline
htmlByline
listingOrder
name
version
getModuleList
showAbout
showCredit
showVersion
byline | modid.t[42] |
htmlByline | modid.t[43] |
listingOrder | modid.t[143] |
The value 1 is reserved for the game's own ID object. Note that the TADS 3 library defines a module ID with listing order 50, which is chosen so that the main library credit will appear after the game credits but before any extension credits using the default order value 100 that we define here. Extensions are free, however, to use a number lower than 5 if they wish to appear before the main library credit.
name | modid.t[39] |
version | modid.t[46] |
getModuleList ( ) | modid.t[149] |
showAbout ( ) | modid.t[127] |
The ABOUT command conventionally displays information about the game and its author - the kind of thing you'd find in an author's notes section in a book - along with any special instructions to the player, such as notes on unusual command syntax. Information that players will find especially helpful include:
- A list of any unusual command phrasings that the game uses. Ideally, you will disclose here every verb that's required to complete the game, beyond the basic set common to most games (LOOK, INVENTORY, NORTH, SOUTH, TAKE, DROP, PUT IN, etc). By disclosing every necessary verb and phrasing, you can be certain to avoid "guess the verb" puzzles. (Note that it's possible to disclose every *required* verb without disclosing every *accepted* verb - some verbs might be so suggestive of a particular puzzle solution that you wouldn't want to disclose them, but as long as you disclose less suggestive alternatives that can be used to solve the same puzzles, you have a valid defense against accusations of using "guess the verb" puzzles.)
- A quick overview of the NPC conversation system, if any. Conversation systems have been slowly evolving as authors experiment with different styles, and at least three or four different conventions have emerged. The default that experienced players will expect is the traditional ASK/TELL system, so it's especially important to mention your system if you're using something else.
- An indication of the "cruelty" level of the game. In particular, many experienced players find it helpful to know from the outset how careful they have to be about saving positions throughout play, so it's helpful to point out whether or not it's possible for the player character to be killed; whether it's possible to get into situations where the game becomes "unwinnable"; and if the game can become unwinnable, whether or not this will become immediately clear. The kindest games never kill the PC and are always winnable, no matter what actions the player takes; it's never necessary to save these games except to suspend a session for later resumption. The cruelest games kill the PC without warning (although if they offer an UNDO command from a "death" prompt, then even this doesn't constitute true cruelty), and can become unwinnable in ways that aren't readily and immediately apparent to the player, which means that the player could proceed for quite some time (and thus invest substantial effort) after the game is already lost.
- A description of any special status line displays or other on-screen information whose meaning might not be immediately apparent.
showCredit ( ) | modid.t[56] |
showVersion ( ) | modid.t[65] |