SCI/Specifications/SCI in action/The message subsystem

From ScummVM :: Wiki
< SCI‎ | Specifications‎ | SCI in action
Revision as of 15:48, 19 January 2009 by Timofonic (talk | contribs) (Merging of the SCI documentation. Work in progress.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Document conversion incomplete. Work in progress.

The message subsystem

The message subsystem developed out of a desire to lessen the amount of coordinative work between dialogue writers and programmers. The text resource of early SCI suffered from the limitation of using a tuple ⟨module, message-id⟩[1] as index into the text resources. Worse, text resources were often generated by using special syntax in the source code, thus making the ordering prone to change as the code was extended and reorganized.

In 1990, Sierra had released its first icon-driven game, King's Quest V. The icon-based approach required a new approach to event handling. Each clickable object would be represented as an SCI instance. When an object was clicked, a method the corresponding instance would be called with a parameter specifying which icon was used. The action linked to each icon was called a verb, and the method doVerb.

Later, when creating the message interface, it was natural to re-use this notion, and couple the module and verb with a unique number for each clickable object (since the instance addresses are unpredictable). Although later versions of the message system were more complicated, these are the essentials of its first iteration.

Soon introduced was the concept of stage directions. They are directions to the voice talents in CD-ROM games. The important bit here is that the stage directions are still present in the shipped message files, and the interpreter must know how to remove them. Any string in parentheses not containing any lower case characters or digits including any whitespace following it is considered to be stage directions and is stripped before the script sees it. Character escapes (either in the form of literal-character escapes, such as \( , or escapes using the ASCII value in hex, such as \30 ) were supported in some versions.

Many versions of the message resource also support longer comments, meant for writer/coder communication. It is unclear how to derive their offsets in the resource, though.

The writers soon realised that the indexing model presented above was too simplistic. Developments in the game plot were still not handled adequately by the system, and required programmer assistance. In addition, the response to each action had to fit in one message box. Therefore, Sierra's programmers added two fields to the indexing model, namely condition (sometimes known as case) and sequence. The condition signified the state of the noun with respect to the game plot, in a manner of speaking. The sequence number allowed writers to write more than one screenful of text. Also, a piece of satellite data was introduced, namely the talker. The game might use this to display the face of the speaker on screen. One talker value was reserved for narrated parts, which don't display a face (but this is game-specific, and really outside the domain of the interpreter).

Even later, recursion was added. Actually, two kinds of recursion, which it is necessary to distinguish, were added. One involved resource-internal recursion, in which the writer decides to re-use a part of another dialogue by including a reference to it. This type of recursion was limited, though; it was impossible to refer to other modules, and the reference always pointed to the first message in a sequence. The other kind of recursion was controlled by the script, and was useful for such things as cut-scenes. The two types of recursion could be mixed freely, which is why there are both message stacks and message stack stacks in Sierra SCI (no kidding! see the included error message file INTERP.ERR or SIERRA.ERR).

Ties to audio

Of course, the story does not end there. CD-ROM games contain audio, and having two addressing schemes would have been a mess. So naturally, the same scheme was used. However, this poses another problem: Individual resources are usually addressed by just a type and a number, not by a message tuple like the one we saw above. Sierra's solution was to add a new resource type, other resource files and maps beside the main one. The extra resource files are called something like RESOURCE.AUD and RESOURCE.SFX, and their maps are contained in map resources, either in the main resource file or separately as patches. The resource type is called audio36, and there is a sync36 type as well which provides cueing capabilities to these resources (like sync does to ordinary audio resources, see section ???).

The maps are indexed by module (room number), so that 100.map contains map entries for all the message tuples that have the module number 100. Map number 65535 (216-1 ) is special - it indexes ordinary audio resources.

To patch resources of this kind, Sierra used a base-36 encoding of the message tuple as the file name. Since this results in oddly looking names, the patch files, if any, are usually stored in a separate directory on the CD.

Notes

  1. While module was traditionally called room or resource number, I have choosen to use the terminology of the later message interface here.