[[I haven't detailed most of the references, and I need to mention games that do
the simulations listed.]]
<P>
Simulation in Interactive Fiction
<P>
== THEORY ==
<P>
At the heart of the interactivity of Interactive Fiction lies the behavior of the
model world: the responses to actions performed by the player character. Modern
IF development systems are designed to make it easy for authors to create these
responses in a declarative manner: the author specifies exactly what happens in
reaction to a particular command in a particular scenario. If the player tries to
TAKE BOOK from a high shelf, and the player character is not standing on the
chair, the game is coded to print a very specific string: "You stretch as far as
you can, but you can't quite reach the book." If the player is standing on the
chair, the game prints "You stretch out and easily grab onto the book, pulling it
off the top shelf", then allows the IF system's TAKE-handling code to proceed as
normal.
<P>
An alternative strategy would be to give all shelf/table-like containers in the
game a height property, and to give the player (and other potential actors) a
reach property; then, by combining the heights of any objects the player is
standing on with the reach of the player, a general check can be performed to
determine whether the player can reach so high. This is a simulationist approach.
<P>
Simulationism is a design philosophy and an implementation strategy for providing
interesting reactivity without the need for the case-by-case authoring required
by declarative programming. A simulation implements a number of rules, then
characterizes the objects in specific ways that the rules will take advantage of.
Objects will have a small number of case-by-case characterizations for use by the
simulation instead of the large number of case-by-case declarations of behavior
in response to specific actions.
<P>
In the example implementation described above, the same height used for deciding
whether the player can reach a given table-like object is also used to determine
how high the player is currently elevated when standing on a table-like
object--both aspects of the reach problem have been reduced to a single property.
Similarly, the system could be extended to allow knocking objects off shelves
with brooms or other long objects by giving such objects a length by which they
extend reach. The length simply characterizes an inherent physical property of
the object, not a reach-specific property, and so could be used in other
simulations.
<P>
The simulationist strategy described above may also open up alternative solutions
to the problem. Perhaps the author intended the player to have to find a ladder
to reach a very high object, but instead a clever player stacks a crate on a
chair on a table and stands on the crate.
<P>
These qualities are typical of simulation. As an implementation strategy,
simulation allows a wide variety of behaviors to be characterized with only a
small number of properties. As a design strategy, simulation tends to open up
emergent solutions which the author didn't anticipate, empowering the player, but
putting a carefully planned-out play-sequence at risk.
<P>
A TYPICAL SIMULATION
<P>
When an IF player character picks up an object, puts it on a table or in a bag,
and travels from room to room, the player is exercising a simulation typically
provided by the the library of an interactive fiction development system. This
simulation answers a question--"where is object X?"--which is basic to the
experience of IF. Although this simulation has grown from the simple one which
appeared in the original colossal cave "Adventure" (Crowther and Woods), that
core simulation can still be seen in every text adventure and work of interactive
fiction written since.
<P>
This simulation is exquisitely simple: every object has a "location" property
whose value is another object. This notion of location is very abstract; an
object in a room is typically "on the floor/ground", but this is not always true.
It may be a painting on the wall, or a chandelier hanging from the ceiling; such
details may be visible as special text output by descriptions, but the program
has no notion of this when processing objects based on location. The only way of
programmatically notating more concrete spatial relationships is to put objects
inside others: a pendant may be in a box on a table in a room. This is indicated
by the pendant's location being the box, the box's location being the table, and
the table's location being the room. To answer the question "what is in the
room?" we cannot merely list the items which have the room as their location, but
must search recursively for objects within objects in the room.
<P>
The relationship between an object and the object/room it is contained in is
implicit in this property. There are also other, more explicit connections
between rooms (or even from objects to rooms or objects to objects) which
represent other sorts of traversibility than those represented by the nested
location hierarchy--typically corridors and doorways, paths and roads.
<P>
This "location simulation" exhibits some fairly typical properties of
simulations: flexibility of meaning from a small number of properties (on the
floor, in the sky, in a box, on a table, on the wall), a large number of actions
that manipulate the properties (GET, PUT x ON y, EMPTY x, ENTER x), behavior
readily predicted by the player (the consequence of each of the above commands is
easily anticipated, unless the author has added declarative overrides),
interaction with other simulations (open/closed, opaque/transparent), and the use
of synthetic text generation ("You see a bear trap, a football helmet, and a
staple remover here", "You put the safety pin on the rickety table").
<P>
SIMULATIONS IN GAMING
<P>
Most non-IF games are built entirely from simulations. These games feature a
small set of rules and a large number of objects or creatures that obey those
rules.
<P>
In Tetris (Pajitnov, 1986), tetraminoes fall down the screen while the player can
translate them horizontally and rotate them. They collide with the other pieces
which have fallen based solely on which grid squares each piece occupies. After a
piece can fall no further, a new piece falls; if a row is filled, that row is
deleted, and the remaining filled grid squares fall down a row. This is the
entire ruleset of Tetris; there are no special cases for rotating an L-shape, nor
a special rule for how a square interacts with a bar.
<P>
In Doom (id Software, 1993), the player has full control over the character's
motion using a simple mapping from the player's control inputs to PC movement.
This movement is then affected by a simulation accounting for the walls in the
world, the height changes in the floor, and other obstacles like barrels and
creatures. When shooting, a set of rules govern whether a given projectile hits a
given target. When a barrel explodes, it does damage to nearby objects
automatically; this can lead to a chain reaction of exploding barrels. Nobody
wrote code for "a chain reaction of exploding barrels"; it is a consequence of
the explosion simulation and a map designer putting down barrels close to each
other.
<P>
In Chess, each piece has its own specific rule for how it is allowed to move and
capture other pieces; but the interaction of these is entirely governed by the
rules without special cases. There is nothing built into the rules of Chess about
defending a piece; instead, this emerges as a consequence of the rules: a piece
which can "attack" another piece on its own team is defending that piece, in that
if the latter piece is captured, the former can retaliate. Such retaliation is
insufficient, though, if the initial capturing piece is "worth less" than the
initially captured piece; but this notion of "worth less" is not something stated
in the game rules, but rather is a natural consequence of the capabilities of the
different pieces, emerging from the one rule about how they move and capture.
<P>
Magic the Gathering (Garfield, 1992?) is somewhat like Chess with much more
per-piece complexity, but it still structures the per-piece rules through
simulations like "swampwalking" and "prevents swampwalking" rather than "piece X
affects piece Y".
<P>
In some sense, there is a continuum from "fully simulated" as Tetris is to "fully
declarative" as a typical Choose-Your-Own-Adventure is; Chess lies somewhere in
the middle, offering a fairly large number of rules to give each piece its unique
movement. In some Doom-like games in which enemies are affected differently by
different weapons, this susceptibility is defined through a purely declarative
table that simply indicates the amount of damage done for each combination of
weapon and creature. Crossword puzzles offer an extreme case; in one sense, they
are purely declarative--if you had to teach a non-English speaker how to judge if
a puzzle was solved, you would simply provide the complete puzzle answer; in
another sense, though, crossword puzzles are a simulation which use a
hypothetical English dictionary/encyclopedia as part of the rules.
<P>
For a more detailed discussion of emergent behavior and other consequences of
simulations, read Harvey Smith's "The Future of Game Design: Moving Beyond Deus
Ex and Other Dated Paradigms" (currently available at
http://www.igda.org/Endeavors/Articles/hsmith_intro.htm )
<P>
COMPUTERS MEET THE REAL WORLD
<P>
Declarative programming is almost unique to IF as compared to both games and
programming in general. (In fact, most computer programming languages lack the
facility for providing per-object declarative variations--allowing *code* on
individual objects. This may seem surprising considering that object-oriented
programming was originally strongly associated with simulation
programming--referencing "the real world". But simulating people standing in line
and being served at different rates is very different than what IF generally
tries to accomplish.)
<P>
For most games, typical programming languages designed to allow dealing with
large numbers of similar objects suffice, given hundreds of similar if not
identical monsters, ten equivalent race cars on a race track, or twenty-two men
in helmets and a single ball of pigskin. This last case, American Football, is
somewhat peculiar, however: because each of the men on the team serves a
different role, there needs to be very different AI logic to handle each one.
Although this logic is not necessarily attached to the object representing the
man (since several men from each team might play that role), it does require each
man to behave rather differently. Although this logic might have elements of
simulation in it--responding directly to the location of the ball-carrier rather
than to the current play that's been called--it is going to have to have a
certain declarative component to it, because that is the nature of the thing
being simulated: football players really *have* assigned roles
 that they are supposed to undertake.
<P>
This gets at why simulation is used so rarely in IF: simulations are good at
handling things which behave similarly. If our goal is to portray the real world,
simulation only helps us so far as the things in the real world behave
similarly--and moreover only so far as multiple such objects appear in the game
world. If only two of the objects in the simulated world--a newspaper and a
sheet--are rippable, it is unlikely to be worth the effort to build a ripping
simulation. A superball, a tea kettle, and a notebook have very few things in
common; you can't bounce a tea kettle, write on a superball, or heat water in a
notebook.
<P>
This is not to say that simulation is of no use in IF--as the "location"
simulation reveals, it is arguably the opposite: simulation provides an essential
interactivity that establishes a "you are there"ness. Without it, IF would
essentially have all possible interactions explicitly enumerated, much closer to
a CYOA. But simulation should not be thought of as a tool for achieving
"realism"; in fact, the further down the simulation route you go, the less varied
your objects may to seem to the player. Rather, simulation is a tool for creating
flexible interactivity, predictable consequences, cross-simulation interaction,
and emergent outcomes. Declarative programming can usually achieve "more
realistic" results except in the case of complex interactions and
cross-simulation interactions.
<P>
DESIGN VS. IMPLEMENTATION
<P>
A simulationist design embraces the notions of flexible interactivity and
predictable consequences inherent in simulations. At its most extreme, the
designer accepts that players will find new, unexpected solutions to problems
based on "exploiting" the properties of the simulation. So long as that
simulation feels "real", the designer accepts that players will do this and
considers this a good thing.
<P>
A simulationist implementation recognizes the challenge of achieving consistent
responses across a large set of actions, or the impossibility of implementing a
very large set of actions, and uses an algorithmic rather than declarative
approach to specify outcomes.
<P>
Although simulationist design and implementation usually go hand-in-hand, they
don't have to. "Lock & Key" (Cadre, 2002) exhibits a simulationist design,
allowing traps and connections to be placed in arbitrary configurations, but the
crux of the game lies in how each trap affects the adventurer struggling past
them, and each of these interactions (and their dependence on the adventurer's
state as caused by previous traps) is carefully hand-coded declaratively. On the
other hand, "Fit for a Queen" (Barrett, 2001) offers a contraption in which
placing objects of different weights on different platforms causes a hanging
object to swing to different locations; this contraption is implemented as a
weight-based simulation to create a puzzle that has a particular solution implied
by the competition rules--a non-simulationist design. (The typical "interesting"
consequences of simulationist design are here irrelevent: the intended solution
doesn't depend on any other puzzles being solved 
and doesn't consume any resources, so should "alternate" solutions exist, they
won't have consequences on the rest of the game.)
<P>
Most of the time, however, a system is simulationist both by design and
implementation.
<P>
== CRAFT ==
<P>
TEXT SYNTHESIS
<P>
Works of IF are among the few primarily text-based "games", which introduces a
complexity for simulations in IF by comparison to other games: the need to
express the state of a simulation with text. Certainly it is possible to simply
print the coordinates of the objects, as in "Asteroids" (Raszewski, 2001), or
draw them with ASCII art as in the old BASIC Star Trek games. But IF has
generally borrowed more from the part of the "Dungeons & Dragons" room
descriptions that offered qualitative, subjective information ("water drips
slowly in the corner") than in the quantiative, objective information ("the
10-foot wide corridor extends 30 feet west, then turns south, widening to
20-feet").
<P>
As such, simulations tend to have sophisticated algorithms for putting pieces of
text together. The most familiar of these is the list: "two all-beef patties,
special sauce, lettuce, cheese, onions, and a sesame seed bun". More
sophisticated list printing as seen in Inform and Tads 3 allows grouping items in
categories and using nested listings, producing things like "a safety pin, four
books (two copies of 'Life, The Universe, and Everything', one of 'Infinite
Jest', and one of 'American Gods'), and two torches (one lit)".
<P>
But even for simple cases like "You put the safety pin on the rickety table"
getting perfect-sounding English can involve some complexity involving pronoun
subsitutions; for example, Dan Schmidt pointed out during Tads 3 development that
an early implementation of LOOK UNDER would print "You see nothing under you" and
"Bob sees nothing under him" (Schmidt, 2001, post to Tads3 mailing list), rather
than the preferred "under yourself" and "under himself". In Heroes (Barrett,
2001), I needed to print text when one character attacked another, but if both of
them had the same "name", the first reference to each would be altered to
something like "the guard" and "the other guard". Further references in the
response used pronouns if the two guards had different genders, or else did not
use pronouns if they were the same.
<P>
Although next-generation libraries like Tads 3 offer tools to make this sort of
English-generation easier to write, in the end it will always require some human
intervention, at least until natural-language generation is completely solved.
<P>
PARSING
<P>
A number of simulation techniques may produce indistinguishable objects, which
complicates understanding references to the objects. The ability to refer to
objects based on their situation (their location, their dynamic properties) is
important, both for disambiguation questions ("which water, the water, the water,
or the water") should instead be, "which water, the pond water, the water in the
bottle, or the water in the bucket?"), and for referring to the objects ("put the
ball on the table in the box"). Tads 3 offers some facilities to do this
automatically.
<P>
REALISM AND ABSTRACTION
<P>
Simulations exhibit varying degrees of realism. Generally they are always
designed to achieve some sense of "truth" (although that truth may be about an
alternate universe, e.g. with a simulation of magic); the question is the degree
of detail provided by simulation. It is important to be willing to make
abstractions and not strive for perfect realism. The traditional "location"
simulation has strong verisimilitude, but little realism, since so little of the
true nature of location is captured in containment-plus-exits. As such it is a
powerful abstraction: it is easy for the player to understand, easy to program,
and easy to modify. As an extreme case, consider the challenge of writing code
that is hardcoded to "the blue key unlocks the silver door" compared to having a
full 3-dimensional description of the key and the lock along with code that
analyzes their shapes to determine whether one unlocks the other.
<P>
== FIFTY SIMULATIONS ==
<P>
It might sound like I'm down on simulationism, but outside of the IF world, I'm a
serious simulationist. But because the best IF tends to integrate puzzles very
tightly with the storyline, and for other reasons mentioned above, I think it's
much more challenging to use simulation successfully in IF. I also think it's a
worthwhile and productive area to explore, but that authors pursuing it need to
clearly understand how simulations interact with storytelling, game design,
emergent behavior, and realism, rather than simply pursuing simulations because
they are "neat" or "more realistic".
<P>
Because simulations are just a tool to use in a game, any given simulation is
really useful on a game by game basis. Nevertheless, for the remainder of this
article, though, I'll discuss a number of possible specific simulations. These
might be implemented by library authors to create a more flexible basis for game
authors, or just implemented directly for a single game. 
<P>
For the most part, these are "realistic" simulations based around the behaviors
of real-world objects, since anything else would be of limited use. Many of the
simulations interact with each other, so they'll become more interesting and
significant as more are created.
<P>
- Baseline simulations
- Physical properties
- Spatiality
- Sensing
- Divisibility
- Liquids
- Gases
- Damage
- Mechanisms
- Magic
- Player character
<P>
[[The above is the list of sections that appears below. I don't know if it needs
summarizing here or not.]]
<P>
BASELINE SIMULATIONS
<P>
The following are nearly universal in current IF systems.
<P>
_Location_: a simple representation of object positioning, based on objects being
"in" or "on" other objects; the choice of preposition is normally determined by
the "containing" object. Another commonly allowed relationship is "is a part of"
(that is, componenthood).
<P>
_Exits_: exits allow traversibility between locations that aren't related in an
in/on fashion.
<P>
_Openability_: Containers and doors can be opened or closed, limiting the
accessibility of the innards or connection.
<P>
_Lockability_: Prevents openability when locked.
<P>
_Opacity_: Opaque containers cannot be seen into and out of when closed;
transparent ones can.
<P>
_Light_: For the player character to see and interact, typically at least one
light source must be in the same room, and visible (not inside closed opaque
containers).
<P>
PHYSICAL PROPERTIES
<P>
A number of basic physical properties can be defined for objects that will be
useful in multiple simulations beyond the simple basic one listed here.
<P>
_Size_: Objects can have a volume which indicates the space they take up in
containers, and containers can have a maximum volume. A stretchy container's
volume grows as more objects are put in it. More abstractly, objects could be one
of "small", "medium", or "large", and could simply fit or not in containers based
on the maximum size that container allows.
<P>
_Mass_: Objects can also have mass; a container like a table overloaded with too
much mass might break; a vehicle with too much mass might not go; a player
character carrying too much mass might drop things or become fatigued. 
<P>
_Density_: Object density can be provided or computed as the ratio of mass to
volume; useful for determining if an object floats.
<P>
_Shape_: Objects can have a representation of shape: either entirely abstract
based on some canned set of shapes specific to the game (long & skinny, round &
flat, etc.), or things like "longest dimension" and "shortest dimension". These
can be used to determine if an object fits in a container, or even if an object
fits through the entrance to a container (e.g. a ship in a bottle). A closed
container could still be "open" but with a different entrance shape, e.g.
allowing a player in a cage to throw a shoe between the bars.
<P>
_Material_: Objects can be made of wood, paper, cloth, metal, flesh, water,
glass, etc. The material property can be used to drive other simulations:
material can imply a density allowing mass or volume to be computed from the
other; material can imply flammability for a burnability simulation; material can
imply whether an object can be written on; etc.
<P>
SPATIALITY
<P>
_Uprightness_: Objects could have a "primary upright" direction, in which they
normally rest unless knocked over or intentionally inverted. The abstraction
could be "upright" or "on its side", or "upright"/"on its side"/"inverted". Some
objects, like spheres, might have no sense of uprightness. Containers could have
different behaviors when knocked on their side: a different max volume, e.g.
stuff spills out or it's a surface/supporter and thus no longer supports things,
a changed ability to contain liquid, a propensity to spontaneously opening when
on its side, etc. Picture a table with a platter on which is a bowl of soup and a
closed wine bottle: knocking over the table, the platter, or the bowl should
result in spilling the soup.
<P>
_Attachment_: Objects could be attached to one another physically (with glue,
tied together with twine, because they have interlocking pieces), so that, for
instance, picking one up implies picking up the other. This is something like
componenthood, but the objects are equal. Perhaps implemented by making a new
object with the other two objects as components.
<P>
_Height_: As discussed at the beginning of this article, the height of objects in
rooms could be computed and used to simulate objects being "out of reach". 
Rather than using numeric values, some abstract "low, medium, high" could be used
instead, but a numeric simulation allows stacking any number of containers to
achieve the height.
<P>
_3D coordinates_: A numeric height simulation is 1/3 of the way to characterizing
objects with explicit 3D locations within a room. This information could be used
to synthesize room descriptions that relate objects to one another, instead of
the current abstract descriptions. Player movement within the room could be
tracked and used for various ends. But I think this is one for which abstraction
is preferable; description doesn't sound that important, and a user interface to
manipulate object locations seems difficult.
<P>
_Proximity_: One abstract approach representing the other 2D location of objects
within rooms is to mark objects as being in proximity to each other. Proximity
could be transitive, so objects form proximity groups, all of which objects are
near each other. Normally proximity isn't important since player characters can
walk around to manipulate any object in the room, but some declarative proximity
has been seen in games to deal with players sitting in chairs or tied up. A
proximity simulation can handle the case of limited mobility--what the player can
reach when, say, standing on a table. At the same time, it offers other features;
players could push objects near other objects, changing proximities. So, say,
only objects that can be brought into proximity could be attached with
_Attachment_. If player characters must be proximate to objects they are
manipulating, actions involving more than one object will require the player be
able to make those objects proximate to one another. The groupings could be
mentioned in the room desc
ription, providing structure to large content lists. With _Proximity_ and
_Height_, the classic "push a chair next to the shelf and stand on it" puzzle
could be a full simulation, admitting alternative solutions.
<P>
_Room_Continuity_: Rooms could also keep track of their relationship to each
other, either with a 3D coordinate system or with additional proximity
information for shared walls. Players could then forge new connections between
rooms by destroying or tunneling through walls. This has been experimented with
in graphics 3D games, but is problematic by making it difficult to control where
the player can go.
<P>
_Flying_: Objects which are flying or levitating do not contribute mass to their
parent container, and do not become wet from liquids in that container.
<P>
SENSING
<P>
Most IF to date has a simple model of sensing: objects are 'in scope' or not,
allowing reference to by the parser and being 'visible' to the player. Closed
containers block lines of scope. Special handling is used for objects in
transparent closed containers.
<P>
Sophisticated sense passing attempts to introduce a more careful simulation of
what you can observe versus what you can touch/reach. 
<P>
_Propagation_: "Sense data", in the form of light and sound energy, needs to
propagate in and out of containers, and possibly through exits to other rooms.
Support for artificial propation, such as microphones & speaker pairs, or
security cameras & monitors, are a natural extension. Text generated might want
to refer to the propogation: "On the monitor, you see ..." and "From the north,
you hear ..."
<P>
_Active vs. Passive_: Active sensing refers to the player taking steps to
observe, as with the command LOOK or LISTEN. Active sensing includes handling
complex description routines for rooms and allowing LOOK WEST to show information
about the contents of adjacent rooms. Passive sensing refers to the player
happening to observe something without any action; this typically means the
consequences direct & indirect of actions taken by the player, independent events
by NPCs, and "random messages" for atmosphere.
<P>
The implementation strategies for active and passive sensing are somewhat
different, but for consistent results both need to behave similarly. If it is too
dark for the player to perceive a character when looking, then the player
shouldn't see the character walking around. More accurately, active sensing may
have better perception than passive sensing, but it shouldn't be worse. Properly
implementing passive sensing is rather complicated, however, since every possible
output message needs to get appropriately tested for visibility and audibility,
which can be complicated by the introduction of microphones and amplifiers,
cameras and monitors, and similar things. Appropriate testing can be complicated
if an event causes both noise and visuals, since the player might see the even,
hear the event, or both. This is more easily done in MUDs (multi-user text
adventures), which already have to deal with different players perceiving or not
perceiving events, and so authors are more used to having to cope with these
possibilities.
<P>
_Unified Sensing_: One approach to the challenge of handling the four major
senses--vision, sound, smell, and touch--is to write a single system which can
propagate any sense at all, and customize it for each case. The general
simulation must be moderately flexible, and abstractions applied must be
appropriate to all senses (or, at least, a superset of the appropriate senses).
This is the approach taken by Tads 3.
<P>
An alternative approach is to consider each sense separately and try to find
entirely different abstractions that make them as different as possible. This
will presumably open up more interesting possible actions and interactions and
gameplay, although it is a lot more work and might be hard to keep the senses
interacting and coordinated.
<P>
_Sight & Light_: The primary sense humans experience, and the one which provides
us with the most information at the highest rate, is vision. Simulated vision can
allow seeing objects at a distance if there is "line of sight" between them,
allow providing less descriptive information about objects seen at a distance,
allow varying levels of ambient lighting, and also provide less descriptive
information about objects seen in low light.  Light propagates much as sight
does, although in addition to containers being opaque or transparent, a container
can also be translucent, allowing light to pass through but blurring it so that
no image is transmitted. Some objects are self-lit and need no lighting (e.g. an
alarm clock in the dark). Images seen in mirrors could be reflected, with 'right'
and 'left' and written text reversed.
<P>
Vision is the only human sense that relies on some other ambient quality
reflecting off objects to perceive them. This is already leveraged in the basic
_Light_ simulation.
<P>
_Sound_: Hearing is the second most significant sense. Containers can be
sound-proof or not, independent of light transparency. Sound could travel from
room to room, going around corners.
<P>
We tend to see things visually only by actively looking for them, although motion
draws our eye and encourages looking. By contrast, we heard things all the time
without trying, although we may not listen. Sound may be a good candidate for
"edge-triggering": for introducing the notion of sustained, multi-turn heard
sounds, which are automatically described the first time they are heard, and then
only mentioned again when the sound stops (or possibly every three turns or some
such to help remind the player). An sustained ambient sound heard across multiple
rooms could be described as "getting louder" and "getting softer" by keeping
track of which sounds the player character is currently hearing.
<P>
_Touch_: Touch is a crucial sense for IF because it corresponds directly to
manipulation; players can only take items which they can touch. But this mapping
need not be strict in both directions; using containers with specific mouth sizes
as discussed in _Size_, it could be possible to touch something through a narrow
opening without being able to take it.
<P>
Touch is unique compared to sight and sound in that it requires physical contact;
there is no interaction at a distance, even within a single room.
<P>
_Smell_: Smell can be implemented somewhat like sight and sound, with reduced
scent at a distance or through partially-odor-blocking containers. Smells might
mix together rather than be perceived separately; see _Mixing_ and the section on
gases.
<P>
Odor is relatively unique compared to the other senses because it lingers. One
implementation might be to have odor-producing objects create 'scent' objects in
the area where they are, which slowly decay if the odor-producing object is moved
away or otherwise stops producing odors. A similar "edge-triggered" scheme as in
_Sound_ might be appropriate for giving feedback to the player about smells and
their changes over time.
<P>
_Recording_: Objects which are capable of recording sense data, such as audio
cameras, tape recorders, and video cameras, can be implemented in a sense-passing
system, saving away some representation of the sense data for future examination.
Video cameras and tape recorders, which record an extended period of time, would
need good _Passive_Sensing_ support so that a given event might be recorded *and*
perceived directly by the player. Since the future state of objects might change,
it is most feasible to record the states as pure text; e.g. the photograph stores
the description of what you see when you look at the photograph.
<P>
_Character-Relative_Observation_:  In games with more than one player character,
different characters may perceive the world differently in a simulated manner.
For example, one character could be blind or another deaf. Even more likely are
the introduction of characters with superior senses: a character who can always
hear things clearly no matter how quiet, a character with extra-sharp vision who
can see things clearly at a distance, or a character who can see in the dark. New
"senses" could be introduced, such as the ability to see 'invisible' creatures.
Handling all of these cases basically only requires printing appropriate messages
when characters perceive things through reduced senses; but this is a basic
requirement of supporting sound-proof but transparent containers, or
non-sound-proof opaque containers. Even in games with only one player character,
_Character-Relative_Observation_ can be used to differentiate _NPC_Sensing_.
<P>
It is possible to treat language as if it were "sense data" in a similar way;
characters who understand a language see the text translated into the language
the game is written in, and characters who do not see the "original language"
text or simply some-randomly generated gibberish.
<P>
There are problematic interactions with _Recording_. Recording a single text
representation of the sense data makes it impossible to print text that is
adjusted to the sense of a particular character. Deferring text generation until
the recording is examined will break due to the state of objects having changed
since the recording was made. The ideal solution is to make copies of all the
objects and global variables which might be involved in generating the
description; however, determining which objects those might be is difficult,
since some objects may rely on arbitrary other objects for printing sense
information.
<P>
A single player character can himself become effectively different player
characters in the face of _Recording_. For example, taking a photograph of the
mysterious stranger results in a photograph whose description refers to "the
mysterious stranger"; if the player later becomes friends with the mysterious
stranger and starts referring to him by name as "Bob", it will be odd if
examining the photograph still refers to "the mysterious stranger" rather than
"Bob".
<P>
_NPC_Sensing_: In addition to sense-passing information around to the player
character and to any recording devices, NPCs might also want to do passive
sensing. One use of this is simply to still generate immediate text for the
player: "The radio crackles to life, and Bob says, 'Boss, the dame just walked in
the front door.'" The other use is to provide information to NPC AI routines that
allow them to react. The information represents state changes in the world
programmatically. For example, you might distribute an event "object Trophy
entered object Table due to action of object Player" that requires visual
perception. Some NPCs will see this and others will not. Using such a scheme
*without* sophisticated sense-passing is still an improvement over current
action-based NPC schemes; an NPC who wants to react to the trophy being placed on
the table must intercept every possible interaction that leads to it (which
becomes effectively impossible with sufficiently complex simulations
, such as the case of a trophy in a box on the table, and we burn the box), or
instead must simply poll every turn and test to see if the trophy happens to be
on the table now. Using events allows the NPC to understand how and why something
happened.
<P>
_Color_: Light can be modelled as colored--for example, as a combination of the
additive primary colors red, green, and blue--and the colors of observed objects
could change under different lighting conventions. As in "Savoir-Faire" (Short,
2002), _Mixing_ liquids and powders of different colors can create a blended
color, for example combinations of the subtractive primary colors cyan, magenta,
and yellow.
<P>
_Information_Copying_: A variation on recording is to allow the duplication of
information content found in drawings, pictures, printed or written texts, or
engravings. Characters can draw freehand, trace existing drawings, copy
documents, or making rubbings of engravings. In each case, a new object is
created which preserves the "information content" of the object, which would
presumably be stored in a separate property on the object.
<P>
DIVISIBILITY
<P>
_Discrete_Divisiblity_: Some objects are made naturally of components which are
assembled into pieces and can be disassembled back into them. Others might be
able to be disassembled violently (breaking off table legs or chopping off
characters arms) but into planned, well-named parts. Or an object might be able
to be 'destroyed' breaking it into pieces using a destruction simulation: rather
than having pre-defined parts, the size and mass and material type of the object
is used to create collection of new "broken pieces" of the original object
(possibly named "piece of X").
<P>
_Irreversible_Continuous_Divisibility_: Some objects may be able to be split into
arbitrary sized pieces, e.g. cutting a rope or slicing a loaf of bread. These
pieces cannot generally be reassembled. (You might tie the two pieces of rope
back together, but that's really no different than tying to unrelated pieces of
rope together, which is a separate simulation issue.)
<P>
_Reversible_Continuous_Divisibly_: Some objects are inherently composed of
too-many-to-count small components that are fluid-like, such as soup and sand.
These objects should be able to be divided arbitrarily and remerged arbitrarily.
<P>
_Noticeable_Individuals_: Sometimes a collection of objects doesn't really
"behave" like a single object in the fluid sense above, but for other reasons we
want to treat it as a single object, yet we want the player to notice and
interact with individuals. Thus we might have a collection of books or crowd of
people, of which some representative individuals might be examinable and
manipulable, while we want to treat the entire collection as if it were a mass.
<P>
LIQUIDS
<P>
Liquids need some notion of amount; if mass and volume are both defined, the two
should be strictly linked based on the amount. (Dividing and merging them
independently could introduce rounding errors that cause them to diverge.) A
number of games have implemented various kinds of divisible flowable liquids, for
example Ivan Cockrum's "Sunset Over Savannah" () and "Savoir-Faire".
<P>
_Fluid_Flow_: Liquids need to be continuously divisible, so you can pull some
amount out of the liquid and put it in another container. Liquids should flow
from one container to another, so if you put too much liquid in a container, it
spills out into the parent container. There are a number of possible commands for
players to move liquids from place to place: "POUR x INTO y" pours an unknown
amount or all of it; "FILL x WITH y" pours liquid until x is full, if possible;
"EMPTY x INTO y dumps all contents of x into y";.
<P>
Liquid entering a container might flow back into its children, for example if
filling a bucket which also contains an open jar. This might always happen--a
simple abstraction--or be based upon the height of the liquid and the height of
the inner container.
<P>
_Mixing_: If there is more than one liquid in a container, the two should
probably mix into a single entity, one which presumably tracks the original two
liquids so it knows what its components are. If a particular mixture has an
identifiable name, you may want to turn mixtures of the right type into that new
type.
<P>
_Liquid/Dry_Interaction_: Submersion in liquid should cause dry objects to become
"wet"; this can happen when a dry object is moved into a liquid or into a
container containing liquid, or if liquid is added to the container the dry
object is in. The consequence of wetness varies for different objects, possibly
based on _Material_. Many objects may simply be wet--traces of moisture on them.
Absorbent objects like cloth can soak up liquid to some limit; the limit could be
explicitly per object or based on the material type. Powders can interact and mix
with each other using the _Fluid_Flow_ simulation but then dissolve when mixed
with "wet" liquids. Wet objects can slowly dry over time.
<P>
_Permeability_: In addition to spilling if knocked over (e.g. with
_Uprightness_), containers could have a slow leak which causes their liquid
contents to leak out over time. Leaked liquid flows out using the _Fluid_Flow_
simulation. The leak could occur at different heights of the container; a leak at
the bottom leaks everything, but a higher leak only leaks liquid if the volume is
above the "leak-volume".
<P>
Containers might also be permeable in the opposite direction; liquid might flow
into an otherwise empty container if submerged, a variant of the _Fluid_Flow_
model.
<P>
_Floating_: Objects can float on the surface of liquids if their density is less
than that of the liquid. Containers can compute their effective density
dynamically, so as a container becomes loaded down, it eventually sinks (causing
it to become flooded as well).
<P>
_Flame/Liquid_Interaction_: Liquids can extinguish flames, or be heated and
boiled, evaporating the liquid (but leaving behind any dry powder components from
#29).
<P>
_Reactive_Chemistry_: Although mixing is easily implemented, reactive chemistry
is more complicated. Powders dissolve in liquids; solutions combined with each
other might precipitate out a solid; acids neutralize bases; magnesium reacts
with water exothermally. However, creating these as *realistic* simulations is
presumably impossible; although chemistry is effectively purely a consequence of
simpler atomic behaviors, simulating atoms and getting chemical behaviors is
infeasible. Instead, chemical behaviors must be explicitly codified and
processed, using appropriate abstractions.
<P>
GASES
<P>
Gases can be viewed as special kinds of fluids that flow and mix in a similar way
to liquids. However, they don't get things "wet", and they don't tend to stay
inside open containers.
<P>
_Gas_Flow_: Each room or container has a "gaseous medium", typically air. If a
container is air-tight, it can have its own unique gaseous medium. If not, all
containers hierarchically connect would have the same medium. Mixing happens as
with liquids, assuming one doesn't want to distinguish gases which would rise or
sink. Wind could induce mixing or even blow gases from room to room. _Sound_
would not travel through a vacuum.
<P>
_Smoke_: Gas-like phenomena such as smoke and fog are opaque and could reduce
visibility for sight lines that pass through them.
<P>
_Gas/Smell_Interaction_: Smells should behave in ways related to gases, since
they are generally airborne. Air-tight containers should be smell-tight; if a
wind blows smoke from one room to another, it should also blow smells from one
room to another.
interaction with smell
<P>
_Gas_Temperature_: The ambient temperature perceived by the player character is
the temperature of the gas around her. Gases of different temperatures that are
mixed will also be averaged. Cold solid objects may slowly absorb heat from gases
present, while hot objects will slowly heat them. This can interact with liquids
and especially wet objects, causing wet objects to dry faster.
<P>
DAMAGE
<P>
Objects can be permanently affected physically without involving chemical
reactions. Many such transformations are irreversible, and since they change the
object from its pristine, natural state, perhaps an appropriate term would be
_Deformations_. For example, objects which are "destroyed" could fragment into
pieces, as discussed in _Discrete Divisibility_.
<P>
_Defacement_: e.g. denting, scarring, or marking. Some deformations do not in any
way significantly impact that functioning of an object. Hitting something with a
hammer might dent or slightly bend it, without impairing its
liquid-tightness--perhaps it could slightly reduce its capacity. Scraping
something with a sharp object might leave a s car. You might be able to write on
paper and other materials using markers, or spray graffiti on objects with a
spray can.
<P>
_Disablement_: Attempts to dent or scar an object could penetrate it or otherwise
violate its integrity, causing dysfunction. A liquid-tight container could leak,
machinery stop working, clothing become unable to be worn, or 
<P>
_Combat_: Violent interactions with objects, resulting in defacement or
disablement, could be driven by a combat system much like one would use for
character vs. character combat. The object's material or other representation of
fragility could interact with the "weapon" type to determine the mode of damage;
then a representation of the object's *functionality* could determine whether
such damage leads to defacement or disablement.
<P>
_Blunt/Cutting_: Two major mode of violent interaction are cutting and blunt
force. (A possible third: stabbing.) Properties like density and mass could
determine the effectiveness of blunt assaults, whereas some sort of 'sharpness'
property could determine the effectiveness of cutting. For example,  cutting
butter divides it; blunt assault deforms and defaces it. One might also
distinguish blade-like cutting from cutting that cannot deeply penetrate due to
the wrong shape; it would presumably be hard to use a sharp piece of glass to cut
butter, rather than merely scar it with a cut.
<P>
_Burning_: Burning is a fairly complex activity suitable for much more complex
simulation. Objects can slowly burn over time, changing material state (becoming
more fragile and less able to support weight) and fragmenting into pieces as they
go. Fire can propagate between objects in contact or _Proximity_. Burning most
objects, of course, would require the presence of air (or a certain amount of
oxygen) and would create _Smoke_.
<P>
MECHANISMS
<P>
_Machinery_: Often a very small, localized simulation is the only way to
implement a piece of machinery which needs to have specific, complex behaviors.
At the simple end of the spectrum lies the microwave oven with a timer in
"Lurking Horror" (Lebling); at the more complex end the Enigma machine in
"Curses" (Nelson). Simpler machines are typically "off" or "on"; simulation comes
into play when the machine has many states, and more than a few are meaningful.
<P>
_Constructs_: A number of commercial non-IF computer games allow level designers
to combine "triggers" which the player sets off (e.g. buttons or hidden
detectors) with "reactors" which react when triggered in various ways (opening a
door or spawning a new enemy). The trigger-reactor interaction is generally a
simulation; some systems deepen the simulation by introducing "multiplexers" that
stimulate multiple reactors, or "logic gates" that require multiple triggers
before they trigger the reactor down the line. Such approaches aren't generally
used in IF since the "level designer" can more easily create that sort of logic
directly in code. However, this technique can be used to allow the *player* to
construct new sorts of machines, as in the spy gadgets in "Spider & Web"
(Plotkin).
<P>
MAGIC
<P>
I've pointed out that the power of general purpose simulation is limited by the
need for having many objects that participate in the simulation. One way of
leveraging simulation is to introduce magic that can consistently affect most or
all objects in the game. This strategy is exemplified by Emily Short's games
"Metamorphoses" (2000) and "Savoir-Faire".
<P>
_Transformation_: Transformation allows changing object properties which are not
normally variable. In "Metamorphoses", most objects possess three physical
properties: size, shape, and material. Two magical machines are provided, one
which can change the size of an object, and the other which changes its material
nature. The puzzles in the game are keyed to the physical properties of the
object, rather than specific objects; players are free to transform any object of
the appropriate shape so as to create the object needed for a particular puzzle.
A more classic example is the FROTZ spell in the Infocom "Enchanter" series
(Lebling & Blank), which uses changes the attribute used by the _Light_
simulation to make arbitrary objects light sources.
<P>
_Manipulation_: Manipulation allows changing the state of objects that *is*
naturally variable, but under conditions where it cannot normally be done.
"Savoir-Faire" introduces a concept of "magic linking" which allows objects to be
manipulated in ways they *could* be manipulated if they are linked to objects
which do allow such manipulation. The REZROV spell from "Enchanter" allows
opening objects which are openable even if they are locked, but does not allow
opening objects which are not naturally openable.
<P>
EXTENDING THE PLAYER CHARACTER
<P>
IF's model of the player and the player character is extremely simple. This is
probably for the best, since it makes the player's interaction simpler and more
comprehensible. But there are certainly numerous areas for improvement.
<P>
_Modelling_Player_Character_Knowledge_: It is possible to keep careful track of
what things the player character knows, and integrate this information with the
parser to disambiguate or to offer implicit interactions. For example, Emily
Short's "Locksmith" library keeps track of what keys the player has used
succesfully and automatically unlocks locks using the appropriate key if known.
<P>
_Inventory_: IF systems use a very simple abstract inventory system for objects
carried by the player character, rather than trying to keep track of whether each
object is in the player's left hand, right hand, or the crook of the right elbow.
Some people are occasionally critical about the lack of realism, although this is
explained away with an implicit. But there are in other possibilities, such as
abstract notion of there being at most one or two "ready" objects. Non-ready
objects cannot be constrained to be _Upright_--attempting to carry an open
container of liquid is impossible if it is not "ready". [Heroes' thief / Zarf's
rock climber example?]
<P>
_Hands_: One could also implement full-fledged hands. The act of taking an object
requires moving the hand into proximity with it--the hand has a size and might
not be able to reach into a given container--then _Attaching_ the hand to it, and
moving the composite object back out of any containers (the composite might be
even larger and not fit anymore; the container could intentionally lock and
"handcuff" the player). The hand and body would be connected in much the same way
you would implement the connection between the two ends of a piece of rope.
<P>
== CHALLENGES ==
<P>
Rope
<P>
Rope is a notoriously difficult thing to implement in IF, because it is flexible
in so many ways and players expect that flexibility. With a number of the above
systems at hand, implementing rope in all of its glory becomes more
plausible--although this might be too much flexibility to put in the hands of the
player for solving puzzles.
<P>
_Attachment_ makes it plausible to tie one end of a rope to an object. If the
rope is implemented to have two ends which can be in adjacent rooms, attachment
will "automatically" pull a tied object along with the end of the rope. Use of
container-mouth sizes or shapes on exits could prevent the dragging of objects
through inappropriate boundaries. A very short rope could use the _Proximity_
simulation to keep both ends near each other. _Irreversible Continuous
Divisibility_ allows cutting the rope into fragments; _Attachment_ might be used
to tie the pieces back together. A proper _Burning_ simulation might allow the
rope to be used as a fuse.
<P>
Of course, there are still significant issues to address, such as implementing
having the rope ends being in different rooms and pulling each other around,
preventing closeable containers from closing on the rope, and coping with the
parsing problem of referring to the ends of the rope when both are present. But
one would hope that the existence of the other simulations would make it much
more tractable.
<P>
Ladders
<P>
Ladders might be able to follow as a natural extension of the _Height_
simulation--one can stand on the ladder and it changes your height, and you could
have exits which are only accessible from certain heights, and only if the player
has _Proximity_ to them.  Perhaps _Uprightness_ could be used to deal with the
ladder being vertical or not, although clearly some information about where it
*can* be placed is needed. Ladders are very dramatically shaped--an extreme ratio
between longest and shortest dimension--and sophisticated shape simulations might
exhibit the appropriate behaviors for fitting a ladder through specifically
shaped exits or vehicles.