12.9. Check, carry out, report

| Chapter 12: Advanced Actions |

| 12.9. Check, carry out, report

The normal behaviour of an action is specified by its three associated rulebooks - check, carry out and report. In the case of our "photographing" example, these rulebooks will be:

> Check photographing. Here, for instance, we need to verify that the player has the camera. If any of our checks fail, we should say why and stop the action. If they succeed, we say nothing.

> Carry out photographing. At this stage no further checking is needed (or allowed): the action now definitively takes place. At this point we might, for instance, deduct one from the number of exposures left on the film in the camera, or award the player points for capturing something interesting for posterity. But we should say nothing.

> Report photographing. At this stage no further activity is needed (or allowed): whatever effect the action had, it has happened and is now over. All we can do is to say what has taken place.

So far we have not really gone into the business of what rulebooks are, and we don't do so here either - suffice to say that we can now create whatever rules we need:

> A check photographing rule:
> if the camera is not carried:
> say "You can hardly photograph without a camera, now can you?" instead.

In fact, writing "a check photographing rule" is over-formal. We can more simply label our rules like so:

> Check photographing:
> if we have photographed the noun:
> say "You've already snapped [the noun]." instead.

> Report photographing: say "Click!"

For the sake of brevity, photography has no interesting consequence (no points to be won, no film to use up), so there are no carry out rules here. Note the way we used the word "instead" once again to stop actions in their tracks.

We can continue to add rules at any point, and a classic thing that happens when testing a new work is that the designer realises there is a case which has not been thought of:

> Check photographing:
> if the noun is the camera:
> say "That would require some sort of contraption with mirrors." instead.

194
| Example The Dark Ages Revisited An electric light kind of device which becomes lit when switched on and dark when switched off. |
RB

195
| Example Paddington A CUT [something] WITH [something] command which acts differently on different types of objects. |
RB

196
| Example Noisemaking Creating a stage after the report stage of an action, during which other characters may observe and react. |
RB

197
| Example Delicious, Delicious Rocks Adding a "sanity-check" stage to decide whether an action makes any sense, which occurs before any before rules, implicit taking, or check rules. |
RB

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 >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. "Delicious, Delicious Rocks" Section 1 - Procedure The sanity-check rules are a rulebook. This is the sanity-check stage rule: abide by the sanity-check rules. The sanity-check stage rule is listed after the before stage rule in the action-processing rules. Section 2 - Scenario Candyland is a room. The lollipop tree is an edible thing in Candyland. The genuine rock is a thing in Candyland. Sanity-check eating an inedible thing: say "Your digestion is so delicate -- you're sure [the noun] wouldn't agree with you." instead. Test me with "eat lollipop / eat rock". Notice that now Inform does not try taking the rock before rejecting the player's attempt to eat it. 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).

Previous | Contents | Next