Verb confusion- trying to feed my animals

For completeness, here’s how I conceptualize all the stages of action processing.

  • “After reading a command” rules are used to interfere with what the player typed, before handing it to the parser. This is what I would consider “overriding the parser” and I recommend avoiding it if it’s at all, in any way possible. These rules are meant for things like changing punctuation, not trying to do any actual parsing.
  • Then the parser does its job and turns the command into an action. The rest of the rules apply to an action, not to a command.
  • “Before” rules are used to alter the action before doing any feasibility checks. I like to use them for converting one action into another: “before opening the desk: try opening the drawer instead”. We don’t need to bother doing any feasibility checks on the original action, because it’s just going to be turned into something else.
  • The action is checked for feasibility: can the player see all the things they need to see, and touch all the things they need to touch? This is where an action will fail if it’s too dark, or if the noun is inside a locked cage. If you want to meddle with this stage, you can hook into various advanced activities, like “reaching inside” (the rules that decide if you can fit your hand into the cage) and “visibility” (the rules that decide if it’s too dark to read a book). Some extensions rename this stage to the “precondition” stage, to make it easier to write your own rules for it.
  • “Instead” rules are used to override the rest of the action processing in a particular case. At this point, the action is known to be feasible in a basic sense—if it requires something to be touchable, then that thing is indeed touchable, for example—but none of the specific rules for that action have been checked. This makes it ideal for special cases like eating a rock, which would otherwise be blocked by…
  • “Check” rules are used to make sure the specific action makes sense. These are the rules that say you can’t eat something that’s not edible, and you can’t take something that’s not portable, and so on. For some actions, there’s a built-in check rule that always stops the action. This means these actions will never do anything unless you use “instead” rules to make an exception. (For example, the burning action is always blocked with the message “this dangerous act would accomplish little”.)
  • “Carry out” rules are used to make the action do its normal, expected behavior. “Carry out eating” removes the object from the game. At this point we know the action hasn’t been handled by a special exception (“instead”) or blocked for not making sense (“check”), so the default behavior is what we want.
  • “After” rules run here, once the action has been handled in its default way. These are useful if you want the behavior of the action to work as expected, but you want to override the description for a special case. If you eat a poisoned cake, the eating action should function normally, but the description should change to say you feel sick. That would be an “after” rule.
  • “Report” rules run at the very end, if nothing else has stopped the action, to describe the default behavior. A “report eating” rule will describe that you devour the object. These rules are completely skipped if you “silently try” an action, which is good for situations where you don’t want to describe success, only failure. For instance, if you try to unlock a door but you’re not holding the key, the game will silently try taking the key: if this works as expected, it won’t interrupt the text with a “Taken.” message, but if something goes wrong (an “instead of taking the key” rule gives you an electric shock), that description should be printed.

Any of these stages (except “carry out”) can stop the action, saying no further processing should happen. So if you handle a special case with an “instead” rule, you don’t have to worry about check, carry out, after, and report getting in the way. This is normally what you want, but it means you do have to handle some aspects of the default behavior on your own—if you have an “instead of eating” rule that’s supposed to remove the object from play, you’ll have to remove it yourself, instead of relying on “carry out” to do it for you.