§18.34. Implicitly taking something
1. When it happens. When an action is tried which requires the actor (normally the player, of course) to be carrying something, but which is not in fact carried by that person. For instance, if the player types WEAR OVERCOAT in reference to a Moroccan overcoat currently draped over a chair.
2. The default behaviour. To print text such as "(first taking the Moroccan overcoat)" and then silently try taking the object in question (the overcoat). If the take succeeds, the silence means that nothing else is printed: if it fails, it will say why.
No matter what rules are written for this activity, it is impossible to use it to allow the action to go ahead even without the item. The activity allows us to change how, or if, an implicit take will happen, but not to change the consequences of failure. (To do that, we would need to say that "The ignore the carrying requirements rule does nothing", but this kind of unstitching of the action machinery needs to be done with caution.)
3. Examples. (a) Forbidding implicit takes for certain dangerous items. (This seems especially fair if taking such items might cause death: the player will not wish to be killed on the strength only of our guess as to what he might be intending to do.)
Rule for implicitly taking the curare:
say "Ordinarily you'd pick up the curare in order to be able to do that, but this seems like a good moment for caution." instead.
(b) Changing the way the implicit action is reported for the player:
Rule for implicitly taking something (called target):
try silently taking the target;
if the player carries the target, say "You appropriate [the target] first, of course. [run paragraph on]"
(c) Combining implicit takes when the noun and second noun must both be carried:
Rule for implicitly taking the noun when the second noun is a thing and the second noun is not carried by the player:
try silently taking the noun;
try silently taking the second noun;
say "(first taking both [the noun] and [the second noun])[line break]"
(d) Making another character reply amusingly:
Rule for implicitly taking something which is carried by the player when the person asked is Clark:
say "'I don't see how I'm supposed to do that when you're holding [the noun],' remarks Clark sulkily." instead.
(e) Causing implicit takes which wouldn't otherwise happen. Suppose we have a photographing action, and there are very small flowers which can't conveniently be snapped without being first picked. We then want an implicit take to occur, even though we wouldn't want this for other sorts of photography. So:
Check an actor photographing a flower:
if the actor is not carrying the noun:
carry out the implicitly taking activity with the noun;
if the actor is not carrying the noun, stop the action.
Note that if the activity doesn't succeed in taking the item, it's expected to print some text explaining this, which is why we don't need to say anything further.
![]() | Start of Chapter 18: Activities |
![]() | Back to §18.33. Reading a command |
![]() | Onward to §18.35. Printing a parser error |
Implicit takes are a convenience to players; in general, we would like to avoid asking players to type any more obvious commands than strictly necessary, while allowing the computer to guess as much as it safely can. Occasionally, though, we have designed a timed puzzle in which the player has a limited number of moves in which to accomplish his objectives. In that case, the implicit take complicates matters, because it means that a player who types
gets away with a spare move compared to the precise but naïf dupe who types
...and really, that doesn't seem quite fair. The way to fix this problem is to fill in the extra minute on the clock during the implicit take; and that is indeed what we do in the following example.
|
|
Implicit takes are a convenience to players; in general, we would like to avoid asking players to type any more obvious commands than strictly necessary, while allowing the computer to guess as much as it safely can. Occasionally, though, we have designed a timed puzzle in which the player has a limited number of moves in which to accomplish his objectives. In that case, the implicit take complicates matters, because it means that a player who types
gets away with a spare move compared to the precise but naïf dupe who types
...and really, that doesn't seem quite fair. The way to fix this problem is to fill in the extra minute on the clock during the implicit take; and that is indeed what we do in the following example.
Implicit takes are a convenience to players; in general, we would like to avoid asking players to type any more obvious commands than strictly necessary, while allowing the computer to guess as much as it safely can. Occasionally, though, we have designed a timed puzzle in which the player has a limited number of moves in which to accomplish his objectives. In that case, the implicit take complicates matters, because it means that a player who types
gets away with a spare move compared to the precise but naïf dupe who types
...and really, that doesn't seem quite fair. The way to fix this problem is to fill in the extra minute on the clock during the implicit take; and that is indeed what we do in the following example.
|
|
|