I think the constraint of allowing two word input only is interesting. It’s not hard to make the game reject any command longer than two words:
After reading a command:
if the number of words in the player's command is greater than 2:
say "Use one or two word commands only.";
reject the player's command.
That’s the most brutally simple way I can see to enforce the one-or-two-word-input-only requirement. Are there other (better) ways to do this?
Inform 7 code reads so nicely.
I think your solution is the easiest, but is has an issue: it doesn’t work when disambiguating the player’s command.
With this source:
There is a room.
The red potion is here. The blue potion is here.
After reading a command:
if the number of words in the player's command is greater than 2:
say "Use one or two word commands only.";
reject the player's command.
we get (with comments in brackets):
>x red potion [3 words.]
Use one or two word commands only.
>x potion [2 words...]
Which do you mean, the red potion or the blue potion?
>red [... but now "red" is added to the command, it isn't considered as a separate command!]
Use one or two word commands only.
You see nothing special about the red potion.
The strange thing is that although the after reading a command does fire after the disambiguation question, the command is not rejected in that case (I’m using 6L38, if that matters.) I guess it’s a bug with Inform.
I haven’t found a solution to that, so unless someone finds one, the best we can do is avoid having objects with similar names in the same location, and use does the player mean rules if necessary to bypass the disambiguation question.
Good point! I am writing the whole thing to avoid any need for disambiguation in any case.
Within the arcane depths of the parser, the ‘After reading a command’ rule is invoked in the disambiguation code after the player’s command has been reconstructed, which allows further interference with the text of it if specified by this rule. However, ‘reject the player’s command’, which usually takes effect by causing the rule to fail, has no effect here. This is because the outcome of the ‘After reading a command’ rule when invoked in this context is unfortunately simply discarded, whereas when invoked in the main body of the parser, failure causes a jump to repeat keyboard input.
So without rewriting bits of the parser (always a fraught enterprise), this is a bug we’re stuck with.
After reading a command:
if the number of words in the player's command is greater than 2:
say "['][The player's command]['] is too long ([number of words in the player's command] words).[paragraph break][bold type]Please use one or two word commands only in this story.[roman type][paragraph break]";
let P be the player's command;
change the text of the player's command to "[word number 1 in P] [word number 2 in P]";
say "I'm trying [bold type]['][the player's command]['][roman type]...";
This is one solution, which automatically tries a truncated version of long commands. This also works for most disambiguations in English because the disambiguating word ends up second in the amended command (e.g. ‘Take blue’ instead of ‘Take blue potion’)
>take potion
Which do you mean, the red potion or the blue potion?
>red
'take red potion' is too long (3 words).
Please use one or two word commands only in this story.
I'm trying 'take red'...
Taken.
Here’s an even neater solution to the disambiguation issue, which takes advantage of the fact that in the context of disambiguation the invocation of the ‘After reading a command’ rule is not done by carrying out an activity:
After reading a command while the reading a command activity is going on:
......
The rule will now not be invoked after the player’s command is amended (lengthened) by disambiguation…
That was my guess, but I didn’t bother checking. Although it’s a “normal” behaviour, it’s still a bug in my opinion since reject the player's command doesn’t work as advertised in that case. But as you say, we are likely stuck with it.
That’s a nice trick! But I’m not sure it’s accepted by the TALP jam rules (depending on the way we interpret “filtering out non recognised words is permitted”), and lettting the parser guess a command can be “risky” at times.
That’s even a nicer trick (in some kind of twisted way), although I’m not sure how I feel about it. (I mean, “when doing something while not doing it at the same time” is not really intuitive.)
I guess you could insert an ‘if the player consents…’ condition to avoid the parser freestyling without oversight 
A less graceful way to reject the player’s command that could be used in this context is
Understand "#blank#" as a mistake.
Or
Blanking is an action out of world.
Understand "#blank#" as blanking.
and in place of ‘reject the player’s command’
Change the text of the player's command to "#blank#"
However, here’s a complete solution which includes asking the consent of the player to try a truncated command but also allows disambiguation to happen as normal, except that no more than two words can be entered here either:
stored_command is initially "".
After reading a command while the reading a command activity is going on:
now stored_command is the player's command;
if the number of words in stored_command is greater than 2:
say "['][stored_command]['] is too long ([number of words in stored_command] words).[paragraph break][bold type]Please use one or two word commands only in this story.[roman type][paragraph break]";
let T be the substituted form of "[word number 1 in stored_command] [word number 2 in stored_command]";
say "Would you like to try ['][T][']?[line break][command prompt]";
if the player consents:
now stored_command is T;
change the text of the player's command to T;
otherwise:
reject the player's command.
After reading a command while the reading a command activity is not going on:
if the number of words in the player's command is greater than (number of words in stored_command plus 2):
say "You have confused me with too many words![line break]No more than two at once please...";
change the text of the player's command to stored_command;
Does the Text Adventure Literacy Jam allow ambiguous nouns at all, though? I don’t see anything in the rules about disambiguation; I could imagine that asking the player for a disambiguation adjective could be allowed, but the rules don’t say.
The solution that perhaps best would adhere to the spirit of the jam might be to not take disambiguation into account, and design all nouns so they’re not ambiguous? Maybe easier said than done, but still…
Yeah, the jam restriction is clearly intended to be a “keep the game simple” thing. Chris said:
But it’s still fun to think about how you would enforce two-word commands in Inform for more complex cases.
Yep, I’m mostly avoiding the issue by making the nouns all simple, but some interesting puzzle ideas for the future are popping into my head! Not letting the player input certain complex commands until other stuff happens, etc. Reminds me of a robot that’s being upgraded.
Since disambiguation is invoked at I6 level deep in the parser, there may be no straightforward way in Inform 7 to fully turn it off, so the only solution may be to design the story such that it never arises, either because all cases are taken care of by ‘does the player mean’ rules, or no cases are even possible