18.15. Phrases concerning rules

| Chapter 18: Rulebooks |

| 18.15. Phrases concerning rules

| This section and the previous one are about a feature which is being withdrawn from Inform in future. Experience shows there are equally good ways to achieve the same ends without needing procedural rules. As elegant as they were, they often confused users, and they were expensive at run-time (that is, they made everything work more slowly). Withdrawing them from Inform will make it possible to make more efficient story files, and will simplify the language. The "ignore" phrase is only one of a suite, which should only be used in procedural rules. The full list is: ignore (rule)
This phrase can only be used in procedural rules, which are now deprecated. It causes the named rule to be ignored (skipped over without producing a result) within the scope of the current "follow".
reinstate (rule)
This phrase can only be used in procedural rules, which are now deprecated. Its only effect is to reverse the effect of any "ignore" phrase affecting the rule named.
reject the result of (rule)
This phrase can only be used in procedural rules, which are now deprecated. It causes the named rule to used, but to have its result ignored, within the scope of the current "follow". In other words, if the rule succeeds or fails then this is suppressed and its rulebook continues.
accept the result of (rule)
This phrase can only be used in procedural rules, which are now deprecated. Its only effect is to reverse the effect of any "reject the result of" phrase affecting the rule named.
substitute (rule) for (rule)
This phrase can only be used in procedural rules, which are now deprecated. Whenever the second rule is to be invoked - from any rulebook, or as a result of any "follow" instruction - invoke the first one instead.
restore the original (rule)
This phrase can only be used in procedural rules, which are now deprecated. Its only effect is to reverse the effect of any "substitute ... for ..." phrase affecting the rule named.
move (rule) to before (rule)
This phrase can only be used in procedural rules, which are now deprecated. This causes the first rule to be ignored whenever it turns up in the ordinary way, but to be invoked either immediately before the second rule whenever that second rule is invoked. In effect, it cuts out the first rule from wherever it was, and glues it onto the second. Note that there is no obligation for the first rule to begin in the same rulebook(s) as the second, so this can be used to slot in a wholly new rule, perhaps only if certain circumstances hold.
move (rule) to after (rule)
This phrase can only be used in procedural rules, which are now deprecated. This causes the first rule to be ignored whenever it turns up in the ordinary way, but to be invoked either immediately after the second rule whenever that second rule is invoked. In effect, it cuts out the first rule from wherever it was, and glues it onto the second. Note that there is no obligation for the first rule to begin in the same rulebook(s) as the second, so this can be used to slot in a wholly new rule, perhaps only if certain circumstances hold.
These rule-changing instructions allow apparently casual sentences to wreak havoc with the model world. This, for instance, is quite the recipe for mayhem and perplexity: A procedural rule: reject the result of the before rules; ignore the after rules; move the after rules to before the before rules.

391
| Example Uptempo Adjust time advancement so the game clock moves fifteen minutes each turn. |
RB

Suppose a game in which all actions take a very long time. Here's a simple implementation: "Uptempo" The fast time rule is listed instead of the advance time rule in the turn sequence rules. This is the fast time rule: increment the turn count; increase the time of day by 15 minutes. When play begins: now the right hand status line is "[time of day]". The Temporal Hot Spot is a room. Test me with "z / z". This works fine as it stands, but we may run into some difficulty with it if we add scheduled events: At 9:30 AM: say "Two turtles run by, almost too fast to see." At 9:37 AM: say "A snail blitzes past." At 9:42 AM: say "The grass grows." At 9:50 AM: say "Several flowers burst open." Time is counted forward after the schedule has already been consulted, so that only the 9:30 AM event happens between 9:30 and 9:45; the next two appear to occur between 9:45 and 10:00 AM, and the 9:50 AM event is not reported until the 10:00 AM to 10:15 wait. To get around this, we might schedule events only on the fifteen-minute mark when we want them to occur. Alternatively, we might try instead "Uptempo" The fast time rule is listed before the timed events rule in the turn sequence rules. The advance time rule is not listed in the turn sequence rules. This is the fast time rule: increment the turn count; increase the time of day by 15 minutes. When play begins: now the right hand status line is "[time of day]". The Temporal Hot Spot is a room. At 9:30 AM: say "Two turtles run by, almost too fast to see." At 9:37 AM: say "A snail blitzes past." At 9:42 AM: say "The grass grows." At 9:50 AM: say "Several flowers burst open." Test me with "z / z / z / z". This time our revised time-advancing rule is listed just before the event scheduler, not just afterwards.

392
| Example Solitude Novice mode that prefaces every prompt with a list of possible commands the player could try, and highlights every important word used, to alert players to interactive items in the scenery. |
RB

393
| Example Swigmore U. Adding a new kind of supporter called a perch, where everything dropped lands on the floor. |
RB

394
| Example Lethal Concentration 1 A poisonous gas that spreads from room to room, incapacitating or killing the player when it reaches sufficient levels. |
RB

395
| Example Lethal Concentration 2 Poisonous gas again, only this time it sinks. |
RB

Previous | Contents | Next