Verb confusion- trying to feed my animals

Hi hi,

I didn’t think that “feed” was a built-in verb in Inform7. So, I created a custom verb:

Feeding is an action applying to one visible thing. Understand “feed” as feeding.

Instead of feeding Chelsea:
say “You’ll need some food first.”

This compiled fine, but when I ran the game with actions listed, the “feed” command triggered the “give” verb. This seems like something that should happen if “feed” already exists as a verb and inform7 understands “feed” as giving.

I’m clearly not understanding something.
Thanks for your help!


Start reviewing here: 17:3 Overriding existing commands

Essentially if FEED is a synonym for GIVE you must either decouple it from that to make new rules, or you might just use the “give” grammar since it’s already pretty much what you want and makes the same standard parser check. Write rules for what happens if you GIVE HAY TO BUCEPHALUS.

Also remember when you use INSTEAD you’re taking over control from the parser which may not be the best option in the scheme of things…


Actions listing on.

give hay to maysie

[giving the hay to Maysie]

(first taking the hay)

[(1) taking the hay - silently]

[(1) taking the hay - silently - succeeded]

Maysie doesn’t seem interested.

[giving the hay to Maysie - failed the block giving rule]


Farm is a room.

A cow is a kind of animal.
A food is a kind of thing. Food is edible.

Maysie is a cow in Farm. "Maysie the cow is here."

some hay is a food in farm. The description is "Delicious...for cows."

Instead of eating hay:
	say "Ick. Ew. No. That's been on the ground with the manure. Animals may love it though."

The block giving rule does nothing when the noun is a food.

After giving a food to an animal:
	try the second noun eating the noun.

After giving hay to Maysie:
	try Maysie eating the noun;
	say "'Moo!' bellows Maysie, in the manner of a satiated cow."

Maysie the cow is here.

You can also see some hay here.

feed hay to maysie
(first taking the hay)
Maysie eats the hay.

“Moo!” bellows Maysie, in the manner of a satiated cow.

1 Like

I’ll recommend this Standard Rules Action Reference which includes all the actions indexed by command and vice versa.

1 Like

Thank you, Hanon.

I think I was trying to figure out if “feed” was already coupled to “give,” OR if I was just completely off-track.
Your example is helpful, and I do like the satiated cow.

re: your caution about using “Instead”
I’ll be the first to admit that I don’t fully understand the difference between using “instead” vs “after” or “carry out.” (I understand them on a basic level, but… I’d appreciate some guidance)

Hi Zed,

This is soooooo useful! thank you! and I do love a spreadsheet!

The general principle I follow is:

  • “Carry out” is for the standard implementation of an action (giving an item transfers it to the other person’s inventory)
  • “Instead” is for exceptions to that standard implementation (this one particular person refuses to accept any objects)
  • “After” is for exceptions to the standard description of the action (it functions normally but is described separately)
1 Like

Most commands are parsed in phases with rulebooks that figure out if they can succeed or not. Daniel pointed out some. In general you can write rules for any phase:

  • Before (stuff that happens before action processing and could stop it - before getting in a vehicle, make sure you have your keys)
  • Check (usually “if this is true, stop the action or do something else” conditions such as making sure a player has learned a spell before casting it)
  • Carry Out (all the check rules have passed and the action is happening - world state changes should go here and all these directions won’t stop the action or ideally don’t redirect. For example, a player flips a mysterious light switch that turns on the lights like normal, but also electrifies a fence, blocking their path. This is where you get the advantage because the author can add one rule carry out switching on the dodgy electrical switch: now the guard gate fence is dangerous. That turns on the switch like normal but also does something else in the process - instead of trying to stuff all the effects that include moving the switch and lighting the room and electrifying the fence etc. into a complicated INSTEAD rule.)
  • After (intercepts before standard report rules for special messages like “Maysie moos” or can set off special results when an action has happened: After switching on the dodgy electrical switch for the first time: now the generator is on fire; say "After flipping the switch, you smell electrical smoke from the west." After rules stop the action - the action has physically happened since we’re past Carry Out, but it stops the general action report messages unless the After rule explicitly continues the action.)
  • Report (the general response(s) to a successful action, like “Taken.” Report rules are cumulative unless explicitly stopped, so you can write report taking the magic flower: say "This makes you very happy to hold it in your hand." which will print that and then the default response, “Taken.”)

Instead intercepts all of these and puts parsingaction processing in the author’s hands, which is why you don’t want to rely solely on Instead rules for any complicated action that does a lot of stuff. I used it because we know we don’t ever want the player to eat hay. What you want to avoid is making any major world-state changes inside an Instead rule because you will often miss something.

If you say:

Instead of taking the light bulb:
    say "You now have a bright idea!"

But the player won’t have the light bulb since the instead rule took precedence over every other rule that runs normally for a TAKE action, including moving the bulb to the player’s inventory. Even if they have the light bulb this rule will always run since the parser is precluded from checking normal world state. It’s like an executive order from the author.

1 Like

I wouldn’t put it quite like that—“instead” is a stage just like any other, coming between “before” and “check”. In particular, “instead” rules can’t bypass “before” rules: as the name suggests, “before” rules are the very first ones that happen once the game knows what exactly the player is trying to do.

“Instead” rules are meant to override the standard action processing, after it’s known that the action is feasible (you can see or touch the appropriate thing), but before any of the action’s specific checks run.

Suppose you want to print a snarky response if the player tries to eat a rock. You’ll want to insert a rule after it’s known that the action is feasible (the player can actually touch the rock), but before any of the specific checks for eating take place (like the one that says rocks are inedible). That’s what an “instead of eating a rock” rule is perfect for!

As Hanon noted, it does bypass all the action-specific processing: both the rules that prevent illogical actions (“check” rules are the ones that prevent eating rocks) and the rules that handle the action in standard, expected cases (“carry out” rules are the ones that will make food disappear when you eat it). But a lot of the time, that’s exactly what you want! Interactive fiction games are made of special cases and exceptions, and “instead” rules are the main mechanism Inform provides to create them.

(“Instead” rules also don’t override the parser, they override the action processing, which is a bit pedantic but is an important point. “Instead” rules only kick in once the parser has already figured out what action the player wants to do.)


this- what you said right here- about what before, and check, and carry out- actually makes happen- is soooo helpful! thank you.

and ya, I think i did know that “instead” was a major over-ride.

1 Like

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.


One thought I would add to this excellent synopsis is that I conceptualise going into the “Before” stage as when the actor (player or NPC) just has the idea of the action in mind, and has not yet really thought about how to carry it out. Considerations such as light, touchability and what they are actually carrying don’t yet apply.

So this is where to:

  • stop the action in its tracks if the actor shouldn’t even be thinking about doing that thing:
    Before answering the invigilator that:
        say "You reconsider and keep silent." instead.
  • arrange for things to automatically get picked up if they need to be carried; lights to automatically to be switched on if light is required etc. in preparation for the rules upcoming that might stop the action if these conditions aren’t right:
    Before unlocking the oaken door with when the brass key is in the location:
        say "(first taking the brass key)[command clarification break]";
        silently try taking the brass key;
        unless the player holds the brass key:
            say "You can't unlock the oaken door without its key." instead.
  • switch the action to a different one that’s more appropriate than the one the parser picked:
    Before entering the Gorge of Eternal Peril:
        try going the Bridge of Death instead.

I am so sorry for replying so late to this…
SO sorry!
because this feels like all I’ve ever wanted! - a conceptual framework for these rules.

and you were so generous.

THANK you!


This is also so very helpful, and generous!!!