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?
Someone gave me the answer for how to do the above. The code is:
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.
I want to take this a step further and figure out how to do the following:
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.
Something can be whole or broken or jumped. Something is usually whole.
After reading a command:
if the window is whole:
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;
now the window is broken;
otherwise if the window is broken:
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;
now the window is jumped.
Now the responses will only fire when the right tag is applied.
**Edit: An “otherwise” is needed to give the player some kind of logical response from the parser if they do the wrong action. Like:
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;
now the window is broken;
otherwise:
say "Nothing happens." instead.
This’ll work, though as a point of nomenclature these are called “properties” in the documentation, like here: 4.7. New either/or properties.
It’s also important to note that the order of the conditions and how the different statements are nested is going to be super important if you take this approach – since as written you’re just firing these rules after reading a command, there’s going to be a hideous amount of complexity in figuring out which order things get evaluated in, and you’ll need tricks like Amanda’s “otherwise” to make sure you don’t like change a property in one loop and then inadvertently satisfy a separate test elsewhere.
You can mitigate this somewhat by breaking rules out separately rather than chucking into one giant after reading a command rule, but then you’ll need to worry about the order in which those rules are evaluated. That’s something you can manually tweak, but it takes more advanced Inform skills and is going to be very fragile and bug-prone.
Similarly, because these rules just look at keywords and you’re not using the Inform world model, right now none of these rules change depending on whether the player is in a room with a window, or whether there’s a rock nearby. So again, you’ll need to put special-case conditions in each of these rules to make sure they’re not firing inappropriately, and provide failure messages if the player tries to do an otherwise-valid action in circumstances where it doesn’t make sense.
This is what I meant in the other thread when I said that by trying to do this keyword thing instead of reading the basics of the docs, you’re setting yourself up for a hideous amount of extra work, a mountain of bugs, and a need to dive into the deep end of Inform’s rules engine as you basically re-implement the parser one special case at a time. I don’t want to be a jerk so this is the last time I’ll post this in one of your threads, but seriously – turn back! This is a bad idea!
My understanding is, you’re not trying to use Inform’s world model here. In other words, you don’t want the usual complement of rooms, things, and actions that let you GO WEST and TAKE BOX and OPEN WINDOW. Please correct me if I’m wrong about this.
But if that’s correct, I actually recommend not using Inform at all. Inform has some very strong built-in assumptions about how those things work, and you’re going to be fighting tooth and nail against those assumptions every step of the way.
Instead, I’d recommend doing your keyword-based parsing in a general-purpose programming language, like JavaScript or Python, if you have experience with any of those. That will give you complete, perfect control over when certain combinations of keywords are recognized and when they aren’t, and you can track the state of the game in any way you like.
Now, if you do want Inform’s world model of directions and containers and all that…well, based on your threads I’ve started sketching out an extension that lets you override the parser like this in a reliable, systematic way. I figure it could be good for dialogue systems or for working in the Robert Lafore tradition of IF.
I have no idea if or when I’ll have it in working order, but my main contribution to this forum is thinking “huh, Inform is really bad at doing this thing” and inventing an extension to make it work.
That’s kind of my take on this as well. The important question is who is the audience for this? Experienced parser players pretty much know they need to use “blunt” commands - BREAK WINDOW. ENTER WINDOW - instead of typing something off the rails like SHATTER THE PANE OF GLASS AND VAULT THROUGH.
Many have tried to make a parser-ish system that’s easy for people who don’t want to get used to the parser … which is kind of throwing out the baby with the bathwater - the point of parser interaction is that it allows somewhat unique interactions within the confines of the model world and there are tropes and expectations experienced players have and limits they mostly understand. Typing the command out of order like GLASS ROCK SMASH TOSS would likely feel ludicrous and more difficult than doing it more simply and logically.
If you’re catering to an audience for whom it is seriously beyond their capability to type simple two and three-word sentences. I’d almost suggest that more limitations on their interactions instead of fewer might be the correct way to go.
Use a choice narrative where every potential method of interaction in a scene is listed. Or something like Texture where you can present actions that can be dragged to one or more words in the description to create an action.
Not that you shouldn’t use Inform, but at some point if you need to drive a nail you will do better using a hammer instead of trying to make a pair of pliers work like a hammer.
Like Draconis said - Inform is very flexible. If you want the world model and rules, you could use one of several extensions such as “Hybrid Choices” to create a choice interface on top of the parser.
One trick I did with Hybrid Choices is interrupt any interaction besides examining with specific objects and jump right to a choice list. You could make a rule so anything like OPEN WINDOW/TAKE WINDOW/HIT WINDOW/KISS WINDOW would instead give a menu of obscure non-parser choices like
“What do you want to do with the window?”
Open it.
Smash it.
Admire your dim reflection.
Polish the glass with some Windex
Breathe on it and write curse words so the next person who takes a shower will see them…
But with enough synonyms defined Inform’s parser could easily handle that.
Really, the main thing to do is just to ensure you have some beta-testers. Read through their transcripts, and if there’s any point in which they have trouble, adjust the game so that it will recognise what they’re trying to do. You can’t ensure your game will understand every possible thing someone will want to enter into it, but it doesn’t take a lot of work to add extra synonyms, both common and obscure.
My advice is always to read the manual, create your IF piece as you go, ask for help and advice on this board when you need it. It sounds as if you’re trying to get Inform7 to work in a way that wasn’t intended. When you read and understand the concepts in the manual and put them in practice, there will be almost nothing you can’t do, that can be done in a parser-based IF. It’s worth the effort. It’s the most fun when you go over the manual, page by page, and make up your own examples, or even add to your IF piece, as you go, using the concepts that you learn. You can be creative throughout.
My understanding is, you’re not trying to use Inform’s world model here. In other words, you don’t want the usual complement of rooms, things, and actions that let you GO WEST and TAKE BOX and OPEN WINDOW. Please correct me if I’m wrong about this.
I want to use a little of informs built in world model: Rooms, taking items, and going west/east/south/north. Pretty sure that’s it.
Parser override when the player's command includes […]:
override attacking the window.
Note that anything you want to override the parser on still has to translate to some sort of action. But you can define new actions for this purpose if you like.