SIMULATIONISM ARTICLE<br>
=====================
<P>
Comments on Overall Structure and Content<br>
-----------------------------------------<br>
The first half of the article looks fine to me, but I have a few concerns
with the structure of the second, and in particular, the "FIFTY SIMULATIONS"
part. For one thing, the introduction to this part seems to be only
half-written (note the author's comment in double square brackets). For
another, it would be helpful to the reader if the introduction to this
section explained *why* it was useful to give a list of simulations at this
point, and also, perhaps, how the list relates to the previous discussion
(more on which below).
<P>
I also felt the ending of this section (which also constitutes the end of
the article) seemed a bit abrupt, effectively leaving the reader stranded in
mid-air (or at the top of a ladder, perhaps). It may just be my personal
taste, but I'd prefer to see a paragraph or two rounding the whole thing
off.
<P>
The author may also want to consider the ordering of this section. At the
beginning we are given a list of 'baseline simulations', and at the end a
pair of 'challenges', suggesting a general movement from what is already
available to what might be most difficult to implement. In between, however,
a different principle of arrangement is followed, and although the logic of
it is clear enough, it may not be the most helpful principle to follow here.
The problem is that a large number of suggestions are mixed together with
little or no comment on their relative feasibility or reliability, or
whether they are proposals for inclusion in standard libraries or
possibilities for authors of individual games to explore. They range from
things that already more or less exist in TADS 3 (see below), to suggestions
that look highly specialized and potentially quite tricky to implement.
Although I haven't given much thought to how one would go about implementing
these suggestions, some of them look like they would probably need more
advanced mathematics than the integer arithmetic supported by most IF
systems (although TADS 3 would be able to cope with this). Also some of them
(e.g. keeping track of 3D co-ordinates)  seem to me to be moving far enough
along the simulationist route to be in some tension with the reservations
towards pushing simulationism in IF too far expressed in the previous text.
That doesn't mean that such suggestions should not be made, but some comment
or recognition of this tension would be welcome, otherwise the reader could
well be left a little confused over what position the author is actually
espousing. One way to meet these concerns might be to order this section in
terms of priority of desirability, generality or feasibility. Splitting the
suggestions into only two or three such categories might help, especially if
supported by an explanation in the text introducing the list.
<P>
Comments in Relation to what is Already Available in TADS 3<br>
-----------------------------------------------------------
<P>
Note: it will be difficult to cite many examples of what follows in
published games, since there are very few TADS 3 game currently published,
and only a few of those make full use of some of the newer features in the
TADS 3 library. Although not a good game (and not intended to be), Eric
Eve's 'The Quest of the Golden Banana' does try to work through a good many
of the TADS 3 library features in a systematic fashion, and the accompanying
TADS 3 Tour Guide (for which the game was written) can be consulted for most
of the examples of the TADS 3 classes and features noted below. Other games
that make use of a number of these features include "Return to Ditch Day" by
Mike Roberts, "The Battle of Walcot Keep" by Steve Breslin and Eric Eve, and
"Square Circle" by Eric Eve.
<P>
The second paragraph under the heading "A Typical Simulation" indicates that
the only model of location is a simple containment relationship, so that
even if a painting is on the wall or a chandelier is hanging from the
ceiling, 'the program has no notion of this when processing objects based on
location'. In TADS 3 this is not necessarily the case, since it is possible
to locate an object in a room and at the same time associate it with a
specific room part (e.g. by setting the paintings
initNominalRoomPartLocation to defaultWestWall). The effect of this is that
the object will then be mentioned when the player examines the room part in
question (e.g. X WEST WALL could respond with "On the west wall you see a
painting. "). I can't think of a specific example where this is used in a
published game, other than "Golden Banana" (where an example is given under
the Decoration section in the Tour Guide).
<P>
BASELINE SIMULATIONS<br>
_Location_ TADS 3 can also model items being "under" or "behind" other
objects. (The Inform Platypus library also deals with "under", IIRC,
although I can't remember whether it also deals with "behind"). "Golden
Banana" provides several examples (see the sections on Underside,
RearContainer and RearSurface in the Tour Guide); a real game example occurs
in the first room of "Square Circle", in which (mild spoiler) the bed is
modelled with an Underside.
<P>
_Light_ TADS 3 models not only absence/presence of light but light intensity
(in practice on a scale 0 = dark to 4 = very bright).
<P>
SPATIALITY<br>
_Attachment_ The TADS 3 Attachable class goes some way towards providing a
framework for handling this, though the precise details have to be left to
the author. See the Attachable section in the Tour Guide.
<P>
_Proximity_ The TADS 3 ConSpace library extension partially implements this,
in so far as in models a 'near to' relation that can be used, for example,
to enforce the condition that the chair is but near to the high window
before the PC can stand on the chair to exit via the window. But this
doesn't go on to model the kind of transitive proximity relation also
suggested here (which would involve another level of complexity, I think).
So far this has not been used in any actual game, so the only example would
be the sample game that comes with the ConSpace extension.
<P>
SENSING<br>
Quite a bit of what's mentioned here is either implemented or partially
implemented in the TADS 3 library. The propagation of sense data in and out
of containers is central to the TADS 3 library's implementation of sense
passing. Passing such data through microphones, cameras and the like can be
achieved by the standard SenseConnector class. Passing to neighbouring rooms
can readily be achieved using a DistanceConnector. "Walcot Keep" used
DistanceConnectors all over the place to allow the PC to see what's
happening in neighbouring locations (e.g. when standing in the castle
courtyard). "Square Circle" also makes fairly extensive use of
DistanceConnectors, for example to list what moveable objects are currently
in the neighbouring locations visible from the prison roof.
<P>
The TADS 3 SensoryEmanation class and its more specialized sublasses (Noise
and Odor) implements quite a bit of what's mentioned under the _Active vs
Passive_ sensing section. At least for sounds and smells a SensoryEmanation
object can be associated either with a location or a specific object within
a location, and can be made to display both active and passive sensory
information under different locations. For example, a ticking bomb concealed
under a pile of rubble could have a Noise object attached to it which could
display a passive sensing "You hear a quite ticking from somewhere" message
at intervals determined by the author (a display schedule can be defined
that, for examples, starts by displaying the message every turn, then every
second turn, then every fourth turn, and finally every eighth turn, thereby
modeling the PC's reduced conscious awareness of the ticking as time
passes). In response to a LISTEN TO TICKING command the same Noise object
could display "It seems to be coming from inside the pile of rubble" while
the bomb is invisible, but "The bomb is ticking loudly" when the bomb is
uncovered (precisely this example is used in "Golden Banana" and discussed
under Noise in the Tour Guide; a simple olfactory example is provided by the
pig in "Square Circle"). The opening scene of "Return to Ditch Day" provides
a response to LISTEN that is probably implemented using a simple
SensoryEmanation.
<P>
The TADS 3 _Sensory Event_ class provides another part of what is being
spoken here. A SightEvent, SmellEvent or SoundEvent may be activated, and
this can then be detected by any interested observer (animate or otherwise),
who can respond to specific SensoryEvents as the programmer determines (see
the section on SensoryEvent in the Tour Guide for more details). I don't
know of any actual games (other than "Golden Banana") that make use of this
yet; since an author could probably achieve the same effect in different
ways in TADS 3 it would in any case be almost impossible for players to be
sure whether SensoryEvents had been used in a game without inspecting the
source code.
<P>
TADS 3 provides at least a partial implementation of the features mentioned
under _Sight & Light_. In addition to containers being opaque and
transparent they can be obscured or attenuation (reducing the amount of
light passing in an out). A light level of 2 is considered not enough to
read by. Self-lit objects (such as an alarm clock seen in the dark) can be
modelled by being given a brightness of 1: they can then be seen themselves,
but do not enable anything else to be seen. Objects can also be given a
sightSize property (or its equivalent for other senses) that determines how
much detail can be discerned under less than ideal viewing conditions (e.g.
from a distance).
<P>
Everything mentioned under _Sound_ is standard in the TADS 3 library. It is
possible to define the sense-passing properties of any container (each sense
independent of the others), and a DistanceConnector will pass sound as well
as sight from one location to another (or only sound, or only sight, or
whatever combination of senses the programmer cares to define).
<P>
TADS 3 allows most of what's mentioned under _Touch_. A container can allow
touching through while at the same time preventing extraction from.
<P>
TADS 3 allows reduced scent at a distance or partially odor-blocking
containers, although there's no simulationist provision for mixing smells
(with the standard library you'd just seem them listed separately).
<P>
It is possible in the TADS 3 library to implement new senses. I'm not sure
how easy it would be to block the existing senses on different actors,
however; I suspect an author would need to do quite a bit of work to achieve
this consistently throughout a game.
<P>
It's very easy to write game text in TADS 3 that switches between 'the
mysterious stranger' and 'Bob' as appropriate (though I'd have thought TADS
2, Inform and HUGO could all cope with that reasonably easily too, by simply
referring to the object's name property).
<P>
Most of what's mentioned under _NPC Sensing_ could be achieved through
SensoryEvents in TADS 2, since (as mentioned) any game object can be
programmed to response to SensoryEvents.
<P>
DIVISIBILITY<br>
Some of what is mentioned under _Noticeable Individuals_ is handled in TADS
3 through the CollectiveGroup class. I can't think of a real game use of
this, so I can only refer you to the discussion of CollectiveGroup in the
TourGuide (and the associated example in "Golden Banana").
<P>
DAMAGE<br>
_Defacement_. For an example of marking objects, see the rubber sheet, the
globe and the note in "Square Circle" - although this a game-specific
implementation, not part of the TADS 3 library.
<P>
_Burning_. The TADS 3 Candle and FireSource classes provide some of this,
but only at a fairly basic level (again the candles in "Golden Banana" are
the only example I can supply).
<P>
EXTENDING THE PLAYER CHARACTER<br>
_Modelling Player Character Knowledge_. Most of this is standard in TADS 3.
The TADS 3 standard library keeps track of what keys the player character
has successfully used as described here. In addition it keeps track of which
objects the player character has seen (mostly) and which the PC knows about,
and this is used in the TADS 3 conversation system to determine which topic
a player is referring to (for example, if the PC has yet to see or hear
about the lighthouse, ASK BOB ABOUT LIGHTHOUSE will not trigger the specific
lighthouse response). The TADS 3 library also allows the system to be
expanded to track NPC knowledge as well, although this requires more work on
the part of the programmer. Steve Breslin has written a library extension to
make NPC knowledge tracking a bit easier.
<P>
Any TADS 3 game involving keys or conversation (respectively) will
demonstrate these features: "Return to Ditch Day" and "Square Circle" are
probably the most obvious examples.
<P>
CHALLENGES<br>
_Ladders_ The TADS 3 Game "The Battle of Walcot Keep" attempts to implement
ladders of a sort (specifically, scaling ladders), though not quite in the
detail mentioned here. The Walcot ladders must be leant against an
appropriate wall before they can scales, and actually take actors from one
location to another. There is no actual tracking of height as such, though.
<P>
Typos and Other Quibbles<br>
------------------------<br>
Under "A TYPICAL SIMULATION", quite early in first paragraph, "provided by
the the library" (delete one or other "the").
<P>
Under "TEXT SYNTHESIS", first paragraph, final sentence; "quantiative"
should read "quantitative".
<P>
Under "FIFTY SIMULATIONS" the sentence "Because simulations are just a tool
to use in a game, any given simulation is really useful on a game by game
basis." Has the word "only" been omitted  between "really" and "useful"?
<P>
"_Opacity_" Should this be "_Opacity/Transparency_"?
"Light_" Should this be "_Darkness/Light_"?
<P>
Under "PHYSICAL PROPERTIES"<br>
Should "_Mass_" really be "_Weight_", since the ensuing discussion indicates
that it is actually weight, not inertia, that is under consideration here.
<P>
Under "SPATIALITY"<br>
_3D coordinates_ "A numeric height simulation is 1/3..."; this should really
be "A numeric height simulation is one third..."
<P>
Under "SENSING"<br>
_Propagation_. The spelling of "propagation" becomes somewhat wayward in
this paragraph. Both "propation" and "propogation" need to be corrected to
"propagation".
<P>
Under "DIVISIBILITY"<br>
_Discrete Divisibility_. "chopping off characters arms" should be "chopping
off characters' arms" (i.e., an apostrophe is needed).
<P>
Under "MAGIC"<br>
_Transformation_, last sentence: "which uses changes the attribute..." is
clearly wrong; either "uses" or "changes" needs to be deleted.
<P>
Under "EXTENDING THE PLAYER CHARACTER"<br>
_Inventory_. The sentence "But there are in other possibilities, such as
abstract notion of there being at most one or two 'ready' objects." is a bit
garbled. I suspect "in" needs to be deleted and either 'the' or 'an'
inserted between 'as' and 'abstract'.
<P>

<P>