§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.
![]() | Start of Chapter 12: Advanced Actions |
![]() | Back to §12.8. Irregular English verbs |
![]() | Onward to §12.10. Action variables |
|
|
|
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
Here is how we might insert such a stage in our action processing, using rulebook manipulation.
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
...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). |
|
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
Here is how we might insert such a stage in our action processing, using rulebook manipulation.
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
...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). 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
Here is how we might insert such a stage in our action processing, using rulebook manipulation.
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
...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). |