Building a New Interactive Fiction System
This is an index that will help those that wish to develop their own interactive fiction system. Feel free to edit this index.
[Samwyse] I don't like this page. See the discussion tab for my reasons, but I've inserted some notes below.
A World Model is the collection of rules and concepts that define how things are modelled 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 definetly the first step in any IF system. [Samwyse] Good start!
Most systems will use the Object as the basis for everything. [Samwyse] Look out! We're starting to discuss how to implement a world model, instead of how to write one.
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. [Samwyse] Ok, now we've jumped the tracks. This paragraph and the following, IMHO, needs to go in a page on objects, to which a section on world model implementation could then point.
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 be implemented before, but is a good idea. One-to-one, one-to-many, and many-to-many Relationships would be an absolute must.
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. In Inform, this is known as the Before/After rule system. [Samwyse] We get back on track here, although I'd drop the bit about Inform.
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. [Samwyse] Again, this paragraph and the following, IMHO, needs to go in a seperate page that defines events.
There are many more aspects of Events, but will be covered later.
These two elements make up the majority of modern IF world models. However, recently there have been ideas floating around about a higher level of abstraction. Such things as Scenarios or Puzzles could be implemented? Perhaps. [Samwyse] From here on, the discussion is pretty good, but I'm not sure it's appropriate for this page. Puzzles and scenarios are perhaps better discussed in a page devoted to writing a game, not a system. OTOH, a world model probably should recognize that puzzles and scenarios exist, setting things up for a discusion in the implemenation section.
A Puzzle has a Goal and one or more Problems and Solutions. The exact implementation details depends on the IF system being built.
The same goes for Scenarios, which are parts of the game. For example, in Christminster the first Goal is to enter the college. This has a specific Goal and many Puzzles. The main use of Scenarios is Context, the idea that Objects should behave differently under different conditions. Scenarios merely organize these conditions into logical components of a game.
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.
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.)
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.)
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.)
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.
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.)
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.
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)
- The Interactive Fiction Authoring System Developer's Guide by Peer Schaefer
- An idea for a Wiki Based Interactive Fiction System
- Discussions about creating an IF language and world models on the rec.arts.int-fiction newsgroup