Inform 7: How do I make it so that when the player types specific keywords (in no particular order) certain text is displayed?

I want to be able to make it so that if the player types the keywords 1) either throw or toss, 2) either rock or stone, 3) either smash or break or shatter, and 4) either glass or window then the game says “you throw a rock at the window and the glass shatters” since that is what the player must be trying to do since they typed a combination of those keywords. Ideally, the order that the keywords are typed in doesn’t matter. For example the player could type “glass rock smash toss” and the game would still say “you throw a rock at the window and the glass shatters.” This is so that any sentence can be typed and lead to the solution (ex smashing the glass) as long as the sentence holds the correct meaning. How do I make this happen?

1 Like

Maybe something like this:

After reading a command:
	if the player's command includes "glass/window" and the player's command includes "toss/throw" and the player's command includes "rock/stone":
		say "The window shatters." instead.

And then of course change the description of the window. Does that do it?


I would specifically…

After reading a command:
    if [all that]:
        change the text of the player's command to "rockbreakwindow".

Window-shattering is an action applying to nothing.
Understand "rockbreakwindow" as window-shattering.

This means you can still use Inform’s normal action-processing machinery.

Do you want the whole game to work like this? I mean, will every command be keyword-based in this way?

1 Like

Yeah, that’s the idea.

The Inform parser is very good at handling both verb and noun synonyms. Have you tried that first? As a player I would be frustrated if I entered the quite reasonable command of “throw rock at window” and it failed because I didn’t enter “to smash it” (or even just “throw rock”!). So I’m not sure your goal of helping players would be realised by instructing the parser to ignore all syntactic and contextual clues by just matching keywords instead.


I’ve tried using inform by using the documentation but it seems a lot simpler to just use the keywords method that I’ve been talking about rather than having to read through all of the inform 7 documentation.

Also I could just have the keywords be “throw/toss” and “rock/stone” if I wanted the player to be able to just write “throw rock” to break the glass.

Oh man. I get what you are saying - there is certainly a lot of documentation - but what you’re talking about doing here is going to eventually require far more work, and eventually more advanced knowledge of I7, than if you just start with the basics and work with the system.

Like, as you note here, what happens if the player types a shorthand version of the command? What if they type the right verb but with the wrong object, how do you let them know that that’s a possible action instead of them concluding they should never try that verb again? What if you have two objects with similar names so there’s ambiguity about what object the player means?

Inform out of the box will take care of all of this stuff for you with only a little work; the approach you’re talking about here will require a ton of manual work-arounds that will eventually get fiendishly complex since you’d basically be trying to re-implement the parser from scratch.

I promise, it will be way easier on you - and on your testers and eventual players - to just take advantage of all the stuff Inform is set up to do, rather than try to reinvent the wheel. You don’t need to read all the docs to get started making a game - I think if you read Chapters 1-8 of Writing With Inform, that’s enough to get you on your way, and after you’re good with the basics you’ll probably want to read Chapters 17 and 19. At that point you should have enough grounding to just dip into the other chapters (and/or the recipe book) when there’s some specific thing you want to learn how to do.

That’s still a fair bit of documentation to read, I know, but it’s only like an hour or two to work through, and trust me, if you persist with this new keyword approach you are setting yourself up for many many hours of extra work that won’t actually leave you with a better mastery of the language by the end of it - plus this way you’ll easily be able to get help from folks here if you run into challenges or have questions about how to do something.

Good luck!


It’s also worth pointing out that even with keyword-style parsing, you still want to use Inform’s objects, rooms, actions, and rulebooks. So you’re going to wind up reading through at least two-thirds of the documentation anyway.


This is the the point you should really pay attention to. No one will be able to help you unpick problems if you go about actions this way. My worst experiences have been with doing convoluted, home-brewed solutions instead of taking a breath and trying to understand Inform’s toolbox. Because when you make it up like this, you are assuming that the player will do things exactly as you envisioned them, and players will never, ever do that. Like, never. They will do things you never anticipated. If you’re wrestling with Inform’s toolbox, a ton of smart people here will look at your problem and help you figure out how to tweak your code to cover the bases. With home-brew code, they can’t do that.


This is really swimming upstream against how Inform’s parser is organized, to an extent to which I’d say that if you really wanted a game to work this way, you’d want something other than Inform. If you wanted to use Inform but spend less time understanding how Inform does things, you’d be much better off working within Inform’s normal framework – you’d have to figure out much, much more stuff to do something this idiosyncratic.

I like abusing Inform as much as the next mad scientist, so I cobbled together something that sort of does what you want…

Lab is a room.

Understand the command "throw" as something new.
Understand the command "break" as something new.

Table of Keywords
raw-keyword canonical-keyword
"throw" "throw"
"toss"  "throw"
"break" "break"
"shatter"   "break"
"smash" "break"
"glass" "glass"
"window"    "glass"
"rock"  "rock"
"stone" "rock"

Keywording is an action applying to one topic.
understand "keyword [text]" as keywording.

Keyword-action is a text based rulebook with default success.

keyword-action "break glass rock throw":
    say “you throw a rock at the window and the glass shatters.”

last keyword-action: rule fails.

carry out keywording: follow the keyword-action rules for "[the topic understood]".

After reading a command:
  let L be a list of texts;
  let cmd be the substituted form of "[the player's command]";
  repeat with i running from 1 to the number of words in cmd begin;
    let w be word number i in cmd;
    if w is a raw-keyword listed in the table of keywords, add the canonical-keyword entry to L;
  end repeat;
  if the number of entries in L is 4 begin;
    sort L;
    now cmd is "keyword";
    repeat with w running through L begin;
      now cmd is "[cmd] [w]";
    end repeat;
    change the text of the player's command to cmd;
  end if;

But what it doesn’t do is relate any of those words to objects within the game – you’d have to replace all that functionality yourself.


The replies in this thread have added up to a lot of pushback – mine included! – so I want to make the devil’s case for a moment.

IF parsers settled on a “standard model” in the early 90s. (Basically a table of VERB OBJ, VERB PREP OBJ, VERB PREP OBJ PREP OBJ, … with smart matching of OBJ phrases.) The idea of picking keywords out of a soup of words went by the wayside. Some early games did it! I learned about His Majesty’s Ship “Impetuous” from Aaron Reed’s blog series, for example. And there’s stuff like Starship Titanic’s SpookiTalk, which… I don’t know that I’ve ever seen a discussion of how that worked under the hood.

Anyway. We recognize that the standard verb model doesn’t work great for dialogue with NPCs. Inform 7 reintroduced keyword-ish parsing under the heading of “topics”. I think you could write a whole game using topic matching without descending into regexes or the “After reading a command” rulebook. And that would sort of make sense, for an all-dialogue game? You wouldn’t get this kind of response if you suggested it, anyway!

For messing-around-with-handheld-objects games, the standard verb model is very entrenched. Then again, the audience is also very entrenched! We’re all familiar with both the existing parser dev tools and the existing parser games. So it’s a little unfair to completely shut out the idea.

But it’s true that it’s swimming upstream in Inform.


Yes, I don’t think this is a terrible idea—Inform even has examples for how to completely replace the parser with a keyword-matching system (“Fragment of a Greek Tragedy”). It would be interesting to see what the modern descendants of the keyword-parsing games like Local Call for Death and HMS Impetuous would look like.

I do think, if you want the entire game to work this way, it’s going to be difficult to do this in Inform. Someone with a lot of Inform experience could design an extension that makes this easier—that’s basically what Zed is setting up—but I think it’s going to be difficult to do as a beginner, and will involve reading a lot more of the documentation than you’d expect.

In the meantime, while such an extension doesn’t exist (but I’m now tempted to see what I can do), you may find it easier to use a different programming language instead (Python or JavaScript or whatever you’re familiar with). The main thing you’d lose is Inform’s natural language syntax and its world model, and the syntax isn’t much use to you if you haven’t worked through the documentation yet.


Since I’m now the person least experienced with Inform responding to you (and therefore closest to your own experience level):

The problem/concern you mentioned was reading the documentation in its entirety. I can understand why looking at all of the documentation might make you want to do something else. The truth is, the docs make a lot more sense if you are already trying to do something with Inform. If you are trying to build a room for the first time, you will use hardly any of the documentation. I don’t think reading it from start to finish before touching the IDE is a good way for beginners to get excited about their first game.

Why not try a room, reading as you go? Then try it with your keyword approach. There’s no harm in running an experiment. I think you’ll find you’re reading the documentation either way, but probably not in order. Judge for yourself.


Have to strongly second this and similar opinions in this thread. What you essentially seem to be asking is ‘How can I code in Inform without learning Inform’, which is a bit like asking ‘How can I speak Japanese without learning Japanese’. Idyllic though it sounds, I fear you are choosing the path of pain!


Thanks for the feedback everyone. I have another question that is an extension of this post. Let’s say that the player puts the right keywords in and so the game says “you throw a rock at the window and the glass shatters.”

How do I make it so that when the game says “you throw a rock at the window and the glass shatters” the following gets activated (basically meaning that it appears and influences the game as if it had “never existed” before):

After reading a command:
	if the player's command includes "jump/go" and the player's command includes "through/into/inside" and the player's command includes "window/broken window/window frame":
		say "You jump through the broken window" instead.

And how do I make it so that when the game says “you throw a rock at the window and the glass shatters” the following gets DEactivated (basically meaning that it gets “deleted” and does not influence the game anymore):

After reading a command:
	if the player's command includes "jump/go" and the player's command includes "through/into/inside" and the player's command includes "window/broken window/window frame":
		say "You try to jump through the window and shatter the glass with your body but the window is too strong and you fall backwards" instead.

The usual way is to have it tied to some state in the world.

The window can be broken or unbroken. The window is unbroken.
After reading a command when [conditions] and the window is unbroken: