[MUD-Dev] Re: Room descriptions
Hal Black
hal at moos.ml.org
Sun Sep 27 00:16:26 CEST 1998
On Sat, Sep 26, 1998 at 10:06:17PM -0500, Raph & Kristen Koster wrote:
>
> On Sat, 26 Sep 1998, Orion Henry wrote:
>
> > A room description does not affect a character and therefore
> > should not pretend to. In an ideal situation a room should not
> > even make mention of objects or people. It should be concise
> > and at most two sentences long.
>
> Again, the same accepted wisdom. I am more interested in WHY we feel
> that's the way it should be.
I think the reason why we feel this way was touched on by both you and
Mr. Darklock. Namely, the Vampire doesn't like to feel sun on his face and
the scenario on Legends that transports people to various situations. It
makes sense for a young boy to have great joy in bubble-gum, but probably
not so for a stodgy vampire.
Thus, the main objection is probably to the fact that most descriptions are
viewer-independent, and therefore really not a true perception. We are
probably thinking from the basis of descriptions as
string long() {
return
"Glorious sunbeams pierce the fluffy cumulus clouds here and bring joy\n\
to your heart as they caress your face.\n"
}
Obviously this is not viewer-sensitive as has been pointed out earlier.
It is much like those point-of-view narratives they used you make you write in
grammar school. Write about your room from your point of view, your mom's
point of view, your cat's point of view, and a roach's point of view. The
challenge is to write room descriptions the same way.
Take a piece of Already-Been-Chewed gum on the floor:
A stodgy elder:
"Kids have no respect these days. Some lay-about has left some disgusting gum
here on the floor."
A woman in a business suit:
"Some child has discarded some gum here. Thank goodness I spotted it so I
didn't get it all over my new shoes."
A kid:
"Blueberry Hubba Bubba. The tell-tale sign of Stinky Stan. And it's still
fresh."
An infant:
"Hmm, what's this? It's blue, I think I'll put this in my mouth."
One of the things that I have planned for my mud is to do some observer-
specific rendering of sensations. Certainly everyone doesn't see things the
same way, or even notice the same things. This may even extend to context.
For example, a cannister labeled "Bio-hazard" will certainly attract more
notice in a day care building than in a pharmaceutical factory, where there
may be hundreds of such cannisters.
In conclusion, I think the objection corresponds to treating all visitors as
if they have the same thought processes, when the set of visitors may be
in fact heterogeneous. Legends (as I understood what you said) was placing
folks in different roles a la Quantum Leap - incidentally something I always
wanted to code. And this is certainly a Good. Remember the old-school LP
death sequence when you go to meet Death and Lars saves you? At one point
in that script Death asks you "Are you scared?" And you note that you're not.
Death says "No glands, that's why." Being in an incorporeal state, you may
need some help with your feelings, since none of us remembers being dead
to know what it feels like (Okay, at least I don't, maybe some people have
had some religious experiences).
In other circumstances, you do not. For a heterogeneous population, it is
unfair to ascribe the same feelings and reactions to everyone. I think it is
this kind of blanket application that people cringe from, not your specific
example where ascribing feelings to place someone in a role is indeed a Good.
As an aside note, this is very much an issue in the modern world: social
engineering. The easiest and most apparent issue is advertising. Some people
want you to buy mountain dew. You happen to want to be trendy and extreme.
They try to put the image in your head that drinking some corn syrup and tonic
water is trendy and extreme. Therefore, you will want to drink mountain dew.
This is obviously very successful, so there is a lot to be said in favor of
using associations not only to place people in roles, but also to trigger
emotions and actions.
More information about the mud-dev-archive
mailing list