mirror of
https://github.com/ganelson/inform.git
synced 2024-06-26 04:00:43 +03:00
Converted documentation and examples to Markdown and removed indoc from build process
This commit is contained in:
Graham Nelson
parent
6b08fa1427
commit
c8511d8e34
|
|
@ -1,6 +1,6 @@
|
|||
# Inform 7
|
||||
|
||||
[Version](notes/versioning.md): 10.2.0-beta+6X38 'Krypton' (14 March 2024)
|
||||
[Version](notes/versioning.md): 10.2.0-beta+6X39 'Krypton' (3 April 2024)
|
||||
|
||||
## About Inform
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
Prerelease: beta
|
||||
Build Date: 14 March 2024
|
||||
Build Number: 6X38
|
||||
Build Date: 3 April 2024
|
||||
Build Number: 6X39
|
||||
|
|
|
|||
|
|
@ -38,8 +38,8 @@
|
|||
<div class="w3-quarter">
|
||||
<a href="indocn.html"><img src="docs-assets/indoc.jpg" alt="Indoc" style="width:100%"></a>
|
||||
<h3><a href="indocn.html">indoc</a></h3>
|
||||
<p>A tool for typesetting the two books about Inform, and their hundreds
|
||||
of examples, as ebooks or mini-websites, such as the one built into the apps.</p>
|
||||
<p>A tool formerly used for typesetting the two books about Inform, but now deprecated,
|
||||
and likely to be removed from this repository at some point.</p>
|
||||
</div>
|
||||
<div class="w3-quarter">
|
||||
<a href="inpolicyn.html"><img src="docs-assets/inpolicy.jpg" alt="Inpolicy" style="width:100%"></a>
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
Title: Navigation page for Indoc
|
||||
Author: Graham Nelson
|
||||
|
||||
@ Indoc is not part of the main Inform compiler and is not shipped inside the
|
||||
Inform apps. Instead, it's used as a stand-alone command-line tool by the
|
||||
maintainers of Inform: it generates the formatted documentation about the
|
||||
language which is used both inside the apps and on the project website. (So,
|
||||
although Indoc is not included in the apps, its output is.)
|
||||
@ Indoc is now deprecated, and is likely to be removed from this repository
|
||||
at some future point. Until early 2024 it was used as a stand-alone command-line
|
||||
tool by the maintainers of Inform to generate formatted documentation about the
|
||||
language for use inside the apps and on the project website. This is now done
|
||||
by //inbuild//, and no further work will be done on //indoc//.
|
||||
|
||||
Indoc is a single literate program, and is not divided into modules.
|
||||
|
||||
|
|
@ -13,17 +13,4 @@ Indoc is a single literate program, and is not divided into modules.
|
|||
|
||||
(*) See //indoc: Manual// and //indoc: Reference Card// for usage.
|
||||
|
||||
(*) In particular, //indoc: Documentation Markup// explains how the two books
|
||||
supplied with Inform are marked up.
|
||||
|
||||
@ The texts of the manuals and examples supplied inside the Inform app are
|
||||
stored elsewhere in the repository.[1]
|
||||
|
||||
(*) See: //https://github.com/ganelson/inform/resources/Documentation/
|
||||
|
||||
[1] In principle, Indoc could be used with other books entirely, and the author
|
||||
has sometimes used it as a quick way to turn text files into ePub ebooks. But
|
||||
it's a non-goal to make it a super-duper general purpose documentation maker:
|
||||
there are plenty of those in existence already.
|
||||
|
||||
@ Indoc contains the basic //foundation// library, but none of the //services//.
|
||||
|
|
|
|||
|
|
@ -12,11 +12,6 @@
|
|||
<link href="docs-assets/Navigation.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
||||
<link href="docs-assets/Fonts.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
||||
<link href="docs-assets/Base.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
||||
<script src="http://code.jquery.com/jquery-1.12.4.min.js"
|
||||
integrity="sha256-ZosEbRLbNQzLpnKIkEdrPv7lOy9C27hHQ+Xp8a4MxAQ=" crossorigin="anonymous"></script>
|
||||
|
||||
<script src="docs-assets/Bigfoot.js"></script>
|
||||
<link href="docs-assets/Bigfoot.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
||||
<link href="docs-assets/Colours.css" rel="stylesheet" rev="stylesheet" type="text/css">
|
||||
|
||||
</head>
|
||||
|
|
@ -53,11 +48,11 @@
|
|||
<!--Weave of 'Navigation page for Indoc' generated by Inweb-->
|
||||
<div class="breadcrumbs">
|
||||
<ul class="crumbs"><li><a href="index.html">Home</a></li><li><b>Navigation page for Indoc</b></li></ul></div>
|
||||
<p class="commentary firstcommentary"><a id="SP1" class="paragraph-anchor"></a><b>§1. </b>Indoc is not part of the main Inform compiler and is not shipped inside the
|
||||
Inform apps. Instead, it's used as a stand-alone command-line tool by the
|
||||
maintainers of Inform: it generates the formatted documentation about the
|
||||
language which is used both inside the apps and on the project website. (So,
|
||||
although Indoc is not included in the apps, its output is.)
|
||||
<p class="commentary firstcommentary"><a id="SP1" class="paragraph-anchor"></a><b>§1. </b>Indoc is now deprecated, and is likely to be removed from this repository
|
||||
at some future point. Until early 2024 it was used as a stand-alone command-line
|
||||
tool by the maintainers of Inform to generate formatted documentation about the
|
||||
language for use inside the apps and on the project website. This is now done
|
||||
by <a href="inbuild/index.html" class="internal">inbuild</a>, and no further work will be done on <a href="indoc/index.html" class="internal">indoc</a>.
|
||||
</p>
|
||||
|
||||
<p class="commentary">Indoc is a single literate program, and is not divided into modules.
|
||||
|
|
@ -65,21 +60,8 @@ although Indoc is not included in the apps, its output is.)
|
|||
|
||||
<ul class="items"><li>● The contents page for the Indoc web is here: <a href="indoc/index.html" class="internal">indoc</a>.
|
||||
</li><li>● See <a href="indoc/M-iti.html" class="internal">Manual (in indoc)</a> and <a href="indoc/M-rc.html" class="internal">Reference Card (in indoc)</a> for usage.
|
||||
</li><li>● In particular, <a href="indoc/M-dm.html" class="internal">Documentation Markup (in indoc)</a> explains how the two books
|
||||
supplied with Inform are marked up.
|
||||
</li></ul>
|
||||
<p class="commentary firstcommentary"><a id="SP2" class="paragraph-anchor"></a><b>§2. </b>The texts of the manuals and examples supplied inside the Inform app are
|
||||
stored elsewhere in the repository.<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup>
|
||||
</p>
|
||||
|
||||
<ul class="items"><li>● See: //<a href="https://github.com/ganelson/inform/resources/Documentation/" class="external">https://github.com/ganelson/inform/resources/Documentation/</a>
|
||||
</li></ul>
|
||||
<ul class="footnotetexts"><li class="footnote" id="fn:1"><p class="inwebfootnote"><sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup> In principle, Indoc could be used with other books entirely, and the author
|
||||
has sometimes used it as a quick way to turn text files into ePub ebooks. But
|
||||
it's a non-goal to make it a super-duper general purpose documentation maker:
|
||||
there are plenty of those in existence already.
|
||||
<a href="#fnref:1" title="return to text"> ↩</a></p></li></ul>
|
||||
<p class="commentary firstcommentary"><a id="SP3" class="paragraph-anchor"></a><b>§3. </b>Indoc contains the basic <a href="../../inweb/foundation-module/index.html" class="internal">foundation</a> library, but none of the <a href="services.html" class="internal">services</a>.
|
||||
<p class="commentary firstcommentary"><a id="SP2" class="paragraph-anchor"></a><b>§2. </b>Indoc contains the basic <a href="../../inweb/foundation-module/index.html" class="internal">foundation</a> library, but none of the <a href="services.html" class="internal">services</a>.
|
||||
</p>
|
||||
|
||||
<!--End of weave-->
|
||||
|
|
|
|||
|
|
@ -120,7 +120,8 @@ the problem message test cases, so we observe them.
|
|||
<span class="reserved-syntax">void</span><span class="plain-syntax"> </span><span class="function-syntax">Coverage::which_problems_have_test_cases</span><button class="popup" onclick="togglePopup('usagePopup2')"><span class="comment-syntax">?</span><span class="popuptext" id="usagePopup2">Usage of <span class="code-font"><span class="function-syntax">Coverage::which_problems_have_test_cases</span></span>:<br/><a href="2-pc.html#SP7_1">§7.1</a></span></button><span class="plain-syntax">(</span><span class="reserved-syntax">void</span><span class="plain-syntax">) {</span>
|
||||
<span class="plain-syntax"> </span><span class="reserved-syntax">filename</span><span class="plain-syntax"> *</span><span class="identifier-syntax">CAT</span><span class="plain-syntax"> = </span><a href="../../../inweb/foundation-module/3-fln.html#SP2" class="function-link"><span class="function-syntax">Filenames::in</span></a><span class="plain-syntax">(</span><span class="identifier-syntax">path_to_inpolicy_workspace</span><span class="plain-syntax">, </span><span class="identifier-syntax">I</span><span class="string-syntax">"cases.txt"</span><span class="plain-syntax">);</span>
|
||||
<span class="plain-syntax"> </span><span class="identifier-syntax">TEMPORARY_TEXT</span><span class="plain-syntax">(</span><span class="identifier-syntax">COMMAND</span><span class="plain-syntax">)</span>
|
||||
<span class="plain-syntax"> </span><span class="identifier-syntax">WRITE_TO</span><span class="plain-syntax">(</span><span class="identifier-syntax">COMMAND</span><span class="plain-syntax">, </span><span class="string-syntax">"..%cintest%cTangled%cintest inform7 -catalogue "</span><span class="plain-syntax">, </span><span class="constant-syntax">FOLDER_SEPARATOR</span><span class="plain-syntax">, </span><span class="constant-syntax">FOLDER_SEPARATOR</span><span class="plain-syntax">, </span><span class="constant-syntax">FOLDER_SEPARATOR</span><span class="plain-syntax">);</span>
|
||||
<span class="plain-syntax"> </span><span class="identifier-syntax">WRITE_TO</span><span class="plain-syntax">(</span><span class="identifier-syntax">COMMAND</span><span class="plain-syntax">, </span><span class="string-syntax">"..%cintest%cTangled%cintest inform7 -catalogue "</span><span class="plain-syntax">,</span>
|
||||
<span class="plain-syntax"> </span><span class="constant-syntax">FOLDER_SEPARATOR</span><span class="plain-syntax">, </span><span class="constant-syntax">FOLDER_SEPARATOR</span><span class="plain-syntax">, </span><span class="constant-syntax">FOLDER_SEPARATOR</span><span class="plain-syntax">);</span>
|
||||
<span class="plain-syntax"> </span><a href="../../../inweb/foundation-module/3-shl.html#SP4" class="function-link"><span class="function-syntax">Shell::redirect</span></a><span class="plain-syntax">(</span><span class="identifier-syntax">COMMAND</span><span class="plain-syntax">, </span><span class="identifier-syntax">CAT</span><span class="plain-syntax">);</span>
|
||||
<span class="plain-syntax"> </span><span class="reserved-syntax">if</span><span class="plain-syntax"> (</span><a href="../../../inweb/foundation-module/3-shl.html#SP5" class="function-link"><span class="function-syntax">Shell::run</span></a><span class="plain-syntax">(</span><span class="identifier-syntax">COMMAND</span><span class="plain-syntax">)) </span><a href="../../../inweb/foundation-module/3-em.html#SP2" class="function-link"><span class="function-syntax">Errors::fatal</span></a><span class="plain-syntax">(</span><span class="string-syntax">"can't run intest to harvest cases"</span><span class="plain-syntax">);</span>
|
||||
<span class="plain-syntax"> </span><span class="identifier-syntax">DISCARD_TEXT</span><span class="plain-syntax">(</span><span class="identifier-syntax">COMMAND</span><span class="plain-syntax">)</span>
|
||||
|
|
@ -143,7 +144,7 @@ to problem messages:
|
|||
<span class="reserved-syntax">void</span><span class="plain-syntax"> </span><span class="function-syntax">Coverage::which_problems_are_referenced</span><button class="popup" onclick="togglePopup('usagePopup3')"><span class="comment-syntax">?</span><span class="popuptext" id="usagePopup3">Usage of <span class="code-font"><span class="function-syntax">Coverage::which_problems_are_referenced</span></span>:<br/><a href="2-pc.html#SP7_1">§7.1</a></span></button><span class="plain-syntax">(</span><span class="reserved-syntax">void</span><span class="plain-syntax">) {</span>
|
||||
<span class="plain-syntax"> </span><span class="reserved-syntax">pathname</span><span class="plain-syntax"> *</span><span class="identifier-syntax">D</span><span class="plain-syntax"> = </span><a href="../../../inweb/foundation-module/3-pth.html#SP5" class="function-link"><span class="function-syntax">Pathnames::from_text</span></a><span class="plain-syntax">(</span><span class="identifier-syntax">I</span><span class="string-syntax">"resources"</span><span class="plain-syntax">);</span>
|
||||
<span class="plain-syntax"> </span><span class="identifier-syntax">D</span><span class="plain-syntax"> = </span><a href="../../../inweb/foundation-module/3-pth.html#SP4" class="function-link"><span class="function-syntax">Pathnames::down</span></a><span class="plain-syntax">(</span><span class="identifier-syntax">D</span><span class="plain-syntax">, </span><span class="identifier-syntax">I</span><span class="string-syntax">"Documentation"</span><span class="plain-syntax">);</span>
|
||||
<span class="plain-syntax"> </span><span class="reserved-syntax">filename</span><span class="plain-syntax"> *</span><span class="identifier-syntax">WWI</span><span class="plain-syntax"> = </span><a href="../../../inweb/foundation-module/3-fln.html#SP2" class="function-link"><span class="function-syntax">Filenames::in</span></a><span class="plain-syntax">(</span><span class="identifier-syntax">D</span><span class="plain-syntax">, </span><span class="identifier-syntax">I</span><span class="string-syntax">"Writing with Inform.txt"</span><span class="plain-syntax">);</span>
|
||||
<span class="plain-syntax"> </span><span class="reserved-syntax">filename</span><span class="plain-syntax"> *</span><span class="identifier-syntax">WWI</span><span class="plain-syntax"> = </span><a href="../../../inweb/foundation-module/3-fln.html#SP2" class="function-link"><span class="function-syntax">Filenames::in</span></a><span class="plain-syntax">(</span><span class="identifier-syntax">D</span><span class="plain-syntax">, </span><span class="identifier-syntax">I</span><span class="string-syntax">"Writing with Inform.md"</span><span class="plain-syntax">);</span>
|
||||
<span class="plain-syntax"> </span><a href="../../../inweb/foundation-module/4-tf.html#SP5" class="function-link"><span class="function-syntax">TextFiles::read</span></a><span class="plain-syntax">(</span><span class="identifier-syntax">WWI</span><span class="plain-syntax">, </span><span class="constant-syntax">FALSE</span><span class="plain-syntax">, </span><span class="string-syntax">"unable to read 'Writing with Inform' source text"</span><span class="plain-syntax">, </span><span class="constant-syntax">TRUE</span><span class="plain-syntax">,</span>
|
||||
<span class="plain-syntax"> &</span><a href="2-pc.html#SP4" class="function-link"><span class="function-syntax">Coverage::xref_harvester</span></a><span class="plain-syntax">, </span><span class="identifier-syntax">NULL</span><span class="plain-syntax">, </span><span class="identifier-syntax">NULL</span><span class="plain-syntax">);</span>
|
||||
<span class="plain-syntax">}</span>
|
||||
|
|
|
|||
|
|
@ -265,7 +265,7 @@ Total memory consumption was 139901K = 137 MB
|
|||
|
||||
99.9% was used for memory not allocated for objects:
|
||||
|
||||
62.4% text stream storage 89495180 bytes in 514929 claims
|
||||
62.4% text stream storage 89495152 bytes in 514929 claims
|
||||
3.8% dictionary storage 5500480 bytes in 7771 claims
|
||||
---- sorting 2624 bytes in 531 claims
|
||||
5.0% source text 7200000 bytes in 3 claims
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
100.0% in inform7 run
|
||||
68.0% in compilation to Inter
|
||||
46.5% in //Sequence::undertake_queued_tasks//
|
||||
67.8% in compilation to Inter
|
||||
46.3% in //Sequence::undertake_queued_tasks//
|
||||
4.2% in //MajorNodes::pre_pass//
|
||||
3.4% in //MajorNodes::pass_1//
|
||||
1.9% in //ImperativeDefinitions::assess_all//
|
||||
|
|
@ -14,15 +14,15 @@
|
|||
0.3% in //Sequence::undertake_queued_tasks//
|
||||
0.3% in //World::stage_V//
|
||||
5.4% not specifically accounted for
|
||||
27.6% in running Inter pipeline
|
||||
9.2% in step 14/15: generate inform6 -> auto.inf
|
||||
6.9% in step 5/15: load-binary-kits
|
||||
5.7% in step 6/15: make-synoptic-module
|
||||
27.2% in running Inter pipeline
|
||||
8.8% in step 14/15: generate inform6 -> auto.inf
|
||||
6.8% in step 5/15: load-binary-kits
|
||||
6.1% in step 6/15: make-synoptic-module
|
||||
1.9% in step 9/15: make-identifiers-unique
|
||||
0.3% in step 12/15: eliminate-redundant-operations
|
||||
0.3% in step 4/15: compile-splats
|
||||
0.3% in step 7/15: shorten-wiring
|
||||
0.3% in step 8/15: detect-indirect-calls
|
||||
2.3% not specifically accounted for
|
||||
3.8% in supervisor
|
||||
0.4% not specifically accounted for
|
||||
2.0% not specifically accounted for
|
||||
4.2% in supervisor
|
||||
0.8% not specifically accounted for
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
"is": {
|
||||
"type": "kit",
|
||||
"title": "Architecture16Kit",
|
||||
"version": "10.2.0-beta+6X38"
|
||||
"version": "10.2.0-beta+6X39"
|
||||
},
|
||||
"compatibility": "16-bit",
|
||||
"kit-details": {
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
"is": {
|
||||
"type": "kit",
|
||||
"title": "Architecture32Kit",
|
||||
"version": "10.2.0-beta+6X38"
|
||||
"version": "10.2.0-beta+6X39"
|
||||
},
|
||||
"compatibility": "32-bit",
|
||||
"kit-details": {
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
"is": {
|
||||
"type": "kit",
|
||||
"title": "BasicInformKit",
|
||||
"version": "10.2.0-beta+6X38"
|
||||
"version": "10.2.0-beta+6X39"
|
||||
},
|
||||
"needs": [ {
|
||||
"need": {
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
"is": {
|
||||
"type": "kit",
|
||||
"title": "CommandParserKit",
|
||||
"version": "10.2.0-beta+6X38"
|
||||
"version": "10.2.0-beta+6X39"
|
||||
},
|
||||
"needs": [ {
|
||||
"need": {
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
"is": {
|
||||
"type": "kit",
|
||||
"title": "EnglishLanguageKit",
|
||||
"version": "10.2.0-beta+6X38"
|
||||
"version": "10.2.0-beta+6X39"
|
||||
},
|
||||
"needs": [ {
|
||||
"need": {
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
"is": {
|
||||
"type": "kit",
|
||||
"title": "WorldModelKit",
|
||||
"version": "10.2.0-beta+6X38"
|
||||
"version": "10.2.0-beta+6X39"
|
||||
},
|
||||
"needs": [ {
|
||||
"need": {
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
Inform 7 v10.2.0 has started.
|
||||
I've now read your source text, which is 11 words long.
|
||||
I've also read version 1 of Basic Inform by Graham Nelson, which is 7888 words long.
|
||||
I've also read version 1 of English Language by Graham Nelson, which is 2330 words long.
|
||||
I've also read version 6 of Standard Rules by Graham Nelson, which is 35013 words long.
|
||||
I've also read version 2 of Basic Inform by Graham Nelson, which is 8538 words long.
|
||||
I've also read version 2 of English Language by Graham Nelson, which is 2330 words long.
|
||||
I've also read version 7 of Standard Rules by Graham Nelson, which is 34998 words long.
|
||||
Problem__ PM_KindUnalterable
|
||||
>--> You wrote 'A person is a kind of room' (source text, line 2), but that
|
||||
seems to contradict 'A person is a kind of thing' (the Standard Rules, line 129),
|
||||
seems to contradict 'A person is a kind of thing' (the Standard Rules, line 130),
|
||||
as a room and a thing are incompatible. (If a room were a kind of a thing
|
||||
or vice versa there'd be no problem, but they aren't.)
|
||||
Inform 7 has finished.
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
Inform 7 v10.2.0 has started.
|
||||
I've now read your source text, which is 11 words long.
|
||||
I've also read version 1 of Basic Inform by Graham Nelson, which is 7888 words long.
|
||||
I've also read version 1 of English Language by Graham Nelson, which is 2330 words long.
|
||||
I've also read version 6 of Standard Rules by Graham Nelson, which is 35013 words long.
|
||||
I've also read version 2 of Basic Inform by Graham Nelson, which is 8538 words long.
|
||||
I've also read version 2 of English Language by Graham Nelson, which is 2330 words long.
|
||||
I've also read version 7 of Standard Rules by Graham Nelson, which is 34998 words long.
|
||||
Problem__ PM_KindsCircular
|
||||
>--> You wrote 'A person is a kind of animal' (source text, line 3), but that
|
||||
seems to contradict 'An animal is a kind of person' (the Standard Rules, line 356),
|
||||
seems to contradict 'An animal is a kind of person' (the Standard Rules, line 357),
|
||||
as it would make a circularity with an animal and a thing each being kinds
|
||||
of the other.
|
||||
Inform 7 has finished.
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
Inform 7 v10.2.0 has started.
|
||||
I've now read your source text, which is 12 words long.
|
||||
I've also read version 1 of Basic Inform by Graham Nelson, which is 7888 words long.
|
||||
I've also read version 1 of English Language by Graham Nelson, which is 2330 words long.
|
||||
I've also read version 6 of Standard Rules by Graham Nelson, which is 35013 words long.
|
||||
I've also read version 2 of Basic Inform by Graham Nelson, which is 8538 words long.
|
||||
I've also read version 2 of English Language by Graham Nelson, which is 2330 words long.
|
||||
I've also read version 7 of Standard Rules by Graham Nelson, which is 34998 words long.
|
||||
Problem__ PM_TransposedNegationPair
|
||||
>--> In 'A door is either opaque or transparent' (source text, line 3), you
|
||||
proposed to set up the properties 'opaque' and 'transparent' as opposites
|
||||
|
|
@ -10,7 +10,7 @@ Problem__ PM_TransposedNegationPair
|
|||
opposites, but the other way around. (This matters because it affects
|
||||
whether things not explicitly said to be either should be opaque or
|
||||
transparent. Here you imply transparent is the default, but in the previous
|
||||
declaration 'A container can be transparent or opaque' (the Standard Rules, line 267),
|
||||
declaration 'A container can be transparent or opaque' (the Standard Rules, line 268),
|
||||
opaque was.) Putting these two property names the other way around should
|
||||
fix it.
|
||||
Inform 7 has finished.
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
Inform 7 v10.2.0 has started.
|
||||
I've now read your source text, which is 10 words long.
|
||||
I've also read version 1 of Basic Inform by Graham Nelson, which is 7888 words long.
|
||||
I've also read version 1 of English Language by Graham Nelson, which is 2330 words long.
|
||||
I've also read version 6 of Standard Rules by Graham Nelson, which is 35013 words long.
|
||||
I've also read version 2 of Basic Inform by Graham Nelson, which is 8538 words long.
|
||||
I've also read version 2 of English Language by Graham Nelson, which is 2330 words long.
|
||||
I've also read version 7 of Standard Rules by Graham Nelson, which is 34998 words long.
|
||||
Problem__ PM_TransposedNegationPair2
|
||||
>--> In 'A door can be opaque' (source text, line 3), you proposed to set up
|
||||
the property 'opaque' as something which is sometimes held and sometimes
|
||||
not, but by default is not. However, that clashes with the existing
|
||||
declaration 'A container can be transparent or opaque' (the Standard Rules, line 267),
|
||||
declaration 'A container can be transparent or opaque' (the Standard Rules, line 268),
|
||||
which establishes that opaque is the opposite of transparent, and is held
|
||||
by default. (The simplest way to fix this is just to change 'opaque' to
|
||||
'transparent' in your sentence here.)
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
Inform 7 v10.2.0 has started.
|
||||
I've now read your source text, which is 46 words long.
|
||||
I've also read version 1 of Basic Inform by Graham Nelson, which is 7888 words long.
|
||||
I've also read version 1 of English Language by Graham Nelson, which is 2330 words long.
|
||||
I've also read version 6 of Standard Rules by Graham Nelson, which is 35013 words long.
|
||||
I've also read version 2 of Basic Inform by Graham Nelson, which is 8538 words long.
|
||||
I've also read version 2 of English Language by Graham Nelson, which is 2330 words long.
|
||||
I've also read version 7 of Standard Rules by Graham Nelson, which is 34998 words long.
|
||||
Problem__ PM_VarKOVClash
|
||||
In Part Three - Variables and Rulebooks, Chapter 1 - Variables, Section 3 -
|
||||
Used when ruling on accessibility in the extension Standard Rules by Graham
|
||||
Nelson:
|
||||
>--> You wrote 'The container in question is an object that varies' (the
|
||||
Standard Rules, line 470): but the name supplied for this new variable is a
|
||||
Standard Rules, line 471): but the name supplied for this new variable is a
|
||||
piece of text which is not available because it has a rival meaning
|
||||
already, as a result of definitions made elsewhere. (Sometimes these are
|
||||
indirect: for instance, defining a column in a table called 'question' can
|
||||
|
|
@ -19,7 +19,7 @@ In Part Three - Variables and Rulebooks, Chapter 1 - Variables, Section 3 -
|
|||
defined which might cause this clash.
|
||||
Problem__ PM_VarKOVClash
|
||||
>--> You wrote 'The supporter in question is an object that varies' (the
|
||||
Standard Rules, line 471): again, the name supplied for this new variable
|
||||
Standard Rules, line 472): again, the name supplied for this new variable
|
||||
is a piece of text which is not available because it has a rival meaning
|
||||
already.
|
||||
Inform 7 has finished.
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
Inform 7 v10.2.0 has started.
|
||||
I've now read your source text, which is 15 words long.
|
||||
I've also read version 1 of Basic Inform by Graham Nelson, which is 7888 words long.
|
||||
I've also read version 1 of English Language by Graham Nelson, which is 2330 words long.
|
||||
I've also read version 6 of Standard Rules by Graham Nelson, which is 35013 words long.
|
||||
I've also read version 2 of Basic Inform by Graham Nelson, which is 8538 words long.
|
||||
I've also read version 2 of English Language by Graham Nelson, which is 2330 words long.
|
||||
I've also read version 7 of Standard Rules by Graham Nelson, which is 34998 words long.
|
||||
Problem__ PM_VariableContradiction
|
||||
>--> You wrote 'The command prompt is "What do you want to do? >"' (source
|
||||
text, line 3), but in another sentence 'The command prompt is ">"' (the
|
||||
Standard Rules, line 495): but this looks like a contradiction, because the
|
||||
Standard Rules, line 496): but this looks like a contradiction, because the
|
||||
initial value of this variable seems to be being set in each of these
|
||||
sentences, but with a different outcome.
|
||||
Inform 7 has finished.
|
||||
|
|
|
|||
|
|
@ -60,7 +60,8 @@ the problem message test cases, so we observe them.
|
|||
void Coverage::which_problems_have_test_cases(void) {
|
||||
filename *CAT = Filenames::in(path_to_inpolicy_workspace, I"cases.txt");
|
||||
TEMPORARY_TEXT(COMMAND)
|
||||
WRITE_TO(COMMAND, "..%cintest%cTangled%cintest inform7 -catalogue ", FOLDER_SEPARATOR, FOLDER_SEPARATOR, FOLDER_SEPARATOR);
|
||||
WRITE_TO(COMMAND, "..%cintest%cTangled%cintest inform7 -catalogue ",
|
||||
FOLDER_SEPARATOR, FOLDER_SEPARATOR, FOLDER_SEPARATOR);
|
||||
Shell::redirect(COMMAND, CAT);
|
||||
if (Shell::run(COMMAND)) Errors::fatal("can't run intest to harvest cases");
|
||||
DISCARD_TEXT(COMMAND)
|
||||
|
|
@ -83,7 +84,7 @@ to problem messages:
|
|||
void Coverage::which_problems_are_referenced(void) {
|
||||
pathname *D = Pathnames::from_text(I"resources");
|
||||
D = Pathnames::down(D, I"Documentation");
|
||||
filename *WWI = Filenames::in(D, I"Writing with Inform.txt");
|
||||
filename *WWI = Filenames::in(D, I"Writing with Inform.md");
|
||||
TextFiles::read(WWI, FALSE, "unable to read 'Writing with Inform' source text", TRUE,
|
||||
&Coverage::xref_harvester, NULL, NULL);
|
||||
}
|
||||
|
|
|
|||
Binary file not shown.
|
|
@ -1,69 +0,0 @@
|
|||
volume: Changes to Inform
|
||||
images: Imagery/doc_images/
|
||||
cover: changes_cover.png
|
||||
|
||||
dc:title: Changes to Inform
|
||||
dc:creator: Graham Nelson and Emily Short
|
||||
dc:subject: Interactive Fiction
|
||||
dc:identifier: inform-changes
|
||||
|
||||
contents_expandable = yes
|
||||
treat_code_as_verbatim = no
|
||||
inform_definitions_mode = yes
|
||||
alphabetization = word-by-word
|
||||
|
||||
css: p.quoted + {
|
||||
font-family: "Lucida Grande", Geneva, Arial, Tahoma, Verdana, Helvetica, Helv;
|
||||
}
|
||||
|
||||
css: td.midnightrighthalfpage ++ {
|
||||
background-color: #ffffe5;
|
||||
}
|
||||
|
||||
css: <i>text</i> = italic
|
||||
css: <b>text</b> = boldface
|
||||
|
||||
css: body.paper ++ {
|
||||
overflow-y: visible;
|
||||
}
|
||||
|
||||
ebook {
|
||||
granularity = 2
|
||||
examples_mode = open
|
||||
navigation = unsigned
|
||||
}
|
||||
|
||||
test {
|
||||
# test HTML for the I7 website
|
||||
format = HTML
|
||||
navigation = midnight
|
||||
examples_mode = openable
|
||||
images_copy = yes
|
||||
}
|
||||
|
||||
website {
|
||||
# HTML for the I7 website
|
||||
destination = Website/content/learn/man/
|
||||
images_copy = no
|
||||
examples_mode = openable
|
||||
}
|
||||
|
||||
newwebsite {
|
||||
# HTML for the I7 website
|
||||
images_copy = no
|
||||
images_path = /assets/images/doc_images/
|
||||
examples_mode = openable
|
||||
}
|
||||
|
||||
html_for_chm {
|
||||
# Minimally tagged HTML for CHM
|
||||
html_light = yes
|
||||
destination = Website/content/learn/man/Inform-manuals/
|
||||
top_and_tail = Website/models/HTMLModel.html
|
||||
top_and_tail_sections = Website/models/HTMLModel.html
|
||||
}
|
||||
|
||||
plain {
|
||||
# Plain text for screenreaders
|
||||
destination = Website/content/learn/man/ChangesToInform.txt
|
||||
}
|
||||
|
|
@ -20,7 +20,7 @@ Suppose we have a complete Encyclopedia in our game. The player is allowed to pi
|
|||
Instead of examining a collective:
|
||||
say "[The noun] consists of [the list of things which are part of the noun]."
|
||||
|
||||
Now the real work begins. One reason to make this an activity is that we might easily want to override it for specific objects; for instance, the generic collecting activity here would not deal properly with collectives of clothing where some items might be worn and others not. In that case, we would want to write another, more specific "collecting" activity to handle the complexities of fashion.
|
||||
Now the real work begins. One reason to make this an activity is that we might easily want to override it for specific objects; for instance, the generic collecting activity here would not deal properly with collectives of clothing where some items might be worn and others not. In that case, we would want to write another, more specific `collecting` activity to handle the complexities of fashion.
|
||||
|
||||
{**}Collecting something is an activity.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Index: Person who comments on the player's every action
|
|||
Description: A complete story by Emily Short, called "A Day for Fresh Sushi", rewritten using Inform 7. Noteworthy is the snarky commenter who remarks on everything the player does, but only the first time each action is performed.
|
||||
For: Z-Machine
|
||||
|
||||
The following is an almost-completely-faithful rewrite of Emily Short's "A Day for Fresh Sushi", which was originally written using the (very different) Inform 6 programming language. The – let us be honest and call it a gimmick – of this game is the evil fish, who has some unpleasant remark to offer on pretty much every action. But the effect would wear off fast if he repeated himself, so these comments need to be single-use only.
|
||||
The following is an almost-completely-faithful rewrite of Emily Short's _A Day for Fresh Sushi_, which was originally written using the (very different) Inform 6 programming language. The – let us be honest and call it a gimmick – of this game is the evil fish, who has some unpleasant remark to offer on pretty much every action. But the effect would wear off fast if he repeated himself, so these comments need to be single-use only.
|
||||
|
||||
Inform 7's repeated action syntax makes it much tidier to write the same scenario, so:
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Example: *** A point for never saving the game
|
|||
Location: Out of world actions
|
||||
RecipeLocation: Saving and Undoing
|
||||
Index: A point for never saving the game
|
||||
Description: In some of the late 1970s "cave crawl" adventure games, an elaborate scoring system might still leave the player perplexed as to why an apparently perfect play-through resulted in a score which was still one point short of the supposed maximum. Why only 349 out of 350? The answer varied, but sometimes the last point was earned by never saving the game - in other words by playing it right through with nothing to guard against mistakes (except perhaps ``undo`` for the last command), and in one long session.
|
||||
Description: In some of the late 1970s cave-crawl adventure games, an elaborate scoring system might still leave the player perplexed as to why an apparently perfect play-through resulted in a score which was still one point short of the supposed maximum. Why only 349 out of 350? The answer varied, but sometimes the last point was earned by never saving the game - in other words by playing it right through with nothing to guard against mistakes (except perhaps ``UNDO`` for the last command), and in one long session.
|
||||
For: Untestable
|
||||
|
||||
Here is one way to score this point with Inform:
|
||||
|
|
|
|||
|
|
@ -2,10 +2,10 @@ Example: *** A View of Green Hills
|
|||
Location: Adjacent rooms and routes through the map
|
||||
RecipeLocation: Continuous Spaces and The Outdoors
|
||||
Index: LOOK [direction] command
|
||||
Description: A ``look`` [direction] command which allows the player to see descriptions of the nearby landscape.
|
||||
Description: A ``LOOK`` [direction] command which allows the player to see descriptions of the nearby landscape.
|
||||
For: Z-Machine
|
||||
|
||||
Suppose a game in which the player is wandering an open landscape with long vistas, allowing them to ``look`` in some direction, or even look at an adjacent location.
|
||||
Suppose a game in which the player is wandering an open landscape with long vistas, allowing them to ``LOOK`` in some direction, or even look at an adjacent location.
|
||||
|
||||
{*}"A View of Green Hills"
|
||||
|
||||
|
|
@ -20,7 +20,7 @@ Suppose a game in which the player is wandering an open landscape with long vist
|
|||
if the viewed item is not a room, say "You can't see anything promising that way." instead;
|
||||
try looking toward the viewed item.
|
||||
|
||||
In rules about action handling, "noun" refers to the first object that the player has mentioned in their command, so if the player typed ``look west``, "let the viewed item be the room noun from the location" would be processed as "let the viewed item be the room west from the location", and so on.
|
||||
In rules about action handling, `noun` refers to the first object that the player has mentioned in their command, so if the player typed ``LOOK WEST``, `let the viewed item be the room noun from the location` would be processed as `let the viewed item be the room west from the location`, and so on.
|
||||
|
||||
We can at need override the default behaviour, if it is not going to be appropriate for the player to see the next room over. There is only sky above at any time, so...
|
||||
|
||||
|
|
|
|||
|
|
@ -5,37 +5,37 @@ Index: About Inform's regular expression support
|
|||
Description: Some footnotes on Inform's regular expressions, and how they compare to those of other programming languages.
|
||||
For: Untestable
|
||||
|
||||
There is not really any unanimity about what regular expression language is. The unix tools sed and grep extend on Kleene's original grammar. Henry Spencer's regex library extended on this again, and was a foundation for Perl, but Perl once again went further. Philip Hazel's ``pcre``, despite the name Perl Compatible Regular Expressions, makes further extensions still, and so on.
|
||||
There is not really any unanimity about what regular expression language is. The unix tools sed and grep extend on Kleene's original grammar. Henry Spencer's regex library extended on this again, and was a foundation for Perl, but Perl once again went further. Philip Hazel's PCRE, despite the name Perl Compatible Regular Expressions, makes further extensions still, and so on.
|
||||
|
||||
Inform's regular expressions are modelled on those of Perl, as the best de facto standard we have, but a few omissions have been inevitable. Inform's regex matcher must occupy source code less than one hundredth the size of ``pcre``, and it has very little memory. Inform aims to behave exactly like Perl except as follows:
|
||||
Inform's regular expressions are modelled on those of Perl, as the best de facto standard we have, but a few omissions have been inevitable. Inform's regex matcher must occupy source code less than one hundredth the size of PCRE, and it has very little memory. Inform aims to behave exactly like Perl except as follows:
|
||||
|
||||
1. Inform allows angle brackets as synonymous with square brackets, for reasons explained above. This means literal angle brackets have to be escaped as "\<" and "\>" in Inform regular expressions, which is unnecessary in Perl.
|
||||
1. Inform allows angle brackets as synonymous with square brackets, for reasons explained above. This means literal angle brackets have to be escaped as `\<` and `\>` in Inform regular expressions, which is unnecessary in Perl.
|
||||
|
||||
2. Inform only has single-line mode, not multiline mode: this removes need for the mode-switches "(?m)" and "(?s)" and the positional markers "\A" and "\Z". Multiline mode is idiosyncratic to Perl and is a messy compromise to do with holding long files of text as single strings, yet treating them as lists of lines at the same time: this would not be sensible for Inform. Similarly, because there is no ambiguity about how line breaks are represented in Inform strings (by a single "\n"), initial newline convention markers such as "(*ANYCRLF)" are unsupported.
|
||||
2. Inform only has single-line mode, not multiline mode: this removes need for the mode-switches `(?m)` and `(?s)` and the positional markers `\A` and `\Z`. Multiline mode is idiosyncratic to Perl and is a messy compromise to do with holding long files of text as single strings, yet treating them as lists of lines at the same time: this would not be sensible for Inform. Similarly, because there is no ambiguity about how line breaks are represented in Inform strings (by a single `\n`), initial newline convention markers such as `(*ANYCRLF)` are unsupported.
|
||||
|
||||
3. The codes "\a", "\r", "\f", "\e", "\0" for alarm, carriage return, form feed, escape and the zero character are unsupported: none of these can occur in an Inform string.
|
||||
3. The codes `\a`, `\r`, `\f`, `\e`, `\0` for alarm, carriage return, form feed, escape and the zero character are unsupported: none of these can occur in an Inform string.
|
||||
|
||||
4. Inform does not allow characters to be referred to by character code (whereas Perl allows "\036" for an octal character code, "\x7e" for a hexadecimal one, "\cD" for a control character). This is because we do not want the user to know whether text is internally stored as ZSCII or Unicode.
|
||||
4. Inform does not allow characters to be referred to by character code (whereas Perl allows `\036` for an octal character code, `\x7e` for a hexadecimal one, `\cD` for a control character). This is because we do not want the user to know whether text is internally stored as ZSCII or Unicode.
|
||||
|
||||
5. Inform's character class "\p" (and its negation "\P") have no equivalent in Perl, and Inform's understanding of "\w" is different. Perl defines this as an upper or lower case English letter, underscore or digit, which is good for programming-language identifiers, but bad for natural language - for instance, "é" is not matched by "\w" in Perl, but unquestionably it appears in words. Inform therefore defines "\w" as the negation of "\s" union "\p".
|
||||
5. Inform's character class `\p` (and its negation `\P`) have no equivalent in Perl, and Inform's understanding of `\w` is different. Perl defines this as an upper or lower case English letter, underscore or digit, which is good for programming-language identifiers, but bad for natural language - for instance, `é` is not matched by `\w` in Perl, but unquestionably it appears in words. Inform therefore defines `\w` as the negation of `\s` union `\p`.
|
||||
|
||||
6. Inform supports only single-digit grouping numbers "\1" to "\9", whereas Perl allows "\10", "\11", ...
|
||||
6. Inform supports only single-digit grouping numbers `\1` to `\9`, whereas Perl allows `\10`, `\11`, ...
|
||||
|
||||
7. POSIX named character ranges are not supported. These are only abbreviations in any case, and are not very useful. (Note that the POSIX range "[:punct:]", which is supposedly for punctuation, includes many things we do not want to think of that way - percentage signs, for instance - and so "\p" has a more natural-language-based definition.)
|
||||
7. POSIX named character ranges are not supported. These are only abbreviations in any case, and are not very useful. (Note that the POSIX range `[:punct:]`, which is supposedly for punctuation, includes many things we do not want to think of that way - percentage signs, for instance - and so `\p` has a more natural-language-based definition.)
|
||||
|
||||
8. Character classes can be used inside ranges, so that "<\da-f>" is legal, but not as ends of contiguous runs, so that "<\d-X>" is not legal. (As reckless as this is, it is legal in Perl.)
|
||||
8. Character classes can be used inside ranges, so that `<\da-f>` is legal, but not as ends of contiguous runs, so that `<\d-X>` is not legal. (As reckless as this is, it is legal in Perl.)
|
||||
|
||||
9. For obvious reasons, escapes to Perl code using the notation "(?{...})" are unsupported, and so is the Perl iteration operator "\G".
|
||||
9. For obvious reasons, escapes to Perl code using the notation `(?{...})` are unsupported, and so is the Perl iteration operator `\G`.
|
||||
|
||||
10. Perl's extended mode "(?x)", a lexical arrangement which allows expressions to be expanded out as little computer programs with comments, is unsupported. It would look awful syntax-coloured in the Inform interface and is not a style of coding to be encouraged.
|
||||
10. Perl's extended mode `(?x)`, a lexical arrangement which allows expressions to be expanded out as little computer programs with comments, is unsupported. It would look awful syntax-coloured in the Inform interface and is not a style of coding to be encouraged.
|
||||
|
||||
Inform further does not support the Python extension of named subexpression groups, nor the Java extension of the possessive quantifier "++". There was only so much functionality we could squeeze in.
|
||||
Inform further does not support the Python extension of named subexpression groups, nor the Java extension of the possessive quantifier `++`. There was only so much functionality we could squeeze in.
|
||||
|
||||
As verification of Inform's matching algorithm, we took the Perl 5 source code's notorious "re-test.txt" set of 961 test cases, removed the 316 using features unsupported by Inform (220 tested multiline mode, for instance), and ran the remaining 645 cases through Inform. It agrees with Perl on 643 of these: the two outstanding are –
|
||||
As verification of Inform's matching algorithm, we took the Perl 5 source code's notorious `re-test.txt` set of 961 test cases, removed the 316 using features unsupported by Inform (220 tested multiline mode, for instance), and ran the remaining 645 cases through Inform. It agrees with Perl on 643 of these: the two outstanding are –
|
||||
|
||||
1. Perl is able to match "^(a\1?){4}$" against "aaaaaa" but Inform is not - Inform's backtracking is not as good when it comes to repetitions of groupings which are recursively defined. (Note that the optional "\1" match refers to the value of the bracketed expression which contains it, so that the interpretation is different on each repetition. Here to match we have to interpret "?" as 0, 0, 1, 0 repeats respectively as we work through the "{4}".)
|
||||
1. Perl is able to match `^(a\1?){4}$` against `aaaaaa` but Inform is not - Inform's backtracking is not as good when it comes to repetitions of groupings which are recursively defined. (Note that the optional `\1` match refers to the value of the bracketed expression which contains it, so that the interpretation is different on each repetition. Here to match we have to interpret `?` as 0, 0, 1, 0 repeats respectively as we work through the `{4}`.)
|
||||
|
||||
2. Perl matches "((<a-c>)b*?\2)*" against "ababbbcbc" finding the match "ababb", whereas Inform finds the match "ababbbcbc". This is really a difference of opinion about whether the outer asterisk, which is greedy, should be allowed three matches rather than two if to do so requires the inner asterisk, which is not greedy, to eat more than it needs on one of those three matches.
|
||||
2. Perl matches `((<a-c>)b*?\2)*` against `ababbbcbc` finding the match `ababb`, whereas Inform finds the match `ababbbcbc`. This is really a difference of opinion about whether the outer asterisk, which is greedy, should be allowed three matches rather than two if to do so requires the inner asterisk, which is not greedy, to eat more than it needs on one of those three matches.
|
||||
|
||||
Case 1 is a sacrifice to enable Inform's back-tracking to use less memory. Case 2 simply seems unimportant.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,25 +5,23 @@ Index: About the examples
|
|||
Description: An explanation of the examples in this documentation, and the asterisks attached to them. Click the heading of the example, or the example number, to reveal the text.
|
||||
For: Untestable
|
||||
|
||||
[ZL: .png to be substituted]::
|
||||
|
||||
This is the first of about 400 numbered examples. In a few cases, such as this one, they provide a little background information, but almost all demonstrate Inform source text. The techniques demonstrated tend to be included either because they are frequently asked for, or because they show how to achieve some interesting effect.
|
||||
|
||||
The same examples are included in **both** of the books of documentation, but in a different order: in *Writing with Inform*, they appear near the techniques used to make them work; in *The Inform Recipe Book*, they are grouped by the effects they provide. For instance, an example called [Do Pass Go], about the throwing of a pair of dice, appears in the [Randomness] section of *Writing with Inform* and also in the [Dice and Playing Cards] section of *The Inform Recipe Book*. Clicking the italicised WI and RB buttons at the right-hand side of an example's heading switches between its position in each book.
|
||||
|
||||
Many computing books quote excerpts from programs, but readers have grown wary of them: they are tiresome to type in, and may only be fragments, or may not ever have been tested. The authors of Inform have tried to avoid this. All but two dozen examples contain entire source texts. A single click on the paste icon ///paste.png/// (always placed just left of the double-quoted title) will write the complete source text into the Source panel. All that is then required is to click the Go button, and the example should translate into a working game.
|
||||
Many computing books quote excerpts from programs, but readers have grown wary of them: they are tiresome to type in, and may only be fragments, or may not ever have been tested. The authors of Inform have tried to avoid this. All but two dozen examples contain entire source texts. A single click on the paste icon (always placed just left of the double-quoted title) will write the complete source text into the Source panel. All that is then required is to click the Go button, and the example should translate into a working game.
|
||||
|
||||
In most cases, typing the single command ``test me`` will play through a few moves to show off the effect being demonstrated. (You may find it convenient to create a "scratch" project file for temporary trials like this, clearing all its text and starting again with each new test.)
|
||||
In most cases, typing the single command ``TEST ME`` will play through a few moves to show off the effect being demonstrated. (You may find it convenient to create a "scratch" project file for temporary trials like this, clearing all its text and starting again with each new test.)
|
||||
|
||||
As part of the testing process which verifies a new build of Inform, each example in turn is extracted from this documentation, translated, played through, and the resulting transcript mechanically checked. So the examples may even work as claimed. But the flesh is weak, and there are bound to be glitches. We would welcome reports, so that future editions can be corrected.
|
||||
|
||||
Each example is loosely graded by difficulty: if they were exercises in a textbook, the asterisks would indicate how many marks each question scores. As a general rule:
|
||||
|
||||
[ZL: better without bullets; first line actually appears mangled; possibly a bug in IFM parsing ...]::
|
||||
|
||||
- * A simple example, fairly easily guessed.
|
||||
- ** A complicated or surprising example.
|
||||
- *** An example needing detailed knowledge of many aspects of the system.
|
||||
- **** A complete scenario, containing material not necessarily relevant to the topic being demonstrated.
|
||||
Rating | Difficulty
|
||||
-------- | ----------
|
||||
\* | A simple example, fairly easily guessed.
|
||||
\*\* | A complicated or surprising example.
|
||||
\*\*\* | An example needing detailed knowledge of many aspects of the system.
|
||||
\*\*\*\* | A complete scenario, containing material not necessarily relevant to the topic being demonstrated.
|
||||
|
||||
In general, the main text of *Writing with Inform* tries never to assume knowledge of material which has not yet appeared, but the trickier examples almost always need to break this rule.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Index: The Pointy Hat of Liminal Transgression
|
|||
Description: The Pointy Hat of Liminal Transgression allows its wearer to walk clean through closed doors.
|
||||
For: Z-Machine
|
||||
|
||||
If somebody tries to walk through a closed door, the "can't go through closed doors rule" usually stops them. This is a rule belonging to the "check going" rulebook. These names are fairly explanatory when written out, but hard to remember: fortunately we don't need to remember them, as the Index panel contains a full inventory of the check, carry out and report rules for every action, showing all of their names and the order in which they are checked. (We can also find out which rules are stopping an action by typing the testing command ``actions``.)
|
||||
If somebody tries to walk through a closed door, the `can't go through closed doors rule` usually stops them. This is a rule belonging to the `check going` rulebook. These names are fairly explanatory when written out, but hard to remember: fortunately we don't need to remember them, as the Index panel contains a full inventory of the check, carry out and report rules for every action, showing all of their names and the order in which they are checked. (We can also find out which rules are stopping an action by typing the testing command ``ACTIONS``.)
|
||||
|
||||
Here we make the rule do nothing provided a condition holds:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
Example: ** Actaeon
|
||||
Location: Understanding any, understanding rooms
|
||||
Location: Scope
|
||||
RecipeLocation: Travelling Characters
|
||||
Index: FOLLOW command
|
||||
Description: A ``follow`` command allowing the player to pursue a person who has just left the room.
|
||||
Description: A ``FOLLOW`` command allowing the player to pursue a person who has just left the room.
|
||||
For: Z-Machine
|
||||
|
||||
Suppose we want the player to be able to go after characters who are moving around the map. The trick, of course, is that once characters are gone they are no longer visible to "follow [person]", so we need "follow [any person]" to find them.
|
||||
Suppose we want the player to be able to go after characters who are moving around the map. The trick, of course, is that once characters are gone they are no longer visible to `"follow [person]"`, so we need `"follow [any person]"` to find them.
|
||||
|
||||
{*}"Actaeon"
|
||||
|
||||
|
|
|
|||
|
|
@ -68,5 +68,5 @@ Here we construct a video camera to track and play back actions:
|
|||
|
||||
Test me with "set camera to recording / x lucas / lucas, take inventory / lucas, eat croissant / set camera to playing back / z".
|
||||
|
||||
Notice that both Lucas' implied taking action (picking up the croissant) and his eating action are recorded on the same move.
|
||||
Notice that both Lucas's implied taking action (picking up the croissant) and his eating action are recorded on the same move.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Index: Radios and other devices active when switched on
|
|||
Description: Modifying the rules for examining a device so that all devices have some specific behaviour when switched on, which is described at various times.
|
||||
For: Z-Machine
|
||||
|
||||
The built-in behaviour of Inform is to print a line after a device is examined, saying whether the item is on or off. This is often inappropriate, and we could simply turn off that behaviour in general by instructing Inform to ignore the "examine devices rule" (see the chapter on [Rulebooks]).
|
||||
The built-in behaviour of Inform is to print a line after a device is examined, saying whether the item is on or off. This is often inappropriate, and we could simply turn off that behaviour in general by instructing Inform to ignore the `examine devices rule` (see the chapter on [Rulebooks]).
|
||||
|
||||
Perhaps, though, we would like continue to have a short passage about the action of any switched on device; we'd just like a little more control over what it says from time to time. And in that case, we might change the rule to give a new activity control over that portion of the description:
|
||||
|
||||
|
|
@ -19,7 +19,7 @@ Perhaps, though, we would like continue to have a short passage about the action
|
|||
if the item is switched on, say "[The item] is switched on.";
|
||||
otherwise say "[The item] is switched off."
|
||||
|
||||
Borrowing from the rulebooks chapter, we can replace the standard "examine devices" rule with something that uses this activity.
|
||||
Borrowing from the rulebooks chapter, we can replace the standard `examine devices rule` with something that uses this activity.
|
||||
|
||||
{**}The new described devices rule is listed instead of the examine devices rule in the carry out examining rules.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Example: **** Air Conditioning is Standard
|
|||
Location: Writing a paragraph about
|
||||
RecipeLocation: Event Scheduling
|
||||
Index: Paragraphs of flexible descriptions
|
||||
Description: Uses "writing a paragraph about" to make person and object descriptions that vary considerably depending on what else is going on in the room, including some randomised NPC interactions with objects or with each other.
|
||||
Description: Uses `writing a paragraph about` to make person and object descriptions that vary considerably depending on what else is going on in the room, including some randomised NPC interactions with objects or with each other.
|
||||
For: Z-Machine
|
||||
|
||||
{*}"Air Conditioning is Standard"
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ We'll set up a little political espionage scenario from which our player can mak
|
|||
|
||||
The player is wearing a housekeeping uniform and a brunette wig. The player carries a telephone called a Nokia.
|
||||
|
||||
Borrowing again from the chapter on [Understanding], we might arrange things so that the player knows and can call a few standard numbers with such syntax as ``call home``:
|
||||
Borrowing again from the chapter on [Understanding], we might arrange things so that the player knows and can call a few standard numbers with such syntax as ``CALL HOME``:
|
||||
|
||||
{**}Understand "home" as 555-9200.
|
||||
|
||||
|
|
@ -46,7 +46,7 @@ And what if we'd like to have the player learn some phone numbers during the gam
|
|||
|
||||
Understand "Stephen" as 555-2513 when the blue paper is examined.
|
||||
|
||||
This will understand ``call stephen`` once the paper is examined; before that, the player will just get the "That's not a number you know" response that Inform uses for all attempts to call unknown names.
|
||||
This will understand ``CALL STEPHEN`` once the paper is examined; before that, the player will just get the ``That's not a number you know`` response that Inform uses for all attempts to call unknown names.
|
||||
|
||||
We'd better plant this paper for the player to find:
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Suppose that we have a series of games each of which allows the player to select
|
|||
if File of Preferences exists:
|
||||
read File of Preferences into the Table of Preference Settings;
|
||||
choose row 1 in the Table of Preference Settings;
|
||||
say "(The current puzzle difficulty is set to [challenge level entry].)";
|
||||
say "(The current puzzle difficulty is set to [challenge level entry].)"
|
||||
|
||||
Check quitting the game:
|
||||
write File of Preferences from the Table of Preference Settings.
|
||||
|
|
@ -37,5 +37,5 @@ Suppose that we have a series of games each of which allows the player to select
|
|||
|
||||
Our preference file is restricted to a single option here for simplicity's sake, but we could keep track of more information – whether the player preferred verbose or brief room descriptions, screen configurations, and so on.
|
||||
|
||||
If we were disposed to be somewhat crueler, we could use a similar method to make the player finish each episode of the series in order to "unlock" the next. All we would need to do is store a numerical password in our preferences file when the player finished a given level; the next level would check, say, the Table of Completed Levels for that password, and refuse to play unless the right number were present.
|
||||
If we were disposed to be somewhat crueler, we could use a similar method to make the player finish each episode of the series in order to unlock the next. All we would need to do is store a numerical password in our preferences file when the player finished a given level; the next level would check, say, the Table of Completed Levels for that password, and refuse to play unless the right number were present.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Example: * All Roads Lead to Mars
|
|||
Location: Adjacent rooms and routes through the map
|
||||
RecipeLocation: Map
|
||||
Index: Rooms player is forced to visit in order
|
||||
Description: Layout where the player is allowed to wander any direction he likes, and the map will arrange itself in order so that he finds the correct "next" location.
|
||||
Description: Layout where the player is allowed to wander any direction he likes, and the map will arrange itself in order so that he finds the correct next location.
|
||||
For: Z-Machine
|
||||
|
||||
Suppose we want to allow the player to wander freely in any direction, but ourselves maintain control over the order in which they encounter the rooms. This sort of effect emphasises the order of the story-telling over any kind of rigorous simulation of space; on multiple play-throughs, the player might not find all the same rooms in the same locations.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Example: * Alpaca Farm
|
|||
Location: New commands for old grammar
|
||||
RecipeLocation: Clarification and Correction
|
||||
Index: USE action which divines rational behaviour for a wide range of possible nouns
|
||||
Description: A generic ``use`` action which behaves sensibly with a range of different objects.
|
||||
Description: A generic ``USE`` action which behaves sensibly with a range of different objects.
|
||||
For: Z-Machine
|
||||
|
||||
This example takes the ordering of grammar lines to its logical extreme, sorting the player's input into different categories depending on the kind and condition of the objects mentioned.
|
||||
|
|
@ -50,5 +50,5 @@ This example takes the ordering of grammar lines to its logical extreme, sorting
|
|||
|
||||
Test me with "use gate / use blower / use nippers / use brush / use apple / remove sombrero / use sombrero".
|
||||
|
||||
Whether we actually want a ``use`` action is a subject of some theoretical debate in the IF community. On the one hand, it helps avoid guess-the-verb problems where the player cannot figure out what term to use in order to express a fairly simple idea. On the other, it encourages the player to think that all items have one and exactly one use, rather than getting them to consider the range of possibilities that arise from having a complex vocabulary.
|
||||
Whether we actually want a ``USE`` action is a subject of some theoretical debate in the IF community. On the one hand, it helps avoid guess-the-verb problems where the player cannot figure out what term to use in order to express a fairly simple idea. On the other, it encourages the player to think that all items have one and exactly one use, rather than getting them to consider the range of possibilities that arise from having a complex vocabulary.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,10 +2,10 @@ Example: * Anchorite
|
|||
Location: New commands for old grammar
|
||||
RecipeLocation: Entering and Exiting, Sitting and Standing
|
||||
Index: GET DOWN and DOWN understood as EXIT
|
||||
Description: By default, Inform understands ``get off``, ``get up``, or ``get out`` when the player is sitting or standing on an enterable object. We might also want to add ``get down`` and ``down`` as exit commands, though.
|
||||
Description: By default, Inform understands ``GET OFF``, ``GET UP``, or ``GET OUT`` when the player is sitting or standing on an enterable object. We might also want to add ``GET DOWN`` and ``DOWN`` as exit commands, though.
|
||||
For: Z-Machine
|
||||
|
||||
With ``get down``, we can replace the whole command, which will not interfere with the normal function of the ``take`` verb, or allow the player to attempt to ``get`` any other directions:
|
||||
With ``GET DOWN``, we can replace the whole command, which will not interfere with the normal function of the ``TAKE`` verb, or allow the player to attempt to ``GET`` any other directions:
|
||||
|
||||
{*}"Anchorite"
|
||||
|
||||
|
|
@ -13,7 +13,7 @@ With ``get down``, we can replace the whole command, which will not interfere wi
|
|||
|
||||
Understand "get down" as exiting.
|
||||
|
||||
This doesn't cover the case where the player just types ``down``, and we don't want to preempt the normal operation of the ``go`` action here. So instead of writing a new understand instruction, we might catch this one at the action-processing level:
|
||||
This doesn't cover the case where the player just types ``DOWN``, and we don't want to preempt the normal operation of the ``GO`` action here. So instead of writing a new understand instruction, we might catch this one at the action-processing level:
|
||||
|
||||
{**}Instead of going down when the player is on a supporter:
|
||||
try exiting.
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ To add a new activity to an existing Inform rule, we need to do three things:
|
|||
|
||||
1) Define our new activity.
|
||||
|
||||
2) Give a basic rule that says what is supposed to happen when that activity occurs, as in "Rule for..."
|
||||
2) Give a basic rule that says what is supposed to happen when that activity occurs, as in `Rule for...`
|
||||
|
||||
3) Replace the existing rule in Inform's rulebooks with a new one that calls on our activity.
|
||||
|
||||
|
|
@ -97,7 +97,7 @@ Now we do the same thing to room descriptions.
|
|||
|
||||
Our replacement rule this time around is a little bit trickier just because the rule that we're replacing is a complicated one: describing a room already checks to see whether there's light to see by, whether the player has turned off room descriptions when entering a room for the second time, and whether the player character is (say) inside a closed box they can't see out of.
|
||||
|
||||
But all of those details are re-copied from the standard rules, and the important thing is that, at the end, we again carry out our activity.
|
||||
But all of those details are re-copied from the Standard Rules, and the important thing is that, at the end, we again carry out our activity.
|
||||
|
||||
{**}This is the activity-based room description body text rule:
|
||||
if the visibility level count is 0:
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Example: ** Anteaters
|
|||
Location: Stored actions
|
||||
RecipeLocation: Remembering, Converting and Combining Actions
|
||||
Index: Device to remember and play back actions
|
||||
Description: The player carries a gizmo that is able to record actions performed by the player, then force them to repeat those actions when the gizmo is dropped. This includes storing actions that apply to topics, as in "look up anteater colonies in the guide".
|
||||
Description: The player carries a gizmo that is able to record actions performed by the player, then force them to repeat those actions when the gizmo is dropped. This includes storing actions that apply to topics, as in ``LOOK UP ANTEATER COLONIES IN THE GUIDE``.
|
||||
For: Z-Machine
|
||||
|
||||
{*}"Anteaters"
|
||||
|
|
|
|||
|
|
@ -13,29 +13,11 @@ Generally this produces good behaviour. Occasionally, though, two objects have s
|
|||
|
||||
Understand the consumption property as describing an apple.
|
||||
|
||||
The player can meaningfully type
|
||||
|
||||
``` transcript
|
||||
>eat bitten apple
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
``` transcript
|
||||
>eat pristine apple
|
||||
```
|
||||
|
||||
but if they type
|
||||
|
||||
``` transcript
|
||||
>eat apple
|
||||
```
|
||||
|
||||
Inform will, annoyingly, ask
|
||||
The player can meaningfully type ``EAT BITTEN APPLE`` or ``EAT PRISTINE APPLE`` but if they type ``EAT APPLE`` Inform will, annoyingly, ask
|
||||
|
||||
Which do you mean, an apple or the apple?
|
||||
|
||||
This gives the player no indication of why Inform is making a distinction. So here we add a special "printing the name" rule to get around that situation:
|
||||
This gives the player no indication of why Inform is making a distinction. So here we add a special `printing the name rule` to get around that situation:
|
||||
|
||||
{*}"Apples"
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Example: * Bad Hair Day
|
|||
Location: Instead rules
|
||||
RecipeLocation: Characterisation
|
||||
Index: Examining the player
|
||||
Description: Change the player's appearance in response to ``examine me``.
|
||||
Description: Change the player's appearance in response to ``EXAMINE ME``.
|
||||
For: Z-Machine
|
||||
|
||||
{*}"Bad Hair Day"
|
||||
|
|
|
|||
|
|
@ -2,10 +2,10 @@ Example: *** Ballpark
|
|||
Location: Text with numbers
|
||||
RecipeLocation: Varying What Is Written
|
||||
Index: Saying a number in round numbers
|
||||
Description: A new "to say" definition which allows the author to say "[a number in round numbers]" and get verbal descriptions like "a couple of" or "a few" as a result.
|
||||
Description: A new `to say` definition which allows the author to say `"[a number in round numbers]"` and get verbal descriptions like ``a couple of`` or ``a few`` as a result.
|
||||
For: Z-Machine
|
||||
|
||||
Sometimes it is more sensible to describe numbers roughly than in exact terms. For instance, we might want to have our player perceive "many people" rather than "forty-two people" on entering a room. To achieve this, we might write our own "to say" phrase.
|
||||
Sometimes it is more sensible to describe numbers roughly than in exact terms. For instance, we might want to have our player perceive ``many people`` rather than ``forty-two people`` on entering a room. To achieve this, we might write our own `to say` phrase.
|
||||
|
||||
{*}"Ballpark"
|
||||
|
||||
|
|
@ -15,7 +15,7 @@ Sometimes it is more sensible to describe numbers roughly than in exact terms. F
|
|||
say "[approximation entry]";
|
||||
rule succeeds.
|
||||
|
||||
[Phrases] will be explained more thoroughly in a later chapter, but as we have already seen in the examples, we can make a "To say..." phrase that will allow us to create our own text substitutions. In this case, we are going to replace the specific number with a vaguer one chosen from a chart, so:
|
||||
[Phrases] will be explained more thoroughly in a later chapter, but as we have already seen in the examples, we can make a `To say...` phrase that will allow us to create our own text substitutions. In this case, we are going to replace the specific number with a vaguer one chosen from a chart, so:
|
||||
|
||||
{**}Table of Numerical Approximation
|
||||
threshold approximation
|
||||
|
|
@ -27,7 +27,7 @@ Sometimes it is more sensible to describe numbers roughly than in exact terms. F
|
|||
21 "many"
|
||||
1000 "lots and lots of"
|
||||
|
||||
The idea here is that we will work our way through the table until we hit a line where the threshold number is higher than the number we want to express, and then print that output: so if we have less than one item, we'll print "no"; if we have more than none but less than two, we'll print "one"; if we have less than three, we'll print "a couple of"; if we have three, four, or five (but not six), we'll print "a few."
|
||||
The idea here is that we will work our way through the table until we hit a line where the threshold number is higher than the number we want to express, and then print that output: so if we have less than one item, we'll print ``no``; if we have more than none but less than two, we'll print ``one``; if we have less than three, we'll print ``a couple of``; if we have three, four, or five (but not six), we'll print ``a few.``
|
||||
|
||||
{**}A room has a number called the population. The population of a room is usually 0. The description of a room is usually "You observe [population of the location in round numbers] [if population of the location is 1]person [otherwise]people [end if]here.".
|
||||
|
||||
|
|
|
|||
|
|
@ -2,34 +2,28 @@ Example: *** Baritone, Bass
|
|||
Location: Understanding values
|
||||
RecipeLocation: Traits Determined By the Player
|
||||
Index: Allowing the player to describe the main character before starting play
|
||||
Description: Letting the player pick a gender (or perhaps other characteristics) before starting play.
|
||||
Description: Letting the player pick a vocal range (or perhaps other characteristics) before starting play.
|
||||
For: Z-Machine
|
||||
|
||||
[ZL: This example should either be cut or should accept "neither" ]::
|
||||
|
||||
The "reading a command" activity is rather advanced; for the moment, what we need to understand is that we're intervening in commands at the start of play and insisting that the player's first instruction to the game consist of a choice of gender. After that point, the gender will be set and play will proceed as normal.
|
||||
|
||||
In order to do the parsing, we define gender as a kind of value, and give several alternate names to each gender.
|
||||
The `reading a command` activity is rather advanced; for the moment, what we need to understand is that we're intervening in commands at the start of play and insisting that the player's first instruction to the game consist of a choice of vocal range. After that point, it will be set and play will proceed as normal.
|
||||
|
||||
{*}"Baritone, Bass"
|
||||
|
||||
Getting Started is a room.
|
||||
|
||||
Gender is a kind of value. The genders are masculine, feminine, and unknown. Understand "male" or "man" or "M" as masculine. Understand "female" or "woman" or "F" as feminine.
|
||||
|
||||
A person has a gender. The gender of the player is unknown.
|
||||
|
||||
|
||||
Vocal range is a kind of value. The vocal ranges are soprano, mezzosoprano, contralto, countertenor, tenor, baritone, bass, and unknown.
|
||||
|
||||
A person has a vocal range. The vocal range of the player is unknown.
|
||||
|
||||
When play begins:
|
||||
now the command prompt is "Please choose a gender for your character. >".
|
||||
|
||||
After reading a command when the gender of the player is unknown:
|
||||
if the player's command includes "[gender]":
|
||||
now the gender of the player is the gender understood;
|
||||
if the gender of the player is unknown:
|
||||
say "This story requires a selection of male or female. [run paragraph on]";
|
||||
now the command prompt is "Please choose a vocal range for your character. >".
|
||||
|
||||
After reading a command when the vocal range of the player is unknown:
|
||||
if the player's command includes "[vocal range]":
|
||||
now the vocal range of the player is the vocal range understood;
|
||||
if the vocal range of the player is unknown:
|
||||
say "This story requires a selection of vocal range. [run paragraph on]";
|
||||
reject the player's command;
|
||||
if the gender of the player is masculine, now the player is male;
|
||||
if the gender of the player is feminine, now the player is female;
|
||||
say "[line break]Thank you. We now begin...";
|
||||
now the command prompt is ">";
|
||||
move the player to Sandy Beach;
|
||||
|
|
@ -37,21 +31,19 @@ In order to do the parsing, we define gender as a kind of value, and give severa
|
|||
otherwise:
|
||||
say "Sorry, we're not ready to go on yet. [run paragraph on]";
|
||||
reject the player's command.
|
||||
|
||||
|
||||
Sandy Beach is a room.
|
||||
|
||||
Instead of examining the player when the player is female:
|
||||
say "Congratulations, you are a girl!"
|
||||
|
||||
Instead of examining the player when the player is male:
|
||||
say "Congratulations, you are a boy!"
|
||||
|
||||
If we had a whole series of things to ask the player about, we might define a whole series of kinds of value
|
||||
Singing is an action applying to nothing. Understand "sing" as singing.
|
||||
|
||||
The vocal ranges are soprano, mezzosoprano, contralto...
|
||||
Instead of singing:
|
||||
say "You sound off with a glorious [vocal range of the player]!"
|
||||
|
||||
and use a "construction stage" variable to keep track of the current stage of character-construction, as in
|
||||
If we had a whole series of things to ask the player about, we might define a whole series of kinds of value:
|
||||
|
||||
After reading a command when the current construction stage is choosing a vocal range:
|
||||
The hairstyles are quiffed, beehive, bangs...
|
||||
|
||||
and use a `construction stage` variable to keep track of the current stage of character-construction, as in
|
||||
|
||||
After reading a command when the current construction stage is choosing a hairstyle:
|
||||
...
|
||||
|
||||
|
|
|
|||
|
|
@ -5,9 +5,9 @@ Index: GIVE action for other characters
|
|||
Description: Allowing characters other than the player to give objects to one another, accounting for the possibility that some items may not be desired by the intended recipients.
|
||||
For: Z-Machine
|
||||
|
||||
By default, if we make no modifications, telling one player to give something to another will fail, even if persuasion succeeds. This is because the default behaviour of the ``give`` command is interrupted by the "block giving rule" – since in many cases we do not want people to exchange objects freely.
|
||||
By default, if we make no modifications, telling one player to give something to another will fail, even if persuasion succeeds. This is because the default behaviour of the ``GIVE`` command is interrupted by the `block giving rule` – since in many cases we do not want people to exchange objects freely.
|
||||
|
||||
However, suppose that we do want characters to be able to exchange articles freely: we allow persuasion to succeed and turn off the "block giving rule".
|
||||
However, suppose that we do want characters to be able to exchange articles freely: we allow persuasion to succeed and turn off the `block giving rule`.
|
||||
|
||||
{*}"Barter Barter"
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Index: Death message replaced
|
|||
Description: Completely replacing the endgame text and stopping the game without giving the player a chance to restart or restore.
|
||||
For: Z-Machine
|
||||
|
||||
Occasionally, a piece of IF is sufficiently serious that it feels bathetic to offer the player the usual restore-restart-undo-quit options at the end. The following would replace "\*\*\* You have died \*\*\*" with a centered epitaph, then quit the game when the player hits a key.
|
||||
Occasionally, a piece of IF is sufficiently serious that it feels bathetic to offer the player the usual restore-restart-undo-quit options at the end. The following would replace ``*** You have died ***`` with a centered epitaph, then quit the game when the player hits a key.
|
||||
|
||||
This example relies on a standard extension to avoid any fancy programming:
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ In many previous examples, we have sent hapless deities wandering around a map o
|
|||
room-name-length set to 25,
|
||||
room-shape set to "circle".
|
||||
|
||||
This produces a line-and-dot map, where the names of rooms do not appear inside the city-circles, but rather (thanks to "room-name-offset") off to one side. We specify a long room-name-length because we want all the names of the cities spelled out in full; and we make all the elements white because we intend to place them over a black background layer.
|
||||
This produces a line-and-dot map, where the names of rooms do not appear inside the city-circles, but rather (thanks to `room-name-offset`) off to one side. We specify a long room-name-length because we want all the names of the cities spelled out in full; and we make all the elements white because we intend to place them over a black background layer.
|
||||
|
||||
We can then superimpose this on a vector map of Greece and tweak the exact positions of cities a little by hand (in Adobe Illustrator, as it happens, but other programs would also allow this level of editing). The result:
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ Here we've changed the property of the envelope to keep track of the fact that i
|
|||
{**}Instead of searching the desk:
|
||||
say "Further investigation of the desk reveals nothing else suspicious."
|
||||
|
||||
Notice that we have two rules that apply to "searching the desk", but one of them has a more specific set of parameters ("when the envelope is lost"). This means that Inform will consult that rule first and use it if it applies; it will only carry out our plain vanilla "instead of searching the desk" rule when the more restricted rule is not relevant.
|
||||
Notice that we have two rules that apply to `searching the desk`, but one of them has a more specific set of parameters (`when the envelope is lost`). This means that Inform will consult that rule first and use it if it applies; it will only carry out our plain vanilla `instead of searching the desk` rule when the more restricted rule is not relevant.
|
||||
|
||||
{**}Test me with "x envelope / x desk / search desk / look / get envelope / x envelope".
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Example: ** Beekeeper's Apprentice
|
|||
Location: Line breaks and paragraph breaks
|
||||
RecipeLocation: Examining
|
||||
Index: Examining everything at once
|
||||
Description: Making the ``search`` command examine all the scenery in the current location.
|
||||
Description: Making the ``SEARCH`` command examine all the scenery in the current location.
|
||||
For: Z-Machine
|
||||
|
||||
We have to create a suitable action and say what it does, and to repeat what we do through all the scenery items. That needs material from subsequent chapters, but is quite ordinary Inform all the same:
|
||||
|
|
@ -28,12 +28,10 @@ We have to create a suitable action and say what it does, and to repeat what we
|
|||
|
||||
The reason for this example is to show the use of saying `"[run paragraph on]"`. It means we have output such as:
|
||||
|
||||
``` transcript
|
||||
>search
|
||||
hive: The honeycombed hive is all around you, thrumming with life.
|
||||
> SEARCH
|
||||
hive: The honeycombed hive is all around you, thrumming with life.
|
||||
|
||||
honey: Wax-sealed honey has been cached in many of the hexagonal nurseries.
|
||||
```
|
||||
honey: Wax-sealed honey has been cached in many of the hexagonal nurseries.
|
||||
|
||||
Without the running on, the prompts "hive:" and "honey:" would be separated from the descriptions following them, which would look a little odd.
|
||||
Without the running on, the labels ``hive:`` and ``honey:`` would be separated from the descriptions following them, which would look a little odd.
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ Here we want Inform to consult every appropriate attitude rule until it gets to
|
|||
An attitude rule:
|
||||
if the player wears the top hat, she gets angry.
|
||||
|
||||
Now, as we saw, the 'no outcome' result will never be returned and printed as Maggie's reaction, precisely because it is "no outcome". Therefore, we provide a final attitude rule which will give her a default response to all statements:
|
||||
Now, as we saw, the "no outcome" result will never be returned and printed as Maggie's reaction, precisely because it is "no outcome". Therefore, we provide a final attitude rule which will give her a default response to all statements:
|
||||
|
||||
{**}The last attitude rule:
|
||||
she is only mildly annoyed.
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ For: Z-Machine
|
|||
let target be a random pocket which is part of the noun;
|
||||
say "[The target] contains [a list of things in the target]."
|
||||
|
||||
Now we've created the rules that will govern any specific jackets we might happen to put in our game: each one will always have one pocket, which will be able to contain no more than two things. The description of "a list of things" is text with a list, which we will learn about further in a few sections.
|
||||
Now we've created the rules that will govern any specific jackets we might happen to put in our game: each one will always have one pocket, which will be able to contain no more than two things. The description of `a list of things` is text with a list, which we will learn about further in a few sections.
|
||||
|
||||
Next we might want to create the environment and an actual example of the jacket kind:
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Index: DRINKing a potion which then goes away
|
|||
Description: A potion that the player can drink.
|
||||
For: Z-Machine
|
||||
|
||||
Some kinds of game objects – food, for instance – can only sensibly be used once, and should then be destroyed. The ``eat`` command already implements this, but suppose we also had a category of drinkable potions:
|
||||
Some kinds of game objects – food, for instance – can only sensibly be used once, and should then be destroyed. The ``EAT`` command already implements this, but suppose we also had a category of drinkable potions:
|
||||
|
||||
{*}"Beverage Service"
|
||||
|
||||
|
|
|
|||
|
|
@ -37,19 +37,14 @@ Suppose we want a bookshelf with a very large number of books on it. They aren't
|
|||
|
||||
Test me with "south / examine ocd / examine books / examine books / examine plato / n / x hercules / s / x hercules".
|
||||
|
||||
Now if we type ``x hercules`` in the Lounge, we will get
|
||||
Now if we type ``X HERCULES`` in the Lounge, we will get
|
||||
|
||||
``` transcript
|
||||
>x hercules
|
||||
You can't see any such thing.
|
||||
```
|
||||
> X HERCULES
|
||||
You can't see any such thing.
|
||||
|
||||
thanks to our somewhat slovenly implementation of the Lounge scenery; but in the Reading Room,
|
||||
|
||||
``` transcript
|
||||
>x hercules
|
||||
You can't find any such text.
|
||||
```
|
||||
> X HERCULES
|
||||
You can't find any such text.
|
||||
|
||||
In practice we might also want to extend our coverage somewhat to handle a case where the player tried to take books from the bookshelf: currently that would not be understood.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Index: Checking for missed properties
|
|||
Description: Testing to make sure that all objects have been given descriptions.
|
||||
For: Z-Machine
|
||||
|
||||
It may occasionally be useful to check whether all objects in our game have a given property. Here we have a "not for release" section that will run at the start of the game and alert us to any objects lacking description:
|
||||
It may occasionally be useful to check whether all objects in our game have a given property. Here we have a `not for release` section that will run at the start of the game and alert us to any objects lacking description:
|
||||
|
||||
{*}"Bic"
|
||||
|
||||
|
|
|
|||
|
|
@ -61,5 +61,5 @@ In a fuller implementation of this game, we might make it possible to get by the
|
|||
resume the story;
|
||||
try looking.
|
||||
|
||||
"If the player consents" is just a convenient way to ask a yes/no question that the player must answer before going on with the game.
|
||||
`If the player consents` is just a convenient way to ask a yes/no question that the player must answer before going on with the game.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,9 +5,9 @@ Index: Blanking the status line before play
|
|||
Description: Emptying the status line during the first screen of the game.
|
||||
For: Z-Machine
|
||||
|
||||
Occasionally we want to print something as our first screen and then pause the game. By default, Inform will print a rather odd status line, with "You" on the left side and "0" on the right. This is because the left hand status line is set to display the location, but (because we're not done with the when-play-begins rules) the player has not yet even been moved to a room.
|
||||
Occasionally we want to print something as our first screen and then pause the game. By default, Inform will print a rather odd status line, with ``You`` on the left side and ``0`` on the right. This is because the left hand status line is set to display the location, but (because we're not done with the when-play-begins rules) the player has not yet even been moved to a room.
|
||||
|
||||
We can tidy this up in the "starting the virtual machine" activity, by temporarily changing the status line content. We will not provide game-pausing code here, because that is easily done by extension; so:
|
||||
We can tidy this up in the `starting the virtual machine` activity, by temporarily changing the status line content. We will not provide game-pausing code here, because that is easily done by extension; so:
|
||||
|
||||
{*}"Blankness"
|
||||
|
||||
|
|
|
|||
|
|
@ -2,10 +2,10 @@ Example: * Blink
|
|||
Location: To say one of
|
||||
RecipeLocation: Varying What Is Written
|
||||
Index: Creating our own text variations rules
|
||||
Description: Making a "by atmosphere" token, allowing us to design our own text variations such as "[one of]normal[or]gloomy[or]scary[by atmosphere]".
|
||||
Description: Making a `by atmosphere` token, allowing us to design our own text variations such as `"[one of]normal[or]gloomy[or]scary[by atmosphere]"`.
|
||||
For: Z-Machine
|
||||
|
||||
Suppose we are writing a game in which the mood of the piece changes, and we would like to have lots of descriptions that vary according to its current state. We might in that case want to create our own "by atmosphere" token, to control text variations, like this:
|
||||
Suppose we are writing a game in which the mood of the piece changes, and we would like to have lots of descriptions that vary according to its current state. We might in that case want to create our own `"[by atmosphere]"` token, to control text variations, like this:
|
||||
|
||||
{*}"Blink"
|
||||
|
||||
|
|
@ -17,7 +17,7 @@ Suppose we are writing a game in which the mood of the piece changes, and we wou
|
|||
To say by atmosphere -- ending say_one_of with marker I7_SOO_ATM:
|
||||
(- {-close-brace} -).
|
||||
|
||||
Since we're operating within the untyped Inform 6, we can make use of the fact that kinds of value are (internally) just constants, enumerated in the same order in which they were originally defined. In other words, "normal" at the I6 level translates to 1, "melancholy" to 2, and "creepy" to 3; so we can return the value of the current atmosphere, and thereby select option 1, 2, or 3:
|
||||
Since we're operating within the untyped Inform 6, we can make use of the fact that kinds of value are (internally) just constants, enumerated in the same order in which they were originally defined. In other words, `normal` at the I6 level translates to 1, `melancholy` to 2, and `creepy` to 3; so we can return the value of the current atmosphere, and thereby select option 1, 2, or 3:
|
||||
|
||||
{**}Include (-
|
||||
Global current_atmosphere = 1;
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Example: * Bosch
|
|||
Location: Stored actions
|
||||
RecipeLocation: Scoring
|
||||
Index: FULL SCORE using a list of stored actions
|
||||
Description: Creating a list of actions that will earn the player points, and using this both to change the score and to give ``full score`` reports.
|
||||
Description: Creating a list of actions that will earn the player points, and using this both to change the score and to give ``FULL SCORE`` reports.
|
||||
For: Z-Machine
|
||||
|
||||
We could, if we wanted, make a table of stored actions all of which represent things that will earn points for the player. For instance:
|
||||
|
|
@ -46,5 +46,5 @@ We could, if we wanted, make a table of stored actions all of which represent th
|
|||
|
||||
Test me with "eat lily / w / full score / get leaf / full".
|
||||
|
||||
This system is tidy, but limited: we cannot give actions interesting names in the score list, like "seducing the pirate's daughter" or "collecting a valuable artifact". So it will not be ideal in all situations, but it has the virtue of being easy to extend, and of listing all of the player's successes in the order in which they occurred in their play-through.
|
||||
This system is tidy, but limited: we cannot give actions interesting names in the score list, like `seducing the pirate's daughter` or `collecting a valuable artifact`. So it will not be ideal in all situations, but it has the virtue of being easy to extend, and of listing all of the player's successes in the order in which they occurred in their play-through.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ For: Z-Machine
|
|||
|
||||
Scenes can have properties – a fact that is very useful when it comes to writing a series of scenes that all need to act alike in some respect.
|
||||
|
||||
Suppose we have a plot that features a number of scripted scenes, where we need the player to stand still and wait while the events of the scene play out. One way to set this up is to create a property for such scenes – let's call them "restricted" – and then write a rule that keeps the player in place while the scene happens:
|
||||
Suppose we have a plot that features a number of scripted scenes, where we need the player to stand still and wait while the events of the scene play out. One way to set this up is to create a property for such scenes – let's call them `restricted` – and then write a rule that keeps the player in place while the scene happens:
|
||||
|
||||
{*}"Bowler Hats and Baby Geese"
|
||||
|
||||
|
|
|
|||
|
|
@ -2,16 +2,16 @@ Example: ** Bribery
|
|||
Location: New rules
|
||||
RecipeLocation: Barter and Exchange
|
||||
Index: GIVE command extended
|
||||
Description: A ``give`` command that gets rid of Inform's default refusal message in favor of something a bit more sophisticated.
|
||||
Description: A ``GIVE`` command that gets rid of Inform's default refusal message in favor of something a bit more sophisticated.
|
||||
For: Z-Machine
|
||||
|
||||
If we want to rewrite the functionality of a command that usually ends with a "block..." rule, we will have to begin by turning the blocking off.
|
||||
If we want to rewrite the functionality of a command that usually ends with a `block...` rule, we will have to begin by turning the blocking off.
|
||||
|
||||
{*}"Bribery"
|
||||
|
||||
The block giving rule is not listed in the check giving it to rules.
|
||||
|
||||
As it happens, correct behaviour is built into the ``give`` command once "block giving" is turned off, so we do not have to write a replacement report or carry-out rule; the object will be transferred to the possession of the caterpillar. But we do want to adjust the action just a little so that our gift cheers up the recipient:
|
||||
As it happens, correct behaviour is built into the ``GIVE`` command once the `block giving rule` is turned off, so we do not have to write a replacement report or carry-out rule; the object will be transferred to the possession of the caterpillar. But we do want to adjust the action just a little so that our gift cheers up the recipient:
|
||||
|
||||
{**}Carry out giving (this is the gratitude for gifts rule): improve the mood of the second noun.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ For: Z-Machine
|
|||
After examining something when the label is part of the noun:
|
||||
say "A bright red sticky label is attached to [the noun]!"
|
||||
|
||||
Here is the essential point: whenever we ``attach label to`` something, it becomes part of that object.
|
||||
Here is the essential point: whenever we ``ATTACH LABEL TO`` something, it becomes part of that object.
|
||||
|
||||
{**}Instead of tying the red sticky label to something:
|
||||
now the red sticky label is part of the second noun;
|
||||
|
|
@ -50,7 +50,7 @@ Much of the rest is just tidying to make sure that the player's commands are red
|
|||
|
||||
Understand the commands "stick" or "apply" as "tie".
|
||||
|
||||
We could have created a new "sticking" action, but to keep the example short we will use the built-in "tying" action instead, and respond to the command ``stick`` just as if it were ``tie``.
|
||||
We could have created a new `sticking` action, but to keep the example short we will use the built-in `tying it to` action instead, and respond to the command ``STICK`` just as if it were ``TIE``.
|
||||
|
||||
{**}Understand "peel [something]" or "peel off [something]" as taking.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,11 +5,11 @@ Index: Lighting and relighting a candle
|
|||
Description: A candle which reacts to lighting and blowing actions differently depending on whether it has already been lit once.
|
||||
For: Z-Machine
|
||||
|
||||
"Sire," said the Minister of the Interior to Napoleon, "yesterday I saw the most intrepid man in your Empire." - "What man is that?" said the Emperor brusquely, "and what has he done?" - "He wants to do something, Sire." - "What is it?" - "To visit the sewers of Paris."
|
||||
|
||||
This man existed and his name was Bruneseau.
|
||||
|
||||
- Victor Hugo, Les Miserables
|
||||
> "Sire," said the Minister of the Interior to Napoleon, "yesterday I saw the most intrepid man in your Empire." - "What man is that?" said the Emperor brusquely, "and what has he done?" - "He wants to do something, Sire." - "What is it?" - "To visit the sewers of Paris."
|
||||
>
|
||||
> This man existed and his name was Bruneseau.
|
||||
>
|
||||
> - Victor Hugo, Les Miserables
|
||||
|
||||
Let's say that our intrepid explorer has a candle that can be lit and blown out again, and should accordingly appear unlit, burning, or partly burnt:
|
||||
|
||||
|
|
@ -47,5 +47,5 @@ Let's say that our intrepid explorer has a candle that can be lit and blown out
|
|||
|
||||
Test me with "x candle / light candle / x candle / blow out candle / x candle".
|
||||
|
||||
We must be careful: "if the noun was lit" would throw errors because past-tense rules can only be applied to specific items, not to variables that could be anything.
|
||||
We must be careful: `if the noun was lit` would throw errors because past-tense rules can only be applied to specific items, not to variables that could be anything.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Now we build in the instruction for what Inform should say if the player tries t
|
|||
if the count of exits is 1, say "From here, the only way out is [list of viable directions].";
|
||||
otherwise say "From here, the viable exits are [list of viable directions]."
|
||||
|
||||
There is no theoretical reason why we have to define "count of exits" here: we could, if we wanted, just say "if the number of viable directions is 0", "if the number of viable directions is 1", and so on. However, each calculation of a "viable direction" takes a bit of computing power, so there is some slight savings in not requiring the game to count viable directions more than once in this routine.
|
||||
There is no theoretical reason why we have to define `count of exits` here: we could, if we wanted, just say `if the number of viable directions is 0`, `if the number of viable directions is 1`, and so on. However, each calculation of a `viable direction` takes a bit of computing power, so there is some slight savings in not requiring the game to count viable directions more than once in this routine.
|
||||
|
||||
{**}Dome is a room. North of Dome is North Chapel. South of the Dome is South Chapel. West of the Dome is Western End. Quiet Corner is northwest of the Dome, north of Western End, and west of North Chapel. Loud Corner is east of North Chapel, northeast of Dome, and north of Eastern End. Eastern End is north of Dim Corner and east of Dome. Dim Corner is southeast of Dome and east of South Chapel. Ruined Corner is southwest of Dome, west of South Chapel, and south of Western End.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ For: Z-Machine
|
|||
say "It looks as if [the DK] was the death knell for [the victim], who looks startled, then nonexistent.";
|
||||
now the victim is nowhere.
|
||||
|
||||
If we leave it at that, then pulling the cactus will kill Luckless Luke but then say "Nothing obvious happens.", which seems like a bit of an anti-climax. So we add a special case response for that one:
|
||||
If we leave it at that, then pulling the cactus will kill Luckless Luke but then say ``Nothing obvious happens.``, which seems like a bit of an anti-climax. So we add a special case response for that one:
|
||||
|
||||
{**}After pulling the cactus when Luckless Luke was in the location:
|
||||
say "That's a real shame."
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ For: Z-Machine
|
|||
|
||||
Camp Bethel Kitchen is a room.
|
||||
|
||||
One use for text alternatives is to change the description of a room after first visiting. We've already seen, in the example [Slightly Wrong], how to do this with "[if visited] ... [otherwise] ... [end if]". But since the first description is printed once and the second description on all subsequent occasions, we could equally well write
|
||||
One use for text alternatives is to change the description of a room after first visiting. We've already seen, in the example [Slightly Wrong], how to do this with `"[if visited] ... [otherwise] ... [end if]"`. But since the first description is printed once and the second description on all subsequent occasions, we could equally well write
|
||||
|
||||
{**}The description of Camp Kitchen is "[one of]You've never been into the kitchen before, though you've spent many an hour in the dining lodge. The place is larger than you would have expected, and it has none of the fake rustic touches of the rest of the camp[or]A tidy, efficient industrial kitchen, without any of the kitsch rusticity found elsewhere[stopping]."
|
||||
|
||||
|
|
@ -27,9 +27,9 @@ Jeremy is following a sequence of actions to do an implied task (still somewhat
|
|||
|
||||
A housefly is an animal in the Camp Bethel Kitchen. "A large housefly [one of]lands on a countertop[or]flies around noisily[or]circles Jeremy's chef hat[at random]."
|
||||
|
||||
The housefly's description is merely "at random" rather than "purely at random" because we want to show it doing a different thing each turn, whereas Fluffy could plausibly stare out the window for five turns in a row.
|
||||
The housefly's description is merely `at random` rather than `purely at random` because we want to show it doing a different thing each turn, whereas Fluffy could plausibly stare out the window for five turns in a row.
|
||||
|
||||
There are more complex ways to change and override the initial descriptions of people and things; if text alternatives do not get us far enough, we can turn to the "rule for writing a paragraph about," documented in the [Activities] chapter.
|
||||
There are more complex ways to change and override the initial descriptions of people and things; if text alternatives do not get us far enough, we can turn to the `rule for writing a paragraph about` documented in the [Activities] chapter.
|
||||
|
||||
Another frequent use of text alternatives is to give characters a bit of variety in things they're likely to say many times in the course of a game:
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ As the descriptions make clear, the ferris wheel should be visible from everywhe
|
|||
|
||||
as it normally would.
|
||||
|
||||
Now, by default, if the player were to type ``touch ferris wheel`` while in another room, the story would respond
|
||||
Now, by default, if the player were to type ``TOUCH FERRIS WHEEL`` while in another room, the story would respond
|
||||
|
||||
You can't reach into By the Wheel.
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ This may not be quite what we want, but we can replace this text with our own re
|
|||
say "You can only look from this distance.";
|
||||
deny access.
|
||||
|
||||
And because our accessibility rules are considered before the "Instead" phase, we can write the following rule confident that it will apply only when the player is in fact in range to touch the ferris wheel:
|
||||
And because our accessibility rules are considered before the `Instead` phase, we can write the following rule confident that it will apply only when the player is in fact in range to touch the ferris wheel:
|
||||
|
||||
{**}Instead of touching the ferris wheel:
|
||||
say "You don't dare: it's spinning too fast."
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ First we create the concept of facts, and the idea that facts can make some thin
|
|||
|
||||
Definition: a fact is interesting if it is unknown and it is ready to learn.
|
||||
|
||||
Now, we also need a way to tell Inform to introduce certain new facts when the right previous ones have been introduced. We'll create a "following" relation, according to which a new fact can be told to the player when the player has already learned all the facts it follows. This way, we can simulate the effect of putting together several pieces of evidence to come to a conclusion:
|
||||
Now, we also need a way to tell Inform to introduce certain new facts when the right previous ones have been introduced. We'll create a `following` relation, according to which a new fact can be told to the player when the player has already learned all the facts it follows. This way, we can simulate the effect of putting together several pieces of evidence to come to a conclusion:
|
||||
|
||||
{**}Following relates various facts to various facts. The verb to follow means the following relation.
|
||||
|
||||
|
|
@ -51,7 +51,7 @@ Next we need a way for the game to introduce these new facts. Let's say we want
|
|||
let chosen fact be a random interesting fact which is conveyed by the item;
|
||||
say "[chosen fact][paragraph break]".
|
||||
|
||||
The "after choosing notable locale objects" line here handles things so that any interesting conclusions we want to draw are always given first, followed by the less interesting description.
|
||||
The `after choosing notable locale objects` line here handles things so that any interesting conclusions we want to draw are always given first, followed by the less interesting description.
|
||||
|
||||
And finally, we need to give the player a little evidence to piece together:
|
||||
|
||||
|
|
|
|||
|
|
@ -5,17 +5,17 @@ Index: Modifying and re-parsing an entered command
|
|||
Description: Determining that the command the player typed is invalid, editing it, and re-examining it to see whether it now reads correctly.
|
||||
For: Z-Machine
|
||||
|
||||
Novice players of interactive fiction, unfamiliar with its conventions, will often try to add extra phrases to a command that the game cannot properly parse: ``hit door with fist``, for instance, instead of ``hit door``.
|
||||
Novice players of interactive fiction, unfamiliar with its conventions, will often try to add extra phrases to a command that the game cannot properly parse: ``HIT DOOR WITH FIST``, for instance, instead of ``HIT DOOR``.
|
||||
|
||||
While we can deal with some of these instances by expanding our range of actions, at some point it becomes impossible to account for all the possible prepositional phrases that the player might want to tack on. So what do we do if we want to handle those appended bits of text sensibly?
|
||||
|
||||
We could go through and remove any piece of text containing "with ..." from the end of a player's command; the problem with that is that it overzealously lops off the ends of valid commands like ``unlock door with key``, as well. So clearly we don't want to do this as part of the "After reading a command..." stage.
|
||||
We could go through and remove any piece of text containing `with ...` from the end of a player's command; the problem with that is that it overzealously lops off the ends of valid commands like ``UNLOCK DOOR WITH KEY``, as well. So clearly we don't want to do this as part of the `After reading a command...` stage.
|
||||
|
||||
A better time to cut off the offending text is right before issuing a parser error. At that point, Inform has already determined that it definitely cannot parse the instruction as given, so we know that there's something wrong with it.
|
||||
|
||||
The next problem, though, is that after we've edited the player's text we want to feed the corrected version back to Inform and try once more to interpret it.
|
||||
|
||||
This is where we have a valid reason to write a new "rule for reading a command". We will tell Inform that when we have just corrected the player's input to something new, it should not ask for a new command (by printing a prompt and waiting for another line of input); it should instead paste our stored corrected command back into "the player's command" and proceed as though that new text had just been typed.
|
||||
This is where we have a valid reason to write a new `rule for reading a command`. We will tell Inform that when we have just corrected the player's input to something new, it should not ask for a new command (by printing a prompt and waiting for another line of input); it should instead paste our stored corrected command back into `the player's command` and proceed as though that new text had just been typed.
|
||||
|
||||
Thanks to John Clemens for the specifics of the implementation.
|
||||
|
||||
|
|
@ -51,5 +51,5 @@ Thanks to John Clemens for the specifics of the implementation.
|
|||
|
||||
Test me with "attack troll with sword / unlock chest with sword / attack troll as a test".
|
||||
|
||||
A caveat about using this method in a larger game: "parser error flag" will not automatically control the behaviour of any rules we might have written for Before reading a command... or After reading a command..., so they may now fire at inappropriate times. It is a good idea to check for parser error flag in those rules as well.
|
||||
A caveat about using this method in a larger game: `parser error flag` will not automatically control the behaviour of any rules we might have written for Before reading a command... or After reading a command..., so they may now fire at inappropriate times. It is a good idea to check for parser error flag in those rules as well.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,9 +5,7 @@ Index: Status line with centered text, the easy way
|
|||
Description: Replacing the two-part status line with one that centers only the room name at the top of the screen.
|
||||
For: Z-Machine
|
||||
|
||||
[ZL: "included as part of the standard distribution..."]::
|
||||
|
||||
If we want to lay out the status line in some other way than with left-hand and right-hand entries, it is possible to do this as well. Later we will learn about the "rule for constructing the status line", but here is a basic effect using this rule and an Inform extension included as part of the standard distribution, called Basic Screen Effects.
|
||||
If we want to lay out the status line in some other way than with left-hand and right-hand entries, it is possible to do this as well. Later we will learn about the `rule for constructing the status line`, but here is a basic effect using this rule and an Inform extension called Basic Screen Effects.
|
||||
|
||||
{*}"Centered"
|
||||
|
||||
|
|
|
|||
|
|
@ -11,9 +11,9 @@ Suppose we want to allow the player to go to sleep some of the time:
|
|||
|
||||
A person is either awake or asleep. A person is usually awake.
|
||||
|
||||
The important thing to note here is that it does not work to say "the player is either asleep or awake". This is because the player is not necessarily one specific person or thing during the game: the identity of the player can be changed, as we will see later.
|
||||
The important thing to note here is that it does not work to say `the player is either asleep or awake`. This is because the player is not necessarily one specific person or thing during the game: the identity of the player can be changed, as we will see later.
|
||||
|
||||
So if we want to make rules about the properties of the player, we should attach these rules to the "person" kind.
|
||||
So if we want to make rules about the properties of the player, we should attach these rules to the `person` kind.
|
||||
|
||||
{**}Linear Algebra Class is a room. "The blackboard is covered with square arrangements of numbers. These are supposed to convey something to you, but mostly you're finding them soporific."
|
||||
|
||||
|
|
|
|||
|
|
@ -7,8 +7,8 @@ For: Z-Machine
|
|||
|
||||
We might want to allow every television to be tuned to a channel (a number property) which the player could refer to, so that
|
||||
|
||||
- ``watch channel 13``
|
||||
- ``turn off channel 4``
|
||||
- ``WATCH CHANNEL 13``
|
||||
- ``TURN OFF CHANNEL 4``
|
||||
|
||||
would be directed to the appropriate television object, if any television is turned on and tuned to the correct station. We might now write:
|
||||
|
||||
|
|
|
|||
|
|
@ -5,13 +5,11 @@ Index: Channel 2. Television with more advanced parsing
|
|||
Description: Understanding channels (a number) in the names of televisions, with more sophisticated parsing of the change channel action.
|
||||
For: Z-Machine
|
||||
|
||||
[ZL: I took more liberties here than usual; please review.]::
|
||||
|
||||
Our previous implementation of televisions ([Channel 1]) doesn't accept ``tune fifties television to channel 4``; neither does it deal with player input like ``tune to channel 4 on fifties television``, nor ``tune to channel 4`` where no television is specified.
|
||||
Our previous implementation of televisions ([Channel 1]) doesn't accept ``TUNE FIFTIES TELEVISION TO CHANNEL 4``; neither does it deal with player input like ``TUNE TO CHANNEL 4 ON FIFTIES TELEVISION``, nor ``TUNE TO CHANNEL 4`` where no television is specified.
|
||||
|
||||
When we are designing commands which involve two elements (here, a television and a channel number), it's usually a good idea to allow the player to specify those elements in either order, as we saw demonstrated briefly in [New commands for old grammar].
|
||||
|
||||
We might, therefore, want to add a few refinements: first by defining a `"[channel]"` token that will accept input of the forms `"[number]"` and "channel [number]", and second by creating some additional "Understand" lines that will accept variant versions of the player's input.
|
||||
We might, therefore, want to add a few refinements: first by defining a `"[channel]"` token that will accept input of the forms `"[number]"` and "channel [number]", and second by creating some additional `Understand` lines that will accept variant versions of the player's input.
|
||||
|
||||
{*}"Channel 2"
|
||||
|
||||
|
|
|
|||
|
|
@ -2,12 +2,12 @@ Example: *** Cheese-makers
|
|||
Location: Why are scenes designed this way?
|
||||
RecipeLocation: Saying Complicated Things
|
||||
Index: TALK TO command used with scenes
|
||||
Description: Scenes used to control the way a character reacts to conversation and comments, using a ``talk to`` command.
|
||||
Description: Scenes used to control the way a character reacts to conversation and comments, using a ``TALK TO`` command.
|
||||
For: Z-Machine
|
||||
|
||||
As we have seen, there are a number of different ways of controlling conversation in interactive fiction, and the best choice of way will depend quite a lot on what kind of work we're writing.
|
||||
|
||||
One common model is to replace Inform's default ``ask`` and ``tell`` commands with a ``talk to`` command. This gives the player less control than they would otherwise have: instead of asking a character about any topic under the sun, they're restricted to seeing (or not seeing) a single sequence of text that the author has written in advance. On the other hand, such a system is harder for the player to break (since they can never ask about a topic that the author hasn't implemented), and easier for the author to tie into plot developments. If we give ``talk to`` different output at each scene, we get conversation that is always tied to the current state of the plot.
|
||||
One common model is to replace Inform's default ``ASK`` and ``TELL`` commands with a ``TALK TO`` command. This gives the player less control than they would otherwise have: instead of asking a character about any topic under the sun, they're restricted to seeing (or not seeing) a single sequence of text that the author has written in advance. On the other hand, such a system is harder for the player to break (since they can never ask about a topic that the author hasn't implemented), and easier for the author to tie into plot developments. If we give ``TALK TO`` different output at each scene, we get conversation that is always tied to the current state of the plot.
|
||||
|
||||
This is a design approach that works best in a game with a large number of short, focused scenes. For other kinds of conversation system design, compare the other examples listed in the Recipe Book.
|
||||
|
||||
|
|
@ -15,7 +15,7 @@ This is a design approach that works best in a game with a large number of short
|
|||
|
||||
Chapter 1 - Replacing old talk commands and making a new one
|
||||
|
||||
Here, using some techniques that will be discussed in the chapter on [Understanding], we get rid of Inform's default handling of ``ask`` and ``tell``, and create our own ``talk to`` action instead:
|
||||
Here, using some techniques that will be discussed in the chapter on [Understanding], we get rid of Inform's default handling of ``ASK`` and ``TELL``, and create our own ``TALK TO`` action instead:
|
||||
|
||||
{**}Understand the commands "ask" and "tell" and "say" and "answer" as something new.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Index: Hints leading the player through conversation
|
|||
Description: Using name-printing rules to keep track of whether the player knows about objects, and also to highlight things they might want to follow up.
|
||||
For: Z-Machine
|
||||
|
||||
Suppose we have a conversation system in which it is important to keep track of which subjects the player has heard mentioned. If we're careful to mark subjects in brackets, we can use the "printing the name of" activity to record which things have been mentioned so far:
|
||||
Suppose we have a conversation system in which it is important to keep track of which subjects the player has heard mentioned. If we're careful to mark subjects in brackets, we can use the `printing the name of` activity to record which things have been mentioned so far:
|
||||
|
||||
{*}"Chronic Hinting Syndrome"
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Index: Using lists as rings
|
|||
Description: Retrieving items from an airport luggage carousel is such fun, how can we resist simulating it, using a list as a ring buffer?
|
||||
For: Z-Machine
|
||||
|
||||
The only point we need to be careful about is that the carousel is simulated twice over, in the following text: once in the built-in way that objects are inside other objects, so that the luggage items are objects contained in the carousel object; but then again by the "circle of misery" list, a ring buffer keeping track of what order things are in. We need to be careful that these two records do not fall out of synchrony: anything put into the carousel must be added to the list, anything taken out must be removed. (In fact we forbid things to be added, for simplicity's sake.)
|
||||
The only point we need to be careful about is that the carousel is simulated twice over, in the following text: once in the built-in way that objects are inside other objects, so that the luggage items are objects contained in the carousel object; but then again by the `circle of misery` list, a ring buffer keeping track of what order things are in. We need to be careful that these two records do not fall out of synchrony: anything put into the carousel must be added to the list, anything taken out must be removed. (In fact we forbid things to be added, for simplicity's sake.)
|
||||
|
||||
{*}"Circle Of Misery"
|
||||
|
||||
|
|
|
|||
|
|
@ -5,11 +5,11 @@ Index: Photographs referred to by subject matter
|
|||
Description: An instant camera that spits out photographs of anything the player chooses to take a picture of.
|
||||
For: Z-Machine
|
||||
|
||||
We start by creating a camera and a photograph object. As usual when we want to have a kind of object that can be dispensed in bulk, we start off with a bunch of identical instances of the object out of play (in this case, kept in an out-of-play container called "film roll"); we can then move them into play and give them characteristics when they're needed.
|
||||
We start by creating a camera and a photograph object. As usual when we want to have a kind of object that can be dispensed in bulk, we start off with a bunch of identical instances of the object out of play (in this case, kept in an out-of-play container called `film roll`); we can then move them into play and give them characteristics when they're needed.
|
||||
|
||||
Each photograph can depict exactly one thing – we're assuming that the player is not a landscape photographer here – so we create a relation to indicate what is shown by each photograph. We'll then use that relation to determine how photographs are described, named, and parsed:
|
||||
|
||||
{*}"Claims Adjustment"
|
||||
{*}`Claims Adjustment`
|
||||
|
||||
A photograph is a kind of thing. 36 photographs are in the film roll.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Index: Standard IF demonstration
|
|||
Description: Implementation of "Cloak of Darkness", a simple example game that for years has been used to demonstrate the features of IF languages.
|
||||
For: Z-Machine
|
||||
|
||||
"Cloak of Darkness" is a brief example game that has been implemented in nearly every IF system currently used. It hasn't got much claim to complexity or richness, but it does exemplify many of the standard things one might want an IF language to be able to do: define descriptions and the results of actions, assign synonyms to nouns, create new verbs, handle darkness, track repeated acts, and so on.
|
||||
_Cloak of Darkness_ is a brief example game that has been implemented in nearly every IF system currently used. It hasn't got much claim to complexity or richness, but it does exemplify many of the standard things one might want an IF language to be able to do: define descriptions and the results of actions, assign synonyms to nouns, create new verbs, handle darkness, track repeated acts, and so on.
|
||||
|
||||
Here is what the game looks like in Inform:
|
||||
|
||||
|
|
@ -23,13 +23,13 @@ Whatever room we define first becomes the starting room of the game, in the abse
|
|||
|
||||
Instead of going north in the Foyer, say "You've only just arrived, and besides, the weather outside seems to be getting worse."
|
||||
|
||||
We can add more rooms by specifying their relation to the first room. Unless we say otherwise, the connection will automatically be bidirectional, so "The Cloakroom is west of the Foyer" will also mean "The Foyer is east of the Cloakroom":
|
||||
We can add more rooms by specifying their relation to the first room. Unless we say otherwise, the connection will automatically be bidirectional, so `The Cloakroom is west of the Foyer` will also mean `The Foyer is east of the Cloakroom`:
|
||||
|
||||
{**}The Cloakroom is west of the Foyer. "The walls of this small room were clearly once lined with hooks, though now only one remains. The exit is a door to the east."
|
||||
|
||||
In the Cloakroom is a supporter called the small brass hook. The hook is scenery. Understand "peg" as the hook.
|
||||
|
||||
Inform will automatically understand any words in the object definition ("small", "brass", and "hook", in this case), but we can add extra synonyms with this sort of Understand command.
|
||||
Inform will automatically understand any words in the object definition (``SMALL``, ``BRASS``, and ``HOOK``, in this case), but we can add extra synonyms with this sort of Understand command.
|
||||
|
||||
{**}The description of the hook is "It's just a small brass hook, [if something is on the hook]with [a list of things on the hook] hanging on it[otherwise]screwed to the wall[end if]."
|
||||
|
||||
|
|
@ -41,7 +41,7 @@ This description is general enough that, if we were to add other hangable items
|
|||
|
||||
Neatness is a kind of value. The neatnesses are neat, scuffed, and trampled. The message has a neatness. The message is neat.
|
||||
|
||||
We could if we wished use a number to indicate how many times the player has stepped on the message, but Inform also makes it easy to add descriptive properties of this sort, so that the code remains readable even when the reader does not know what "the number of the message" might mean.
|
||||
We could if we wished use a number to indicate how many times the player has stepped on the message, but Inform also makes it easy to add descriptive properties of this sort, so that the code remains readable even when the reader does not know what `the number of the message` might mean.
|
||||
|
||||
{**}Instead of examining the message:
|
||||
increment score;
|
||||
|
|
@ -91,5 +91,5 @@ This defines an object which is worn at the start of play. Because we have said
|
|||
|
||||
Test me with "s / n / w / inventory / hang cloak on hook / e / s / read message".
|
||||
|
||||
And that's all. As always, type ``test me`` to watch the scenario play itself out.
|
||||
And that's all. As always, type ``TEST ME`` to watch the scenario play itself out.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,15 +5,15 @@ Index: Adverbs used in commands
|
|||
Description: Accepting adverbs anywhere in a command, registering what the player typed but then cutting them out before interpreting the command.
|
||||
For: Z-Machine
|
||||
|
||||
It has sometimes been suggested that IF should allow for the player to use adverbs, so that doing something "carefully" will have a different effect from doing it "quickly". There are several inherent challenges here: it's a good idea to make very sure the player knows all their adverb options, and the list of possibilities should probably not be too long.
|
||||
It has sometimes been suggested that IF should allow for the player to use adverbs, so that doing something ``CAREFULLY`` will have a different effect from doing it ``QUICKLY``. There are several inherent challenges here: it's a good idea to make very sure the player knows all their adverb options, and the list of possibilities should probably not be too long.
|
||||
|
||||
Another trick is that adverbs complicate understanding commands, because they can occur anywhere: one might type ``go west carefully`` or ``carefully go west``, and ideally the game should understand both. After reading a command is the best point to do this sort of thing, because we can find adverbs, interpret them, and remove them from the command stream. So:
|
||||
Another trick is that adverbs complicate understanding commands, because they can occur anywhere: one might type ``GO WEST CAREFULLY`` or ``CAREFULLY GO WEST``, and ideally the game should understand both. After reading a command is the best point to do this sort of thing, because we can find adverbs, interpret them, and remove them from the command stream. So:
|
||||
|
||||
{*}"Cloves"
|
||||
|
||||
Manner is a kind of value. The manners are insouciantly, sheepishly, and defiantly.
|
||||
|
||||
Now we have, automatically, a value called manner understood to be used whenever parsing manners, and we can use this even during the "after reading a command" stage, so:
|
||||
Now we have, automatically, a value called manner understood to be used whenever parsing manners, and we can use this even during the `after reading a command` stage, so:
|
||||
|
||||
{**}After reading a command:
|
||||
if the player's command includes "[manner]":
|
||||
|
|
@ -59,5 +59,5 @@ Now we have, automatically, a value called manner understood to be used whenever
|
|||
|
||||
The qualification about turn count is to prevent this before message from occurring when the player first looks around the room (automatically) at the start of play.
|
||||
|
||||
Note that to test this example, one must type ``insouciantly test me``, and not simply ``test me``: a poseur's work is never done.
|
||||
Note that to test this example, one must type ``INSOUCIANTLY TEST ME``, and not simply ``TEST ME``: a poseur's work is never done.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Index: Murderer chosen randomly at start of play
|
|||
Description: A murderer for the mystery is selected randomly at the beginning of the game.
|
||||
For: Z-Machine
|
||||
|
||||
"When play begins" is the best point to initialise any aspects of the game that are meant to change between playings. For instance, in this scenario, we would randomly select one of the other characters to be guilty of murder:
|
||||
`When play begins` is the best point to initialise any aspects of the game that are meant to change between playings. For instance, in this scenario, we would randomly select one of the other characters to be guilty of murder:
|
||||
|
||||
{*}"Clueless"
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Index: Conversation based on keyword recognition
|
|||
Description: A character who responds to keywords in the player's instructions and remarks, even if there are other words included.
|
||||
For: Z-Machine
|
||||
|
||||
The "reading a command" activity is not the only point at which we can interact with snippets, as it happens; it is merely the most useful. "The player's command" can be consulted at other points, however, as in this example of your somewhat deaf (or distracted, or simply cussed) Aunt:
|
||||
The `reading a command` activity is not the only point at which we can interact with snippets, as it happens; it is merely the most useful. `The player's command` can be consulted at other points, however, as in this example of your somewhat deaf (or distracted, or simply cussed) Aunt:
|
||||
|
||||
{*}"Complimentary Peanuts"
|
||||
|
||||
|
|
@ -16,7 +16,7 @@ The "reading a command" activity is not the only point at which we can interact
|
|||
rule succeeds;
|
||||
say "'Hmmf,' says Aunt Martha."
|
||||
|
||||
The topic understood is also a snippet, so that whenever one has been generated, we can treat it in the same way as "the player's command":
|
||||
The topic understood is also a snippet, so that whenever one has been generated, we can treat it in the same way as `the player's command`:
|
||||
|
||||
{**}Asking someone about something is speech.
|
||||
Telling someone about something is speech.
|
||||
|
|
@ -30,7 +30,7 @@ The topic understood is also a snippet, so that whenever one has been generated,
|
|||
rule succeeds;
|
||||
say "'Hmmf,' says Aunt Martha."
|
||||
|
||||
This is superior to checking "the player's command" because we do not want ``ask martha about french fries`` to trigger the "Martha" keyword, only the "french fries" keywords.
|
||||
This is superior to checking `the player's command` because we do not want ``ASK MARTHA ABOUT FRENCH FRIES`` to trigger the ``MARTHA`` keyword, only the ``FRENCH FRIES`` keywords.
|
||||
|
||||
{**}The Empyrean Shuttle Bay is a room. "From here you have an excellent view of the colony world, which looks... well, it looks discouragingly orange. But terraforming is in progress."
|
||||
|
||||
|
|
@ -46,16 +46,14 @@ This is superior to checking "the player's command" because we do not want ``ask
|
|||
|
||||
This means that Martha will respond to keywords regardless of the setting in which they occur. For instance:
|
||||
|
||||
``` transcript
|
||||
>martha, get in the shuttle
|
||||
"Shuttles! I hate shuttles," Aunt Martha grumbles. "Give me an airplane! AIRPLANE."
|
||||
> MARTHA, GET IN THE SHUTTLE
|
||||
"Shuttles! I hate shuttles," Aunt Martha grumbles. "Give me an airplane! AIRPLANE."
|
||||
|
||||
>martha, for pity's sake, do you see an airplane around here?
|
||||
"Those were the days," Aunt Martha agrees, plainly reliving the days when she wore a blue-and-white uniform and passed out packets of salted peanuts.
|
||||
> MARTHA, FOR PITY'S SAKE, DO YOU SEE AN AIRPLANE AROUND HERE?
|
||||
"Those were the days," Aunt Martha agrees, plainly reliving the days when she wore a blue-and-white uniform and passed out packets of salted peanuts.
|
||||
|
||||
>martha, pass me the rations
|
||||
"Do you think there are any peanuts in there?" she asks in a wistful tone.
|
||||
```
|
||||
> MARTHA, PASS ME THE RATIONS
|
||||
"Do you think there are any peanuts in there?" she asks in a wistful tone.
|
||||
|
||||
This is not the stuff of which Loebner-winning chatbots are made, admittedly, but it is occasionally a useful alternative to stricter modes of command-parsing.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Index: Describing objects with parts
|
|||
Description: Objects which automatically include a description of their component parts whenever they are examined.
|
||||
For: Z-Machine
|
||||
|
||||
It is straightforward to make a rule that anything with parts must mention all those parts during an ``examine`` command:
|
||||
It is straightforward to make a rule that anything with parts must mention all those parts during an ``EXAMINE`` command:
|
||||
|
||||
{*}"Control Center"
|
||||
|
||||
|
|
@ -20,7 +20,7 @@ It is straightforward to make a rule that anything with parts must mention all t
|
|||
|
||||
The command chair is an enterable supporter in the Control Center. It is pushable between rooms. "Because the computer is too large for you to reach all of the front panel from a standing position, there is a command chair on casters which allows you to push back and forth." The description of the command chair is "Quite ordinary, really, but for the heady rush of power that comes of sitting in it.". Some casters are part of the command chair.
|
||||
|
||||
Now whenever we look at any object with components, we will first see the description, then a list of parts which belong to it. The following refinement brings in elements of later chapters, but it may be worth noting: because we've written our rule as an "After examining...", anything that pre-empts the operation of the examine command will also prevent that rule from occurring. So for instance:
|
||||
Now whenever we look at any object with components, we will first see the description, then a list of parts which belong to it. The following refinement brings in elements of later chapters, but it may be worth noting: because we've written our rule as an `After examining`, anything that pre-empts the operation of the examine command will also prevent that rule from occurring. So for instance:
|
||||
|
||||
{**}A hair-thick needle is part of the ennui meter.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ In a very dense environment, we might want to offer the player room descriptions
|
|||
|
||||
There are a wide range of possible reasons to do this – to shift the narrative emphasis, to change the mood of the game by highlighting different parts of the environment, to show the game from the perspective of different viewpoint characters – but in the following example, our goal is to show the player only the objects that are currently useful for puzzles.
|
||||
|
||||
To do this, we need some notion of what puzzles are currently available and unsolved, so we make an "unsolved" adjective; we also need to know which things solve the puzzle, so we create a "resolving" relation, to indicate which objects resolve which problems.
|
||||
To do this, we need some notion of what puzzles are currently available and unsolved, so we make an `unsolved` adjective; we also need to know which things solve the puzzle, so we create a `resolving` relation, to indicate which objects resolve which problems.
|
||||
|
||||
Given that information, we can create rules about which objects in the game world are currently interesting, which are currently dull, and describe accordingly:
|
||||
|
||||
|
|
|
|||
|
|
@ -7,6 +7,8 @@ For: Z-Machine
|
|||
|
||||
Making major changes to display features, such as the construction of the status line, sometimes requires that we rely on Inform 6 in bulk; here is how we might produce the Trinity-style status line, with the location centered at the top center of the screen.
|
||||
|
||||
Note that this example _only_ works if the Settings for it are set to the Z-machine story file format: it does not work on the default Glulx setting, which has a different screen arrangement.
|
||||
|
||||
{*}"Corner of No and Where"
|
||||
|
||||
No is a room. Where is west of No.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Example: *** Costa Rican Ornithology
|
|||
Location: Reading and talking
|
||||
RecipeLocation: Reading Matter
|
||||
Index: Book with various contents
|
||||
Description: A fully-implemented book, answering questions from a table of data, and responding to failed consultation with a custom message such as "You flip through the Guide to Central American Birds, but find no reference to penguins."
|
||||
Description: A fully-implemented book, answering questions from a table of data, and responding to failed consultation with a custom message such as ``You flip through the Guide to Central American Birds, but find no reference to penguins.``
|
||||
For: Z-Machine
|
||||
|
||||
The following relies on quite a number of features we haven't met yet: tables, rules for printing names, instructions for understanding the player's commands. It is offered simply as an example of how a fully implemented book might be handled in Inform.
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ Suppose that we have a design in which the player spends lots of time on enterab
|
|||
otherwise say "[The actor] leaps gracefully across the distance...";
|
||||
move the actor to the holder of the noun, without printing a room description.
|
||||
|
||||
Because this rule occurs before the "implicitly pass through other barriers rule", that rule will not occur when we move from platform to platform; we'll use our own custom rule instead.
|
||||
Because this rule occurs before the `implicitly pass through other barriers rule`, that rule will not occur when we move from platform to platform; we'll use our own custom rule instead.
|
||||
|
||||
{**}Rule for setting action variables for entering:
|
||||
now the place left is the holder of the actor.
|
||||
|
|
|
|||
|
|
@ -5,11 +5,11 @@ Index: Printing the description of something activity
|
|||
Description: Adding a "printing the description of something" activity.
|
||||
For: Z-Machine
|
||||
|
||||
Suppose we want to add rules so that any time we examine a charred object (and most of our objects can be charred), a line about the charring is appended to the end of the object description. We could use "after examining...", but perhaps we would prefer for the sentence about the charring not to appear in its own paragraph.
|
||||
Suppose we want to add rules so that any time we examine a charred object (and most of our objects can be charred), a line about the charring is appended to the end of the object description. We could use `after examining...`, but perhaps we would prefer for the sentence about the charring not to appear in its own paragraph.
|
||||
|
||||
This is an ideal occasion for a new activity. We look at the action index for "examining" to identify the rule that causes the old behaviour (in this case, the "standard examining rule"); replace this with a new rule that calls our activity; and write our "printing the description" activity in such a way that it uses an object's description without forcing a paragraph return afterward.
|
||||
This is an ideal occasion for a new activity. We look at the action index for `examining` to identify the rule that causes the old behaviour (in this case, the `standard examining rule`); replace this with a new rule that calls our activity; and write our `printing the description` activity in such a way that it uses an object's description without forcing a paragraph return afterward.
|
||||
|
||||
Then we will use "after printing the description" to add our line about charring, and make sure that the paragraph return does occur before the prompt.
|
||||
Then we will use `after printing the description` to add our line about charring, and make sure that the paragraph return does occur before the prompt.
|
||||
|
||||
So:
|
||||
|
||||
|
|
@ -19,7 +19,7 @@ So:
|
|||
|
||||
The fancy examining rule is listed instead of the standard examining rule in the carry out examining rules.
|
||||
|
||||
This instruction replaces a normal piece of the examine action, the standard examining rule, with another one of our own devising. (The replacement of the standard examining rule will be explained in more detail in the chapter on [Rulebooks].)
|
||||
This instruction replaces a normal piece of the examine action, the `standard examining rule`, with another one of our own devising. (The replacement of the standard examining rule will be explained in more detail in the chapter on [Rulebooks].)
|
||||
|
||||
{**}Printing the description of something is an activity.
|
||||
|
||||
|
|
@ -27,7 +27,7 @@ This instruction replaces a normal piece of the examine action, the standard exa
|
|||
carry out the printing the description activity with the noun;
|
||||
rule succeeds.
|
||||
|
||||
All we have done here is enclose what is usually just a rule inside an activity. This means that we can now write before and after rules for the activity, and also add special instructions like "Rule for printing the name of something while printing the description of something" – this may not be likely to arise often, but Inform now has the concept of "printing the description of something" as a separate context of action. Next we add the modification that lets us append to the description without a new line:
|
||||
All we have done here is enclose what is usually just a rule inside an activity. This means that we can now write before and after rules for the activity, and also add special instructions like `Rule for printing the name of something while printing the description of something` – this may not be likely to arise often, but Inform now has the concept of `printing the description of something` as a separate context of action. Next we add the modification that lets us append to the description without a new line:
|
||||
|
||||
{**}Rule for printing the description of something (called item):
|
||||
if the description of the item is not "":
|
||||
|
|
@ -35,16 +35,16 @@ All we have done here is enclose what is usually just a rule inside an activity.
|
|||
otherwise:
|
||||
say "You see nothing special about [the item]. [run paragraph on]".
|
||||
|
||||
"run paragraph on" here will mean that we do not get a paragraph break following the description, even if it ends with a period. We also insert a space, so that our follow-on comments will be properly punctuated.
|
||||
`run paragraph on` here will mean that we do not get a paragraph break following the description, even if it ends with a period. We also insert a space, so that our follow-on comments will be properly punctuated.
|
||||
|
||||
{**}After printing the description of something charred:
|
||||
say "It is charred." instead.
|
||||
|
||||
The instead at the end of this line stops Inform for going on with any other "after printing the description of..." rules.
|
||||
The `instead` at the end of this line stops Inform for going on with any other `after printing the description of...` rules.
|
||||
|
||||
The standard library also has rules for printing additional text about containers and supporters with visible contents, and devices that are switched on; with this current system, we could add those as "after printing the description" rules as well, building up a complete paragraph if we wanted. But for simplicity we won't exemplify all of that here. The effects would be much the same as with the "charred" line.
|
||||
The Standard Rules also have rules for printing additional text about containers and supporters with visible contents, and devices that are switched on; with this current system, we could add those as `after printing the description` rules as well, building up a complete paragraph if we wanted. But for simplicity we won't exemplify all of that here. The effects would be much the same as with the "charred" line.
|
||||
|
||||
Now, because we want to make sure that we always do get a paragraph break after our description, we add this rule last after all the other rules. "Last" and "first" rules are covered in more detail in the chapter on [Rulebooks].
|
||||
Now, because we want to make sure that we always do get a paragraph break after our description, we add this rule last after all the other rules. `Last` and `first` rules are covered in more detail in the chapter on [Rulebooks].
|
||||
|
||||
{**}Last after printing the description of something:
|
||||
say paragraph break.
|
||||
|
|
@ -65,12 +65,12 @@ Now, because we want to make sure that we always do get a paragraph break after
|
|||
|
||||
Instead of burning the grain of sand: say "You drop the grain into the fire pit, where it becomes indistinguishable from all the others."; now the grain of sand is nowhere. Instead of dropping the grain of sand: now the grain of sand is nowhere; say "You return the grain of sand to its brethren."
|
||||
|
||||
The player's description is handled in an unusual way, and this will produce a space paragraph break there where it should not. Instead, therefore, we will add an instead for examining the player (probably a good idea anyway):
|
||||
The player's description is handled in an unusual way, and this will produce a space paragraph break there where it should not. Instead, therefore, we will add an `instead` for examining the player (probably a good idea anyway):
|
||||
|
||||
{**}Instead of examining the player:
|
||||
say "You are sunburned and there is sand in cracks you didn't know existed."
|
||||
|
||||
Test me with "i / x stick / x bottle / x sand / x paper / x me / burn stick / x stick / burn paper / x paper".
|
||||
|
||||
The "printing a description" activity may be useful for other games, and can be imported just by lifting section 1.
|
||||
The `printing a description` activity may be useful for other games, and can be imported just by lifting section 1.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ For: Z-Machine
|
|||
|
||||
Definition: a thing is old if its last use is 12 or less.
|
||||
|
||||
The actual number chosen in this definition is pretty much irrelevant: the main thing is that we want to establish relative values. The lower the "last use" number of an item, the older that item should be understood to be, as we see here:
|
||||
The actual number chosen in this definition is pretty much irrelevant: the main thing is that we want to establish relative values. The lower the `last use` number of an item, the older that item should be understood to be, as we see here:
|
||||
|
||||
{**}To decide which thing is cyclically random (collection - a description of objects):
|
||||
let choice be the oldest member of the collection;
|
||||
|
|
@ -23,7 +23,7 @@ This phrase will select, from the collection of objects passed to it, the one th
|
|||
{**}After taking inventory:
|
||||
say "You stare morosely at [the cyclically random thing carried by the player], wondering what you're ever going to find to do with it."
|
||||
|
||||
We could have said "You stare morosely at [the oldest thing carried by the player]" here, but doing so would not have set the "last use" property correctly, so we would not get the cycling behaviour that we're looking for.
|
||||
We could have said `"You stare morosely at [the oldest thing carried by the player]"` here, but doing so would not have set the `last use` property correctly, so we would not get the cycling behaviour that we're looking for.
|
||||
|
||||
{**}The Evidence Room is a room. Some shelves are scenery supporters in the Evidence Room. A box is a kind of container which is open and not openable. On the shelves is a box. It contains a deformed bullet and a driver's license.
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ And to add a few additional details:
|
|||
{**}Instead of doing something other than waiting, looking, listening or examining during Lecture:
|
||||
say "Dr Freitag glares at you so fiercely that you are frozen into inaction."
|
||||
|
||||
Notice the careful phrasing of "doing something other than..." so that we do not mention the objects; if we had written "something other than listening to something...", the instead rule would match only action patterns which involved a noun. We state the rule more generally so that it will also match nounless commands such as ``jump`` and ``sing``, since Freitag will probably take a dim view of those as well.
|
||||
Notice the careful phrasing of `doing something other than...` so that we do not mention the objects; if we had written `something other than listening to something...`, the instead rule would match only action patterns which involved a noun. We state the rule more generally so that it will also match nounless commands such as ``JUMP`` and ``SING``, since Freitag will probably take a dim view of those as well.
|
||||
|
||||
{**}When Lecture ends:
|
||||
now Freitag is nowhere;
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Example: ** Delayed Gratification
|
|||
Location: Named rules and rulebooks
|
||||
RecipeLocation: Waiting, Sleeping
|
||||
Index: WAIT UNTIL [time] command
|
||||
Description: A ``wait until`` [time] command which advances until the game clock reaches the correct hour.
|
||||
Description: A ``WAIT UNTIL [time]`` command which advances until the game clock reaches the correct hour.
|
||||
For: Z-Machine
|
||||
|
||||
{*}"Delayed Gratification"
|
||||
|
|
|
|||
|
|
@ -2,16 +2,14 @@ Example: *** Delicious, Delicious Rocks
|
|||
Location: Check, carry out, report
|
||||
RecipeLocation: Food
|
||||
Index: Sanity-check stage before the Before rules
|
||||
Description: Adding a "sanity-check" stage to decide whether an action makes any sense, which occurs before any before rules, implicit taking, or check rules.
|
||||
Description: Adding a sanity-check stage to decide whether an action makes any sense, which occurs before any before rules, implicit taking, or check rules.
|
||||
For: Z-Machine
|
||||
|
||||
In some cases, we may want to add new stages to action processing. One possibility is a stage where we check the sanity of what the player is trying to do before executing any of the other commands; so that we avoid, for instance
|
||||
|
||||
``` transcript
|
||||
>eat rock
|
||||
(first taking the rock)
|
||||
That's plainly inedible.
|
||||
```
|
||||
> EAT ROCK
|
||||
(first taking the rock)
|
||||
That's plainly inedible.
|
||||
|
||||
Here is how we might insert such a stage in our action processing, using rulebook manipulation.
|
||||
|
||||
|
|
@ -42,5 +40,5 @@ It is of course possible to get the same effect with
|
|||
Before eating an inedible thing:
|
||||
say "Your digestion is so delicate -- you're sure [the noun] wouldn't agree with you." instead.
|
||||
|
||||
...and in a small game with few rules, there's not much reason to add an extra stage. The ability to modify the stages of action processing becomes useful when we have a fairly large game with sophisticated modeling and want to be sure that some kinds of message (such as the sanity-check) are always handled before other things that we might be doing at the before stage (such as generating implicit actions like opening doors before going through them).
|
||||
...and in a small game with few rules, there's not much reason to add an extra stage. The ability to modify the stages of action processing becomes useful when we have a fairly large game with sophisticated modeling and want to be sure that some kinds of message (such as the `sanity-check`) are always handled before other things that we might be doing at the before stage (such as generating implicit actions like opening doors before going through them).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
Assembly Room
|
||||
Democratic Process
|
||||
An Interactive Fiction
|
||||
Release 1 / Serial number 150512 / Inform 7 build 6M22 (I6/v6.33 lib 6/12N) SD
|
||||
Release 1 / Serial number 160428 / Inform 7 v10.2.0 / D
|
||||
|
||||
Assembly Room
|
||||
On most days, this room is used for elementary school assemblies; at the moment, it serves as a voting place.
|
||||
|
|
@ -14,8 +14,12 @@
|
|||
(Testing.)
|
||||
|
||||
>[1] put ballot in machine
|
||||
(first writing in your vote)
|
||||
|
||||
(first taking the ballot)
|
||||
|
||||
You perform your solemn duty, nobly inking in a cross.
|
||||
|
||||
You put the ballot into the machine.
|
||||
|
||||
> >
|
||||
|
|
@ -2,30 +2,40 @@ Example: *** Democratic Process
|
|||
Location: Before rules
|
||||
RecipeLocation: Taking, Dropping, Inserting and Putting
|
||||
Index: PUT and INSERT automatically TAKE first
|
||||
Description: Make ``put`` and ``insert`` commands automatically take objects if the player is not holding them.
|
||||
Description: Making something happen automatically before an item is put into a box.
|
||||
For: Z-Machine
|
||||
|
||||
[ZL: https://inform7.atlassian.net/browse/I7-2348 This refers to outdated behaviour ]::
|
||||
|
||||
"Stop" and "Continue" are most useful when we need to write rules that will have to stop the action some of the time but at other times let it pass; so for instance:
|
||||
`stop the action` is most useful when we need to write rules that will have to stop the action some of the time but at other times let it pass. For example, let's create a polling station, where the idea is to ``TAKE BALLOT``, ``VOTE``, and then ``PUT BALLOT IN MACHINE``:
|
||||
|
||||
{*}"Democratic Process"
|
||||
|
||||
Before inserting something which is not carried by the player into something:
|
||||
if the noun is in the second noun, say "Already done." instead;
|
||||
say "(first taking [the noun])[line break]";
|
||||
silently try taking the noun;
|
||||
if the player is not holding the noun, stop the action.
|
||||
|
||||
Before putting something which is not carried by the player on something:
|
||||
if the noun is on the second noun, say "Already done." instead;
|
||||
say "(first taking [the noun])[line break]";
|
||||
silently try taking the noun;
|
||||
if the player is not holding the noun, stop the action.
|
||||
|
||||
The Assembly Room is a room. "On most days, this room is used for elementary school assemblies; at the moment, it serves as a voting place." The ballot is on the desk. The desk is in the Assembly Room.
|
||||
|
||||
The machine is a container in the Assembly Room. "On the ballot machine is a sign which reads 'PUT BALLOTS IN ME :)'." Understand "ballot machine" as the machine.
|
||||
|
||||
Test me with "put ballot in machine".
|
||||
|
||||
The ballot can be marked or unmarked. The description of the ballot is "The old-fashioned sort you mark by hand.[if the ballot is marked] A cross in a deranged hand is written next to 'Hiram Q. Flathead IV'."
|
||||
|
||||
The machine is a container in the Assembly Room. "On the ballot machine is a sign which reads 'PUT BALLOTS IN ME :)'." Understand "ballot machine" as the machine.
|
||||
|
||||
Voting is an action applying to nothing. Understand "vote" as voting.
|
||||
|
||||
Check voting:
|
||||
if the ballot is marked, say "Not for another four years, thank you."
|
||||
|
||||
Carry out voting:
|
||||
now the ballot is marked.
|
||||
|
||||
Report voting:
|
||||
say "You perform your solemn duty, nobly inking in a cross."
|
||||
|
||||
We need some rules to prevent blank ballots being put into the machine. A neat way to do that is to automate the process, so that ``PUT BALLOT IN MACHINE`` automatically triggers ``VOTE``, and ``VOTE`` in turn automatically takes the ballot if the player hasn't got it:
|
||||
|
||||
{**}Before inserting the unmarked ballot into something:
|
||||
say "(first writing in your vote)[line break]";
|
||||
try voting;
|
||||
if the ballot is unmarked, stop the action.
|
||||
|
||||
Before voting when the player is not carrying the ballot:
|
||||
say "(first taking [the ballot])[line break]";
|
||||
silently try taking the ballot;
|
||||
if the player is not carrying the ballot, stop the action.
|
||||
|
||||
Test me with "put ballot in machine".
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Index: Containers that calculate internal volume and available room
|
|||
Description: Receptacles that calculate internal volume and the amount of room available, and cannot be overfilled.
|
||||
For: Z-Machine
|
||||
|
||||
In the following, we pretend that every item has a cuboidal shape. Every thing has a length, width and depth, while a "measured container" also has interior dimensions. (Thus a 10x10x10 container with 1cm-thick sides might have interior dimensions 9x9x9.)
|
||||
In the following, we pretend that every item has a cuboidal shape. Every thing has a length, width and depth, while a `measured container` also has interior dimensions. (Thus a 10x10x10 container with 1cm-thick sides might have interior dimensions 9x9x9.)
|
||||
|
||||
{*}"Depth"
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ When testing this example, the author made use of the following: it's no longer
|
|||
say "[the item] - height [height of the item], width [width of the item], depth [depth of the item].";
|
||||
say "largest side [largest dimension of the item], middling [middling dimension of the item], smallest [shortest dimension of the item]."
|
||||
|
||||
We now introduce a new kind: a measured container, which not only has exterior dimensions–the height, width and depth which every thing now has–but also interior measurements. A convenient way to do calculations with the hollow interior is to regard it as if it were a solid shape in its own right, and we do this with the aid of something out of world, which the player never sees: the "imaginary cuboid", which is made into the shape of whatever measured container's interior is being thought about.
|
||||
We now introduce a new kind: a measured container, which not only has exterior dimensions–the height, width and depth which every thing now has–but also interior measurements. A convenient way to do calculations with the hollow interior is to regard it as if it were a solid shape in its own right, and we do this with the aid of something out of world, which the player never sees: the `imaginary cuboid`, which is made into the shape of whatever measured container's interior is being thought about.
|
||||
|
||||
{**}A measured container is a kind of container. A measured container has a length called interior height. A measured container has a length called interior width. A measured container has a length called interior depth.
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ For: Z-Machine
|
|||
|
||||
Here's the part that allows reaching through the window.
|
||||
|
||||
We replace the usual rule that says the player can never reach into a room with one that more specifically checks whether we are trying to reach through the window. If we aren't, we return the usual refusal. If we are, we return a custom refusal if the window is closed ("You can't reach through the closed window"), but allow access if the window is open.
|
||||
We replace the usual rule that says the player can never reach into a room with one that more specifically checks whether we are trying to reach through the window. If we aren't, we return the usual refusal. If we are, we return a custom refusal if the window is closed (``You can't reach through the closed window``), but allow access if the window is open.
|
||||
|
||||
{**}The can't reach through closed window rule is listed instead of the can't reach inside rooms rule in the reaching inside rules.
|
||||
|
||||
|
|
|
|||
|
|
@ -27,10 +27,10 @@ We get a similar set of guesses if we write
|
|||
|
||||
{**}The bench is in the cabin. On the bench are some blue vinyl cushions.
|
||||
|
||||
Using "some" rather than "a" or "the" tells Inform that the cushions are to be referred to as a plural object in the future. And because of the "on the bench..." phrase, Inform will guess that the bench is a supporter and that it is fixed in place and cannot be moved from room to room. We do have to tell it that the bench can be sat on, though:
|
||||
Using `some` rather than `a` or `the` tells Inform that the cushions are to be referred to as a plural object in the future. And because of the `on the bench` wording, Inform will guess that the bench is a `supporter` and that it is `fixed in place` and cannot be moved from room to room. We do have to tell it that the bench can be sat on, though:
|
||||
|
||||
{**}The bench is enterable.
|
||||
|
||||
And now a short script, so that if we type ``test me``, we experiment with the case and bench:
|
||||
And now a short script, so that if we type ``TEST ME``, we experiment with the case and bench:
|
||||
|
||||
{**}Test me with "examine case / get rods / open case / get rods / sit on bench / take cushions / get up"
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ The order in which we define these things is fairly open. We could also define a
|
|||
|
||||
{**}A sign is scenery in the Cabin. The description is "You can get half-day and full-day sight-seeing tours, and half-day and full-day fishing trips."
|
||||
|
||||
Where "the description" is assumed to refer to the thing most recently defined, if no object is specified.
|
||||
Where `the description` is assumed to refer to the thing most recently defined, if no object is specified.
|
||||
|
||||
{**}The view of the Malaspina glacier is a backdrop. It is everywhere. The description is "The Malaspina glacier covers much of the nearby slope, and -- beyond it -- an area as large as Rhode Island."
|
||||
|
||||
|
|
|
|||
|
|
@ -9,5 +9,5 @@ It stands to reason that the captain wouldn't let just anyone meddle with his fi
|
|||
|
||||
{*}The Cabin contains a glass case. In the glass case is a collection of fishing rods. The case is closed, transparent, openable, lockable, and locked. The case is scenery. The small silver key unlocks the case.
|
||||
|
||||
Now there's a silver key that will unlock it – though since we haven't said where the key is, the player will never be able to find it in the game. (If we look at the World index, we find "small silver key" right at the bottom, not inside any of the rooms. That is as good as not existing at all – though we usually use the term "out of play" – but as we will later see, it is possible to have things initially out of play but brought into existence later on.)
|
||||
Now there's a silver key that will unlock it – though since we haven't said where the key is, the player will never be able to find it in the game. (If we look at the World index, we find `small silver key` right at the bottom, not inside any of the rooms. That is as good as not existing at all – though we usually use the term `out of play` – but as we will later see, it is possible to have things initially out of play but brought into existence later on.)
|
||||
|
||||
|
|
|
|||
|
|
@ -13,5 +13,5 @@ This anticipates a later chapter, but it would probably be a good idea to hint t
|
|||
|
||||
{**}Instead of taking the chest: say "It's too heavy to lift, but you might be able to push it, and just inch it over the frame of the door."
|
||||
|
||||
Otherwise, attempts to pick it up will just reply with "That's fixed in place."
|
||||
Otherwise, attempts to pick it up will just reply with ``That's fixed in place.``
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Index: Command prompt changing to reflect state of combat
|
|||
Description: Combat scenario in which the player's footing and position changes from move to move, and the command prompt also changes to reflect that.
|
||||
For: Z-Machine
|
||||
|
||||
Suppose our game features a detailed simulated combat between the player character and an opponent. The player character might have several weapons available, and several types of attack available; and at any given time they might be perched up in the rigging of his ship, standing on the open deck, or boxed in between some barrels. Their options will vary depending on their position, and obviously it would detract from the pacing to make them keep ``look``ing in the middle of combat for a reminder of where they are. Instead, we'll roll this information into the command prompt:
|
||||
Suppose our game features a detailed simulated combat between the player character and an opponent. The player character might have several weapons available, and several types of attack available; and at any given time they might be perched up in the rigging of his ship, standing on the open deck, or boxed in between some barrels. Their options will vary depending on their position, and obviously it would detract from the pacing to make them keep ``LOOK``ing in the middle of combat for a reminder of where they are. Instead, we'll roll this information into the command prompt:
|
||||
|
||||
{*}"Don Pedro's Revenge"
|
||||
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue