One of my beta testers just found some very odd behaviour. He was trying different shortcuts, such as “l” for “look”, “i” for “inventory”, etc and he tried “g”, thinking it was a shortcut for “get”. So, he typed “g crowbar” and it tried to move him east instead of getting the crowbar. He then moved west to a room with no crowbar in it and typed “g crowbar” and it moved him west again. He then tried nonsense like “g flibble” and it did the same thing.
We figured out that it was repeating the last command and was ignoring whatever was typed after it (which is very inconsistent with how other actions work) and after digging around for a while, I found the “again” command and realised that “g” is short for “again”.
So, to avoid confusion, I decided to remove those commands with:
Understand "again" and "g" as something new.
but it doesn’t work. Every other action I’ve ever done this with, becomes an unknown verb, unless I assign it to a new action.
Then I tried this, hoping to spoof the behaviour of an unknown verb:
Understand the command "g" and "again" as something new. Gerfing is an action applying to nothing. Understand "g" and "again" as gerfing.
Instead of gerfing:
say "That's not a verb I recognise."
but both “again” and “g” still repeat the previous command.
Does anyone know of a way to remove “again” and “g”, so that they are no longer recognised verbs?
The long answer is that processing AGAIN takes place first in the I6 parser code, before any grammar lines are considered. Thus you can’t change this behavior short of changing the parser directly. And the parser is somewhat difficult to change at a practical level. Either you have to have an impractically long inclusion in your I7, or you need to modify the CommandParserKit directly. (Someone may want to correct me on this?)
I would instead have a COMMANDS action that among other things includes the AGAIN/G command.
Again/g is indeed handled deep inside the parser but the actual words are exposed as constants which you can override with simple inclusions.
Include (- Constant AGAIN1__WD = ' '; -) replacing "AGAIN1__WD".
Include (- Constant AGAIN2__WD = ' '; -) replacing "AGAIN2__WD".
Include (- Constant AGAIN3__WD = ' '; -) replacing "AGAIN3__WD".
Be sure not to use empty quotes '', it’s not valid (I don’t know enough I6 to tell why).
I used a space (' ') since the parser will not try to match a space.
If someone mistook the A-button (JUMP) with the B-button (SHOOT) in Super Mario, would you remove a button? Or try to explain to the player which button does what?
The tester had a mistaken assumption about an abbreviated command. (A deeply rooted convention even.) Simply telling that tester: “No, that button does something else.” solves the problem.
After reading a command:
if word number 1 in the player's command is "g" or word number 1 in the player's command is "again":
say "Performing last action again.";
If it worked like other commands, I probably wouldn’t, but a lot of the confusion seems to come from the fact that “g” ignores everything typed after it, which makes it seem to the testers as if it’s doing something related to what they typed (eg. “g crowbar”). Especially since I’ve now had another tester send me an email telling me that the abbreviation for “go” is “doing something weird”.
It just seems to be so confusing to some people (and not really all that useful), that removing the command seems to be the cleanest solution.
I don’t know inform 7, but it looks to me the cleanest solution would be to catch the cases where g is followed by more text and print a helpful error message.
How familiar with parsers are your testers, and who do you expect to be playing your parser?
Most people willingly playing a parser are probably gonna be people who know what ‘g’ means and find it very useful and important (i.e. people familiar with parsers).
Removing it will cause more frustration than just printing out a message that says “repeating last command” (like others suggest) when it fires.
Do people use “g / again”?
I’ve always found that ↑ (up arrow) was better.
It’s the same number of keystrokes (1 + return key), it’s generalised (you can go back as much as you want), you can see what’s the command before sending it, and I’m already used to it because of the terminal.
I think the first appearance of AGAIN in an Infocom game was Cutthroats (1984). I haven’t seen a lot of discussion about it, but I assume that it was part of the nice, new gray box interpreter (at least C64 got a new one with keypress sounds, new color scheme, and lower-case support).
That means that AGAIN has been around for 39 years.
I wouldn’t disable established features unless there’s some significant gameplay reason specific to your work. Most (not all, obviously) players will just expect it to be there and for it to work. Even if it’s rarely used, its absence will probably bother people.
Adding a short comment or explaining in some other way is probably the best approach.
After reading a command:
if word number 1 in the player's command is "g" or word number 1 in the player's command is "again":
if number of words in the player's command > 1:
say "I don't understand.";
reject the player's command;
say "Performing last action again.";
I use G all the time, and would be miffed if it wasn’t available.
Why cater to one inexperienced person in a way that would potentially alienate your base of players? I think a message like @rileypb 's would be sufficient to help new players.
I’d also suggest you include a section for new parser players at the beginning of your games explaining the basic commands and shortcuts. I always include these, and I’ve gotten a lot of positive feedback for doing it (although I don’t think I explain G in them-- I should probably add that!).
