Parser errors – Leave them or change them?

I’ve been back and forth on this lately. In some aspects, a game will feel more thorough and polished if you can’t spot any default error messages, but that being said, when I play an Inform 7 game, I’m looking out for the default parser error messages to kind of learn the writer’s thinking.

I can give changing the “going nowhere” message a pass, but say I try to “unscrew doorhinges”, and the game tells me “That’s not a verb I recognise” – then I’ll know there’s no way I can ever unscrew anything in the game. If it instead says something like “I don’t think that’ll work here” or “That is not the solution to this problem”, then I’ll probably go thinking that unscrewing will work at some point in the game.

I’m sure most experienced IF players recognize the default errors just as well as they know the default actions.

What’s your personal and expert opinions on this? Leave all, leave some, or leave none?

It’s nice to change the common ones. As you said, it gives your game a sense of polish, and that’s usually the last thing I do.

Just be wary of making them too long or too specific; especially if it’s something the player could see a lot, like “You can’t go that way.” or “That’s already open.”

Something like “Zounds! There’s nothing in that direction except for solid granite. Last you consulted an ancient tome about materials, that should prove nigh impossible! Have ye gone mad, or do your eyes plainly deceive you?” will get old really fast, unless you’re going for a specific type of parser humor.

I’d go for “leave some”–or at least, make sure the functional ones stay functional. A message like “That’s already open” seems like it conveys what it needs to convey simply enough; no need to change it unless you have a better way to say it.

The same point applies to “That’s not a verb I recognise,” especially compared with the alternatives you suggest, which suggest that you could do the same thing elsewhere. I could see maybe changing it to “That’s not something you can do in this game”–but that might be misleading if the player had tried an unrecognized verb for the right activity, “unbolt” instead of “unscrew” or something.

But you do probably want to make sure that you don’t rely too much on experienced parser player’s expectations of what the default messages will do. Hopefully, not everyone who plays will be an experienced parser player.

(BTW, “unscrew” is a built-in synonym for “turn,” so that particular situation probably won’t arise anyway!)

As you note, error messages do a lot of work in conveying systems knowledge. So the difference between “that doesn’t work in this game” and “that doesn’t work in this situation” is a strong signal that experienced players will pick up on.

The precise wording of the error message isn’t as important. You can certainly change the defaults if you want; just be conscious of the signals.

Oh, that’s a lot of great advice! I suppose I don’t have to worry about players expecting the defaults, then, as long as I keep the meaning intact. And, yeah, I realise now that “unscrew” wasn’t the best example, but I had completely forgotten that it was built-in.

Thanks a lot, all three of you!