I’m trying to avoid repeated answers given by Inform. For example, if I say “examine tree” the first time, I should get the normal answer. But if I type “examine tree” again, I should get a generic answer taken from a cycling list.
I’ve tried to solve this problem with the following rule :
Instead of examining something for at least the second time : say ...
But it’s obviously too generic : the second time the player uses “examine”, with any object, Inform fires the generic answer. I can fix this issue with an Instead rule for each object to examine, but it looks like an overkill.
In more programming wording, I’m looking for the best way to create a rule (i) taking the subject of examination as a parameter and (ii) answering fully or not, depending on the number of precedent executions.
Any answer/documentation would be really appreciated.
Many thanks for your help !
You can refer to the direct object of the current action with “the noun”, or you can introduce parameter names with “(called <...>)”. So, one way to get the desired output would be:
The Lab is a room.
Before examining something when we have examined the noun:
say "[One of]First cycling description[or]Second cycling description[or]Third cycling description[cycling]." instead;
[or, alternatively:
Before examining something (called the examinee) when we have examined the examinee: [etc.]
]
The table is a supporter in the Lab. The description is "It's a table made of stainless steel."
The widget is on the table. The description is "It's an ordinary widget."
The gadget is on the table. The description is "It's an ordinary gadget."
Test sequence with "x me/x table/x widget/x gadget".
Test me with "test sequence/test sequence".
Output:
Lab
You can see a table (on which are a widget and a gadget) here.
>test me
(Testing.)
>[1] test sequence
(Testing.)
>[2] x me
As good-looking as ever.
>[3] x table
It's a table made of stainless steel.
On the table are a widget and a gadget.
>[4] x widget
It's an ordinary widget.
>[5] x gadget
It's an ordinary gadget.
>[6] test sequence
(Testing.)
>[7] x me
First cycling description.
>[8] x table
Second cycling description.
>[9] x widget
Third cycling description.
>[10] x gadget
First cycling description.
One caveat is, of course, that the players might be annoyed if the objects’ descriptions contain important information, which they’ll be able to see only once.
The description of the tree is "[tree_identifying]Some kind of tree."
To say tree_identifying:
now the description of the tree is "[one of]Is it a larch?[or]An elm, perhaps?[or]It might be an ash...[cycling]"
Exactly what I was looking for @StJohnLimbo .
So I have to repeat your rule (I selected your second option) for each verb concerned by the “non-repeat” rule, right ?
Thanks also to J.J Guest and jrb for the answers !
For example, the following returns two different descriptions in sequence, then cycles twice through three descriptions in sequence, then switches to a constant description.
It achieves the switch after 2 cycles by nesting [one of][or][stop_tree_identifying][stopping] in the third of the cycling descriptions. The first cycle, this just prints nothing. The second cycle it triggers the switch. Inserting additional [or]s would extend the number of cycles before the trigger. e.g. [one of][or][or][or][stop_tree_identifying][stopping] would switch after 4 cycles.
The description of the tree is "[one of]Some kind of tree.[or]What could it be?[start_tree_identifying][stopping]".
To say start_tree_identifying:
now the description of the tree is "[one of]Is it a larch?[or]An elm, perhaps?[or]It might be an ash...[one of][or][stop_tree_identifying][stopping][cycling]".
To say stop_tree_identifying:
now the description of the tree is "You've given up trying to work out what it is. Best get back to other business.".
Only an issue (for examining) if your story includes the possibility of darkness, but using a Before rule rather than an Instead, Check or Carry Out rule preempts the basic visibility rule (which runs between Before and Instead rulebooks) and in darkness blocks actions (like examining) declared as requiring light.
The same consideration applies to most rules that (unlike examining) require objects be touchable (governed by basic accessibility rule) or carried (carrying requirements rule).
EDIT: that said, I’ve a feeling that although it does now, it might not always have been the case that examining was declared as requiring light.
Personally, I consider the Before stage as being when the actor has just hatched the thought of performing the action, so considerations of light, touchability, or carrying don’t yet apply.
I thought about mentioning that, but refrained from it, because it does seem that some part of the parser intervenes correctly in the dark, regardless of the Before (or I might be misunderstanding or overlooking something).
When I add this to my example:
After jumping:
now the lab is dark.
… it will result in:
Lab
You can see a table (on which are a widget and a gadget) here.
>x widget
It's an ordinary widget.
>g
First cycling description.
>jump
It is now pitch dark in here!
>x widget
You can't see any such thing.
>x gadget
You can't see any such thing.
That is, the repeatedly-examined widget will behave the same as the gadget, and the Before rule will not inadvertently cause one of the cycling descriptions to print in the dark.
Most things in darkness are out of scope, so are rejected by the parser and don’t get as far as generating an action and running its Before rulebook.
But things which are in scope despite darkness, most commonly (but not exclusively) the player’s possessions, will be affected by this.
It’s one of those things which is probably bad style but you’ll get away with in most circumstances because the edge cases where it makes a difference don’t apply.
(One might say that the player is familiar enough with himself and his possessions, after having examined them once, to warrant printing the generic “you’ve already examined this enough” message even in the dark. But of course that depends on how the OP writes the generic cycling messages, so it’s good to keep the issue in mind.)
Now that the technical question’s been solved, I’m just posting this to very strongly agree with @StJohnLimbo’s caveat here. IF players are often in the habit of examining everything they find as soon as they come across it, but might only realize from context or later developments that a particular thing or its description is significant in a way they hadn’t previously considered. Forcing them to scroll back up into their interpreter’s screen buffer or hoping they’re taking a transcript to see those details again could be an exercise in frustration. While on the flip side, I don’t think I’ve seen players or reviewers complain that repeated X TREEs give the same response, so this could be a solution in search of a problem.
If a particular description is quite long, or embeds some action or reaction that wouldn’t make sense to repeat, I often use one of… stopping to add a second, more compact description, but I’d personally be wary of doing much more than that unless there was a specific need based on the particular design of the game.
While there are ways to group actions together, and also generic rules like “Before doing something”, and ways to refer to “the current action” and “the action name part of the current action” and keep track of them etc., I’m not aware of a succinct way to phrase a general “Before/Instead of doing something when we have done the current action” rule preamble.
(Edited to add: Of course, one could write a “To decide if we are repeating:” phrase or similar, but then one would just have to account inside of that for the various actions, so that wouldn’t make an interesting difference.)
Thanks for your piece of advice @DeusIrae. I’m aware of that issue. Considering my story ends at turn 10, avoiding repetition is part of the design (and also a way for me to get used to Inform and better understand it’s mechanics).
But be sure I’ll beta-test my assumptions in any case
If your story is short, and if you’d like to avoid all repetitions, you could get around defining separate rules for various actions by storing all actions and just having one rule, like this:
The actions-so-far is a list of stored actions that varies.
After doing something:
add the current action to the actions-so-far;
continue the action;
Before doing something when the current action is listed in the actions-so-far:
say "[One of]We did that already[or]Not again[cycling]." instead;
I have only tested this with a few moves in my barebones example, so I don’t know whether there might be hidden pitfalls, but it can’t hurt to explore various ways of achieving things in Inform.
(One obvious caveat is that it can be very easy to make the game unwinnable: if the player takes the gadget and then drops it, he won’t be able to take it again. But it sounds as if you’re aiming for a special kind of scenario, so that might be okay.)
If it’s important to have exceptions, define them as a kind of action and exclude them from your rule:
Taking is repeatable behaviour.
Dropping is repeatable behaviour.
After doing something other than repeatable behaviour:
add the current action to the actions-so-far;
continue the action;
see the documentation §7.9. All actions and exceptional actions and §7.15. Kinds of action
