Text patterns in Understand statements

I don’t see it that way. One of the charms of IF, dating back to the very early days, is that it gives the player the illusion of great freedom. You can wander around the landscape and try a bunch of stuff, whatever occurs to you. Most of it won’t work, of course – the “freedom” is, to a considerable extent, an illusion. But it’s an important illusion.

With respect to your question (“why not just restrict…”), the answer is obvious. If you do that, you’re being extremely rude to the player. Players will not like your games – that’s why not.

Here’s a simple example that will illustrate what I’m saying. The room description says, “You are standing at the edge of a small pond.” The player types ‘x water’. The parser replies, “You see no water here.” The parser is simply wrong. This is not something you can argue with or quibble about – it’s just plain wrong. That’s why any halfway decent game programmer will list ‘water’ as a synonym for ‘pond’, even though the word “water” is not part of the room description. It’s not only a basic courtesy to the player, it also gives you a hedge against the breakdown of the simulated world.

The player will always be able to break down the simulation if she tries – it’s only a simulation, and never a very deep one. But it should at least include common synonyms in order to handle the more obvious commands that a player may try.

You asked “why not just restrict the possible words to whichever are actually mentioned in the text?” I gave a scenario in which I, as a player, would definitely be annoyed if I were restricted to words mentioned in the text: not being able to refer to an “oak” as a “tree”.

When writing custom responses (to “examine”, “climb”, “search”, etc) I wind up using a lot of synonyms – for the sake of variety. You don’t want the game to have a litany of “You can’t climb the oak.” “You find nothing in the oak.” “The oak feels rough.” That’s tedious.

So it’s quite common for me to wind up with a dozen synonyms in the text. Not in the room description text, but scattered through various responses. And, as folks have said, it’s bad form to not recognize them.

to be sure, I’m not against synonyms, just excesses detracting from gameplay. If you mention tree and allow for branches, then the player may also expect bark, fungi growing by the roots, worms etc…

I’d rewrite the example and contributions:

[code][The Low Trees are a backdrop in GravelWalk. “The green leafy tree branches stretch out to the sides blocking your view.”
Understand “tree”, “trees”, “green”, “lush”, “leafy”, “view”, “branch”, “branches”, “chump” and “chumps” as the Low Trees.]

GravelWalk is a room. “You are standing at the edge of a small pond. Lush trees run along a gravel walk west.”

A gravel walk is a backdrop in GravelWalk. “It leads west.”

The lush green leafy tree branches are a backdrop in GravelWalk. “The green leafy tree branches stretch out to the sides blocking your view.”

The small water pond is a backdrop in GravelWalk. “Fish swim underneath the pond.” Understand “fish” as the pond.
[/code]

yeah, I try to cram as much in the names just to avoid understand… :laughing:

The only problem with that is that if a player tries “take tree” he will hear “The lush green leafy tree branches is hardly portable.” I know, I’ve tried it myself.

and?

I would expect it to be a problem if taking a tree worked…

I also don’t see the problem with the response, except for the easily-fixed grammatical error (set the branches plural-named) and the verbosity if the player tries a bunch of unsuccessful actions on the tree.

The problem with it is simply that it’s bad writing. Writing well is one of several skills that an IF author needs to master. If you’re not concerned with writing well, you may still be able to create a solid game, but people will snicker at you.

I agree that the message isn’t good writing, but I don’t think it’s a particularly important one–Most characters wouldn’t attempt to pick up a tree without a reason. Conversely, that would be a horrible response to “examine tree”, which is a reasonable action for the PC.

But why cause trouble for yourself? Instead of giving the tree a long complex name and running the risk of having a silly message pop up when the game refers to the object, why not just give it a normal name and include synonyms? It’s not actually appreciably more work.

(Incidentally, if we look at the original example, the only word in the understand line beside “chump(s)” that isn’t in the description is “lush,” and that might be in the room description. So the idea that you don’t need synonyms that aren’t in the text is a bit of a red herring.)

That is true. The only example I can think of in which a very long printed name was important was “the thing your aunt gave you which you don’t know what it is” from HHGG.

Hm, I agree with you, Jim, particularly regarding this sentence:

Don’t fish swim in ponds? Wouldn’t there be dirt underneath the pond? Not sure fish can swim in dirt, even though they are excellent swimmers.

good catch :laughing:

There was an episode in Beet the Devil in which long printed names were important, but I’m virtually certain that the objects had simple names in the source code and were given absurdly long printed names for that episode.

In fact, I don’t know if the player could use the printed name to refer to the object even when it was being played – Carolyn, care to comment?

They can’t, which is notable when the printed name changes during play. You can “understand the printed name property as describing an object” but that only applies to the name as a whole, not the individual words.

Sorry, I know that in general a player can’t use the printed name to refer to an object unless the author does some special tricks to make sure that it happens; what I meant was, I can’t remember whether in that particular moment of Beet the Devil the author did something to make sure that the player could refer to the objects using the ridiculously long printed names that they had just acquired.

Ah, that makes more sense. You have enough I7 experience that I would be surprised if you hadn’t changed a printed name at some point.

No problem, I was unclear.

Notwithstanding the ugly printed name issue others mentioned, I’d say you’re conflating two different issues. One is a courtesy to the player, that reasonable synonyms should be provided for everything in a game, to prevent early-Sierra-style “guess the noun” annoying unintentional puzzles. Others have gone into detail about this.

The other, highlighted in your quote above, could be called something like ‘economy of nouns’. The more nouns you mention in text, especially in descriptions, the more game-things the player expects to be able to interact with. Redirecting subordinate nouns to the main things (via Understand lines, in I7) is one potential workaround, but depending on how emphasized they were in a description, it may be a bit distracting. “The branches aren’t important in this story.” is another approach, often found in more literary/less simulationesque IF. But the best method may be simple omission; if a class of nouns isn’t mentioned in the text at all, that should be enough for players not to expect to be able to reference it. Short’s Counterfeit Monkey has a great economy of nouns in this respect, in part because of the authorial work and processing power each new thing entails.

Maybe it comes down to exactly the type of work being created. If it’s a high-sim game like Kerkerkruip or another roguelike, it’s reasonable for players to be able to refer to many things, and to manipulate them in many ways, that are not explicitly mentioned in the text, using their out-of-game knowledge: water can freeze, pools can be drawn from, containers can be filled with liquids and powders, paper burns quickly, acids and bases mix to form salt water, dirt and powders can be dug in, and so on. Whereas a literary-style game can use “that’s not important” and economy of nouns and related methods to convey the opposite state of being, that the game does not exhaustively simulate interlocking systems, and the player certainly should not need to refer to anything implicit, rather than explicit, in the text. It’s all about managing player expectations.

there were lots of guess-the-verb in sierra because there was very few text as most of screen estate was occupied by the lame childish imagery

have you played Swineback Ridge recently? :laughing:

agreed