6.3. Modifying Existing Commands

| 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

214
| Example Slogar's Revenge 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. |
WI

Under most circumstances, locking and unlocking require the player to be carrying the key he uses to unlock something. This makes sense -- unless the key is on a keychain, or on a chain around his neck, for instance. So here we explore one way to circumstantially override the carrying requirements, while still making sure that the player cannot unlock the door if the unlocking tool is nowhere in sight. In essence, we are rewriting the carrying requirements rule with a different one of our own devising, and swapping it in only at those moments when it is correct to do so. "Slogar's Revenge" Section 1 - Procedure Procedural rule for locking something with the Amulet of Tumblers: substitute the amulet carrying rule for the carrying requirements rule. Procedural rule for unlocking something with the Amulet of Tumblers: substitute the amulet carrying rule for the carrying requirements rule. We can now replace the usual behavior of the carrying requirements rule (to check whether the player is carrying something and, if not, to generate an implicit take) with a similar rule of our own; note that "if the player has the second noun" is a more compact way to write "if the player carries the second noun or the player wears the second noun": This is the amulet carrying rule: if the player has the second noun: continue the action; say "(first picking up the amulet)[command clarification break]"; try silently taking the second noun; if the player is not carrying the second noun: stop the action; Section 2 - Scenario The Daunting Dungeon is a room. West of the Daunting Dungeon is the Disturbing Door. The Disturbing Door is a door. West of the Disturbing Door is the Fallow Field. The Disturbing Door is closed and locked. The player wears the Amulet of Tumblers. The Amulet of Tumblers unlocks the Disturbing Door. Test me with "unlock disturbing door with amulet / open door / west / remove amulet / close door / lock disturbing door with amulet / drop amulet / unlock disturbing door with amulet". For a more systematic handling of the keychain problem (and a number of other refinements to the behavior of doors), see the Locksmith extension included with Inform.

Previous | Contents | Next