Building a New Interactive Fiction System

From IFWiki

This is an index that will help those that wish to develop their own interactive fiction system. Feel free to edit this index.

World Models

world model is the collection of rules and concepts that define how things are modeled in interactive fiction. There are many aspects of world models, and they are arguably the most important aspect of building a new IF system. Designing the world model is definitely the first step in any IF system. A world model consists of objects and events.

Objects

Most systems will use the object as the basis for everything. An object is simply something in the game world. It could be the player, a room, a key, and so on. Objects have many sorts of data associated with them. Properties are any sort of data, usually, like name or description. Attributes are yes/no variables stating whether or not an object is a weapon, container, etc. Usually giving an object an attribute also makes it inherit data and methods from a class or template, a predefined object. States or conditions are similar to attributes, but more dynamic. If an object is switchable, it can be on or off. A candle can be lit or unlit. A dial on a machine could be 0, 1, or 42. 

Usually NPCs, players, and rooms are implemented as objects, too. But how are objects organized? By an object tree, usually. Objects have a parent, siblings, and children. If two keys are in a box, then the box's children are the keys, the keys' siblings are each other, and the keys' parent is the box. There have also been proposals to implement more abstract relationships between objects. For instance, you could say that John IsA EmployeeOf Mike. This has never really been implemented before, but is a good idea. One-to-one, one-to-many, and many-to-many relationships would be an absolute must.

Events

The second most important aspect of the world model is events. Events are simply things that take place in the game world and how objects react to them.

An event is simply something that happens. It's usually an action, such as the player eating a cookie. It could also be when something changes states or conditions. This event triggers a stimulus, which is forwarded to the appropriate objects. They may respond to this trigger in any way they see fit. Usually this style of events will merely change the default library action. There are many more aspects of events, but will be covered later.

An Example World Model

Graham Nelson provides a detailed world model for the Inform Standard Library in his Designer's Manual. Rather than repeat it here (it is rather lengthy), we will look at the much simpler world model of the original PDP-10 Fortran version of Adventure.

1. Substance

The world is made up of rooms, items and (implicitly) the player. Rooms represent some region of space, either indoors or outdoors. Items represent physical objects, and may possess multiple internal states. (The most complicated item in Adventure is the plant, which has six states.) The player is neither a room nor an item. Items may have an alternate location from which they are visible, in which case they cannot be picked up by the player. (Adventure uses an alternate location value of -1 to render an object immovable at a single location.)

2. Containment

There is no hierarchy of items or rooms. The player always has a location, which is a room. Rooms are not contained within any other room or item. Items are either contained within a room, carried by the player, or are nowhere at all; they cannot be contained within other items. (There is no player-object, as is found in more modern systems. Instead, the player is represented by a single global variable containing a room number.)

3. Space

The world consists of a collection of rooms. Rooms possess attributes, such as 'ambient light', 'water is present' or 'NPCs will not enter'. Travel between rooms is effected by movement words, which describe the desired destination. (It is worth noting that Adventure recognizes 76 distinct movement words, of which compass directions don't appear until the 42nd entry. Also, BACK and LOOK are movement words, although they are treated specially.)

4. Sense

Each room has a two descriptions, a long one which is displayed upon inital entry and every fifth time the player re-enters a room, and a short one which is displayed during other visits.

Items have a short name, which is only used when being carried. Items possess one or more descriptions, one for each internal state. Some of these descriptions may be an empty string, in which case the item is effectively invisible to the player.

5. Time

A game divides its internal time into a series of turns. Each turn represents one opportunity for the player to issue a command. NPCs (dwarves and the pirate) are allowed one movement between rooms per turn. Resources (flashlight batteries, for example) are used up on a per-turn basis.

The game also tracks the "real world" time, and has the ability to limit play during working hours. (Adventure was originally played upon very expensive computers that had to be shared by multiple users.)

6. Action.

An action is the smallest possible potential transition between states of the world; they do not trigger other implicit actions such as TAKE or DROP. Actions may fail, in which case the world is not altered (by the player, that is; NPCs continue to move about), or they may succeed, in which case a change is made to the world. A failed action has no consequences. An action can involve at most one item, which must be either carried by the player or in the same room as the player.

Interpreters and Compilers

The choice of an interpreter is the most important decision facing a designer. Do you want an interpreter that is designed for Interactive Fiction, one that is general purpose, or do you want to skip the interpreter and distribute executables that are tied to a particular system?

If you choose to forgo an interpreter, then you can use just about any compiled language, such as C, FORTRAN or LISP. This option was popular in the very early days of Interactive Fiction, mostly because the other options didn't really exist. The big disadvantage is that a story has to be re-compiled for each platform, but in some circumstances this may not be that important; for example, you may be creating a game intended for users of a particular brand of cell phone. Another issue is that nowadays people are wary of running executables of unknown origin. Being written in FORTRAN didn't seem to hurt Adventure, but viruses weren't a big problem before the creation of the Internet.

General purpose interpreters include BASIC, Java, Flash, and all of the major scripting languages (Perl, Python, etc). These tend to avoid the problems of compiled executables: Scripts and byte-codes can be run on multiple platforms, and some interpreters support signed code and/or sandboxes which greately reduce the consumers' fears of downloading malicious code. Some interpreters (Java, Flash, .NET) have a major advantage in that first-time players will probably have the interpreter already installed. The major disadvantage is that none of these platforms were designed for writing Interactive Fiction, so an aspiring author will need to build a support framework from scratch. Creation of a set of libraries for Interactive Fiction would definitely be useful to such authors, assuming that they exist, or a general purpose interpreter can be used to implement a more specialized interpreter. The latter is has been done mostly for the Z-machine, which has interpreters written in Java, Flash, Perl and even Javascript.

Interpreters that are designed for Interactive Fiction include (in alphabetical order) Adrift, AdvSys, AGT, Alan, Glulx, HUGO, Level 9, Magnetic Scrolls, the TADS family and the Z-machine. (A more complete list can be found here. Note that some of these are legacy systems, and it may be impossible to produce new storyfiles for them.) The primitive operations understood by these interpreters are usually much more limited than general purpose interpreters, to the point that malicious code is almost impossible to write. At the same time, those operations that do exist are designed for I-F, so a storyfile for these interpreters may be smaller and/or faster than storyfiles for the more general purpose interpreters. Finally, none of these interpreters are very likely to already be installed on an end-user's computer.

The choice of a compiler is intimately tied to a choice of interpreter; in fact there are strong reasons for basing the choice of an interpreter on the choice of a compiler. As noted above, some specialized interpreters no longer have any way for new content to be produced. A fairly complete list of specialized compilers that do exist can be found here. Despite of the length of that list, the main IF languages in use today are Adrift, Alan, Inform, Hugo, TADS 2, and TADS 3. Here is an attempt to compare all but one on a feature-by-feature basis; Adrift is left out because it's IDE (Integrated Development Environment) is not based on editting text files. It should also be noted that the Inform compiler produces storyfiles for two different interpreters, Glulx and the Z-machine.

(more to come)

References

Links

Retrieved from "https://www.ifwiki.org/index.php?title=Building_a_New_Interactive_Fiction_System&oldid=88470"