version 5 by Aaron Reed
Section: Defining Tasks
Puzzles can also require another new object, the "task." We might call a task "the specific step needed to advance its parent puzzle towards a solution," or, perhaps, "the action the designer wishes the player to take next." Tasks cannot require anything and are always internally sequential.
A task represents a series of actions to be performed. In addition, a task may define a room where those actions must take place in. In fact, both values are optional, though at least one must be present: if no venue is specified, the actions take place wherever the player happens to be, while if there are no actions, the task merely requires being in a certain place.
Again, from Cloak of Darkness:
Noticing-The-Dark-Room is a task. The venue is The Bar. [Note that while this is not strictly necessary to winning the game, it demonstrates the logic of why the later actions are performed, and is thus useful both for testing the clue and so later actions make sense to a player requesting hints.]
Hanging-The-Cloak is a task. The venue is Cloakroom. Requirements for Hanging-The-Cloak: do the action of putting the cloak on the hook.
Reading-The-Message is a task. The venue is The Bar. Requirements for Reading-The-Message: do the action of examining the scrawled message.
Or, from Adventure:
Catching-The-Bird is a task with venue In_Bird_Chamber. Requirements for Catching-The-Bird: do the action of taking cage; do the action of catching bird.
Note the syntax for adding actions. An object-based rulebook, the "requirements" rules, is processed when play begins to generate the list of actions necessary to complete the task, which are added via the "do (a stored action)" routine. Actions are performed in the order they are defined in. This could be useful to create kinds of actions which always require a certain first or last step, as in "First requirements for an eating task: do the action of the person asked taking the fork." (Note that it is always "requirements" even if there is only one.)
It might seem like a great deal of work to define each individual action that must be taken to solve the game in this way. Fortunately, Intelligent Hinting will automatically perform preliminary actions necessary for the commands in our requirements rule to make sense, to the limits of the standard library's world model. This means that it will move to venues via pathfinding and gather any required portable objects along the way. If the venue or a required object is behind a locked barrier, Intelligent Hinting first attempts to locate the necessary key(s) before continuing, and will unlock or open as necessary; if taking an item would exceed the player's carrying capacity, it first tries to drop or put into a holdall the least recently taken thing. It is also smart enough to skip steps that have already been taken: it will not try to wear something that's already worn, or enter something the player is already inside.
Another example from Adventure illustrates:
Recharging-Lantern is a task. Requirements for Recharging-Lantern: do the action of inserting coins into vending machine; do the action of taking fresh batteries; do the action of inserting fresh batteries into lantern.
That's it. We don't need to track down the various items (the coins, the lantern), since the extension will do that for us, and we don't need to specify a venue, since it can see the vending machine is fixed in place and at Dead_End_13, and will navigate the maze on its own.
The result of this is that puzzles can concern themselves less with common-sense actions like opening doors, and more with actions that produce specific changes in our story.