mirror of
https://github.com/ganelson/inform.git
synced 2024-07-09 02:24:21 +03:00
1594 lines
86 KiB
HTML
1594 lines
86 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|
<html>
|
|
<head>
|
|
<title>S/pwm</title>
|
|
<meta name="viewport" content="width=device-width initial-scale=1">
|
|
<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>
|
|
<nav role="navigation">
|
|
<h1><a href="../webs.html">Sources</a></h1>
|
|
<ul>
|
|
<li><a href="../compiler.html">compiler tools</a></li>
|
|
<li><a href="../other.html">other tools</a></li>
|
|
<li><a href="../extensions.html"><b>extensions and kits</b></a></li>
|
|
<li><a href="../units.html">unit test tools</a></li>
|
|
/ul>
|
|
<h2>Extensions</h2>
|
|
<ul>
|
|
<li><a href="../basic_inform/index.html">Basic Inform</a></li>
|
|
<li><a href="../standard_rules/index.html">Standard Rules</a></li>
|
|
</ul>
|
|
<h2>Kits</h2>
|
|
<ul>
|
|
<li><a href="../BasicInformKit/index.html">BasicInformKit</a></li>
|
|
<li><a href="../BasicInformExtrasKit/index.html">BasicInformExtrasKit</a></li>
|
|
<li><a href="../CommandParserKit/index.html">CommandParserKit</a></li>
|
|
<li><a href="../EnglishLanguageKit/index.html">EnglishLanguageKit</a></li>
|
|
<li><a href="../WorldModelKit/index.html">WorldModelKit</a></li>
|
|
</ul>
|
|
|
|
|
|
</nav>
|
|
<main role="main">
|
|
|
|
<!--Weave of 'S/var' generated by 7-->
|
|
<ul class="crumbs"><li><a href="../webs.html">Source</a></li><li><a href="../extensions.html">Extensions</a></li><li><a href="index.html">srules</a></li><li><b>Variables and Rulebooks</b></li></ul><p class="purpose">The global variables and those built-in rulebooks which do not belong either to specific actions or to specific activities.</p>
|
|
|
|
<ul class="toc"><li><a href="#SP1">§1. The player's situation</a></li><li><a href="#SP11">§11. Rulebooks</a></li><li><a href="#SP21">§21. Rules</a></li><li><a href="#SP22">§22. Startup</a></li><li><a href="#SP24">§24. The turn sequence</a></li><li><a href="#SP29">§29. Shutdown</a></li><li><a href="#SP30">§30. Scene changing</a></li><li><a href="#SP32">§32. Action-processing</a></li><li><a href="#SP37">§37. Specific action-processing</a></li><li><a href="#SP41">§41. Player's action awareness</a></li><li><a href="#SP42">§42. Accessibility</a></li><li><a href="#SP43">§43. Reaching inside</a></li><li><a href="#SP44">§44. Reaching outside</a></li><li><a href="#SP45">§45. Visibility</a></li><li><a href="#SP46">§46. Does the player mean</a></li><li><a href="#SP48">§48. Adjectives applied to values</a></li><li><a href="#SP49">§49. Scene descriptions</a></li><li><a href="#SP50">§50. Command parser errors</a></li><li><a href="#SP51">§51. Internal rules</a></li></ul><hr class="tocbar">
|
|
|
|
<p class="inwebparagraph"><a id="SP1"></a><b>§1. The player's situation. </b>A set of global variables defines the player's current situation in
|
|
space and time.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Although users often think of the protagonist object as a fixed object
|
|
whose name is "player", this is a variable, and it is possible to change
|
|
perspective during play and become somebody else — at which point the
|
|
"player" variable will point to a different object.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Note that "player" is a name given to a variable explicitly defined in
|
|
the <code class="display"><span class="extract">srules</span></code> template with a given name (in this case <code class="display"><span class="extract">player</span></code>), so it
|
|
has a "translates into I6" sentence.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
|
|
<span class="plain">Part Three - Variables and Rulebooks</span>
|
|
|
|
<span class="plain">Chapter 1 - Variables</span>
|
|
|
|
<span class="plain">Section 1 - Situation</span>
|
|
|
|
<span class="plain">The player is a person that varies.</span>
|
|
<span class="plain">The player variable translates into I6 as "player".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP2"></a><b>§2. </b>The I7 variable "location" corresponds to I6's <code class="display"><span class="extract">real_location</span></code>, not
|
|
<code class="display"><span class="extract">location</span></code>. Its value is never equal to a pseudo-room representing darkness:
|
|
it is always an actual room, and I7 has nothing corresponding to I6's
|
|
<code class="display"><span class="extract">thedark</span></code> "room". Similarly, we use an I7 variable "darkness witnessed" for a
|
|
flag which the I6 library would have stored as the <code class="display"><span class="extract">visited</span></code> attribute for the
|
|
<code class="display"><span class="extract">thedark</span></code> object.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The "maximum score" is, rather cheekily, translated to an I6 constant:
|
|
and this cannot be changed at run-time.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The location -- documented at var_location -- is an object that varies.</span>
|
|
<span class="plain">The score -- documented at var_score -- is a number that varies.</span>
|
|
<span class="plain">The last notified score is a number that varies.</span>
|
|
<span class="plain">The maximum score is a number that varies.</span>
|
|
<span class="plain">The turn count is a number that varies.</span>
|
|
<span class="plain">The time of day -- documented at var_time -- is a time that varies.</span>
|
|
<span class="plain">The darkness witnessed is a truth state that varies.</span>
|
|
|
|
<span class="plain">The location variable translates into I6 as "real_location".</span>
|
|
<span class="plain">The score variable translates into I6 as "score".</span>
|
|
<span class="plain">The last notified score variable translates into I6 as "last_score".</span>
|
|
<span class="plain">The maximum score variable translates into I6 as "MAX_SCORE".</span>
|
|
<span class="plain">The turn count variable translates into I6 as "turns".</span>
|
|
<span class="plain">The time of day variable translates into I6 as "the_time".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP3"></a><b>§3. </b>It is arguable that "noun", "second noun" and "person asked" ought
|
|
to be rulebook variables belonging to the action-processing rules, so that
|
|
they essentially did not exist outside of the context of an ongoing action.
|
|
The reason this isn't done is partly historical (rulebook variables were a
|
|
fairly late development, implemented in April 2007, though they had long
|
|
been planned). But it is sometimes useful to get at the nouns in an action
|
|
after it has finished, and making them global variables also makes them a
|
|
little faster to look up (a good thing since they are used so much), and
|
|
causes them to be indexed more prominently.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">"Item described" is simply an I7 name for <code class="display"><span class="extract">self</span></code>. (This is an Inter variable
|
|
which refers to the object currently under discussion.) In early drafts of I7,
|
|
it was called "this object", but somehow this raised expectations too high
|
|
about how often it would be meaningful: it looked like a pronoun running
|
|
meanings from sentence to sentence.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section 2 - Current action</span>
|
|
|
|
<span class="plain">The noun -- documented at var_noun -- is an object that varies.</span>
|
|
<span class="plain">The second noun is an object that varies.</span>
|
|
<span class="plain">The person asked -- documented at var_person_asked -- is an object that varies.</span>
|
|
<span class="plain">The reason the action failed -- documented at var_reason -- is an action name</span>
|
|
<span class="plain">based rule producing nothing that varies.</span>
|
|
<span class="plain">The item described is an object that varies.</span>
|
|
|
|
<span class="plain">The noun variable translates into I6 as "noun".</span>
|
|
<span class="plain">The second noun variable translates into I6 as "second".</span>
|
|
<span class="plain">The person asked variable translates into I6 as "actor".</span>
|
|
<span class="plain">The reason the action failed variable translates into I6 as "reason_the_action_failed".</span>
|
|
<span class="plain">The item described variable translates into I6 as "self".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP4"></a><b>§4. </b>"Person reaching" turns out to have exactly the same meaning as "person
|
|
asked" — they are both the <code class="display"><span class="extract">actor</span></code>, in Inter terms, but are used in different
|
|
situations.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section 3 - Used when ruling on accessibility</span>
|
|
|
|
<span class="plain">The person reaching -- documented at var_person_reaching -- is an object that varies.</span>
|
|
<span class="plain">The container in question is an object that varies.</span>
|
|
<span class="plain">The supporter in question is an object that varies.</span>
|
|
<span class="plain">The particular possession -- documented at var_particular -- is a thing that varies.</span>
|
|
|
|
<span class="plain">The person reaching variable translates into I6 as "actor".</span>
|
|
<span class="plain">The container in question variable translates into I6 as "parameter_object".</span>
|
|
<span class="plain">The supporter in question variable translates into I6 as "parameter_object".</span>
|
|
<span class="plain">The particular possession variable translates into I6 as "particular_possession".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP5"></a><b>§5. </b>Parsing variables follow. The I6 parser tends to put any data read as part
|
|
of a command into the variable <code class="display"><span class="extract">parsed_number</span></code>, but then, Inter is typeless:
|
|
we can't have a single I7 variable for all these possibilities since it could
|
|
then have no legal type. We solve this as follows. Whenever a kind of value
|
|
K is created which can be parsed as part of a command, an I7 variable "the
|
|
K understood" is also created, as a K that varies. All of these variables
|
|
are translated into Inter's <code class="display"><span class="extract">parsed_number</span></code>, so in effect they provide aliases
|
|
of each possible type for the same underlying memory location. The four
|
|
exceptional kinds of value not parsed by the systematic approaches in Inform
|
|
for enumerated KOVs and units are "number", "time", "snippet" and "truth
|
|
state": because of their exceptional status, they don't get "the K
|
|
understood" variables created automatically for them, so we must construct
|
|
those by hand. Hence "the number understood", "the time understood", "the
|
|
topic understood" (for historical reasons this one is not called "the snippet
|
|
understood"), "the truth state understood" but no others.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section 4 - Used when understanding typed commands</span>
|
|
|
|
<span class="plain">The player's command -- documented at var_command -- is a snippet that varies.</span>
|
|
<span class="plain">The matched text is a snippet that varies.</span>
|
|
<span class="plain">The number understood -- documented at var_understood -- is a number that varies.</span>
|
|
<span class="plain">The real number understood -- documented at var_understood -- is a real number that varies.</span>
|
|
<span class="plain">The time understood is a time that varies.</span>
|
|
<span class="plain">The topic understood is a snippet that varies.</span>
|
|
<span class="plain">The truth state understood is a truth state that varies.</span>
|
|
<span class="plain">The current item from the multiple object list is an object that varies.</span>
|
|
|
|
<span class="plain">The player's command variable translates into I6 as "players_command".</span>
|
|
<span class="plain">The matched text variable translates into I6 as "matched_text".</span>
|
|
<span class="plain">The topic understood variable translates into I6 as "parsed_number".</span>
|
|
<span class="plain">The current item from the multiple object list variable translates into I6 as</span>
|
|
<span class="plain">"multiple_object_item".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP6"></a><b>§6. </b></p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section 5 - Presentation on screen</span>
|
|
|
|
<span class="plain">The command prompt -- documented at var_prompt -- is a text that varies.</span>
|
|
<span class="plain">The command prompt is ">".</span>
|
|
|
|
<span class="plain">The left hand status line -- documented at var_sl -- is a text that varies.</span>
|
|
<span class="plain">The right hand status line is a text that varies.</span>
|
|
|
|
<span class="plain">The left hand status line variable translates into I6 as "left_hand_status_line".</span>
|
|
<span class="plain">The right hand status line variable translates into I6 as "right_hand_status_line".</span>
|
|
|
|
<span class="plain">The listing group size is a number that varies.</span>
|
|
<span class="plain">The listing group size variable translates into I6 as "listing_size".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP7"></a><b>§7. </b>Now some linguistic variables:
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section 6 - Language generation</span>
|
|
|
|
<span class="plain">The prior named object is an object that varies.</span>
|
|
<span class="plain">The prior named object variable translates into I6 as "prior_named_noun".</span>
|
|
<span class="plain">An object has a text called list grouping key.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP8"></a><b>§8. </b>...but they are not the last global variables created by the Standard Rules.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">These bibliographic data variables are concealed because they are under a
|
|
heading which ends with the word "unindexed". There are two reasons why
|
|
these variables are unindexed: first, they appear in a different guise only
|
|
a little lower in the Contents index as part of the Library Card, and
|
|
second, we don't want users to think of them as manipulable during play.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Rather sneakily, we also define a Figure here. This is done in order to
|
|
make it legal to declare variables and properties of the kind of value
|
|
"figure name" (because it ensures that such variables can always be
|
|
initialised — there is always at least one Figure in the world). Of
|
|
course plenty of Inform projects have no artwork at all: so the cover art
|
|
figure is unique in that it might refer to nothing. That sounds a little
|
|
arbitrary but in fact follows a convention used by the Blorb format for
|
|
binding story files with their resources, which in turn follows Infocom
|
|
conventions of 1987-89: the cover art always has resource ID number 1,
|
|
whether it exists or not. Inform creates figures and sound effects counting
|
|
upwards from 1, giving them each unique resource ID numbers, so the first
|
|
to be created gets ID number 1: by defining "figure of cover" here, we
|
|
can be sure that we are first, so everything works.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section 7 - Unindexed Standard Rules variables - Unindexed</span>
|
|
|
|
<span class="plain">The story title, the story author, the story headline, the story genre</span>
|
|
<span class="plain">and the story description are text variables. [*****]</span>
|
|
<span class="plain">The release number and the story creation year are number variables. [**]</span>
|
|
|
|
<span class="plain">The release number is usually 1.</span>
|
|
<span class="plain">The story headline is usually "An Interactive Fiction".</span>
|
|
<span class="plain">The story genre is usually "Fiction".</span>
|
|
|
|
<span class="plain">The story title variable translates into I6 as "Story".</span>
|
|
|
|
<span class="plain">Section SR2/6b - Unindexed Standard Rules variables - Unindexed (for figures language element only)</span>
|
|
|
|
<span class="plain">Figure of cover is the file of cover art ("The cover art.").</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP9"></a><b>§9. </b>And we finish out the set with some "secret" variables used only by the
|
|
Standard Rules or by Inform, and which are therefore also unindexed. Their
|
|
names are all hyphenated, to reduce the chance of anyone stumbling into
|
|
them in a namespace clash.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The first set of three secret variables is used by the predicate calculus
|
|
machinery in Inform. This is the code which handles logical sentences such as
|
|
"at least six doors are open" or descriptions such as "open doors", by
|
|
reducing them to a logical notation which sometimes makes use of variables.
|
|
For instance, "open doors" reduces to something like "all x such that
|
|
door(x) and open(x)", with x being a variable. When Inform works with
|
|
such logical propositions, it often needs to substitute x=c, that is, to
|
|
replace x with a given constant c. But it can only do this if c is an
|
|
Inform 7 value. This is a problem if what it wants is to substitute in
|
|
something which is only meaningful at the I6 level: say, it wants to
|
|
substitute a value c which will eventually translate to <code class="display"><span class="extract">whatever</span></code>, but
|
|
it can't find any I7 value c which will do this.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">We solve this problem by constructing some unusual I7 variables whose only
|
|
purpose is that Inform can use them in substitutions. They should never be
|
|
referred to in I7 source text anywhere else at all, not even elsewhere in
|
|
the Standard Rules.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(1) The sentence "The i6-nothing-constant is an object that varies." is
|
|
a rare example of a flat lie in the Standard Rules, as it is the I6 constant
|
|
<code class="display"><span class="extract">nothing</span></code> and never varies at all. It exists as a "variable" so that the
|
|
substitution x=~<code class="display"><span class="extract">nothing</span></code> can be made.
|
|
</li></ul>
|
|
<ul class="items"><li>(2) Well, once you start telling lies it's so hard to stop, and it's also a
|
|
lie that the "I6-varying-global" translates to <code class="display"><span class="extract">nothing</span></code>. It actually
|
|
translates to whatever the Inform machinery for compiling propositions happens
|
|
to want at the moment, so it has no permanent meaning at all. (It will
|
|
always translate to an I6 global variable storing a value whose I7 kind
|
|
is "object", so the type-checking machinery isn't endangered by this
|
|
chicanery. It will in fact never translate to <code class="display"><span class="extract">nothing</span></code>, but we make the
|
|
translation sentence below in order to avoid allocating any storage at
|
|
run-time for what is in the end only a label.)
|
|
</li></ul>
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section 8 - Unindexed Standard Rules variables - Unindexed</span>
|
|
|
|
<span class="plain">The I6-nothing-constant is an object that varies.</span>
|
|
<span class="plain">The I6-nothing-constant variable translates into I6 as "nothing".</span>
|
|
|
|
<span class="plain">The I6-varying-global is an object that varies.</span>
|
|
<span class="plain">The I6-varying-global variable translates into I6 as "nothing".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP10"></a><b>§10. </b>The remaining secret variables are:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(1) The "item-pushed-between-rooms" is needed to get the identity of
|
|
an object being pushed by a command like PUSH ARMCHAIR NORTH out of I6
|
|
and into the action variable "thing gone with" of the going action.
|
|
</li></ul>
|
|
<ul class="items"><li>(2) The "actor-location" is needed temporarily to store the room in
|
|
which the actor of the current action is standing, and it wants to be
|
|
an I6 global (rather than, say, a rulebook variable belonging to the
|
|
action-processing rulebook) so that Inform can use common code to handle
|
|
this alongside <code class="display"><span class="extract">noun</span></code>, <code class="display"><span class="extract">second</span></code> and <code class="display"><span class="extract">actor</span></code> when compiling preambles
|
|
to rules.
|
|
</li></ul>
|
|
<ul class="items"><li>(3) The "parameter-object" is likewise needed in order to compile
|
|
preambles to rules in object-based rulebooks.
|
|
</li></ul>
|
|
|
|
<pre class="display">
|
|
<span class="plain">The item-pushed-between-rooms is an object that varies.</span>
|
|
<span class="plain">The item-pushed-between-rooms variable translates into I6 as "move_pushing".</span>
|
|
|
|
<span class="plain">The actor-location is an object that varies. [*]</span>
|
|
<span class="plain">The actor-location variable translates into I6 as "actor_location".</span>
|
|
|
|
<span class="plain">The scene being changed is a scene that varies. [*]</span>
|
|
<span class="plain">The scene being changed variable translates into I6 as "parameter_value".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP11"></a><b>§11. Rulebooks. </b>Whereas Basic Inform equips the language with only a handful of rulebooks
|
|
to start out, the Standard Rules are replete with them.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Note, however, that many of these have explicit support in the <code class="display"><span class="extract">basicinform</span></code>
|
|
template and in the compiler itself, and that they must be created exactly
|
|
in the order below, unless matching changes are made to both other places.
|
|
In particular, these need to stay in sync:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(a) The sequence of declaration of these rulebooks here, in the Standard Rules.
|
|
</li><li>(b) The inweb <code class="display"><span class="extract">@d</span></code> definitions in the form <code class="display"><span class="extract">TURN_SEQUENCE_RB</span></code> in the section
|
|
Rulebooks of the Inform source code.
|
|
</li><li>(c) The I6 <code class="display"><span class="extract">Constant</span></code> definitions in the form <code class="display"><span class="extract">TURN_SEQUENCE_RB</span></code> in the file
|
|
<code class="display"><span class="extract">Definitions.i6t</span></code> of the <code class="display"><span class="extract">basicinform</span></code> template.
|
|
</li></ul>
|
|
<p class="inwebparagraph"><a id="SP12"></a><b>§12. </b>When an interactive fiction project using the Standard Rules starts up,
|
|
it does the following:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(1) Consider the startup rules.
|
|
</li><li>(2) Repeatedly follow the turn sequence rules until the Inter variable
|
|
<code class="display"><span class="extract">deadflag</span></code> is set, which is used to indicate that the game has ended in one
|
|
way or another (though not necessarily in "death").
|
|
</li><li>(3) Follow the shutdown rules.
|
|
</li></ul>
|
|
<p class="inwebparagraph">Briefly, the startup phase takes us to the end of the room description
|
|
after the banner is printed. The turn sequence covers a complete turn,
|
|
and runs through from prompting the player for a command to notifying
|
|
him of any change in score which occurred. The shutdown rules then go
|
|
from printing the obituary text, through final score, to the question
|
|
about quitting or restarting.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Chapter 2 - Rulebooks</span>
|
|
|
|
<span class="plain">Section 1 - The Standard Rulebooks</span>
|
|
|
|
<span class="plain">Turn sequence rules is a rulebook.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP13"></a><b>§13. </b>Now a set of rulebooks to do with the passage of time.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Scene changing rules is a rulebook.</span>
|
|
<span class="plain">When play begins is a rulebook.</span>
|
|
<span class="plain">When play ends is a rulebook.</span>
|
|
<span class="plain">When scene begins is a scene based rulebook.</span>
|
|
<span class="plain">When scene ends is a scene based rulebook.</span>
|
|
<span class="plain">Every turn rules is a rulebook.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP14"></a><b>§14. </b>The action machinery requires some 16 rulebooks to work, though that is
|
|
the result of gradual simplification — in 2006 it required 25, for instance.
|
|
The "action-processing" rulebook, like the turn sequence rulebook, is a
|
|
master of ceremonies: it belongs to the Standard Rules and is only rarely if
|
|
at all referred to by users.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">As remarked above, it's something of a historical accident that "actor" is
|
|
a rulebook variable belonging to the action-processing rules (and thus in
|
|
scope for every rulebook it employs) while "noun" and "second noun" are
|
|
global variables (and thus in scope everywhere).
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The main action-processing rulebook delegates most of its detailed work to
|
|
a subsidiary, the "specific action-processing" rulebook, at the point where
|
|
what rulebooks we consult next depends on what the action is (hence "specific")
|
|
— see below for more on how check/carry out/report rules are filed.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Action-processing rules is a rulebook.</span>
|
|
<span class="plain">The action-processing rulebook has a person called the actor.</span>
|
|
<span class="plain">Setting action variables is a rulebook.</span>
|
|
<span class="plain">The specific action-processing rules is a rulebook.</span>
|
|
<span class="plain">The specific action-processing rulebook has a truth state called action in world.</span>
|
|
<span class="plain">The specific action-processing rulebook has a truth state called action keeping silent.</span>
|
|
<span class="plain">The specific action-processing rulebook has a rulebook called specific check rulebook.</span>
|
|
<span class="plain">The specific action-processing rulebook has a rulebook called specific carry out rulebook.</span>
|
|
<span class="plain">The specific action-processing rulebook has a rulebook called specific report rulebook.</span>
|
|
<span class="plain">The specific action-processing rulebook has a truth state called within the player's sight.</span>
|
|
<span class="plain">The player's action awareness rules is a rulebook.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP15"></a><b>§15. </b>The rules on accessibility and visibility, which control whether an action
|
|
is physically possible, have named outcomes as a taste of syntactic sugar.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Accessibility rules is a rulebook.</span>
|
|
<span class="plain">Reaching inside rules is an object-based rulebook.</span>
|
|
<span class="plain">Reaching inside rules have outcomes allow access (success) and deny access (failure).</span>
|
|
<span class="plain">Reaching outside rules is an object-based rulebook.</span>
|
|
<span class="plain">Reaching outside rules have outcomes allow access (success) and deny access (failure).</span>
|
|
<span class="plain">Visibility rules is a rulebook.</span>
|
|
<span class="plain">Visibility rules have outcomes there is sufficient light (failure) and there is</span>
|
|
<span class="plain">insufficient light (success).</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP16"></a><b>§16. </b>Two rulebooks govern the processing of asking other people to carry out actions:
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Persuasion rules is a rulebook.</span>
|
|
<span class="plain">Persuasion rules have outcomes persuasion succeeds (success) and persuasion fails (failure).</span>
|
|
<span class="plain">Unsuccessful attempt by is a rulebook.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP17"></a><b>§17. </b>Next, the six classic rulebooks best known to users of Inform. It's
|
|
perhaps an unfortunate point of the design that there are so many as six:
|
|
that seems rather a lot of stages to go through, and indeed means that there
|
|
is sometimes some ambiguity about which rulebook to use if one wants to
|
|
achieve a given effect. There are really two reasons why things are done
|
|
this way:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(a) To try to encourage a distinction between:
|
|
</li></ul>
|
|
<ul class="items"><ul class="items"><li>(i) the general implementation of an action, made with carry out, check
|
|
and report rules — say, a "photographing" action which could be used in
|
|
any situation and could be copied and pasted into another project; and
|
|
</li></ul>
|
|
</li></ul>
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><ul class="items"><li>(ii) the contingent rules applying in particular situations in play, made
|
|
with before, instead and after rules, such as that custodians at the
|
|
Metropolitan Museum of Art forbid flash photography.
|
|
</li></ul>
|
|
</li></ul>
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(b) To improve the efficiency of action-processing by forcing control to
|
|
run only through those carry out, check and report rules which can possibly
|
|
be relevant to the current action. Whereas all before, instead and after
|
|
rules are all piled up together in their own rulebooks, check, carry out
|
|
and report rules are divided up into specialised rulebooks tied to the
|
|
particular action in progress. Thus on a taking action, the six stages
|
|
followed are before, instead, check taking, carry out taking, after and
|
|
report taking.
|
|
</li></ul>
|
|
<p class="inwebparagraph">During play, then, the three rulebooks "check", "after" and "report"
|
|
are completely empty. This is the result of a reform in April 2007 which
|
|
wasn't altogether popular. Before then, Inform rather cleverly filed rules like
|
|
"Check doing something with the haddock" in the generic "check"
|
|
rulebook and ran this rulebook as part of the action processing sequence.
|
|
But this clearly broke principle (i) above, and meant that the six-stage
|
|
process — already quite complicated enough — was actually a nine-stage
|
|
process only pretending, by deceitful syntax, to be a six-stage one. Check
|
|
rules sometimes appeared to be filed in the wrong order, breaking the
|
|
ordinary precedence conventions, and this was not due to a bug but because
|
|
they were only pretending all to be in the same rulebook. Still more clever
|
|
indexing and rule-ordering tricks ameliorated this a little, but in the end
|
|
it was just a bad design: withdrawing the ability to make check, carry out
|
|
and report rules apply to multiple actions resulted in much cleaner code,
|
|
and also a clearer conceptual definition of what these rulebooks were for.
|
|
(But users still didn't like the change: actual functionality was
|
|
withdrawn.)
|
|
</p>
|
|
|
|
<p class="inwebparagraph">So if they are always empty and never used, why are the three rulebooks
|
|
called simply "check", "after" and "report" created in the first
|
|
place? The answer is that this is a convenience for parsing rule preambles
|
|
in Inform: it provides a temporary home for such rules before they are divided up
|
|
into their specific rulebooks, and it also makes it easier for Inform to detect
|
|
and give a helpful Problem message in response to rules like "Check taking
|
|
or dropping the perch" which can't be filed anywhere in our scheme, and so
|
|
have to be forbidden.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Before rules is a rulebook.</span>
|
|
<span class="plain">Instead rules is a rulebook.</span>
|
|
<span class="plain">Check rules is a rulebook.</span>
|
|
<span class="plain">Carry out rules is a rulebook.</span>
|
|
<span class="plain">After rules is a rulebook.</span>
|
|
<span class="plain">Report rules is a rulebook.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP18"></a><b>§18. </b>The next rulebook in this roundup is one used for parsing ambiguous
|
|
commands during play. This looks like the job of an activity rather than a
|
|
rulebook, but (i) we want information in the form of a nicely-named five point
|
|
scale of responses, rather than wanting something to be done, and (ii) it
|
|
doesn't really make any sense to split that question into a before, for and
|
|
after stage. So this is a named rulebook instead.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">"Does the player mean" is essentially a front end for the I6 parser's
|
|
<code class="display"><span class="extract">ChooseObjects</span></code> entry point, which relies on numerical scores to assess the
|
|
likelihood of possible choices. To facilitate that, the I7 compiler recognises
|
|
these five outcome names and translates them into the Inter constants
|
|
<code class="display"><span class="extract">RBNO4_OUTCOME</span></code>, <code class="display"><span class="extract">RBNO3_OUTCOME</span></code>, ..., <code class="display"><span class="extract">RBNO0_OUTCOME</span></code> respectively. So don't
|
|
change the names of these outcomes.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The does the player mean rules is a rulebook.</span>
|
|
<span class="plain">The does the player mean rules have outcomes it is very likely, it is likely, it is possible,</span>
|
|
<span class="plain">it is unlikely and it is very unlikely.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP19"></a><b>§19. </b>The following rulebook was added at the (implied) suggestion of John
|
|
Clemens, whose Consolidated Multiple Actions extension made use of
|
|
something similar.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The multiple action processing rules is a rulebook.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP20"></a><b>§20. </b>And that's it: all of the named rulebooks now exist. There will, of
|
|
course, be hundreds more rulebooks soon, created automatically as activities
|
|
and actions are created — when we create the "dropping" action, for
|
|
instance, we also create the "check dropping", "carry out dropping" and
|
|
"report dropping" rulebooks — but there are no more stand-alone rulebooks.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP21"></a><b>§21. Rules. </b>At run-time, the value of a rule is the (packed) address of an I6 routine.
|
|
In the case of rules created in I7 source text, the body of the rule
|
|
definition is compiled by Inform to a new I6 routine which carries it out.
|
|
But there are also primitive rules which are implemented in the template
|
|
I6 layer, and these need no I7 source text definitions: instead we simply
|
|
tell Inform the name of the I6 routine which will be handling this rule, and
|
|
that it need not bother to create one for itself.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">An example of this is provided by the first rule we shall create: the
|
|
"little-used do nothing rule". This is aptly named on both counts. We
|
|
never follow it, we never put it into any rulebook. It exists only so that
|
|
variables and properties with the kind of value "rule" can be initialised
|
|
automatically to a safely neutral default value. It makes no decision.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section 2 - The Standard Rules</span>
|
|
|
|
<span class="plain">The little-used do nothing rule translates into I6 as "LITTLE_USED_DO_NOTHING_R".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP22"></a><b>§22. Startup. </b>Every rulebook contains a (possibly empty) run of "first" rules, then
|
|
a (possibly empty) run of miscellaneous rules, then a (possibly empty)
|
|
run of "last" rules. It's unusual to have more than one rule anchored
|
|
to either end as "first" or "last", but entirely legal, and we make
|
|
use of that ability here.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The "first" rules here are the ones which get the basic machinery working
|
|
to the point where it is safe to run arbitrary I7 source text. They necessarily
|
|
do very low-level things, and it is not guaranteed that I7 phrases will behave
|
|
to specification if executed before these early rules have finished. So it
|
|
is hazardous to obstruct or alter them.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(a) The "initialise memory rule" starts up the memory allocation heap,
|
|
if there is one, and sets some essential I6 variables. If there is any rule
|
|
not to meddle with, this is it.
|
|
</li></ul>
|
|
<ul class="items"><li>(b) The "virtual machine startup rule" carries out necessary steps to
|
|
begin execution on the virtual machine in use: this entails relatively little
|
|
on the Z-machine versions 5 or 8, but can involve extensive work to get the
|
|
screen display working on Glulx or Z6. Before anything else happens, however,
|
|
the "starting the virtual machine" activity (see below) is carried out.
|
|
</li></ul>
|
|
<ul class="items"><li>(c) The "seed random number generator rule" seeds the RNG to a fixed value
|
|
if Inform has requested this (which it does in response to the <code class="display"><span class="extract">-rng</span></code> command
|
|
line switch, which is in turn used by the <code class="display"><span class="extract">intest</span></code> testing utility: it's a
|
|
way to make deterministic tests of programs which use random values).
|
|
</li></ul>
|
|
<ul class="items"><li>(d) The "update chronological records rule" is described in further detail
|
|
below, since it appears both here and also in the turn sequence rulebook.
|
|
Here it's providing us with a baseline of initial truths from which we can
|
|
later assess conditions such as "the marble door has been open". A subtle
|
|
and questionable point of the design is that this rule is placed at a time
|
|
when the object representing the player is not present in the model world.
|
|
This is done to avoid regarding the initial situation as one of the turns
|
|
for purposes of a rule preamble like "... when the player has been in the
|
|
Dining Room for three turns". It's as if the player teleports into an
|
|
already-existing world, like some Star Trek crewman, just in time for the
|
|
first command.
|
|
</li></ul>
|
|
<ul class="items"><li>(e) All items begin unmentioned, as might be expected.
|
|
</li></ul>
|
|
<ul class="items"><li>(f) And the "position player in model world rule" completes the initial
|
|
construction of the spatial model world.
|
|
</li></ul>
|
|
<ul class="items"><li>(g) The "start in the correct scenes rule" ensures that we start out
|
|
in the correct scenes. (This can't wait, because it's just conceivable
|
|
that somebody has written a rule with a preamble like "When play
|
|
begins during the Hunting Season...": it's also where the scene
|
|
Entire Game begins.) That completes the necessary preliminaries before
|
|
ordinary I7 rules can be run.
|
|
</li></ul>
|
|
|
|
<pre class="display">
|
|
<span class="plain">The start in the correct scenes rule is listed first in the startup rulebook. [7th.]</span>
|
|
<span class="plain">The position player in model world rule is listed first in the startup rulebook. [6th.]</span>
|
|
<span class="plain">This is the declare everything initially unmentioned rule:</span>
|
|
<span class="plain">repeat with item running through things:</span>
|
|
<span class="plain">now the item is not mentioned.</span>
|
|
<span class="plain">The declare everything initially unmentioned rule is listed first in the startup rulebook. [5th]</span>
|
|
<span class="plain">The update chronological records rule is listed first in the startup rulebook. [4th.]</span>
|
|
<span class="plain">The seed random number generator rule is listed first in the startup rulebook. [3rd.]</span>
|
|
<span class="plain">The virtual machine startup rule is listed first in the startup rulebook. [2nd.]</span>
|
|
<span class="plain">The initialise memory rule is listed first in the startup rulebook. [1st.]</span>
|
|
|
|
<span class="plain">The virtual machine startup rule translates into I6 as "VIRTUAL_MACHINE_STARTUP_R".</span>
|
|
<span class="plain">The initialise memory rule translates into I6 as "INITIALISE_MEMORY_R".</span>
|
|
<span class="plain">The seed random number generator rule translates into I6 as "SEED_RANDOM_NUMBER_GENERATOR_R".</span>
|
|
<span class="plain">The update chronological records rule translates into I6 as "UPDATE_CHRONOLOGICAL_RECORDS_R".</span>
|
|
<span class="plain">The position player in model world rule translates into I6 as "POSITION_PLAYER_IN_MODEL_R".</span>
|
|
|
|
<span class="plain">This is the start in the correct scenes rule: follow the scene changing rules.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP23"></a><b>§23. </b>The remaining rules, though, are fair game for alteration, and as if to
|
|
prove the point they are all written in standard I7 source text. Note that
|
|
the baseline score is set only after the when play begins rulebook has
|
|
finished, because games starting with a non-zero score normally do this
|
|
by changing the score in a when play begins rule: and we don't want such
|
|
a change to be notified to the player as if it has happened through some
|
|
action.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The when play begins stage rule is listed in the startup rulebook.</span>
|
|
<span class="plain">The fix baseline scoring rule is listed in the startup rulebook.</span>
|
|
<span class="plain">The display banner rule is listed in the startup rulebook.</span>
|
|
<span class="plain">The initial room description rule is listed in the startup rulebook.</span>
|
|
|
|
<span class="plain">This is the when play begins stage rule: follow the when play begins rulebook.</span>
|
|
|
|
<span class="plain">This is the fix baseline scoring rule: now the last notified score is the score.</span>
|
|
|
|
<span class="plain">This is the display banner rule: say "[banner text]".</span>
|
|
|
|
<span class="plain">This is the initial room description rule: try looking.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP24"></a><b>§24. The turn sequence. </b>In each turn, a command is read and parsed from the keyboard, and any
|
|
action(s) that requested is or are processed. (And may in turn cause
|
|
other actions, which must also be processed.) There is then a fair
|
|
amount of business needed to end one turn and get ready for another.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The turn sequences rulebook terminates early if <code class="display"><span class="extract">deadflag</span></code> becomes set at
|
|
any point, so the last turn of play will be incomplete. Besides that
|
|
consideration, it can also end early if the command for the turn was
|
|
for an out-of-world action such as saving the game: in such cases, the
|
|
"generate action rule" stops the rulebook once the action has been
|
|
fully processed. All the same, play basically consists of running down
|
|
this list of rules over and over again.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP25"></a><b>§25. </b>The "first" rules in the turn sequence cover us up to the end of the
|
|
events which take place in the model world during this turn's action(s).
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(a) The "parse command rule" prints up the prompt, reads a command from
|
|
the keyboard, parses it into dictionary words, deals with niceties such as
|
|
UNDO or OOPS, and then runs it through the traditional I6 parser to turn
|
|
it into a request for an action or list of actions. But see note below.
|
|
</li></ul>
|
|
<ul class="items"><li>(b) The "mentioned" property records whether something's name has been
|
|
printed since the last command.
|
|
</li></ul>
|
|
<ul class="items"><li>(c) The "generate action rule" then either sends a single action to the
|
|
action-processing rules, or else runs through the list, printing the noun
|
|
up with a colon each time and then sending the action to the action-processing
|
|
rules. But see note below.
|
|
</li></ul>
|
|
<ul class="items"><li>(d) We then run the scene changing rulebook, because people often write
|
|
every turn rules which are predicated on particular scenes ("Every turn
|
|
during the Grand Waltz: ..."), and such rules will fail if we haven't kept
|
|
up with possible scene changes arising from something done in the action(s)
|
|
just completed.
|
|
</li></ul>
|
|
<ul class="items"><li>(e) The "every turn stage rule" follows the every turn rulebook. This
|
|
earns its place among the "first" rules in order for it to have priority
|
|
over all the other book-keeping rules at the end of a turn — including any
|
|
which the user, or an extension included by the user, chooses to add to the
|
|
turn sequence rules.
|
|
</li></ul>
|
|
<p class="inwebparagraph">An unusual point here is that the "parse command rule" and the
|
|
"generate action rule" are written such that they do nothing unless
|
|
the turn sequence rulebook is being followed at the top level (by <code class="display"><span class="extract">Main</span></code>,
|
|
that is). This prevents them from being used recursively, which would not
|
|
work properly, and enables a popular trick from the time before the 2008
|
|
reform to keep working: we can simulate six turns going by in which the
|
|
player does nothing by running "follow the turn sequence rules" six
|
|
times in a row. Everything happens exactly as it should — the turn count,
|
|
the time of day, timed events, and so on — except that no commands are
|
|
read and no consequent actions generated.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">A first turn sequence rule (this is the every turn stage rule): follow the every turn rules. [5th.]</span>
|
|
<span class="plain">A first turn sequence rule: follow the scene changing rules. [4th.]</span>
|
|
<span class="plain">The generate action rule is listed first in the turn sequence rulebook. [3rd.]</span>
|
|
<span class="plain">The declare everything initially unmentioned rule is listed first in the turn sequence rulebook. [2nd.]</span>
|
|
<span class="plain">The parse command rule is listed first in the turn sequence rulebook. [1st.]</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP26"></a><b>§26. </b>Three miscellaneous things then happen, all implemented by primitives
|
|
in the template I6 layer:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(e) The "timed events rule" is the one which causes other rules, keyed
|
|
to particular times of day, to fire.
|
|
</li></ul>
|
|
<ul class="items"><li>(f) The "advance time rule" then causes the "time of day" global variable
|
|
to advance by the duration of a single turn, which by default is 1 minute.
|
|
</li></ul>
|
|
<ul class="items"><li>(g) The "update chronological records rule" tells the chronology machine
|
|
that a slice of time has been completed. Inform can only decide past tense
|
|
conditions like "the black door has been open" by continuously measuring
|
|
the present to see if the black door is open now, and making a note for
|
|
future reference if it is. But of course it's impossible for any computer
|
|
to continuously do anything, and besides, Inform has other calls on it.
|
|
What in fact happens is the Inform performs these measurements at "chronology
|
|
points", which are strategic moments during play, and this is one of them.
|
|
</li></ul>
|
|
|
|
<pre class="display">
|
|
<span class="plain">The timed events rule is listed in the turn sequence rulebook.</span>
|
|
<span class="plain">The advance time rule is listed in the turn sequence rulebook.</span>
|
|
<span class="plain">The update chronological records rule is listed in the turn sequence rulebook.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP27"></a><b>§27. </b>We now come to the rules anchored at the end, using "last". This part of
|
|
the rulebook is reserved for book-keeping which has to happen positively
|
|
at the end of the turn.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(h) First, we check for scene changes again. We did this only a short while
|
|
ago, but scene changes might well have arisen as a result of rules which
|
|
fired during the every turn rulebook, or from timed events, or in some other
|
|
way, and it's important to start the next turn in the correct scene — so we
|
|
check again to make sure.
|
|
</li></ul>
|
|
<ul class="items"><li>(i) Then we run the "adjust light rule". Keeping track of light and darkness
|
|
is quite difficult, and potentially also quite slow: it's not unlike a sort
|
|
of discretised version of ray-tracing, with many light sources and barriers
|
|
to think about (some transparent, some opaque). So we do this as little as
|
|
possible: once per turn we calculate whether the player is in light or not,
|
|
and act accordingly if so.
|
|
</li></ul>
|
|
<ul class="items"><li>(j) The "note object acquisitions rule" does two things:
|
|
</li></ul>
|
|
<ul class="items"><ul class="items"><li>(i) Gives the "handled" property to everything carried or worn by the player.
|
|
</li><li>(ii) Changes the current player's holdall in use, if necessary. (That's to
|
|
say: if the player has dropped his previous player's holdall, we try to find a
|
|
new one to use from his remaining possessions.)
|
|
</li></ul>
|
|
</li></ul>
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(k) The "notify score changes rule" tells the player if the score has changed
|
|
during the turn, or rather, since the last time either this rule or the startup
|
|
"fix baseline scoring rule" ran. (If the score were to change in the course
|
|
of an out-of-world action, it would be notified a turn late, but of course
|
|
out-of-world actions are not supposed to do that sort of thing.)
|
|
</li></ul>
|
|
|
|
<pre class="display">
|
|
<span class="plain">A last turn sequence rule: follow the scene changing rules. [3rd from last.]</span>
|
|
<span class="plain">The adjust light rule is listed last in the turn sequence rulebook. [2nd from last.]</span>
|
|
<span class="plain">The note object acquisitions rule is listed last in the turn sequence rulebook. [Penultimate.]</span>
|
|
<span class="plain">The notify score changes rule is listed last in the turn sequence rulebook. [Last.]</span>
|
|
|
|
<span class="plain">This is the notify score changes rule:</span>
|
|
<span class="plain">if the score is not the last notified score:</span>
|
|
<span class="plain">issue score notification message;</span>
|
|
<span class="plain">now the last notified score is the score;</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP28"></a><b>§28. </b>That's it, but we need to map these I7 rule names onto the names of their
|
|
I6 primitives in the template layer.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The adjust light rule translates into I6 as "ADJUST_LIGHT_R" with</span>
|
|
<span class="plain">"[It] [are] [if story tense is present tense]now [end if]pitch dark in</span>
|
|
<span class="plain">[if story tense is present tense]here[else]there[end if]!" (A).</span>
|
|
<span class="plain">The advance time rule translates into I6 as "ADVANCE_TIME_R".</span>
|
|
<span class="plain">The generate action rule translates into I6 as "GENERATE_ACTION_R" with</span>
|
|
<span class="plain">"(considering the first sixteen objects only)[command clarification break]" (A),</span>
|
|
<span class="plain">"Nothing to do!" (B).</span>
|
|
|
|
<span class="plain">The note object acquisitions rule translates into I6 as "NOTE_OBJECT_ACQUISITIONS_R".</span>
|
|
<span class="plain">The parse command rule translates into I6 as "PARSE_COMMAND_R".</span>
|
|
<span class="plain">The timed events rule translates into I6 as "TIMED_EVENTS_R".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP29"></a><b>§29. Shutdown. </b>Goodbye is not the hardest word to say, but it does involve a little bit of
|
|
work. It might not actually be goodbye, for one thing: if this rulebook ends
|
|
in success, then we go back to repeating the turn sequence rulebook just as
|
|
if nothing had happened.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(a) The "when play ends stage rule" follows the rulebook of the same name.
|
|
</li></ul>
|
|
<ul class="items"><li>(b) The "resurrect player if asked rule" does nothing unless one of the
|
|
"when play ends" rules ran the "resume the game" phrase, in which case
|
|
it stops the rulebook with success (see above).
|
|
</li></ul>
|
|
<ul class="items"><li>(c) The "print player's obituary rule" carries out the activity of nearly
|
|
the same name (see below).
|
|
</li></ul>
|
|
<ul class="items"><li>(d) The "ask the final question rule" asks the celebrated "Would you like
|
|
to RESTART, RESTORE a saved game or QUIT?" question, and acts on the
|
|
consequences. It can also cause an UNDO, and on a victorious ending may
|
|
carry out the "amusing a victorious player" activity (see below). The rule
|
|
only actually ends in the event of a QUIT: an UNDO, RESTART or RESTORE is
|
|
performed at the hardware level by the virtual machine and destroys the
|
|
current execution context entirely.
|
|
</li></ul>
|
|
|
|
<pre class="display">
|
|
<span class="plain">The when play ends stage rule is listed first in the shutdown rulebook.</span>
|
|
<span class="plain">The resurrect player if asked rule is listed last in the shutdown rulebook.</span>
|
|
<span class="plain">The print player's obituary rule is listed last in the shutdown rulebook.</span>
|
|
<span class="plain">The ask the final question rule is listed last in the shutdown rulebook.</span>
|
|
|
|
<span class="plain">This is the when play ends stage rule: follow the when play ends rulebook.</span>
|
|
<span class="plain">This is the print player's obituary rule:</span>
|
|
<span class="plain">carry out the printing the player's obituary activity.</span>
|
|
|
|
<span class="plain">The resurrect player if asked rule translates into I6 as "RESURRECT_PLAYER_IF_ASKED_R".</span>
|
|
<span class="plain">The ask the final question rule translates into I6 as "ASK_FINAL_QUESTION_R".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP30"></a><b>§30. Scene changing. </b>Scene changing is handled by a routine called <code class="display"><span class="extract">DetectSceneChange</span></code> which is
|
|
compiled directly by Inform: this is so primitive that it can't even be handled
|
|
at the template layer. The rulebook is all a little elaborate given that
|
|
it contains only one rule, but it's possible to imagine extensions which
|
|
need to do book-keeping similar to scene changing and which want to make
|
|
use of this opportunity.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The scene change machinery rule is listed last in the scene changing rulebook.</span>
|
|
|
|
<span class="plain">The scene change machinery rule translates into I6 as "SCENE_CHANGE_MACHINERY_R".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP31"></a><b>§31. </b>We couldn't do this earlier (because creating a scene automatically generates
|
|
two rulebooks, and that would have thrown the rulebook numbering), so let's
|
|
take this opportunity to define the "Entire Game" scene:
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section 3 - The Entire Game scene</span>
|
|
|
|
<span class="plain">The Entire Game is a scene.</span>
|
|
<span class="plain">The Entire Game begins when the story has not ended.</span>
|
|
<span class="plain">The Entire Game ends when the story has ended.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP32"></a><b>§32. Action-processing. </b>Action-processing happens on two levels: an upper level, handled by the main
|
|
"action-processing" rulebook, and a lower level, "specific action-processing".
|
|
This division clearly complicates matters, so why do we do it? It turns out be
|
|
convenient for several reasons:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(a) Out-of-world actions like "saving the game" need to run through the
|
|
lower level, or they won't do anything at all, but must not run through the
|
|
upper level, or in-world rules (before or instead rules, for instance) might
|
|
prevent them from happening.
|
|
</li></ul>
|
|
<ul class="items"><li>(b) Requested actions such as generated by a command like "CLARK, BLOW WHISTLE"
|
|
have the reverse behaviour, being handled at the upper level but not the lower.
|
|
(If Clark should agree, a definite non-request action "Clark blowing the whistle"
|
|
is generated afresh: that one does indeed get to the lower level, but the original
|
|
request action doesn't.)
|
|
</li></ul>
|
|
<ul class="items"><li>(c) Specific action-processing has a rather complicated range of outcomes:
|
|
it must succeed or fail, according to whether the action either reaches the
|
|
carry out rules or is converted into another action which does, but also
|
|
ensure that in the event of failure, the exact rule causing the failure is
|
|
recorded in the "reason the action failed" variable.
|
|
</li></ul>
|
|
<ul class="items"><li>(d) The specific action-processing stage is where we have to split consideration
|
|
into action-specific rulebooks (like "check taking") rather than general ones
|
|
(like "instead"). To get this right, we want to use some rulebook variables,
|
|
and these need to be set at exactly the correct moment. It's tricky to
|
|
arrange for that in the middle of a big rulebook, but easy to do so at the
|
|
beginning, so we want the start of the SA-P stage to happen at the start of
|
|
a rulebook.
|
|
</li></ul>
|
|
<p class="inwebparagraph">This does mean that an attempt by the user to move the before stage to just
|
|
after the check stage (say) will fail — the before and check stages happen
|
|
in different rulebooks, so no amount of rearranging will do this.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP33"></a><b>§33. </b>The upper level of action-processing consists of seeing whether the actor's
|
|
current situation forbids the action from being tried: does anybody or
|
|
anything intervene to stop it? Are there are any basic reasons of physical
|
|
realism why nobody could possibly try it? Does it require somebody else
|
|
to cooperate who in fact chooses not to?
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Doctrinally, the before stage must see actions before anything else can
|
|
happen. (It needs the absolute freedom to start fresh actions and dispose
|
|
of the one originally intended, sure in the knowledge that no other rules
|
|
have been there first.) So before-ish material is anchored at the "first"
|
|
end of the rulebook.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">The other book-end on the shelf is provided by the instead stage, which
|
|
doctrinally happens only when the action is now thought to be physically
|
|
reasonable. So this is anchored at the "last" end. (In fact it is followed
|
|
by several more rules also anchored there, but this is essentially just
|
|
the clockwork machinery showing through: they aren't realism checks.)
|
|
</p>
|
|
|
|
<p class="inwebparagraph">Miscellaneous general rules to do with physical realism are placed between
|
|
the two book-ends, then, and this is where any newly created action-processing
|
|
rules created by the user or by extensions will go.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section 4 - Action processing</span>
|
|
|
|
<span class="plain">The before stage rule is listed first in the action-processing rules. [3rd.]</span>
|
|
<span class="plain">The set pronouns from items from multiple object lists rule is listed first in the</span>
|
|
<span class="plain">action-processing rules. [2nd.]</span>
|
|
<span class="plain">The announce items from multiple object lists rule is listed first in the</span>
|
|
<span class="plain">action-processing rules. [1st.]</span>
|
|
<span class="plain">The basic visibility rule is listed in the action-processing rules.</span>
|
|
<span class="plain">The basic accessibility rule is listed in the action-processing rules.</span>
|
|
<span class="plain">The carrying requirements rule is listed in the action-processing rules.</span>
|
|
<span class="plain">The instead stage rule is listed last in the action-processing rules. [4th from last.]</span>
|
|
<span class="plain">The requested actions require persuasion rule is listed last in the action-processing rules.</span>
|
|
<span class="plain">The carry out requested actions rule is listed last in the action-processing rules.</span>
|
|
<span class="plain">The descend to specific action-processing rule is listed last in the action-processing rules.</span>
|
|
<span class="plain">The end action-processing in success rule is listed last in the action-processing rules. [Last.]</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP34"></a><b>§34. </b>As we shall see, most of these rules are primitives implemented by the
|
|
template I6 layer, but five are very straightforward.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">This is the set pronouns from items from multiple object lists rule:</span>
|
|
<span class="plain">if the current item from the multiple object list is not nothing,</span>
|
|
<span class="plain">set pronouns from the current item from the multiple object list.</span>
|
|
|
|
<span class="plain">This is the announce items from multiple object lists rule:</span>
|
|
<span class="plain">if the current item from the multiple object list is not nothing,</span>
|
|
<span class="plain">say "[current item from the multiple object list]: [run paragraph on]" (A).</span>
|
|
|
|
<span class="plain">This is the before stage rule: abide by the before rules.</span>
|
|
<span class="plain">This is the instead stage rule: abide by the instead rules.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP35"></a><b>§35. </b>The final rule in the rulebook always succeeds: this ensures that
|
|
action-processing always makes a decision. (I7's doctrine is that an
|
|
action "succeeds" if and only if its carry-out stage is reached, so
|
|
any action getting right to the end of this rulebook must have
|
|
succeeded.)
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">This is the end action-processing in success rule: rule succeeds.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP36"></a><b>§36. </b>The action-processing rulebook contains six primitives:
|
|
</p>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<ul class="items"><li>(1) The "basic visibility rule" checks the action to see if it requires
|
|
light, and if so, and if the actor is the player and in darkness, asks
|
|
the visibility rules (see below) whether the lack of light should stop
|
|
the action. (It would be cleaner to apply this rule to all actors, but we
|
|
would need much more extensive light calculations to do this.)
|
|
</li></ul>
|
|
<ul class="items"><li>(2) The "basic accessibility rule" checks the action to see if it requires
|
|
the noun to be touchable, and if so, asks the accessibility rulebook to
|
|
adjudicate (see below); then repeats the process for the second noun.
|
|
</li></ul>
|
|
<ul class="items"><li>(3) The "carrying requirements rule" checks the action to see if it requires
|
|
the noun to be carried. If so, but the noun is not carried, it generates an
|
|
implicit taking action (in effect, "try silently taking N"); and if that
|
|
fails, then the rulebook is halted in failure. The process is then repeated
|
|
for the second noun.
|
|
</li></ul>
|
|
<ul class="items"><li>(4) If the action is one where the player requests somebody else to do
|
|
something, the "requested actions require persuasion rule" asks the
|
|
persuasion rulebook for permission.
|
|
</li></ul>
|
|
<ul class="items"><li>(5) If the action is one where the player requests somebody else to do
|
|
something, the "carry out requested actions rule" starts a new action by
|
|
the person asked, and looks at the result: if it failed, the "unsuccessful
|
|
attempt by" rulebook is run to tell the player what has (not) happened.
|
|
(If that does nothing, a bland message is printed.) In all cases, the
|
|
original action of requesting is ended in success: a success because,
|
|
whatever happened, the request succeeded in making the actor try to do
|
|
something.
|
|
</li></ul>
|
|
<ul class="items"><li>(6) The "descend to specific action-processing rule" really only runs the
|
|
specific action-processing rulebook, but it's implemented as a primitive in
|
|
the template I6 layer because it must also find out which are the
|
|
specific check, carry out and report rulebooks for the current action (for
|
|
instance, "check taking" is the specific check rulebook for the
|
|
"taking" action — which seems obvious from the names: but at run-time,
|
|
the names aren't so visible).
|
|
</li></ul>
|
|
|
|
<pre class="display">
|
|
<span class="plain">The basic accessibility rule translates into I6 as "BASIC_ACCESSIBILITY_R" with</span>
|
|
<span class="plain">"You must name something more substantial." (A).</span>
|
|
<span class="plain">The basic visibility rule translates into I6 as "BASIC_VISIBILITY_R" with</span>
|
|
<span class="plain">"[It] [are] pitch dark, and [we] [can't see] a thing." (A).</span>
|
|
<span class="plain">The carrying requirements rule translates into I6 as "CARRYING_REQUIREMENTS_R".</span>
|
|
<span class="plain">The requested actions require persuasion rule translates into I6 as</span>
|
|
<span class="plain">"REQUESTED_ACTIONS_REQUIRE_R" with</span>
|
|
<span class="plain">"[The noun] [have] better things to do." (A).</span>
|
|
<span class="plain">The carry out requested actions rule translates into I6 as</span>
|
|
<span class="plain">"CARRY_OUT_REQUESTED_ACTIONS_R" with</span>
|
|
<span class="plain">"[The noun] [are] unable to do that." (A).</span>
|
|
<span class="plain">The descend to specific action-processing rule translates into I6 as</span>
|
|
<span class="plain">"DESCEND_TO_SPECIFIC_ACTION_R".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP37"></a><b>§37. Specific action-processing. </b>And now we descend to the lower level, which is much easier to understand.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The work out details of specific action rule is listed first in the specific</span>
|
|
<span class="plain">action-processing rules.</span>
|
|
|
|
<span class="plain">A specific action-processing rule</span>
|
|
<span class="plain">(this is the investigate player's awareness before action rule):</span>
|
|
<span class="plain">follow the player's action awareness rules;</span>
|
|
<span class="plain">if rule succeeded, now within the player's sight is true;</span>
|
|
<span class="plain">otherwise now within the player's sight is false.</span>
|
|
|
|
<span class="plain">A specific action-processing rule (this is the check stage rule):</span>
|
|
<span class="plain">anonymously abide by the specific check rulebook.</span>
|
|
|
|
<span class="plain">A specific action-processing rule (this is the carry out stage rule):</span>
|
|
<span class="plain">follow the specific carry out rulebook.</span>
|
|
|
|
<span class="plain">A specific action-processing rule (this is the after stage rule):</span>
|
|
<span class="plain">if action in world is true, abide by the after rules.</span>
|
|
|
|
<span class="plain">A specific action-processing rule</span>
|
|
<span class="plain">(this is the investigate player's awareness after action rule):</span>
|
|
<span class="plain">if within the player's sight is false:</span>
|
|
<span class="plain">follow the player's action awareness rules;</span>
|
|
<span class="plain">if rule succeeded, now within the player's sight is true;</span>
|
|
|
|
<span class="plain">A specific action-processing rule (this is the report stage rule):</span>
|
|
<span class="plain">if within the player's sight is true and action keeping silent is false,</span>
|
|
<span class="plain">follow the specific report rulebook;</span>
|
|
|
|
<span class="plain">The last specific action-processing rule: rule succeeds.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP38"></a><b>§38. </b>The unusual use of "anonymously abide by" above is a form of "abide
|
|
by" which may be worth explaining. Suppose rule X consists of an
|
|
instruction to abide by rulebook Y, and suppose that Y in fact fails
|
|
when it reaches Y_k. If the ordinary "abide by" is used then the action
|
|
will be deemed to have failed at rule X, but if "anonymously abide by"
|
|
is used then it will be deemed to have failed at Y_k. (Thus X remains
|
|
anonymous: it can never be the culprit.) We only use this at the check
|
|
stage, because the carry out, report and after stages are not allowed to
|
|
fail the action. (The after stage is allowed to end it, but not in
|
|
failure.)
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP39"></a><b>§39. </b>The specific action-processing rulebook is probably more fruitful than the
|
|
main one if we want to modify what happens. For instance:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>This is the sixth sense rule: if the player is not the actor, say "You sense that [the actor] is up to something."</p>
|
|
|
|
</blockquote>
|
|
|
|
<blockquote>
|
|
<p>The sixth sense rule is listed before the carry out stage rule in the specific action-processing rules.</p>
|
|
|
|
</blockquote>
|
|
|
|
<p class="inwebparagraph">...produces the message at a time when the action is definitely possible and
|
|
will succeed, but before anything has been done.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP40"></a><b>§40. </b>The only rule not spelled out was the primitive "work out details of
|
|
specific action rule", which initialises the rulebook variables so that
|
|
they record the action's specific check, carry out and report rulebooks,
|
|
and whether or not it is in world.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The work out details of specific action rule translates into I6 as</span>
|
|
<span class="plain">"WORK_OUT_DETAILS_OF_SPECIFIC_R".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP41"></a><b>§41. Player's action awareness. </b>This rulebook decides whether or not an action by somebody should be routinely
|
|
reported to the player: is he aware of it having taken place? If the rulebook
|
|
positively succeeds then he is, and otherwise not.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">A player's action awareness rule</span>
|
|
<span class="plain">(this is the player aware of his own actions rule):</span>
|
|
<span class="plain">if the player is the actor, rule succeeds.</span>
|
|
<span class="plain">A player's action awareness rule</span>
|
|
<span class="plain">(this is the player aware of actions by visible actors rule):</span>
|
|
<span class="plain">if the player is not the actor and the player can see the actor, rule succeeds.</span>
|
|
<span class="plain">A player's action awareness rule</span>
|
|
<span class="plain">(this is the player aware of actions on visible nouns rule):</span>
|
|
<span class="plain">if the noun is a thing and the player can see the noun, rule succeeds.</span>
|
|
<span class="plain">A player's action awareness rule</span>
|
|
<span class="plain">(this is the player aware of actions on visible second nouns rule):</span>
|
|
<span class="plain">if the second noun is a thing and the player can see the second noun, rule succeeds.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP42"></a><b>§42. Accessibility. </b>The "accessibility" rulebook is not very visible to users: it's another
|
|
behind-the-scenes rulebook for managing the decision as to whether the actor
|
|
can touch any items which the intended action requires him to be able to
|
|
reach.
|
|
</p>
|
|
|
|
<p class="inwebparagraph">In its default configuration, it contains only the "access through barriers"
|
|
rule. This in all circumstances either succeeds or fails: in other words, it
|
|
makes a definite decision, and this is why it is anchored as "last" in the
|
|
rulebook. If users or extensions want to tweak accessibility at this
|
|
general level, any new rules they add will get the chance to decide before
|
|
the "access through barriers" rule settles the matter. But in practice
|
|
we expect most users to work with one of the two reaching rulebooks instead.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section 5 - Accessibility</span>
|
|
|
|
<span class="plain">The access through barriers rule is listed last in the accessibility rules.</span>
|
|
|
|
<span class="plain">The access through barriers rule translates into I6 as</span>
|
|
<span class="plain">"ACCESS_THROUGH_BARRIERS_R" with</span>
|
|
<span class="plain">"[regarding the noun][Those] [aren't] available." (A).</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP43"></a><b>§43. Reaching inside. </b>What the access through barriers rule does is to try to construct a path
|
|
through the object containment tree from the actor to the item needed, and
|
|
to apply the reaching inside or reaching outside rulebooks each time this
|
|
path passes inside or outside of a container (or room). (Supporters never
|
|
form barriers.)
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The can't reach inside rooms rule is listed last in the reaching inside rules. [Penultimate.]</span>
|
|
<span class="plain">The can't reach inside closed containers rule is listed last in the reaching</span>
|
|
<span class="plain">inside rules. [Last.]</span>
|
|
|
|
<span class="plain">The can't reach inside closed containers rule translates into I6 as</span>
|
|
<span class="plain">"CANT_REACH_INSIDE_CLOSED_R" with</span>
|
|
<span class="plain">"[The noun] [aren't] open." (A).</span>
|
|
<span class="plain">The can't reach inside rooms rule translates into I6 as</span>
|
|
<span class="plain">"CANT_REACH_INSIDE_ROOMS_R" with</span>
|
|
<span class="plain">"[We] [can't] reach into [the noun]." (A).</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP44"></a><b>§44. Reaching outside. </b>And, not quite symmetrically since we don't need to block room-to-room
|
|
reaching on both the inbound and outbound directions,
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The can't reach outside closed containers rule is listed last in the reaching outside rules.</span>
|
|
|
|
<span class="plain">The can't reach outside closed containers rule translates into I6 as</span>
|
|
<span class="plain">"CANT_REACH_OUTSIDE_CLOSED_R" with</span>
|
|
<span class="plain">"[The noun] [aren't] open." (A).</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP45"></a><b>§45. Visibility. </b>The visibility rulebook actually has the opposite sense to the one the name
|
|
might suggest. It is applied only when the player (not any other actor) tries
|
|
to perform an action which requires light to see by; the action is blocked
|
|
if the rulebook succeeds. (Well, but we could hardly call it the invisibility
|
|
rulebook. The name is supposed to suggest that the consideration of visibility
|
|
is being applied: rather the way cricket matches end with a declaration that
|
|
"light stopped play", meaning of course that darkness did.)
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">The can't act in the dark rule is listed last in the visibility rules.</span>
|
|
|
|
<span class="plain">The last visibility rule (this is the can't act in the dark rule): if in darkness, rule succeeds.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP46"></a><b>§46. Does the player mean. </b>This rulebook is akin to a set of preferences about how to interpret the
|
|
player's commands in cases of ambiguity. No two Inform users are likely to
|
|
agree about the best way to decide these, so we are fairly hands-off, and
|
|
make only one rule as standard:
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Does the player mean taking something which is carried by the player</span>
|
|
<span class="plain">(this is the very unlikely to mean taking what's already carried rule):</span>
|
|
<span class="plain">it is very unlikely.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP47"></a><b>§47. </b>And that completes the creation and stocking of the 25 rulebooks. More than
|
|
half of them are initially empty, including before, instead and after — at the
|
|
end of the day, these rulebooks are hooks allowing the user to change the
|
|
ordinary behaviour of things, but ordinariness is exactly what the Standard
|
|
Rules is all about.
|
|
</p>
|
|
|
|
<p class="inwebparagraph"><a id="SP48"></a><b>§48. Adjectives applied to values. </b>There is a small stock of built-in adjectives for values.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section 6 - Adjectival definitions</span>
|
|
|
|
<span class="plain">A scene can be recurring or non-recurring. A scene is usually non-recurring.</span>
|
|
<span class="plain">The Entire Game is recurring.</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP49"></a><b>§49. Scene descriptions. </b>And there is one build-in value property for values.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section 7 - Scene descriptions</span>
|
|
|
|
<span class="plain">A scene has a text called description.</span>
|
|
<span class="plain">When a scene (called the event) begins (this is the scene description text rule):</span>
|
|
<span class="plain">if the description of the event is not "",</span>
|
|
<span class="plain">say "[description of the event][paragraph break]".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP50"></a><b>§50. Command parser errors. </b>This abstracts a set of return codes from the I6 parser, which are written
|
|
there as constants with the notation <code class="display"><span class="extract">*_ETYPE</span></code>.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section 8 - Command parser errors</span>
|
|
|
|
<span class="plain">A command parser error is a kind of value. The command parser errors are</span>
|
|
<span class="plain">didn't understand error,</span>
|
|
<span class="plain">only understood as far as error,</span>
|
|
<span class="plain">didn't understand that number error,</span>
|
|
<span class="plain">can only do that to something animate error,</span>
|
|
<span class="plain">can't see any such thing error,</span>
|
|
<span class="plain">said too little error,</span>
|
|
<span class="plain">aren't holding that error,</span>
|
|
<span class="plain">can't use multiple objects error,</span>
|
|
<span class="plain">can only use multiple objects error,</span>
|
|
<span class="plain">not sure what it refers to error,</span>
|
|
<span class="plain">excepted something not included error,</span>
|
|
<span class="plain">not a verb I recognise error,</span>
|
|
<span class="plain">not something you need to refer to error,</span>
|
|
<span class="plain">can't see it at the moment error,</span>
|
|
<span class="plain">didn't understand the way that finished error,</span>
|
|
<span class="plain">not enough of those available error,</span>
|
|
<span class="plain">nothing to do error,</span>
|
|
<span class="plain">noun did not make sense in that context error,</span>
|
|
<span class="plain">referred to a determination of scope error,</span>
|
|
<span class="plain">I beg your pardon error,</span>
|
|
<span class="plain">can't again the addressee error,</span>
|
|
<span class="plain">comma can't begin error,</span>
|
|
<span class="plain">can't see whom to talk to error,</span>
|
|
<span class="plain">can't talk to inanimate things error, and</span>
|
|
<span class="plain">didn't understand addressee's last name error.</span>
|
|
|
|
<span class="plain">The latest parser error is a command parser error that varies.</span>
|
|
<span class="plain">The latest parser error variable translates into I6 as "etype".</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<p class="inwebparagraph"><a id="SP51"></a><b>§51. Internal rules. </b>These rules do nothing in themselves, and are really just hooks on which
|
|
some response texts can be hung.
|
|
</p>
|
|
|
|
|
|
<pre class="display">
|
|
<span class="plain">Section 9 - Responses for internal rules</span>
|
|
|
|
<span class="plain">The list writer internal rule translates into I6 as</span>
|
|
<span class="plain">"LIST_WRITER_INTERNAL_R" with</span>
|
|
<span class="plain">" (" (A),</span>
|
|
<span class="plain">")" (B),</span>
|
|
<span class="plain">" and " (C),</span>
|
|
<span class="plain">"providing light" (D),</span>
|
|
<span class="plain">"closed" (E),</span>
|
|
<span class="plain">"empty" (F),</span>
|
|
<span class="plain">"closed and empty" (G),</span>
|
|
<span class="plain">"closed and providing light" (H),</span>
|
|
<span class="plain">"empty and providing light" (I),</span>
|
|
<span class="plain">"closed, empty[if serial comma option is active],[end if] and providing light" (J),</span>
|
|
<span class="plain">"providing light and being worn" (K),</span>
|
|
<span class="plain">"being worn" (L),</span>
|
|
<span class="plain">"open" (M),</span>
|
|
<span class="plain">"open but empty" (N),</span>
|
|
<span class="plain">"closed" (O),</span>
|
|
<span class="plain">"closed and locked" (P),</span>
|
|
<span class="plain">"containing" (Q),</span>
|
|
<span class="plain">"on [if the noun is a person]whom[otherwise]which[end if] " (R),</span>
|
|
<span class="plain">", on top of [if the noun is a person]whom[otherwise]which[end if] " (S),</span>
|
|
<span class="plain">"in [if the noun is a person]whom[otherwise]which[end if] " (T),</span>
|
|
<span class="plain">", inside [if the noun is a person]whom[otherwise]which[end if] " (U),</span>
|
|
<span class="plain">"[regarding list writer internals][are]" (V),</span>
|
|
<span class="plain">"[regarding list writer internals][are] nothing" (W),</span>
|
|
<span class="plain">"Nothing" (X),</span>
|
|
<span class="plain">"nothing" (Y).</span>
|
|
|
|
<span class="plain">The action processing internal rule translates into I6 as</span>
|
|
<span class="plain">"ACTION_PROCESSING_INTERNAL_R" with</span>
|
|
<span class="plain">"[bracket]That command asks to do something outside of play, so it can</span>
|
|
<span class="plain">only make sense from you to me. [The noun] cannot be asked to do this.[close</span>
|
|
<span class="plain">bracket]" (A),</span>
|
|
<span class="plain">"You must name an object." (B),</span>
|
|
<span class="plain">"You may not name an object." (C),</span>
|
|
<span class="plain">"You must supply a noun." (D),</span>
|
|
<span class="plain">"You may not supply a noun." (E),</span>
|
|
<span class="plain">"You must name a second object." (F),</span>
|
|
<span class="plain">"You may not name a second object." (G),</span>
|
|
<span class="plain">"You must supply a second noun." (H),</span>
|
|
<span class="plain">"You may not supply a second noun." (I),</span>
|
|
<span class="plain">"(Since something dramatic has happened, your list of commands has been</span>
|
|
<span class="plain">cut short.)" (J),</span>
|
|
<span class="plain">"I didn't understand that instruction." (K).</span>
|
|
|
|
<span class="plain">The parser error internal rule translates into I6 as</span>
|
|
<span class="plain">"PARSER_ERROR_INTERNAL_R" with</span>
|
|
<span class="plain">"I didn't understand that sentence." (A),</span>
|
|
<span class="plain">"I only understood you as far as wanting to " (B),</span>
|
|
<span class="plain">"I only understood you as far as wanting to (go) " (C),</span>
|
|
<span class="plain">"I didn't understand that number." (D),</span>
|
|
<span class="plain">"[We] [can't] see any such thing." (E),</span>
|
|
<span class="plain">"You seem to have said too little!" (F),</span>
|
|
<span class="plain">"[We] [aren't] holding that!" (G),</span>
|
|
<span class="plain">"You can't use multiple objects with that verb." (H),</span>
|
|
<span class="plain">"You can only use multiple objects once on a line." (I),</span>
|
|
<span class="plain">"I'm not sure what ['][pronoun i6 dictionary word]['] refers to." (J),</span>
|
|
<span class="plain">"[We] [can't] see ['][pronoun i6 dictionary word]['] ([the noun]) at the moment." (K),</span>
|
|
<span class="plain">"You excepted something not included anyway!" (L),</span>
|
|
<span class="plain">"You can only do that to something animate." (M),</span>
|
|
<span class="plain">"That's not a verb I [if American dialect option is</span>
|
|
<span class="plain">active]recognize[otherwise]recognise[end if]." (N),</span>
|
|
<span class="plain">"That's not something you need to refer to in the course of this game." (O),</span>
|
|
<span class="plain">"I didn't understand the way that finished." (P),</span>
|
|
<span class="plain">"[if number understood is 0]None[otherwise]Only [number understood in words][end if]</span>
|
|
<span class="plain">of those [regarding the number understood][are] available." (Q),</span>
|
|
<span class="plain">"That noun did not make sense in this context." (R),</span>
|
|
<span class="plain">"To repeat a command like 'frog, jump', just say 'again', not 'frog, again'." (S),</span>
|
|
<span class="plain">"You can't begin with a comma." (T),</span>
|
|
<span class="plain">"You seem to want to talk to someone, but I can't see whom." (U),</span>
|
|
<span class="plain">"You can't talk to [the noun]." (V),</span>
|
|
<span class="plain">"To talk to someone, try 'someone, hello' or some such." (W),</span>
|
|
<span class="plain">"I beg your pardon?" (X).</span>
|
|
|
|
<span class="plain">The parser nothing error internal rule translates into I6 as</span>
|
|
<span class="plain">"PARSER_N_ERROR_INTERNAL_R" with</span>
|
|
<span class="plain">"Nothing to do!" (A),</span>
|
|
<span class="plain">"[There] [adapt the verb are from the third person plural] none at all available!" (B),</span>
|
|
<span class="plain">"[regarding the noun][Those] [seem] to belong to [the noun]." (C),</span>
|
|
<span class="plain">"[regarding the noun][Those] [can't] contain things." (D),</span>
|
|
<span class="plain">"[The noun] [aren't] open." (E),</span>
|
|
<span class="plain">"[The noun] [are] empty." (F).</span>
|
|
|
|
<span class="plain">The darkness name internal rule translates into I6 as "DARKNESS_NAME_INTERNAL_R" with</span>
|
|
<span class="plain">"Darkness" (A).</span>
|
|
|
|
<span class="plain">The parser command internal rule translates into I6 as</span>
|
|
<span class="plain">"PARSER_COMMAND_INTERNAL_R" with</span>
|
|
<span class="plain">"Sorry, that can't be corrected." (A),</span>
|
|
<span class="plain">"Think nothing of it." (B),</span>
|
|
<span class="plain">"'Oops' can only correct a single word." (C),</span>
|
|
<span class="plain">"You can hardly repeat that." (D).</span>
|
|
|
|
<span class="plain">The parser clarification internal rule translates into I6 as</span>
|
|
<span class="plain">"PARSER_CLARIF_INTERNAL_R" with</span>
|
|
<span class="plain">"Who do you mean, " (A),</span>
|
|
<span class="plain">"Which do you mean, " (B),</span>
|
|
<span class="plain">"Sorry, you can only have one item here. Which exactly?" (C),</span>
|
|
<span class="plain">"Whom do you want [if the noun is not the player][the noun] [end if]to</span>
|
|
<span class="plain">[parser command so far]?" (D),</span>
|
|
<span class="plain">"What do you want [if the noun is not the player][the noun] [end if]to</span>
|
|
<span class="plain">[parser command so far]?" (E),</span>
|
|
<span class="plain">"those things" (F),</span>
|
|
<span class="plain">"that" (G),</span>
|
|
<span class="plain">" or " (H).</span>
|
|
|
|
<span class="plain">The yes or no question internal rule translates into I6 as</span>
|
|
<span class="plain">"YES_OR_NO_QUESTION_INTERNAL_R" with</span>
|
|
<span class="plain">"Please answer yes or no." (A).</span>
|
|
|
|
<span class="plain">The print protagonist internal rule translates into I6 as</span>
|
|
<span class="plain">"PRINT_PROTAGONIST_INTERNAL_R" with</span>
|
|
<span class="plain">"[We]" (A),</span>
|
|
<span class="plain">"[ourselves]" (B),</span>
|
|
<span class="plain">"[our] former self" (C).</span>
|
|
</pre>
|
|
|
|
<p class="inwebparagraph"></p>
|
|
|
|
<hr class="tocbar">
|
|
<ul class="toc"><li><a href="S-pwm.html">Back to 'Physical World Model'</a></li><li><a href="S-act.html">Continue with 'Activities'</a></li></ul><hr class="tocbar">
|
|
<!--End of weave-->
|
|
</main>
|
|
</body>
|
|
</html>
|
|
|