mirror of
https://github.com/ganelson/inform.git
synced 2024-07-08 18:14:21 +03:00
1364 lines
70 KiB
HTML
1364 lines
70 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|
<html>
|
|
<head>
|
|
<title>S/prm</title>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|
<meta http-equiv="Content-Language" content="en-gb">
|
|
<link href="inweb.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
|
</head>
|
|
<body>
|
|
|
|
<!--Weave of 'S/pwm' generated by 7-->
|
|
<ul class="crumbs"><li><a href="../webs.html">★</a></li><li><a href="index.html">srules 5/190315</a></li><li><b>Physical World Model</b></li></ul><p class="purpose">Verbal descriptions of spatial relationships; the hierarchy of kinds of object, and their properties.</p>
|
|
|
|
<ul class="toc"><li><a href="#SP9">§9. Verbal descriptions of numerical comparisons</a></li><li><a href="#SP10">§10. Creating the world model</a></li><li><a href="#SP12">§12. Naming properties</a></li><li><a href="#SP14">§14. Rooms</a></li><li><a href="#SP19">§19. Things</a></li><li><a href="#SP25">§25. Directions</a></li><li><a href="#SP30">§30. Doors</a></li><li><a href="#SP33">§33. Containers and supporters</a></li><li><a href="#SP35">§35. Kinds vs patterns</a></li><li><a href="#SP36">§36. The openability pattern</a></li><li><a href="#SP37">§37. The lockability pattern</a></li><li><a href="#SP39">§39. Backdrops</a></li><li><a href="#SP40">§40. People</a></li><li><a href="#SP43">§43. Non-fundamental kinds</a></li><li><a href="#SP44">§44. Men, women and animals</a></li><li><a href="#SP46">§46. Devices</a></li><li><a href="#SP47">§47. Vehicles</a></li><li><a href="#SP49">§49. Player's holdalls</a></li><li><a href="#SP51">§51. Correspondence between I6 and I7 property and attribute names</a></li></ul><hr class="tocbar">
|
|
|
|
<p class="inwebparagraph"><a id="SP1"></a><b>§1. </b>We first extend our suite of verbs and meanings to cover standard
|
|
world-modelling terms.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Part SR1 - The Physical World Model (for interactive fiction language element only)</span>
|
|
|
|
<span class="plain">Section SR1/0 - Language</span>
|
|
|
|
<span class="plain">The verb to be in means the reversed containment relation.</span>
|
|
<span class="plain">The verb to be inside means the reversed containment relation.</span>
|
|
<span class="plain">The verb to be within means the reversed containment relation.</span>
|
|
<span class="plain">The verb to be held in means the reversed containment relation.</span>
|
|
<span class="plain">The verb to be held inside means the reversed containment relation.</span>
|
|
|
|
<span class="plain">The verb to contain means the containment relation.</span>
|
|
<span class="plain">The verb to be contained in means the reversed containment relation.</span>
|
|
|
|
<span class="plain">The verb to be on top of means the reversed support relation.</span>
|
|
<span class="plain">The verb to be on means the reversed support relation.</span>
|
|
|
|
<span class="plain">The verb to support means the support relation.</span>
|
|
<span class="plain">The verb to be supported on means the reversed support relation.</span>
|
|
|
|
<span class="plain">The verb to incorporate means the incorporation relation.</span>
|
|
<span class="plain">The verb to be part of means the reversed incorporation relation.</span>
|
|
<span class="plain">The verb to be a part of means the reversed incorporation relation.</span>
|
|
<span class="plain">The verb to be parts of means the reversed incorporation relation.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP2"></a><b>§2. </b>The enclosure relation, indirectly defined in terms of the above more
|
|
fundamental ones, has a verb but no prepositions (though of course "to be
|
|
enclosed by" is in effect a prepositional expression of this).
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The verb to enclose means the enclosure relation.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP3"></a><b>§3. </b>Those three relations expressed how the inanimate world is arranged, on
|
|
the small scale: the relationships become a little more complicated once
|
|
living beings are involved.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The verb to carry means the carrying relation.</span>
|
|
<span class="plain">The verb to hold means the holding relation.</span>
|
|
<span class="plain">The verb to wear means the wearing relation.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP4"></a><b>§4. </b>One living being is special to our language — the protagonist character,
|
|
that is, the "player" — and so these three verbs all have adjectival forms
|
|
which imply the player as the missing term.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Definition: a thing is worn if the player is wearing it.</span>
|
|
<span class="plain">Definition: a thing is carried if the player is carrying it.</span>
|
|
<span class="plain">Definition: a thing is held if the player is holding it.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP5"></a><b>§5. </b>Animate beings also have the ability to see and touch their surroundings,
|
|
but note that we only model the ability to do these things — we do not attempt
|
|
to track what they actually do see or touch at any given moment, so there are
|
|
no built-in verbs "to see" or "to touch".
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The verb to be able to see means the visibility relation.</span>
|
|
<span class="plain">The verb to be able to touch means the touchability relation.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP6"></a><b>§6. </b>The special status of the player as the sensory focus, so to speak, is
|
|
again shown in the adjectives defined here:
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Definition: Something is visible rather than invisible if the player can see it.</span>
|
|
<span class="plain">Definition: Something is touchable rather than untouchable if the player can touch it.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP7"></a><b>§7. </b>While many of the world-modelling assumptions in I7 are carried over from
|
|
those tried and tested by I6, the idea of concealment is an exception. The
|
|
old I6 attribute <code class="display"><span class="extract">concealed</span></code> simply marked some objects (which we would
|
|
call "things") as being hidden from view in some way, but was never very
|
|
satisfactory. What does hidden mean, exactly — to whose eyes, and in what
|
|
way? Should you be able to take something which is hidden, if you happen to
|
|
know it's there? And so on. It was the muddiest of all the attributes, and
|
|
widely disused as a result. In I7, we instead took the view that
|
|
concealment required an active agent continuously doing the concealing: it
|
|
applies, for instance, to a dagger which someone intentionally hides
|
|
beneath a cloak, but not to a key placed at the back of a shelf by somebody
|
|
long gone.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The verb to conceal (he conceals, they conceal, he concealed, it is concealed,</span>
|
|
<span class="plain">he is concealing) means the concealment relation.</span>
|
|
<span class="plain">Definition: Something is concealed rather than unconcealed if the holder of it conceals it.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP8"></a><b>§8. </b>A final sort of pseudo-containment: does the entire world contain
|
|
something, or not? (For things destroyed during play, or not yet created, the
|
|
answer would be no.)
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Definition: Something is on-stage rather than off-stage if I6 routine "OnStage"</span>
|
|
<span class="plain">makes it so (it is indirectly in one of the rooms).</span>
|
|
<span class="plain">Definition: Something is offstage if it is off-stage.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP9"></a><b>§9. Verbal descriptions of numerical comparisons. </b>We might as well declare these now, too, though they're not needed for
|
|
any of the world-building work. (The verbal usages <code class="display"><span class="extract"><</span></code>, <code class="display"><span class="extract">></span></code>, <code class="display"><span class="extract"><=</span></code> and <code class="display"><span class="extract">>=</span></code>
|
|
are built into NI; those would be the same in any language, and are unlike
|
|
other verbs since they have no inflected forms for non-present tenses.)
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The verb to be greater than means the numerically-greater-than relation.</span>
|
|
<span class="plain">The verb to be less than means the numerically-less-than relation.</span>
|
|
<span class="plain">The verb to be at least means the numerically-greater-than-or-equal-to relation.</span>
|
|
<span class="plain">The verb to be at most means the numerically-less-than-or-equal-to relation.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP10"></a><b>§10. Creating the world model. </b>The 0th kind, "kind", is not created here but by NI itself. The first
|
|
through to ninth kinds created now follow: they must not be reordered or moved.
|
|
Note the two alterative plural definitions for the word "person", with
|
|
"people" being defined earlier to make it the default: "persons" is
|
|
correct, but "people" is more idiomatically usual.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section SR1/1 - Primitive Kinds</span>
|
|
|
|
<span class="plain">A room is a kind. [1]</span>
|
|
<span class="plain">A thing is a kind. [2]</span>
|
|
<span class="plain">A direction is a kind. [3]</span>
|
|
<span class="plain">A door is a kind of thing. [4]</span>
|
|
<span class="plain">A container is a kind of thing. [5]</span>
|
|
<span class="plain">A supporter is a kind of thing. [6]</span>
|
|
<span class="plain">A backdrop is a kind of thing. [7]</span>
|
|
<span class="plain">The plural of person is people. The plural of person is persons.</span>
|
|
<span class="plain">A person is a kind of thing. [8]</span>
|
|
<span class="plain">A region is a kind. [9]</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP11"></a><b>§11. </b>At this point, then, the hierarchy looks like so:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">kind</span>
|
|
<span class="plain"> room</span>
|
|
[1] <span class="plain"> thing</span>
|
|
[2] <span class="plain"> door</span>
|
|
[4] <span class="plain"> container</span>
|
|
[5] <span class="plain"> supporter</span>
|
|
[6] <span class="plain"> backdrop</span>
|
|
[7] <span class="plain"> person</span>
|
|
[8] <span class="plain"> direction</span>
|
|
[3] <span class="plain"> region</span>
|
|
[9]</pre>
|
|
|
|
<p class="inwebparagraph">This framework is the minimum kit needed in order for NI to be able to
|
|
manage the spatial relationships arising from its basic verbs. Room and
|
|
thing are needed to distinguish places and objects; door and backdrop
|
|
because they need to violate the basic rule that an object can only be in
|
|
one place at once — a door is "in" both of the rooms it faces onto —
|
|
and this requires special handling by NI; region because it violates the
|
|
rule that rooms are not themselves subject to being contained in other
|
|
objects, and again this requires special handling. That leaves
|
|
"direction", "container", "supporter" and "person", and these are
|
|
needed to express the concepts inherent in the sentences "A is east of
|
|
B", "A is in B", "A is on B" and "A is carried by B". (We also need
|
|
room and person in order to make sense of the words "somewhere" and
|
|
"someone", for instance.)
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Although further kinds will be created later ("vehicle", for instance),
|
|
those are merely design choices, and NI would not be troubled by their
|
|
absence.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP12"></a><b>§12. Naming properties. </b>Certain properties used for names are held in common by all objects, of
|
|
whatever kind. "Specification" is special: it isn't compiled, but holds
|
|
text used to annotate the Kinds index. "Variable initial value" is
|
|
likewise special; internally, knowledge about the initial value of a
|
|
global variable is stored as knowledge about this property. It can't be
|
|
used for anything else. "Indefinite appearance text" is also an internal
|
|
property (it holds the text sometimes given in double-quotes immediately
|
|
after an object is created).
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">An object has a text called specification.</span>
|
|
<span class="plain">An object has a text called indefinite appearance text.</span>
|
|
<span class="plain">An object has a value called variable initial value.</span>
|
|
<span class="plain">An object has a text called list grouping key.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP13"></a><b>§13. </b>These, on the other hand, are quite genuine:
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">An object has a text called printed name.</span>
|
|
<span class="plain">An object has a text called printed plural name.</span>
|
|
<span class="plain">An object has a text called an indefinite article.</span>
|
|
<span class="plain">An object can be plural-named or singular-named. An object is usually singular-named.</span>
|
|
<span class="plain">An object can be proper-named or improper-named. An object is usually improper-named.</span>
|
|
<span class="plain">An object can be ambiguously plural.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP14"></a><b>§14. Rooms. </b>We now detail each of the fundamental kinds in turn, in order of their
|
|
declaration, and thus beginning with rooms.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section SR1/2 - Rooms</span>
|
|
|
|
<span class="plain">The specification of room is "Represents geographical locations, both indoor</span>
|
|
<span class="plain">and outdoor, which are not necessarily areas in a building. A player in one</span>
|
|
<span class="plain">room is mostly unable to sense, or interact with, anything in a different room.</span>
|
|
<span class="plain">Rooms are arranged in a map."</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP15"></a><b>§15. </b>Rooms have rather few properties built in; this reflects their usual role
|
|
in IF as ambient environments in which interesting things happen, rather
|
|
than being direct participants.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">A room can be privately-named or publicly-named. A room is usually publicly-named.</span>
|
|
<span class="plain">A room can be lighted or dark. A room is usually lighted.</span>
|
|
<span class="plain">A room can be visited or unvisited. A room is usually unvisited.</span>
|
|
|
|
<span class="plain">A room has a text called description.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP16"></a><b>§16. </b>Note that the "map region" property here is created with the type
|
|
"object", not "region", even though we think of it as always being a
|
|
region. This is because of I7's type-checking rule: the type "object" can
|
|
legally hold 0, meaning "nothing", but more specific object types — in
|
|
this case "region" — cannot. That would make them illegal to use in a
|
|
situation where no regions were created, because variables or properties of
|
|
this kind couldn't be initialised. This is why the Standard Rules almost
|
|
always declare object properties as "object" rather than anything more
|
|
specific.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">A room has an object called map region. The map region of a room is usually nothing.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP17"></a><b>§17. </b>Rooms have two specialised spatial relationships of their own, which again
|
|
we need verbal forms of:
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The verb to be adjacent to means the reversed adjacency relation.</span>
|
|
<span class="plain">Definition: A room is adjacent if it is adjacent to the location.</span>
|
|
|
|
<span class="plain">The verb to be regionally in means the reversed regional-containment relation.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP18"></a><b>§18. </b>There's no detailed writeup of regions, since they have no properties
|
|
in the usual setup. So let's add this here for the Kinds index:
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The specification of region is "Represents a broader area than a single</span>
|
|
<span class="plain">room, and allows rules to apply to a whole geographical territory. Each</span>
|
|
<span class="plain">region can contain many rooms, and regions can even be inside each other,</span>
|
|
<span class="plain">though they cannot otherwise overlap. For instance, the room Place d'Italie</span>
|
|
<span class="plain">might be inside the region 13th Arrondissement, which in turn is inside</span>
|
|
<span class="plain">the region Paris. Regions are useful mainly when the world is a large one,</span>
|
|
<span class="plain">and are optional."</span>
|
|
|
|
<span class="plain">A region can be privately-named or publicly-named. A region is usually publicly-named.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP19"></a><b>§19. Things. </b>Things are ubiquitous:
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section SR1/3 - Things</span>
|
|
|
|
<span class="plain">The specification of thing is "Represents anything interactive in the model</span>
|
|
<span class="plain">world that is not a room. People, pieces of scenery, furniture, doors and</span>
|
|
<span class="plain">mislaid umbrellas might all be examples, and so might more surprising things</span>
|
|
<span class="plain">like the sound of birdsong or a shaft of sunlight."</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP20"></a><b>§20. </b>The large number of either/or properties things can have reflects the
|
|
flexibility of the I6 world model, which we largely adopt for I7 too. That
|
|
is, you can have any combination of lit/unlit, edible/inedible, fixed in
|
|
place/portable, and so on. We can divide them into three broad categories:
|
|
first, physical properties. Things come in 2^6 = 64 physically different
|
|
varieties, which is rather a lot, but although some combinations are very
|
|
rare (edible lit pushable between rooms scenery is not met with often)
|
|
this flexibility is helpful in mitigating the rigidity of the kinds
|
|
structure, given that we have single inheritance of kinds. Note that,
|
|
except for "lit", these are all really to do whether and how people
|
|
can move things around — even edibility, which is the ability to be removed
|
|
from the world model entirely.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">A thing can be lit or unlit. A thing is usually unlit.</span>
|
|
<span class="plain">A thing can be edible or inedible. A thing is usually inedible.</span>
|
|
<span class="plain">A thing can be fixed in place or portable. A thing is usually portable.</span>
|
|
<span class="plain">A thing can be scenery.</span>
|
|
<span class="plain">A thing can be wearable.</span>
|
|
<span class="plain">A thing can be pushable between rooms.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP21"></a><b>§21. </b>Second, status properties, which in effect refer to the past history of an
|
|
item without our needing to use the past tenses, which can be tricky or
|
|
inefficient. "Handled" means that the player has at some time carried the
|
|
thing in question. (We used to have "initially carried" here, too, but that's
|
|
now considered a part of the verb "to carry" rather than an adjective.)
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">A thing can be handled.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP22"></a><b>§22. </b>Third, linguistic properties, influencing when and how the thing's name
|
|
will be included in lists. ("Mentioned" goes here rather than as a status
|
|
property because it refers only to the current room description, so it carries
|
|
no long-term historic information. "Marked for listing", similarly, carries
|
|
only short-term information and is used as workspace by the I6 library and
|
|
also by some of the I7 template routines.)
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">A thing can be privately-named or publicly-named. A thing is usually publicly-named.</span>
|
|
<span class="plain">A thing can be undescribed or described. A thing is usually described.</span>
|
|
<span class="plain">A thing can be marked for listing or unmarked for listing. A thing is usually</span>
|
|
<span class="plain">unmarked for listing.</span>
|
|
<span class="plain">A thing can be mentioned or unmentioned. A thing is usually mentioned.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP23"></a><b>§23. </b>We now have a mixed bag of value properties, all descriptive — it's an
|
|
interesting reflection on how qualitative English text usually is that the
|
|
world model so seldom needs quantitative properties (sizes, weights, distances,
|
|
and so on).
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">A thing has a text called a description.</span>
|
|
<span class="plain">A thing has a text called an initial appearance.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP24"></a><b>§24. </b>Lastly on things: an implication about scenery. The following sentence looks
|
|
like an assertion much like others above ("A thing is usually inedible", for
|
|
instance) — but in fact it is an "implication": it says that an object having
|
|
one property also probably has another. The Standard Rules make only very
|
|
sparing use of implications. They can trip up the user (who may quite
|
|
reasonably say that it is up to him what properties something has): but they
|
|
are invaluable if they cause Inform to make deductions which any human reader
|
|
would always make without thought.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">They can of course be overruled by explicit sentences in the source text,
|
|
just as every sentence qualified by "usually" can.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Scenery is usually fixed in place. [An implication.]</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP25"></a><b>§25. Directions. </b>The first important point about directions is that they are not things and
|
|
not rooms. They are not positions in the world, but imaginary arrows pointing
|
|
in different ways one could go from those positions. In the language of
|
|
geometry, we could call them tangent vectors which can be taken anywhere
|
|
in space by parallel transport without altering them: that's to say, the
|
|
"north" in one place is the same as the "north" anywhere else. (This
|
|
is how we get away with having just one set of 12 direction objects, not
|
|
12 different ones for every location.) Implicit in that assumption is that
|
|
the model world occupies a "flat" Euclidean space, to use further
|
|
mathematical jargon: it doesn't wrap around on itself, and there are no
|
|
bad positions where the directions fail. (Compare the Infocom game "Leather
|
|
Goddesses of Phobos", in which the South Pole of Mars is just such a
|
|
singularity: there are three routes out of this location, all of them
|
|
"north". This of course required special programming, and so it would in
|
|
an Inform 7 work, too.) More concisely:
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section SR1/4 - Directions</span>
|
|
|
|
<span class="plain">The specification of direction is "Represents a direction of movement, such</span>
|
|
<span class="plain">as northeast or down. They always occur in opposite, matched pairs: northeast</span>
|
|
<span class="plain">and southwest, for instance; down and up."</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP26"></a><b>§26. </b>The only either/or property created for directions is used to allow them
|
|
to be part of lists of objects:
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">A direction can be privately-named or publicly-named. A direction is usually</span>
|
|
<span class="plain">publicly-named.</span>
|
|
<span class="plain">A direction can be marked for listing or unmarked for listing. A direction is</span>
|
|
<span class="plain">usually unmarked for listing.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP27"></a><b>§27. </b>The following value property expresses that all directions in I7 come in
|
|
matched, diametrically opposing pairs — north/south, up/down and so on.
|
|
This is a concept we need to provide so that I7 can apply its assumption
|
|
that if room X is north of room Y, then probably room Y is also south of
|
|
room X, and so on. (Geometrically, this is the operation of negation in
|
|
the tangent bundle.) Note that the kind of value here is "direction",
|
|
not "object": a value of 0, meaning "there's no opposite", is illegal.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">A direction has a direction called an opposite.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP28"></a><b>§28. </b>I6 historically began with no formal concept of "direction" and has
|
|
no <code class="display"><span class="extract">direction</span></code> attribute marking some of its objects as directions (it looked
|
|
instead for object-tree chidren of a pseudo-object called <code class="display"><span class="extract">compass</span></code>);
|
|
by the time I6 did want such a formal concept, the use of attributes
|
|
to encode what amounted to class membership was no longer thought to be
|
|
good practice. So I6 directions are now expected to belong to a class
|
|
called <code class="display"><span class="extract">CompassDirection</span></code>, and here we assert just that.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Our I7 directions will be created just like any other I7 objects, but we
|
|
want them to emerge with the traditional names which I6 direction objects
|
|
had: so, because the I6 object for north was always called <code class="display"><span class="extract">n_obj</span></code>, we want
|
|
to ensure that the I7 direction "north" also comes out as <code class="display"><span class="extract">n_obj</span></code> in the
|
|
compiled code. Special translates-into-I6-as sentences are used to
|
|
force the I7 object compiler to use a given I6 identifier to represent the
|
|
object, rather inventing something like <code class="display"><span class="extract">O12_north</span></code> as it otherwise would.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Include (-</span>
|
|
<span class="plain">has scenery,</span>
|
|
<span class="plain">-) when defining a direction.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP29"></a><b>§29. </b>The Standard Rules define only thirteen I7 objects, and here we go with
|
|
twelve of them: the standard set of directions, which come in six pairs
|
|
of opposites.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The following set — N/S, NE/SW, E/W, SE/NW, U/D, IN/OUT — is rooted in IF
|
|
tradition. It seems unlikely that people would make IN/OUT a pair of
|
|
directions today if starting from a clean slate: this is really a residue
|
|
of the traditional implementation, in 70s and 80s IF, of commands which
|
|
moved the player in unorthodox way. Outside the cave mouth, typing IN
|
|
should take you inside; in the Y2 Rock Room, typing the magic word PLUGH
|
|
should take you far away. The most convenient way to implement such
|
|
commands in as few instructions as possible was to regard these as
|
|
little-used compass directions rather than independent commands (some
|
|
implementations of the original Adventure regarded XYZZY, PLUGH, PLOVER as
|
|
all being directions, thus using 15 of the 16 possibilities which could be
|
|
represented in a 4-bit field). In the 90s this was seen to be a little
|
|
bogus, but since IN and OUT clearly applied in a variety of settings, they
|
|
continued to be regarded as bona fide directions. In effect, they allow for
|
|
one location to surround another: the canonical example would be a small
|
|
white building in the middle of a field. Anyway, I7 accepts the current
|
|
orthodoxy, so IN/OUT are allowed, even though they cause headaches for the
|
|
interpretation of words like "inside" which might refer either to the
|
|
"horizontal" or "vertical" spatial models as a result.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Of the rest, N/S, NE/SW, E/W, SE/NW and U/D, it's noteworthy that this
|
|
choice imposes a cubical grid on the world, simply because the compass
|
|
directions are at 45 and 90 degree angles to each other: a hexagonal
|
|
tessalation would be more faithful to distances (it would get rid of the
|
|
awkward point that a NE move is root 2 times the length of a N move),
|
|
but in practice the world model doesn't care much about distances, another
|
|
example of its qualitative nature. A further point is that, in a
|
|
three-dimensional cubic lattice, we ought to have another eight pairs
|
|
of directions for "up and northeast", "down and west" and so on —
|
|
instead of which U/D are the only ways out of the horizontal plane.
|
|
But natural language doesn't work that way: it overwhelmingly provides
|
|
words for horizontal travel, because that's the plane in which our eyes
|
|
normally see, and in which we normally walk. Linguistically, "north"
|
|
genuinely means north, but "up" allows for any amount of lateral
|
|
movement into the bargain. It's a doctrine of I7 that linguistic bias is
|
|
a good guide to what's worth modelling and what is not, so we will now
|
|
stop worrying about this and declare the actual objects.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The order of definition of the directions affects the way lists come out:
|
|
the traditional order is N, NE, NW, S, SE, SW, E, W, U, D, IN, OUT.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The north is a direction.</span>
|
|
<span class="plain">The northeast is a direction.</span>
|
|
<span class="plain">The northwest is a direction.</span>
|
|
<span class="plain">The south is a direction.</span>
|
|
<span class="plain">The southeast is a direction.</span>
|
|
<span class="plain">The southwest is a direction.</span>
|
|
<span class="plain">The east is a direction.</span>
|
|
<span class="plain">The west is a direction.</span>
|
|
<span class="plain">The up is a direction.</span>
|
|
<span class="plain">The down is a direction.</span>
|
|
<span class="plain">The inside is a direction.</span>
|
|
<span class="plain">The outside is a direction.</span>
|
|
|
|
<span class="plain">The north has opposite south. Understand "n" as north.</span>
|
|
<span class="plain">The northeast has opposite southwest. Understand "ne" as northeast.</span>
|
|
<span class="plain">The northwest has opposite southeast. Understand "nw" as northwest.</span>
|
|
<span class="plain">The south has opposite north. Understand "s" as south.</span>
|
|
<span class="plain">The southeast has opposite northwest. Understand "se" as southeast.</span>
|
|
<span class="plain">The southwest has opposite northeast. Understand "sw" as southwest.</span>
|
|
<span class="plain">The east has opposite west. Understand "e" as east.</span>
|
|
<span class="plain">The west has opposite east. Understand "w" as west.</span>
|
|
<span class="plain">Up has opposite down. Understand "u" as up.</span>
|
|
<span class="plain">Down has opposite up. Understand "d" as down.</span>
|
|
<span class="plain">Inside has opposite outside. Understand "in" as inside.</span>
|
|
<span class="plain">Outside has opposite inside. Understand "out" as outside.</span>
|
|
|
|
<span class="plain">The inside object translates into I6 as "in_obj".</span>
|
|
<span class="plain">The outside object translates into I6 as "out_obj".</span>
|
|
|
|
<span class="plain">The verb to be above means the reversed mapping up relation.</span>
|
|
<span class="plain">The verb to be mapped above means the reversed mapping up relation.</span>
|
|
<span class="plain">The verb to be below means the reversed mapping down relation.</span>
|
|
<span class="plain">The verb to be mapped below means the reversed mapping down relation.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP30"></a><b>§30. Doors. </b>Doors are, literally, a difficult edge case for the world model of IF, since
|
|
they occupy the awkward junction between the two different ways of dividing
|
|
up space: the "vertical" model of objects containing and supporting each
|
|
other, all within a tree rooted by the room which represents, for the moment,
|
|
the entire stage-set for the play; and the "horizontal" model of rooms
|
|
stitched together at compass directions into a map. The difficulty arises
|
|
because in order for a door to make sense in the horizontal model, it needs
|
|
to be present in two different rooms at the same time, and then it doesn't
|
|
make sense in the vertical model any more, because which object tree is it
|
|
to be in?
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section SR1/5 - Doors</span>
|
|
|
|
<span class="plain">The specification of door is "Represents a conduit joining two rooms, most</span>
|
|
<span class="plain">often a door or gate but sometimes a plank bridge, a slide or a hatchway.</span>
|
|
<span class="plain">Usually visible and operable from both sides (for instance if you write</span>
|
|
<span class="plain">'The blue door is east of the Ballroom and west of the Garden.'), but</span>
|
|
<span class="plain">sometimes only one-way (for instance if you write 'East of the Ballroom is</span>
|
|
<span class="plain">the long slide. Through the long slide is the cellar.')."</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP31"></a><b>§31. </b>This is the first kind we have declared to be a kind of something else:
|
|
a door is a kind of thing. That means a door inherits all of the properties
|
|
of a thing, but in a way which allows us to change the normal expectations.
|
|
So here we see the first case of assertions which contradict earlier ones,
|
|
but in a narrower domain: a thing is usually portable, but a door is usually
|
|
fixed in place.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Our difficulty with doors being multiply present would be enormously worse
|
|
if we allowed anybody to move them around during play. So:
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">A door is always fixed in place.</span>
|
|
<span class="plain">A door is never pushable between rooms.</span>
|
|
<span class="plain">Include (- has door, -) when defining a door.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP32"></a><b>§32. </b>"Every exit is an entrance somewhere else," as Stoppard's play
|
|
"Rosencrantz and Guildenstern are Dead" puts it: and though not all
|
|
I7 doors are present on both sides, they do nevertheless have two sides.
|
|
The representation of this is quite tricky because, as Stoppard implies,
|
|
it's all a matter of which side you look at it from. What we call the
|
|
"other side", and whether or not we say that "the Ballroom is through
|
|
the green door", depends entirely on which side of the green door we
|
|
stand. The awkward truth is that these expressions are undefined unless
|
|
the player is in one of the (possibly) two rooms in which the green
|
|
door is present; and then they are defined relative to him.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The leading-through relation is built in to NI; the other side property,
|
|
though, is merely a convenient name we give to the property in which
|
|
the relation data is stored at run-time.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">A door has an object called other side.</span>
|
|
<span class="plain">The other side property translates into I6 as "door_to".</span>
|
|
<span class="plain">Leading-through relates one room (called the other side) to various doors.</span>
|
|
<span class="plain">The verb to be through means the leading-through relation.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP33"></a><b>§33. Containers and supporters. </b>The carrying capacity property is the exception to the remarks above about
|
|
the qualitative nature of the world model: here for the first and only time
|
|
we have a value which can be meaningfully compared.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section SR1/6 - Containers</span>
|
|
|
|
<span class="plain">The specification of container is "Represents something into which portable</span>
|
|
<span class="plain">things can be put, such as a teachest or a handbag. Something with a really</span>
|
|
<span class="plain">large immobile interior, such as the Albert Hall, had better be a room</span>
|
|
<span class="plain">instead."</span>
|
|
|
|
<span class="plain">A container can be enterable.</span>
|
|
<span class="plain">A container can be transparent or opaque. A container is usually opaque.</span>
|
|
<span class="plain">A container has a number called carrying capacity.</span>
|
|
<span class="plain">The carrying capacity of a container is usually 100.</span>
|
|
|
|
<span class="plain">Include (- has container, -) when defining a container.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP34"></a><b>§34. </b>The most interesting thing to note here (and we will see it again in the
|
|
definition of "people") is that "transparent" the I7 property is not
|
|
a direct match onto <code class="display"><span class="extract">transparent</span></code> the I6 attribute. In I7, the term is
|
|
applicable only to containers (a reform made in January 2008, but clarifying
|
|
what was already de facto the case). In I6, the <code class="display"><span class="extract">transparent</span></code> attribute
|
|
means that child-objects in the object tree are in scope whenever the parent
|
|
object is: in the I7 world model that's always true for supporters, so we
|
|
oblige all supporters to have the attribute <code class="display"><span class="extract">transparent</span></code> in their I6
|
|
compiled forms. The same will be true for people. That doesn't in practice
|
|
mean that I7 never has high shelves or people with daggers concealed
|
|
beneath cloaks — just that we no longer use I6's mechanism for hiding
|
|
these things, and expect the user to write activity rules instead.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section SR1/7 - Supporters</span>
|
|
|
|
<span class="plain">The specification of supporter is "Represents a surface on which things can be</span>
|
|
<span class="plain">placed, such as a table."</span>
|
|
|
|
<span class="plain">A supporter can be enterable.</span>
|
|
<span class="plain">A supporter has a number called carrying capacity.</span>
|
|
<span class="plain">The carrying capacity of a supporter is usually 100.</span>
|
|
|
|
<span class="plain">A supporter is usually fixed in place.</span>
|
|
|
|
<span class="plain">Include (-</span>
|
|
<span class="plain">has transparent supporter</span>
|
|
<span class="plain">-) when defining a supporter.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP35"></a><b>§35. Kinds vs patterns. </b>A problem faced by all object-oriented systems is "fear of the diamond",
|
|
the problematic diagram of inheritance which results when we have two
|
|
different subclasses B and C of a class A, which represent quite different
|
|
ideas, but then we also turn out to want some behaviour D which is shared
|
|
between some of the Bs and some of the Cs. For instance, we might have one
|
|
class for people and another for buildings, but want to use the same
|
|
code when it comes to (say) printing out top ten lists of basketball
|
|
players (people) and skyscrapers (buildings) in height order: why not?
|
|
But then again, what does D conceptually represent? Surely we aren't saying
|
|
there's a natural concept of "basketball player/skyscraper"?
|
|
</p>
|
|
|
|
<p class="inwebparagraph">There are various responses, of which the most widely used now is probably
|
|
that of <code class="display"><span class="extract">C++</span></code>'s notion of templates. We would define our top-ten business
|
|
by writing a function applying to a list of objects of any class T such
|
|
that T provided a height: there would then be no need for "basketball
|
|
player/skyscraper" to be a class in its own right. Instead, we would
|
|
define the behaviour as being available to anything for which it makes
|
|
sense.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">This is broadly what Inform 7 does, too, though not so formally. We use the
|
|
term "pattern" for this, and have actually seen two patterns already —
|
|
the way that containers and supporters share the "carrying capacity"
|
|
limit, and also the notion of transparency — and it's by providing two
|
|
patterns that we are able to deal with the likeness and also unlikeness of
|
|
doors and containers. Their unlikeness is obvious; but their likeness is
|
|
that they both grant or withhold access to some extent of space bordering
|
|
on the current one. (Doors do this for the "horizontal" spatial model
|
|
between rooms, whereas containers do it for the "vertical" spatial model
|
|
of objects enclosing each other.)
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP36"></a><b>§36. The openability pattern. </b>To satisfy the openability pattern, a thing has to provide both of the
|
|
either/or properties "open" and "openable". This entitles it to be
|
|
opened and closed by the opening and closing actions, defined below.
|
|
Note that I7 has no formal concept of patterns as part of its type-checking:
|
|
instead, the rules for these actions explicitly check that they are being
|
|
applied to things matching the pattern, as we shall see.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Doors and containers have, as it happens, exactly opposite conventions
|
|
about the default values of these properties: but that doesn't mean they
|
|
don't share the pattern.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section SR1/8 - Openability</span>
|
|
|
|
<span class="plain">A door can be open or closed. A door is usually closed.</span>
|
|
<span class="plain">A door can be openable or unopenable. A door is usually openable.</span>
|
|
|
|
<span class="plain">A container can be open or closed. A container is usually open.</span>
|
|
<span class="plain">A container can be openable or unopenable. A container is usually unopenable.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP37"></a><b>§37. The lockability pattern. </b>And similarly for lockability, because a principle of the world model is
|
|
that any spatial barrier can be given a lock if the designer so chooses. To
|
|
satisfy this pattern, a thing must
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(i) satisfy the openability pattern, and
|
|
</li><li>(ii) provide both the either/or properties "lockable" and "locked",
|
|
and also the value property "matching key".
|
|
</li></ul>
|
|
<p class="inwebparagraph">Both doors and containers make some implications so that the words "lockable"
|
|
and "locked" carry the implied meanings which human readers expect, but
|
|
this is not essential to the functioning of lockability: it's only a graceful
|
|
addition.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section SR1/9 - Lockability</span>
|
|
|
|
<span class="plain">A door can be lockable. A door is usually not lockable.</span>
|
|
<span class="plain">A door can be locked or unlocked. A door is usually unlocked.</span>
|
|
<span class="plain">A door has an object called a matching key.</span>
|
|
<span class="plain">A locked door is usually lockable. [An implication.]</span>
|
|
<span class="plain">A locked door is usually closed. [An implication.]</span>
|
|
<span class="plain">A lockable door is usually openable. [An implication.]</span>
|
|
|
|
<span class="plain">A container can be lockable. A container is usually not lockable.</span>
|
|
<span class="plain">A container can be locked or unlocked. A container is usually unlocked.</span>
|
|
<span class="plain">A container has an object called a matching key.</span>
|
|
<span class="plain">A locked container is usually lockable. [An implication.]</span>
|
|
<span class="plain">A locked container is usually closed. [An implication.]</span>
|
|
<span class="plain">A lockable container is usually openable. [An implication.]</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP38"></a><b>§38. </b>Note that the lock-fitting relation has, as its domains, "thing" and
|
|
"thing". That means that compile-time typechecking will not reject an
|
|
attempt to apply the relation to (say) two vehicles. At run time, evaluating
|
|
"if X unlocks P" where P is a peculiar thing with no possibility of a lock
|
|
will always come out false; but trying to force it with "now X unlocks P"
|
|
will cause a run-time problem. In short, patterns are defended at run-time,
|
|
not at compile-time.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Lock-fitting relates one thing (called the matching key) to various things.</span>
|
|
<span class="plain">The verb to unlock means the lock-fitting relation.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP39"></a><b>§39. Backdrops. </b>The true subtlety of backdrops is not visible in the brief description here:
|
|
but they require careful handling both in NI and in the template layer code,
|
|
because they can be in many rooms at once.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section SR1/10 - Backdrops</span>
|
|
|
|
<span class="plain">The specification of backdrop is "Represents an aspect of the landscape</span>
|
|
<span class="plain">or architecture which extends across more than one room: for instance,</span>
|
|
<span class="plain">a stream, the sky or a long carpet."</span>
|
|
|
|
<span class="plain">A backdrop is usually scenery.</span>
|
|
<span class="plain">A backdrop is always fixed in place.</span>
|
|
<span class="plain">A backdrop is never pushable between rooms.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP40"></a><b>§40. People. </b>From a compilation point of view, people are surprisingly easy to deal with.
|
|
It may well be argued that this is because the I6 world model is so sketchy
|
|
in modelling them, but that may actually be a good thing, because it's not at
|
|
all obvious that any single model will be sensible for what different
|
|
authors want to do with their characters.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">On gender, see also the "man" and "woman" kinds below. Note that we have
|
|
three gender choices available — male, female and neuter — but these are,
|
|
for historical reasons to do with how gender is handled by the I6 library,
|
|
managed using either/or properties rather than a single three-way value
|
|
property. This doesn't in practice cause trouble. (Specifying something as
|
|
neuter overrides the male/female choice, if anyone does both for the same
|
|
object, but in practice nobody does.) When nothing is said about a person's
|
|
gender, it is assumed male, though this is used only linguistically (for
|
|
instance, the pronoun HIM can be used in commands about the object, rather
|
|
than HER or IT). There has to be some convention here, and in a case where
|
|
we don't know our linguistic ground, opting for the least surprising
|
|
behaviour seems wisest.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section SR1/11 - People</span>
|
|
|
|
<span class="plain">The specification of person is "Despite the name, not necessarily</span>
|
|
<span class="plain">a human being, but anything animate enough to envisage having a</span>
|
|
<span class="plain">conversation with, or bartering with."</span>
|
|
|
|
<span class="plain">A person can be female or male. A person is usually male.</span>
|
|
<span class="plain">A person can be neuter. A person is usually not neuter.</span>
|
|
|
|
<span class="plain">A person has a number called carrying capacity.</span>
|
|
<span class="plain">The carrying capacity of a person is usually 100.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP41"></a><b>§41. </b>I6 has a concept approximately equivalent to I7's "person" — the I6
|
|
library attribute <code class="display"><span class="extract">animate</span></code> — but I6 allows only some of those objects
|
|
to become the protagonist during play (using I6's <code class="display"><span class="extract">ChangePlayer</span></code> routine).
|
|
To be eligible, an object must not only be <code class="display"><span class="extract">animate</span></code> but also provide a
|
|
whole host of writeable properties.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">But I7 provides those I6 properties for every "person", for the sake of a
|
|
clean, uniform design, and accepting the cost that people therefore take
|
|
more bytes of precious Z-machine array space than they necessarily would in
|
|
I6. This is all part of the doctrine that in I7, all characters are equal
|
|
in status: all can be the player, all can carry out actions. Anyway: here
|
|
are all of those I6 properties, spatchcocked into the <code class="display"><span class="extract">Class</span></code> definition
|
|
which NI will compile for "person" — see section 21 of the DM4 for details
|
|
of why these are needed and what they do.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Include (-</span>
|
|
<span class="plain">has transparent animate</span>
|
|
<span class="plain">with before NULL,</span>
|
|
<span class="plain">-) when defining a person.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP42"></a><b>§42. </b>So to the thirteenth and final object created by the Standard Rules: the
|
|
enigmatic default protagonist, whose name is not "player" but "yourself".
|
|
(The I6 library requires this object to be created as <code class="display"><span class="extract">selfobj</span></code>, but that's
|
|
not a name that is ever printed or parsed: it's a constant value used
|
|
only in I6 source code.)
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The <code class="display"><span class="extract">yourself</span></code> object has to be proper-named to prevent the I6 library
|
|
from talking about "the yourself", as it otherwise might. "Undescribed"
|
|
in this context means that "yourself" is not described as being present
|
|
in room descriptions: this would be redundant and annoying.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The I6 property <code class="display"><span class="extract">saved_short_name</span></code> property is an implementation convenience
|
|
for use if there is ever a change of player, in which case the printed name
|
|
of the object will cease to be "yourself" and become "your former self"
|
|
instead. When this happens, the previous printed name (or <code class="display"><span class="extract">short_name</span></code> in
|
|
I6 terms) is stored in <code class="display"><span class="extract">saved_short_name</span></code> so that it can recovered later.
|
|
(We can't assume it was necessarily "yourself" because the source text
|
|
might have overridden this with a sentence like "The printed name of the
|
|
player is "your dreary self".")
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The yourself is an undescribed person. The yourself is proper-named.</span>
|
|
|
|
<span class="plain">The yourself is privately-named.</span>
|
|
<span class="plain">Understand "your former self" or "my former self" or "former self" or</span>
|
|
<span class="plain">"former" as yourself when the player is not yourself.</span>
|
|
|
|
<span class="plain">The description of yourself is usually "As good-looking as ever."</span>
|
|
|
|
<span class="plain">The yourself object translates into I6 as "selfobj".</span>
|
|
<span class="plain">Include (-</span>
|
|
<span class="plain">with saved_short_name (+ "yourself" +),</span>
|
|
<span class="plain">-) when defining yourself.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP43"></a><b>§43. Non-fundamental kinds. </b>We have now finished defining the nine fundamental kinds which NI requires
|
|
in order for it to function. There are six more to define, but it's worth
|
|
emphasising that none of these is required or assumed by either NI or
|
|
its template layer of I6 code. So any of them could be changed drastically
|
|
or got rid of entirely simply by amending the Standard Rules. (Like the
|
|
"player-character" kind, born early 2003, died July 2007.)
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Equally, we could add others if we wanted. The judgement of what ought to be
|
|
part of the basic hierarchy of kinds created by the Standard Rules isn't
|
|
easy. The maximalist position is that users welcome a plethora of kinds to
|
|
simulate many facets of real life, from canal-boats to candles. The minimalist
|
|
position is that kinds are necessary only as the domain of relations (so that
|
|
person is necessary as the domain of P in "P carries X", for instance), and
|
|
that too many kinds confuses the picture and imposes what may be a constraining
|
|
structure on the user, who should be free to decide for himself what concepts
|
|
are most helpful to organise. These arguments are discussed further in the
|
|
white paper, "Natural Language, Semantic Analysis and Interactive Fiction"
|
|
(2005), but briefly: we are minimalist but not puritanically so.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP44"></a><b>§44. Men, women and animals. </b>Of these discretionary kinds, so to speak, "man" and "woman" are perhaps
|
|
the least challengeable. They are not obviously the domains of any
|
|
natural relation (unless one takes a very old-fashioned idea of gender
|
|
identity and supposes that, oh, "X keeps Y" implies that X is a wealthy
|
|
man and Y a mistress). But they are so linguistically natural in story-telling:
|
|
who would ever write "Jack is a person in the House. Jack is male." in
|
|
preference to "Jack is a man in the House."
|
|
</p>
|
|
|
|
<p class="inwebparagraph">An awkward point here is that, of course, most people would simply say "Jack
|
|
is in the House." and expect us to infer that Jack is a person from the fact
|
|
that this is more often a human name than, say, a proprietary brand of
|
|
microphone plug; and that Jack is male, because relatively few girls called
|
|
Jacqueline are nicknamed Jack. As it happens the NI compiler doesn't allow
|
|
for tentative statements about the kinds of objects (only about their
|
|
property values), but it wouldn't be too hard to add such a system, with
|
|
a little care. The trouble is that we would then need a large dictionary of
|
|
boys' and girls' names, valid across American, Canadian, Australian and
|
|
British English (together with a selection from foreign tongues), and this
|
|
would always lead to puzzling omissions (why isn't "Glanville" recognised?)
|
|
or ambiguities (why is "Pat" a man?). And similarly for titles: "Mr",
|
|
"Mrs" and "Ms" are fairly indicative of gender, except in certain
|
|
military contexts, but what about (say) "Admiral" or "Reverend", where
|
|
there is a strong likelihood of masculinity but no more than that?
|
|
So Inform 7's compromise position is that the user does have to specify
|
|
gender explicitly, but that the kinds "man" and "woman" provide
|
|
conveniently abbreviated ways to do so. (We consider male and female
|
|
children to qualify in these categories.)
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Anyway, we set out the Anglo-Saxon plurals, and then declare these kinds
|
|
purely in terms of gender: they have no distinguishing behaviour.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section SR1/12 - Animals, men and women</span>
|
|
|
|
<span class="plain">The plural of man is men. The plural of woman is women.</span>
|
|
|
|
<span class="plain">A man is a kind of person.</span>
|
|
<span class="plain">The specification of man is "Represents a man or boy."</span>
|
|
<span class="plain">A man is always male. A man is never neuter.</span>
|
|
|
|
<span class="plain">A woman is a kind of person.</span>
|
|
<span class="plain">The specification of woman is "Represents a woman or girl."</span>
|
|
<span class="plain">A woman is always female. A woman is never neuter.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP45"></a><b>§45. </b>But what about "animal"? Animals turn up often in IF, and of course
|
|
domestic animals have been part of human society since prehistoric times:
|
|
but then again, the same can be said for stoves and larders, and we aren't
|
|
declaring kinds for those.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The reason "animal" exists is mainly because it is almost always peculiar
|
|
to write "P is a person". Now that we have "man" and "woman" taken
|
|
care of, the remaining objects we might want to declare will almost always
|
|
fall into this category: it's intended to be used for "people" who are
|
|
animate but probably not intelligent, or anyway, not participants in human
|
|
society. It seems unusual to write "The black Labrador is a person."
|
|
because that sounds like an insistent assertion of rights and thus a quite
|
|
different sort of statement. (Don't drown that Labrador! He's a person.)
|
|
</p>
|
|
|
|
<p class="inwebparagraph">As can be seen from the tiny definition of "animal", though, it's really
|
|
nothing more than a name for a position in the kinds hierarchy. There is
|
|
not even any implication for gender.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">An animal is a kind of person.</span>
|
|
|
|
<span class="plain">The specification of animal is "Represents an animal, or at any rate a</span>
|
|
<span class="plain">non-human living creature reasonably large and possible to interact with: a</span>
|
|
<span class="plain">giant Venus fly-trap might qualify, but not a patch of lichen."</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP46"></a><b>§46. Devices. </b>The justification for providing a "device" kind is much thinner. It's done
|
|
largely for traditional reasons — such a concept existed in the I6 library,
|
|
which in turn followed Infocom conventions dating from the early 1980s.
|
|
The inclusion is defensible as representing a common linguistic category
|
|
found in everyday situations, where an inanimate object nevertheless does
|
|
something while under direct or indirect human control: we can also imagine
|
|
relations for which it could be a domain ("X is able to work D" meaning
|
|
that person X understands how to use the controls of device D, say). It
|
|
could equally be attacked as having a rather flimsy world model — it's just
|
|
an on/off switch — and representing a pretty inchoate mass of concepts,
|
|
from a mousetrap to a nuclear reactor.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section SR1/13 - Devices</span>
|
|
|
|
<span class="plain">A device is a kind of thing.</span>
|
|
|
|
<span class="plain">A device can be switched on or switched off. A device is usually switched off.</span>
|
|
<span class="plain">Include (- has switchable, -) when defining a device.</span>
|
|
|
|
<span class="plain">The specification of device is "Represents a machine or contrivance of some</span>
|
|
<span class="plain">kind which can be switched on or off."</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP47"></a><b>§47. Vehicles. </b>Here again the justification boils down to tradition. Vehicles were a
|
|
staple ingredient of the Infocom classics, largely because of code
|
|
originally written for the inflatable boat in the 1978-79 mainframe version
|
|
of "Zork", which was then copied through into later titles. Unlike
|
|
devices, though, vehicles are genuinely difficult to model, and the
|
|
implementation provided by the Standard Rules would be quite a lot of
|
|
work for a user to manage alone. (Consider, for instance, the case when
|
|
the player is sitting in an open basket when Bill, driving a fork-lift
|
|
truck, uses his vehicle to push the basket into another room.) There
|
|
might perhaps be a case for moving all of the vehicles material into
|
|
an extension, but it would have to be an extension supplied as part of
|
|
the built-in set, and whenever it was used the result would be that
|
|
the going action would rely on a pretty complicated interlacing of rules
|
|
as between this extension and the Standard Rules.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Turning to implementation, I6 — surprisingly, perhaps — doesn't have
|
|
a <code class="display"><span class="extract">vehicle</span></code> attribute: a vehicle is an object which is <code class="display"><span class="extract">enterable</span></code> and
|
|
whose <code class="display"><span class="extract">before</span></code> rule for the I6 <code class="display"><span class="extract">##Go</span></code> action returns the magic value 1.
|
|
A troublesome point here is that I6 makes no distinction between vehicles
|
|
which contain and vehicles which support. But we do, because once we have
|
|
decided to make "vehicle" a kind, it has to be either a kind of container
|
|
or a kind of supporter: it can't be both. We get around this by providing
|
|
for container-vehicles in the Standard Rules, as being the more commonly
|
|
occurring case, while providing for the other with the extension Rideable
|
|
Vehicles by Graham Nelson, which is in effect an offshoot of the Standard
|
|
Rules and is built-in to every installation of Inform 7. This also provides
|
|
for animals used as vehicles.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The alternative approach here would be to make "vehicle" not a kind but
|
|
an either/or property of things, so as to provide a pattern of behaviour
|
|
common to certain animals, containers and supporters. We could then move
|
|
Rideable Vehicles back into the Standard Rules, but that would add a fair
|
|
amount of code, and besides, it is unclear that "vehicleness" is something
|
|
we want to come and go during play, or that it's appropriate as an either/or
|
|
property of (for instance) a door or a person.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section SR1/14 - Vehicles</span>
|
|
|
|
<span class="plain">A vehicle is a kind of container.</span>
|
|
|
|
<span class="plain">The specification of vehicle is "Represents a container large enough for</span>
|
|
<span class="plain">a person to enter, and which can then move between rooms at the driver's</span>
|
|
<span class="plain">instruction. (If a supporter is needed instead, try the extension</span>
|
|
<span class="plain">Rideable Vehicles by Graham Nelson.)"</span>
|
|
|
|
<span class="plain">A vehicle is always enterable.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP48"></a><b>§48. </b>The part about vehicles not usually being portable is simply for realism's
|
|
sake: generally speaking if something can hold human weight it's pretty
|
|
large and heavy. (A bicycle is an edge case, and a skateboard is clearly
|
|
an exception, but that's why the rule is only "usually".)
|
|
</p>
|
|
|
|
<p class="inwebparagraph">If all vehicles were wheeled, there would be a case for a rule such as
|
|
"A vehicle is usually pushable between rooms." But this seems more likely
|
|
to trip up the designer with a surprise discovery in beta-testing than to
|
|
help him achieve realism. We don't want to be able to push hot-air balloons,
|
|
boats or spacecraft between rooms.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">A vehicle is usually not portable.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP49"></a><b>§49. Player's holdalls. </b>This is the final kind created in the Standard Rules, and probably the most
|
|
doubtful of all. It simply provides a hook to a cute and traditional feature
|
|
of the I6 library whereby spare possessions are automatically cleared out
|
|
of the player's way: it derives from the rucksack in the 1993 IF title "Curses".
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section SR1/15 - Player's holdall</span>
|
|
|
|
<span class="plain">A player's holdall is a kind of container.</span>
|
|
|
|
<span class="plain">The specification of player's holdall is "Represents a container which the</span>
|
|
<span class="plain">player can carry around as a sort of rucksack, into which spare items are</span>
|
|
<span class="plain">automatically stowed away."</span>
|
|
|
|
<span class="plain">A player's holdall is always portable.</span>
|
|
<span class="plain">A player's holdall is usually openable.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP50"></a><b>§50. </b>To enable the use of player's holdalls, we must declare a constant
|
|
<code class="display"><span class="extract">RUCKSACK_CLASS</span></code> to tell some code in the template layer to use possessions
|
|
with this I6 class as the rucksack pro tem. This is all a bit of a hack, to retrofit
|
|
a degree of generality onto the original I6 library feature, and even then
|
|
it isn't really fully general: only the player has the benefit of a "player's
|
|
holdall" (hence the name), with other actors oblivious.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Include (-</span>
|
|
<span class="plain">Constant RUCKSACK_CLASS = (+ player's holdall +);</span>
|
|
<span class="plain">-) after "Definitions.i6t".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP51"></a><b>§51. Correspondence between I6 and I7 property and attribute names. </b>All of the kinds, objects and properties which make up the standard kit
|
|
provided to every source text are now complete. We conclude Section SR1 by
|
|
giving the NI compiler a dictionary to tell it how I7's names for
|
|
properties — some value properties, some either/or — mesh with those
|
|
in the I6 library.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Ordinarily, a new value property such as "astral significance" would
|
|
be compiled by NI into an I6 property called something like
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">P73_astral_significance</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph">whereas a new either/or property might become either an I6 attribute or an
|
|
I6 property holding only <code class="display"><span class="extract">true</span></code> or <code class="display"><span class="extract">false</span></code>, at the compiler's discretion.
|
|
(It needs to use this discretion because I6 has a hard limit on the number
|
|
of attributes, whereas there are no limits on the number of properties used
|
|
in I7.) And if "astral significance" is a concept handled only by I7
|
|
source text, that's fine.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">But we want our "printed name" property, for instance, to be the text
|
|
which the I6 library prints out whenever it uses the <code class="display"><span class="extract">short_name</span></code> of an
|
|
object: so we want the NI compiler to use the I6 identifier <code class="display"><span class="extract">short_name</span></code>
|
|
for "printed name", not to invent a new one. NI therefore maintains a
|
|
dictionary of equivalents, and here it is. (Any I7 property not named is
|
|
handled purely by I7 source text in the remainder of the Standard Rules.)
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP52"></a><b>§52. </b>First, equivalents where I7 either/or properties map directly onto
|
|
I6 attributes. Note the way "lit" (for things) and "lighted" (for rooms)
|
|
both map onto the same I6 attribute, <code class="display"><span class="extract">light</span></code>. Attributes were in scarce
|
|
supply in I6 (with a limit of 32 in the early days, later raised to 48) and
|
|
this sort of reuse seemed sensible in the early 1990s, especially as the
|
|
meanings were basically similar.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section SR1/16 - Inform 6 equivalents</span>
|
|
|
|
<span class="plain">The wearable property translates into I6 as "clothing".</span>
|
|
<span class="plain">The undescribed property translates into I6 as "concealed".</span>
|
|
<span class="plain">The edible property translates into I6 as "edible".</span>
|
|
<span class="plain">The enterable property translates into I6 as "enterable".</span>
|
|
<span class="plain">The female property translates into I6 as "female".</span>
|
|
<span class="plain">The mentioned property translates into I6 as "mentioned".</span>
|
|
<span class="plain">The lit property translates into I6 as "light".</span>
|
|
<span class="plain">The lighted property translates into I6 as "light".</span>
|
|
<span class="plain">The lockable property translates into I6 as "lockable".</span>
|
|
<span class="plain">The locked property translates into I6 as "locked".</span>
|
|
<span class="plain">The handled property translates into I6 as "moved".</span>
|
|
<span class="plain">The neuter property translates into I6 as "neuter".</span>
|
|
<span class="plain">The switched on property translates into I6 as "on".</span>
|
|
<span class="plain">The open property translates into I6 as "open".</span>
|
|
<span class="plain">The openable property translates into I6 as "openable".</span>
|
|
<span class="plain">The privately-named property translates into I6 as "privately_named".</span>
|
|
<span class="plain">The plural-named property translates into I6 as "pluralname".</span>
|
|
<span class="plain">The ambiguously plural property translates into I6 as "ambigpluralname".</span>
|
|
<span class="plain">The proper-named property translates into I6 as "proper".</span>
|
|
<span class="plain">The pushable between rooms property translates into I6 as "pushable".</span>
|
|
<span class="plain">The scenery property translates into I6 as "scenery".</span>
|
|
<span class="plain">The fixed in place property translates into I6 as "static".</span>
|
|
<span class="plain">The transparent property translates into I6 as "transparent".</span>
|
|
<span class="plain">The visited property translates into I6 as "visited".</span>
|
|
<span class="plain">The marked for listing property translates into I6 as "workflag".</span>
|
|
<span class="plain">The list grouping key property translates into I6 as "list_together".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP53"></a><b>§53. </b>Second, the I7 value properties mapping onto I6 properties. Again,
|
|
<code class="display"><span class="extract">map_region</span></code> is a new I6 property of our own, while the rest are I6 staples.
|
|
And see also "other side", which is translated above for timing reasons.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The indefinite article property translates into I6 as "article".</span>
|
|
<span class="plain">The carrying capacity property translates into I6 as "capacity".</span>
|
|
<span class="plain">The description property translates into I6 as "description".</span>
|
|
<span class="plain">The initial appearance property translates into I6 as "initial".</span>
|
|
<span class="plain">The map region property translates into I6 as "map_region".</span>
|
|
<span class="plain">The printed plural name property translates into I6 as "plural".</span>
|
|
<span class="plain">The printed name property translates into I6 as "short_name".</span>
|
|
<span class="plain">The matching key property translates into I6 as "with_key".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP54"></a><b>§54. </b></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Part SR1a - Simplified (not for interactive fiction language element)</span>
|
|
|
|
<span class="plain">An object has a text called specification.</span>
|
|
<span class="plain">An object has a text called indefinite appearance text.</span>
|
|
<span class="plain">An object has a value called variable initial value.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<hr class="tocbar">
|
|
<ul class="toc"><li><a href="S-prm.html">Back to 'Preamble'</a></li><li><a href="S-var.html">Continue with 'Variables and Rulebooks'</a></li></ul><hr class="tocbar">
|
|
<!--End of weave-->
|
|
</body>
|
|
</html>
|
|
|