Extension to limit parser verbs/how to ignore "Understand"

Authoring Inform 7
#1

I’m toying with the idea of putting together an extension to limit parser verbs, either by making the game not recognize entire actions (e.g. “Understand nothing as attacking.”) or by making the game not recognize certain commands (e.g. “Understand the command “hit” as something new.”)

I would probably want to use such an extension just to eliminate verbs that I don’t typically use in my games (e.g. buying in a game in which there is no need to buy anything) but I suppose it could also be useful for authors who want to limit all interaction to just a few actions.

It seems like the most straightforward thing would be to include all possible “Understand” lines authors might want to use, and let them comment out the ones they don’t want. But I don’t think that’s the way extensions are supposed to work.

However, I’m not sure what good alternatives there are. What would be the best and most idiomatic way to have a bunch of “Understand” lines that the author can choose whether to use or ignore?

Any suggestions?

#2

What about use options? You could group the “Understand” lines into groups and give use options like “Use no commerce” that would exclude, e.g., buying and paying and related stuff.

#3

I’m not sure how to go about putting the understand line into groups. Unless you mean attaching conditions to each one, e.g. “Understand nothing as buying if the no commerce option is active.”

Also, I’m not exactly sure how to create a use option. The example given in the manual is

But I’m having trouble figuring out what that means I should actually do. Make up a new constant name and put it after “Constant” and before “;”?

#4

That’s pretty much what I meant (I confess I hadn’t thought too much about how to code it).

I was thinking here about how authors would use it–if the idea is to make it more convenient to zap a bunch of verbs but also give them some flexibility, then you might want to give authors an easy way to switch in and out a bunch of actions at once with one line of code.

Yeah, as I understand it. I don’t think you ever need to refer to the I6 constant again, Inform just needs something to hook the use option to. (From looking at the source for Disambiguation Control, I think this gets turned into a flag for some I6 code that gets conditionally compiled, and a “Use no commerce” declaration in the code sets that flag.)

#5

Ok, thanks.

Two follow up questions:

  1. Is attaching conditions to understand lines for every (or most) verb likely to affect performance?

  2. Is there any advantage to using use options rather than, say, a regular variable to control the conditions attached to the understand lines? I ask because I was trying to figure out if there was a table or list based way to do this. Like, with a table, the author could just copy-paste a table, go down the list and check off which verbs to include (or exclude).

#6

I looked at this, and the problem seems to be testing the use option at the top level of I7 outside of any phrase, where we’d need to place an Understand statement.

I had similar trouble using I6 ifdefs to control I7 code at the top level, because there’s nothing enforcing the ordering of the I6 includes containing the ifdef and endif relative to the I7 statement that they’re supposed to enclose.

However, I was able to get I6 ifdefs to control I6 statements at I7’s top level.

So, I came up with this:

Understand nothing as buying.
Use commerce translates as (- Constant COMMERCE_ENABLED; -).

[Use commerce.]

Include (-
Ifdef COMMERCE_ENABLED;
Verb 'buy' 'purchase'
    * noun   -> Buy
;
Endif;
-).

Test Chamber is a room.

Test me with "buy me".

I inverted the sense of the use statement, since I couldn’t find a way to fully delete an existing I6 verb within I6 after it had been created by I7. So we omit the verb by default and only create it if the use option is set.

A completely different approach would be to write a preprocessor (e.g., python script) that would read a list of which verbs the author wants to include and output I7 code that disables all others.

A third approach would be to chop the standard rules into a number of smaller extensions, with each action or group of related actions in its own extension, and then have standard rules be a meta extension that includes all of these subextensions. People who wanted normal behavior would just include standard rules, while people who wanted to pick and choose would include whatever subset they desired.

This whole situation makes me think that “compile-time activities” would be a cool I7 feature. It would be nice to be able to include/generate code or perform certain compile-time computations at well-defined stages of the I7 -> I6 translation process. (LISP macros plz.)

#7

Thanks!

Ooh, I like this idea. Ideally I’d want to put something like this on a web page (like Juhana’s thing creator) or something, I suppose at github, so no one would have to download the script. I don’t know how to put together that sort of web page (or if it’s even possible given my limited skill) but it seems worth investigating.

#8

Yeowch! OK, never mind about the use options. I hadn’t thought about the table, but if you have a way of doing it with tables that would be even better (and much more flexible, as you wouldn’t need to predefine all the settings the author can use). Authors wouldn’t even need to copy-paste the table, they should just be able to amend it as in Writing with Inform §16.19.

#9

Probably the easiest way would be to provide a block of code, which users could copy into their projects and comment out what they didn’t want. But that’s not exactly an extension and is much messier.

#10

I’m not sure I follow exactly what you mean by this:

Regarding this…

…part of my goal here would just be to save the author typing everything out, because it’s not difficult to disable actions. I’m not sure lines of code to amend a line in a table would be any less of a hassle than typing out “Understand nothing as buying.”

So at this point I’m not sure if doing this as an extension even makes sense. I will experiment though.

#11

Sorry, by “predefine the settings” I meant something like this: Suppose you defined a use option like “use touchy actions,” so that rubbing, touching, and squeezing,* were eliminated unless the author turned on “use touchy actions.” Then the author couldn’t include touching without also including rubbing and squeezing. If it’s done with a table, then they can include anything they like.

As far as typing out the code for the table, I guess what I was envisioning was that the default state of the table would have all those actions turned off, and you could include a line of the table to turn one back on. Writing out one line of a table could well be less hassle than typing out all the Understand grammar for a given verb/action, where you have to make sure you catch all the synonyms.

Daniel’s block of code idea does seem like it might wind up being easier for the authors.

…what about this? If it’s not critical to remove the verbs/actions completely, maybe you could define a kind of action for the actions you want to stop with a message saying not to bother, and another kind of action for the actions you want to let through after all? Like this:

[code]Cavern is a room.

Rubbing is unimportant action. Touching is unimportant action. Squeezing is unimportant action.

Rubbing is actually important action.

Before unimportant action when the current action is not actually important action: say “That’s not something you need to do in this game.” instead.

A lamp is in the cavern.
Instead of rubbing the lamp:
say “A genie appears and whisks you away from this horrible place!”;
end the story finally.

test me with “touch lamp/squeeze lamp/squeeze me/rub me/rub lamp”.[/code]

Then the extension could define all the stuff you usually want to discard as unimportant action, and the author could define anything they want to put back in as actually important action. (You’d have to pick an action–maybe looking–that would be defined as actually important action in the extension, because that’s the only way to get Inform to understand a kind of action. I have a Uservoice suggestion to change that if anyone’s interested!)

*I guess we’re not programming a ShuffleComp entry based on my favorite Journey song.

#12

Would “Understand nothing as buying” not catch all the synonyms?

#13

I was thinking that your extension would include “Understand nothing as buying” and then the work the author would have to do would be to write back in:

Understand "buy [something]" as buying. Understand the command "purchase" as "buy".

Which was not that much work to copy from the Standard Rules, but making an amended line on a table would be even less work.

#14

Ok, now I see what you’re saying. Thanks!

UPDATE: To see what came of this idea, see this thread.