| Chapter 18: Rulebooks |

| 18.18. Review of Chapter 18: Rulebooks

1. When a work of IF by Inform is playing, rules are being followed: one after another, in lists followed in sequence. A rule is sometimes like a rule of a game, for instance stopping someone from crossing a bridge when it is guarded by a troll: but rules also govern presentational points, the enforcement of physical realism, the way the player's commands are understood and so on. A minimal game produced by Inform contains about 650 rules: for comparison, the large example "The Reliques of Tolti-Aph" has 1176.

The list of rules in a game, including those pre-defined by Inform, may be found from the Rules Index.

2. A rulebook is a sequence of rules to be followed in order until one of them stops the process by making a decision (as a success or a failure, possibly accompanied by a value of some kind). In theory, there is no reason why we could not put the whole decision-making contents of a given rulebook into a single large rule, but breaking out complex decisions into a number of separate rules makes it easier for later authors to modify parts of the behavior at will.

Each rulebook aims to achieve some single, clearly-defined task: sometimes to change matters, sometimes to decide on a particular value, but other times simply to validate something - for instance, that a given command can be applied sensibly to a given noun.

A rulebook may be either action-based or object-based. Action-based rules are the default, so

> The visibility rules are a rulebook.

would produce action-based rules, whereas to create an object-based rulebook we would need to say

> The flotation rules are an object-based-rulebook.

Action-based rules refer to the action most recently taken by the player, as in

> Before attacking something: ...
> A persuasion rule for asking someone to try jumping: ...

Object-based rules refer to an object instead, as in

> Rule for printing the name of something: ...
> A flotation rule for the cork: ...

3. Some rules have names, such as Inform's built-in "can't reach inside closed containers rule". Others, like the ones defined by the following, do not:

> Before attacking the dog: ...
> When play begins: ...
> Every turn: ...

While these have no names, they do take effect, because the preamble (the text up to the colon) tells Inform which rulebooks to copy them into - "before attacking", "when play begins", "every turn".

The preamble can alternatively quote a name but no rulebook:

> This is the evacuating New York rule: ...

creates a named rule ("the evacuating New York rule"), but one that may never happen; it belongs to none of the rulebooks, and will not occur unless we call on it to do so. Finally, the preamble can specify both a name and a rulebook, as in these examples:

> Before attacking the dog (this is the cruelty to animals rule): ...
> When play begins (this is the choose a murderer rule): ...
> Every turn (this is the repeat offender rule): ...

When rules (and rulebooks) are intended for others to use, as is the case when we are creating an extension, it is important to be disciplined in creating rulebooks which allow the maximum flexibility. Each distinguishable step in any process should be placed in its own rule, which should be named. (We can be more relaxed with rulebooks intended only for use in a single work.)

4. Two situations are elaborate enough that Inform groups together a whole set of rulebooks to cope with them. One situation is checking the validity of, and then carrying out and describing, an action. Each different action (such as "taking") has its own rulebooks (such as "carry out taking"). Actions are essentially things done by the fictional people in our model world.

An activity is something done by the computer as part of the machinery which keeps the model world running smoothly. An activity is nothing more than a set of three rulebooks: one to happen before the activity, one which performs the task in question, and one to happen when it is done. So guiding the behaviour of activities is a matter of adding new rules to existing rulebooks, just as it is with guiding the behaviour of actions.

5. While not everything done by the computer is arranged as an activity - that could become very slow and inefficient - activities do provide very many "hooks" on which we can hang new rules of our own, changing how things are done. The activities built into Inform concentrate on providing facilities which would otherwise be very difficult to arrange, or on providing conveniences for situations where IF authors have historically wanted specialized control.

That doesn't mean we can't add our own activities where we like. Sometimes it is simply convenient to handle a complicated decision process (typically one that is full of exceptional cases) by setting it up as an activity, rather than making it a long and messy phrase. (Instances of this can be found in "The Reliques of Tolti-Aph".)

Another useful trick is to take an existing single rule and build a whole activity on top of it. For instance, the example "Crusoe" shows how to build an activity around printing the description of an object.

6. As well as regulating what happens and how it happens, rulebooks also help to organise the division of text into paragraphs with skipped lines dividing them. In general, when text is printed by two different rules, this text is automatically put into two different paragraphs, unless instructions are given to run paragraphs on.

However, this does not apply with rulebooks belonging to activities. Many activities are used for printing purposes, and it would be mayhem if they were allowed to spawn paragraph breaks all of their own.

7. We rarely need to give explicit instructions to follow a rule. If it has been put into the right rulebook, and the rulebook is one which Inform follows as a matter of routine, then the rule will be followed just when we want it to be.

However, we can make Inform follow any rulebook (or even any individual named rule) at any point during play with one of the following phrases:

> follow the birdsong rules;
> consider the birdsong rules;
> abide by the birdsong rules;

or, if the rulebook to be consulted is object-based:

> follow the birdsong rules for the resplendent trogon;
> consider the birdsong rules for the resplendent trogon;
> abide by the birdsong rules for the resplendent trogon;

With follow, we check procedural rules (see below) that might affect the birdsong rules, then carry them out. With consider or abide by, procedural rules are not consulted.

With abide by, we carry out the birdsong rules, then make the result of those rules the result of the current rule as well. Rules can produce the result "rule succeeds" or "rule fails", or they can return a more complex response ("rule succeeds with result red", "rule fails with result the tiger"). They can also defer making a decision, with "make no decision"; in that case, neither success nor failure is decided on, and Inform can go on to the next rule in the rulebook, if there is one.

8. Whenever we have triggered a rule or rulebook that produces a result, we can check that result immediately afterward by saying

> if the rule succeeded...
> if the rule failed...
> if the result of the rule is a man...

For a number of rulebooks built into Inform, more explicit wordings are allowed, simply to make the source text easier to read. For instance:

> A persuasion rule: persuasion succeeds. (Or persuasion fails.)
> A rule for reaching inside the magnetic shell: allow access. (Or deny access.)
> Visibility rule: there is sufficient light. (Or there is not sufficient light).

These explicit wordings are named outcomes, and are defined so:

> Visibility rules have outcomes there is sufficient light (failure) and there is insufficient light (success).

Defaults may be added like this:

> Visibility rules have outcomes there is sufficient light (failure) and there is insufficient light (success - default).

After we have triggered a rule or rulebook, we may refer to the outcome as

> the outcome of the rulebook

In the case of the visibility rules just mentioned, the default result of the rule would be "success" and the default outcome "there is sufficient light".

9. In any rulebook, earlier rules have priority over later ones: often, by declaring success or failure, an earlier rule will prevent later ones even being asked. This means that the ordering of rulebooks is very important. Inform automatically sorts the rules in order of their applicability, so that more specific rules come before less specific ones, on the grounds that special cases ought to take priority over general procedures. The laws for rule ordering are described in the previous section for reference.

We can also exert a little control over the order of a rulebook by explicitly defining a first or last rule.

If we prefer to control the rule ordering explicitly, we may place (or replace) rules with such statements as

> The collapsing bridge rule is listed first [or last] in the instead rules.
> The collapsing bridge rule is listed before [or after] the moving doorways rule in the instead rules.
> My darkness rule is listed instead of the can't act in the dark rule in the visibility rules.
> The can't act in the dark rule is not listed in the visibility rules.
> The can't remove from people rule is not listed in any rulebook.

These phrases are most often useful for meddling with the contents of the standard rules or of extensions by other authors, since rules we write ourselves are likely already to be in the desired order.

If we need more, we must reach for the procedural rules.

Previous | Contents | Next