version 5 by Aaron Reed
Chapter: Structuring Tasks
Section: Helpful Info
A key point to think about when structuring task objects is this: What steps are actions with consequences not built in to the standard Inform library? "Searching" is a common one: a hidden key is often represented by moving the key object to the map "instead of searching" some object. "Instead" is a giveaway here: the library has no conception that the object and the key are in any way related. For this reason, both "search object" and "take key" should be manually added to the task; the library has no idea that searching the object will result in the key appearing, and so neither does Intelligent Hinting.
If possible, it's best to structure objects involved in puzzles such that they *do* correspond to the world model. For an example of this, see the gold chain in "Adventure," which cannot be removed from the bear until after he is fed and it is unlocked. It would be easy to just implement this with an "Instead of taking the chain" rule, but to make things closer to the world model, we give the chain "fixed in place" by default, and change it to "portable" at the appropriate time. This prevents Intelligent Hinting from attempting to take the chain before unlocking it, which it would do if an instead rule was used, since it would have no way of knowing the chain can't be taken.
Care must be taken, also, with long action-sequences in single tasks. For example: if a puzzle requires dropping a held item and then doing something to it, and these are both part of the same task, the extension will set the item down and then try to pick it up again, since it thinks it needs to be holding it to perform the second action-- and next it will drop the item again since it sees the "dropping" action is incomplete. In a case like this, the event could be split into two tasks: one for dropping, and the next for performing the action.