Neutral Library Messages: extension beta

I think that’s hardly worth a standalone extension – it would just be a couple of …is not listed in the check… and …is listed in the report… assertions per unimplemented action. IIRC.

@Aaron: The new Plurality-like phrase [that-them noun] really should require the word “of” in there, like [that-them OF the noun]. This is because Plurality almost always requires the “of” due to this bug, and consistency makes learning & using said phrases easier. I’m currently updating Custom Library Messages which adheres to this (among fixing another few bugs) as well.

Thanks all for the comments. Keep them coming!

Oops-- overlooked that jumping is blocked, rather than allowed by default. I’ve pulled it in line with the other default rejection messages: “You can’t jump here, or can’t do so in that way.”

Yes, this is a good point: I wrote this while thinking of the other case in which this message appears, >TAKE ALL BUT APPLE or whatever. I’ve adopted Matt’s suggestion “There is nothing available, or nothing that matches that description.” to cover both scenarios.

As mentioned above, we shouldn’t narrate the action happening since it’s actually blocked by the library. You’re right that “in this story” was overstepping: I’ve changed it to “You decline to.” Which is essentially the same as the original message, but without any value judgements on the player’s vocal cords.

But we don’t know whether the action’s impossible-- just that the command the player typed didn’t work. As you point out, singing may well be possible if the player types, say, PERFORM ARIA, but we can’t know that here. This is what “or can’t do so in that way” is trying to get at. I share Felix’s concern that this might be dangerous in implying that there’s some other way to do what the player wants, but I think it’s equally dangerous to imply that there’s no way to do what the player wants. Very open to tweaking the wording of these messages to try to strike a balance.

Well, this is the reverse problem as above: technically, these things are happening since the actions succeed. I actually have no problem with actions that succeed but do nothing; if there’s no good reason to stop the player pushing or touching something, we’ll let him. We just don’t want to imply that there was a major change if there’s wasn’t, which is why I tried to make these as simple and declarative as possible.

I agree this is better in the case where there is actually a better grammar line for the player to try, but I feel like it’s more misleading if there isn’t, because it seems to imply a specific course of action (try typing different words) instead of a vaguer one (try something different). Hmm.

Why so?

Sure, but it sounds stuffy and British, which I’m trying to avoid. :slight_smile:

This is not a bad idea. One danger is that the player is going to see this aggregate message quite a lot, probably, so it may be better to instead go the other way and try to differentiate them more in a useful way. Food for thought…

Thanks for the explanation on this-- I’ll update the syntax accordingly.

For the “can’t do so in that way” messages: what do we think about something like:

This is less verbose and still hints that there might be another command to do the same job, although if there isn’t it could still mislead players into fruitless guess the syntax.

Well, that’s why I like “You push the noun, but nothing obvious happens”; it makes it clear that the pushing did happen but that nothing seems to have come of it.

Well, we could always go disjunctive; “You can’t (whatever), or at least not using those words.” I don’t know; it’s not very elegant.

I do feel that “in that way” somewhat falls between two stools; it suggests that you might be able to do it a different way. So if you can’t do it at all, it’s a little misleading, and if you can do it but need extra syntax, it’s also a little misleading. Of course default messages are by their nature compromises.

Too technical – imagine a new player who’s using some iPhone app or something that doesn’t support multiple undos. Reference to the “interpreter” will confuse them, I think. (For bonus points, imagine they’re playing Floatpoint. “If I have an interpreter, why isn’t he helping me talk to these people?”)

There’s also that very generic message telling you that an NPC failed to perform any action you asked him/her to perform: “[The actor] is unable to do that”.
Whatever the reason that action failed, whether the NPC can’t open a safe because it’s locked or he/she can’t sing or jump because those actions fail by default, the player is told simply that the NPC “is unable to do that”.

If you’re in the process of designing a new set of appropriately neutral library messages, is there still any reason not to use the same actor-based library messages for the player’s failed messages and the NPC’s?

Felix: that still has the problem of misleading players in a sequence like >JUMP (“You are unable to do that.”) when in fact >JUMP OVER CHASM is what they need to do next. The difficulty is the conflation of you the player (“You are unable to use that command.”) with you the player character (“Bob is unable to jump.”) Maybe it would be more accurate to invite the parser in and say something like “I am unable to direct your character to do that.” But that’s kind of a mouthful.

Matt: To me, “nothing obvious happens” always implied that something terribly interesting was going on somewhere else, if only I could figure out what this seemingly innocuous thing I pushed was connected to. Maybe that’s just me… good points about the interpreter, I’ll rephrase this.

It’s also not necessarily or even typically the case that the interpreter lacks support for the multiple undo feature. Older versions of the Inform library disabled it by default, until fairly recently. Try UNDO twice in Galatea or Bronze and then try it in Whom the Telling Changed.

I believe Zoom allows multiple undo commands even in games that do not support it, via a menu option, but this is not the norm and it is also outside the scope of this message - the game state is simply rolled back and the library has no opportunity to intercede or respond.

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.

It needs to cover both “PUSH SKYSCRAPER” and “PUSH PENCIL”.

raises hand

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”.

Why not just have two messages for push depending on whether the object is fixed or not.

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. :slight_smile: 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.

–JA

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.