I’d prefer “You push [the noun], but it doesn’t budge.” over the generic “nothing obvious happens”. This is a check rule and not a report rule, right?
For delineating which messages are coming from in-world and which are out of world (i.e., Mr. Parser Voice), you can create say-phrases likeTo say error message prefix: say "[italic type][bracket]".
To say error message suffix: say "[close bracket][roman type]". and wrap those phrases around the appropriate messages. The author can override them merely by redefining them to do something else, including do nothing.
Another tool in your arsenal is to ask if a particular rulebook “is empty”. For example, asking if the carry out singing rules are empty, or the report singing rules are not empty, etc. While that won’t help the case of Instead rules, it can at least figure out if the author has added anything to those actions.
Similarly for your TAKE ALL EXCEPT case – ask if the player’s command includes “all except/but” or whatever, and adapt the message accordingly.
Of course, there’s usually a pause first, while I think of a fruitier word I could say and then remind myself that real adventurers don’t use that kind of language.
Yes, what Zarf said.
How about “Nothing interesting happens”? (Or “You push [the noun], but nothing interesting happens”). That doesn’t seem to imply too much with regard to movement or non-movement of the pushed object, and at the same time it avoids Aaron’s point that “nothing obvious happens” could be taken to imply that “something unobvious happens around the corner”.
Ooh, this is an intriguing idea. After trying a couple test cases, though, I’m not sure it can actually help in practice.
I can think of three major ways an author might try to use one of these do-nothing verbs. First is the “correct” way of unlisting the built-in block rule and making custom rules.
The block buying rule is not listed in the check buying rulebook.
Check buying: if the player does not hold money, instead say "You can't buy something without money."
Carry out buying: say "Congrats, you now own [a noun]!"; now player holds noun.
In this case, as far as I can tell you’ll never see the original Check rule at all: every action would either show one of the newly written check rules, or fall through to a carry out rule. So differentiating between non-empty rulebooks in the built-in message wouldn’t help, since you never see it.
If a player’s creating a custom one-off:
Instead of buying something when player holds money: now money is off-stage; now player holds noun; say "A successful sale!"
…the rulebook stays empty and the check can’t help us. Which is likewise the case if the author’s creating an entirely new action:
Understand the command "purchase" as something new. Purchasing is an action applying to one thing. Understand "purchase [something]" as purchasing. Carry out purchasing: say "It's yours!"
I’m leaning towards phrasing the messages like “You can’t buy [the noun] like that.” I think this reads fairly naturally in all cases-- it makes sense if you can’t do the action because you’re not holding the right thing, using the right grammar, or there at the right time. If there’s no right way to do the action, “that” can be read as referring to the action rather than the way it was performed-- imagine an admonition like “You can’t go around just pushing people like that!” It can still be misinterpreted as meaning there’s a right way, of course, but I think it’s an improvement at least.
I wrote an extension long ago called Grouped Messages As Dialogue that attempted that very thing, so authors who wanted to override all 100+ messages in the game could do so without actually writing 100+ different messages. The extension stopped functioning many builds ago, but one reason I created the activity in Custom Library Messages was so that I might be able to revive the idea later. I agree that if several messages are going to turn out identical, then rig things to that it’s only one parameterized message, and hence, easy to replace. For example, a say-phrase that is passed the library message verb, which an author can override either on a per-action basis (by using the table) or all at once (by defining the say phrase again, since Inform will use the last one defined).
Incidentally, Aaron, this extension seems to work fine with CLM so far. I noticed a comment in it wondering something to that effect.
For SING, I think I once used “You hum a few bars to yourself.” which works even when you’re gagged and/or surrounded by psychopathic librarians.
Incidentally, what happened to “You’re not that thirsty/hungry.”? I liked it.
I can also create short phrases that count the number of rules in a rulebook and/or ask if a named rule is currently listed in the rulebook. I’ve done so before in extensions like… Repeat Through A Rulebook. That would solve your first case. Your second case was the Instead exception I already noted. Your third case is irrelevant – you are not writing default messages for actions that don’t already exist in the standard rules. Redirecting a previously existing command to the new action doesn’t change that.
BTW, I noticed you had some fancy code in that other thread, “how much did the parser understand” or whatever it was called. Are you not using such bits here?
To continue the nitpick, I’m not sure the elegant one-size-fits-all approach really serves the purpose. If “You can’t attack the noun like that” means you can’t attack it at all, or you need to attack it with a different thing, or you need to attack it using different words – then some players will interpret it in the wrong way for the situation. And I think the purpose of the default message should be to convey that the command hasn’t been understood without leading an inexperienced player to a wrong understanding of why it hasn’t been understood. After all, the real audience of the message is relatively new players; the exact wording of the message doesn’t matter much to players who can say “Oh that’s a default message which leaves open possibilities X and Y.”
(Quoting Jenni: “Y’know, every time I read ‘Violence isn’t the answer to this one,’ I am skeptical, because very often this default message is left as a failure notification in places where you’re simply using the wrong kind of violence, or on the wrong thing.” My point being, I know that and you know that, but the target audience for “You can’t attack the object like that” doesn’t know that.)
So that’s why I like the disjunctive responses, which spell out what the parser doesn’t know about the situation.
…now of course this is coming off the top of my head, and you’ve done a lot more combing through transcripts for how people react to them than I have, but that’s my reasoning.
I was thinking more in lines of redirecting the NPC-failed-the-action messages to the PC-failed-the-action messages. So that we get “>MUMMY, OPEN SARCOPHAGUS / It’s already open” or “>MUMMY, OPEN SARCOPHAGUS / It seems to be locked” as the case may be, rather than “>MUMMY, OPEN SARCOPHAGUS / The mummy is unable to do that” in each and every case.
I know that failed NPC actions are intercepted by the carry out requested actions rule, but I’m not sure if that’s merely because the standard library messages only fit when actor is the player or if there is some deeper reason why NPCs’ failed actions should be so summarily reported.
What about referring not to the action tried but to the verb used in trying?
I mean something like:
«The verb “sing” can’t be used at this point in the story.»
That neither precludes that SING may work excellently elsewhere in the game nor that there may be another way to make the PC sing right here and now (and I don’t think it suggests too strongly that there has to be another way to sing or that SING will certainly be usable anywhere in the game either).
What will happen if the verb “sing” can in fact be used at this point in the story, but in a different way, such as “sing to Johnny”? That would be a misleading message.
I like this idea. I think a small standalone extension would be fine just to save authors some extra fussing, and it could be included in Neutral Library Messages if that makes sense. It seems to me that most situations where a procedural rule would be handy (or a preamble-rewriting line, as mentioned here), are in those generic “block action” rules. I don’t like being forced to use Instead or mess with the standard rulebooks just to implement a verb that already exists.
I am cautiously open to this, but where do you draw the line? It seems like it definitely does make sense to block some actions by default (like drinking), while others are in a gray area (attacking or cutting).
The ones which the library currently narrates as if they’re actually taking place are jumping, rubbing, pushing (arguably), and singing (arguably).
I have the impression that I’m in the minority with my opinion, but I think that the standard library should include just the bare minimum set of actions. If the story doesn’t use a particular action it’s better to just respond with “The story doesn’t understand that verb” or similar. It tells the player straight away that they don’t need to try that action later on either. If the author does need to implement the action it’s almost always just as easy to make the action from scratch than to build on top of an existing minimally implemented standard library action. Personally I tend to start a new project by pruning a whole lot of standard actions and putting them back only if it turns out I need them.
I don’t think you’re in the minority. My sense is that JUMP and SING only exist to provide critics with weapons to use against novice authors (c.f. The Lucubrator which someone mentioned earlier.)
I’d vote for giving them the “That’s not a verb I recognize” treatment instead. The problem isn’t that the message is bad, it’s that the commands contribute nothing to the typical story and are easily overlooked by authors as a result.
As long as you purge every trace of “Nothing obvious happens” I will be happy. I spent hours turning stuff in The Reliques of Tolti-Aph, trying to figure out what mysterious event was taking place. I assumed I must be disarming a trap or unlocking a secret passage somewhere on the map; the nature of the scenario added meaning to an otherwise innocuous response.
That’s a problem that many of your new defaults have as well. It seems like you are approaching this from an author’s perspective, where the important thing is that the messages not stick out from the rest of the prose. I think inexperienced players would prefer that such messages look awkward and jarring, to better signal that the response can be ignored.
For example, all of your “Try expressing …” replies can be read as unsolicited hints from the author to try the same thing in a different way.
A different approach would be to use the new line echo functionality to erase the entered command, play an error sound, and redisplay the prompt as though nothing had ever happened. If the response to a command is neither interesting nor informative, why show the response at all? The player may be frustrated, but better that than actively misled.
I don’t think I’d like that as a player. I often use scrollback and transcripts to check whether I’ve tried something, so I’d want a permanent record of everything that didn’t work.
Transcripts would not be affected, and the command history would still reflect the entered command even if scrollback didn’t.
I agree that a simple beep is no good but suppose the interpreter suppressed the output, then displayed a new command prompt with the invalid command pre-loaded in a different style (bold red vs bold green). That would provide a visual cue that the command had been rejected, which would disappear when the player erased the command and entered new one.
You could also adapt it for the case where the command (JUMP) was invalid but a longer form would work. The prompt could come back preloaded with >JUMP [WHERE].
You could further extend it with something like autocomplete, if the Tab key were allowed as a line terminator. The player could press tab and >JUMP [WHERE] would disappear, to be replaced by >JUMP [OVER CHASM]. Pressing Enter would strip away the brackets and process the command as if the player had typed it, including echoing it back to the window with no brackets and no italics. Pressing Tab again would supply a different autocomplete value.
Getting the actual values for autocomplete would take some effort, though. But it’s effort in the right direction: helping the player enter commands for which the game can produce a meaningful response.
I’ve just started trying out Neutral Library Messages with my WIP. Unfortunately, I’ve discovered a conflict with my Lost Items extension.
This is about as small as I can make the example:
[spoiler][code]
Include Default Messages by Ron Newcomb.
To decide which snippet is the misunderstood word: (- (((wn - 1) * 100) + 1) -) .
To decide what number is position of non-dictionary word: (- (FindUnknownWordToken(2)) -).
Include (-
[ FindUnknownWordToken wordnum
w twn numwds; #ifdef TARGET_GLULX;
numwds = parse–>0; #ifnot;
numwds = parse->1; #endif; ! TARGET_GLULX;
! Throw out invalid word numbers
if (wordnum <= 0 || wordnum > numwds) rfalse;
twn=wn; ! save the value of wn so it can be restored
wn=wordnum;
while (1)
{ w=NextWordStopped();
if (w == -1) { wn=twn; rfalse; }
if (w == 0 && TryNumber(wn-1) == -1000)
{ wordnum=wn-1;
wn=twn;
return wordnum;
}
}
];
-)
Table of custom library messages (continued)
library-action library-message-id library-message-text
– 30 “[if position of non-dictionary word is 0]That’s not something you can see right now.[otherwise]You don’t need to use the word [the misunderstood word] in this game.”
Noticing absence of something is an activity on objects.
For noticing absence of something (called item):
say “[The item] isn’t here right now.”
The item sought is an object that varies.
Definition: A thing is sought if it is the item sought.
Rule for printing a parser error when the latest parser error is the can’t see any such thing error:
Repeat with the missing item running through things:
Now the item sought is the missing item;
if the player’s command includes “[any sought thing]”:
carry out the noticing absence activity with the missing item;
rule fails;
now the latest parser error is the can’t see any such thing error;
make no decision;
Test is a room.
Test me with “x foo”[/code][/spoiler]
It looks like looping through things and checking “if the player’s command matches” is messing up the information about the misunderstood word, but I don’t have enough parser-mojo to be able to figure out how to avoid that. Any suggestions?
That would solve your first case. Your second case was the Instead exception I already noted. Your third case is irrelevant – you are not writing default messages for actions that don’t already exist in the standard rules. Redirecting a previously existing command to the new action doesn’t change that.