![]() | Chapter 6: Commands | ![]() ![]() |
6.3. Modifying Existing Commands |
Much of the rest of this chapter discusses the behavior of specific commands in Inform's command library, and how we might change and build on these. This section is instead an overview of the general principles: where and how can one intervene?
Whenever we are dealing with actions, the Actions Index is likely to be useful: it lists all the actions currently implemented, whether in our own source or in extensions or the Standard Rules, and lists the rules pertaining to each.
The lightest and easiest way to change behavior is with an Instead rule:
Instead of eating the apple:
say "It turns out to be made of beeswax, so that's a non-starter."
Instead of tasting an edible thing:
say "It's delicious!"
rule succeeds.
The addition of "rule succeeds" tells Inform that the instead action was a success rather than a failure; this is not usually very important with the player's own actions, but can be useful for actions performed by other characters, so that a successfully replaced action is not followed by the disconcerting line
Clark is unable to do that.
Before and After offer alternative easy forms of modification; the Basic Actions chapter explains all three.
Changing the way an action works in all cases is usually better addressed by changing the main rulebook, rather than with one (or many) instead rules. We may add new check, carry out, and report rules to existing action rulebooks. The Advanced Actions chapter describes these, and ends with some guidelines on when to use before, instead, and after, and when to use check, carry out, and report.
Similarly, we may delete, move, or replace rules that are already present (see the chapter on Rulebooks). This is handy if we decide that an action has restrictions that we dislike and want to abolish. If the restriction we need to change is part of the accessibility rules - those which check whether the player can take, see, and touch items - we may need to look at Changing reachability or changing visibility in the Advanced Actions chapter (to revise what is allowed), at deciding the scope of something in the Activities chapter (to influence what can be seen when), or at Procedural rules (to remove restrictions entirely).
If, for instance, the player character is a burly fellow who can lift any other character he likes:
The can't take other people rule is not listed in any rulebook.
...and rip knobs off doors:
The can't take component parts rule is not listed in the check taking rulebook.
...and commit petty theft:
The new can't take people's possessions rule is listed instead of the can't take people's possessions rule in the check taking rulebook.
This is the new can't take people's possessions rule:
if someone (called the owner) carries the noun:
say "(first waiting until [the owner] is distracted)";
The right approach to use also depends a bit on how systematic a change we anticipate. We may find that instead rules become cumbersome when we want to specify behavior for a very large number of objects. It's fine to have
Instead of tasting the arsenic:
say "You'll live to regret this very very shortly.";
end the story.
but a bit more tedious to have to write
Instead of tasting the peppermint: ...
Instead of tasting the plate: ...
Instead of tasting the banister: ...
Instead of tasting the donkey: ...
(etc.)
in a game in which most items have unique flavor descriptions. In that situation, it may be more sensible to overhaul the design of the action: create a new text property for things, and revise "tasting" so that it now consults this property:
The block tasting rule is not listed in any rulebook.
A thing has some text called the flavor. The flavor of a thing is usually "Nothing special."
Report tasting something:
if the flavor of the noun is "Nothing special.":
say "You taste nothing unexpected." instead;
otherwise:
say "[the flavor of the noun][paragraph break]" instead.
Report someone tasting something:
say "[The actor] licks [the noun]."
One other way we might want to interfere is by lifting the restrictions on whether an item needs to be carried or touchable in order for an action to succeed. We could do this by completely redefining the action to omit the carried restriction; for instance, the following would create a new "donning" action that did not attempt to take objects the player wanted to wear:
Understand the command "wear" as something new.
Understand "wear [something]" as donning. Donning is an action applying to one thing.
This is usually troublesome, and a more satisfying solution usually is to use a procedural rule to turn off the problematic requirement only under specific circumstances. There are three rules that are called between the Before and Instead phases that enforce these restrictions:
the basic accessibility rule
the basic visibility rule
the carrying requirements rule
and we may want to override these selectively using procedural rules. For instance:
A procedural rule when wearing:
ignore the carrying requirements rule;
ignore the can't wear what's not held rule.
The first of these two rules is the general rule that generates the "(first taking..." action; the second is a restriction particular to wearing that disallows wearing anything if the taking has failed.
We can make such modifications even more specific, as in:
A procedural rule when giving the berries to someone:
ignore the carrying requirements rule;
ignore can't give what you haven't got rule.
(Something very similar would work for showing, since the giving and showing actions are almost identical in structure.)
Procedural rules can also be handy if we want to override check rules from the existing check rulebooks but only in very specific cases. The Locksmith extension uses the following rule to allow the player to put objects on a keychain, even though normally we aren't allowed to stack objects that the player is carrying:
Procedural rule when putting something on a keychain (this is the allow putting things on the keychain rule):
ignore the can't put onto something being carried rule.
Slogar's Revenge demonstrates related solutions for locking and unlocking doors when the player should be allowed to lock and unlock with a key he is wearing rather than carrying.
Finally and most sweepingly, we can rip out whole passages of the Standard Rules and replace them - or not. This is a drastic measure and rarely necessary (or so we hope); but see the Extensions chapter for ways to replace sections of existing source, or even revise the Inform 6 template files on which Inform depends. By these means almost anything can be changed. We can throw out a whole range of existing commands and start from scratch, for instance, if we want Inform to know about a completely new and different command set.
See Magic (Breaking the Laws of Physics) for a hat that lets the player walk through closed doors, and an NPC able to reach through solid containers
| ![]() ![]() ![]() Creating an amulet of tumblers that can be used to lock and unlock things even when it is worn, overriding the usual requirement that keys be carried. |
|
Previous | Contents | Next |