[MUD-Dev] Circumstances & Situations

[Travis Casey]

Marian Griffith <gryphon at iaehv.nl> wrote:
>On Wed 24 Dec, Travis Casey wrote:
>
>> Personally, I always get the willies when someone talks about only
>> showing what's in front of the character on a text-based mud.  This opens
>> a large can of worms -- you have to have positions within rooms, an idea
>> of how the character is facing, and an arc of vision for the character.
>
>*shrug* that's for the coders to worry about. From the game's point of
>view it makes things much more interesting (and challenging).

Well, I *am* a coder, so I have to worry about it.  :-)  There comes a point
in adding features when you have to ask if they're going to be worth the
amount of trouble it will take to do them well.

>> This sort of thing has always seemed like too much work to me -- you
>> pretty much have to keep track of all the position and facing data that
>> a graphical mud would need to draw what the character's seeing, and then
>> you have to interpret that data and output it as text.
>
>*shrug* (again ;) It's just a matter of limiting what objects have their
>description or name added to the list of what you see.  Instead of every
>item in the room you see only what is in front of you. I do not think it
>is a very big problem but perhaps somebody who would have to code it can
>enlighten us (me)?

It's actually a considerably bigger problem, if you want to really show
only what the character should be able to see.  I went into this in more
detail in a message yesterday, but here's the short version:

Consider a human character of normal height (five to six feet, for the
sake of argument) walking into a room which has a six-foot tall privacy
screen in it.  Let's say that there's a four-foot tall dwarf behind the
privacy screen.  Now, obviously, the human should not be able to see the
dwarf, and vice-versa.  Now consider replacing the dwarf with an eight-foot
tall ogre.  This time, the human should be able to see the ogre.  The ogre
might be able to see the human, depending on which direction the ogre is
facing.  Now, for real fun, what if there's a six-foot four-inch tall elf
behind the screen?  The human should be able to see the top few inches of
the elf's head -- enough to let the human know that there's someone behind
the screen and see hair color and some of hair style, but probably not
enough
to identify the elf.

What if an arm is sticking out from behind the screen?  Or if a chest is
behind the screen, with just enough of it showing for the character to see
about three inches of it?  Should it be described as a chest, or as a wooden
object, or what?

(For extra fun, consider an analogous scene in a modern-day mud -- a
character walking into a bathroom with stalls which are about six feet
tall at the top, and have a gap of about eight inches at the bottom.  Now
you have to worry about seeing feet as well.  And how about hiding?  What
if I want my character to stand on the toilet and crouch down so neither
feet nor head is visible?  Of course, if a tall person walks right up to
the edge of the stall, they might see me anyways.  Or a character might
want to crouch down so as to be able to see under the stalls better.
For *real* fun, start throwing in mirrors.)

In order to make a text-based mud so that characters only see what they
should
be able to see, you pretty much have to do *all* the real work involved
creating
a graphical representation of the scene *except* actually drawing the scene
on the screen -- you'll need to do raycasting or something similar to decide
exactly what can be seen, and then somehow describe the scene in text --
which
may involve substituting or changing descriptions in intelligent ways (e.g.,
describing only the hair of our elf, or giving a proper description of what
the character can see of the trunk.)

Of course, you may want to implement only some of this -- for example, you
might want to make objects either completely visible or completely
unseeable.
However, you should consider how much you want to do, and why, and how to
explain to players the inevitable questions that are going to pop up about
why they can't do certain things.

>>  IMHO, if you want
>> this sort of detail, it's probably easier to make a graphical mud -- the
>> methods for drawing the world so that only things that are in the
player's
>> line of sight already exist and are fairly simple for the graphical case.
>
>Well no. The one big advantage of textual muds over graphical ones  is the
>amount of detail possible in the text. It is much easier to capture an at-
>mosphere in words than it is in drawings.  The few examples I have seen of
>graphical muds are very cartoonesque  and kind of ruin the immersion  in a
>world  full of swords and magic.  It is also easier to give the impression
>of smooth movement in text muds than it is in graphical games. Of course I
>can only compare to myst so this may be way off the mark.

Far more detail is possible in a picture than in text -- thus the old
saying, "a picture is worth a thousand words."  I could easily send you
a picture of my desk, for example, and you would be able to see everything
on it -- including positions, how many CDs are in my CD rack, the labels
on the disks sitting out on my desk, what color my calculator is, and many
other things.  A text description giving *all* of that information would run
to a few pages at least, and be much less convenient to use.

In point of fact, the *only* thing which makes mud worlds describable with
text is that they are very *empty* worlds compared to the real world.  (Or,
if you prefer, they are described much more abstractly than the real world.)

As for atmosphere -- atmosphere can be captured in graphics quite easily.
Watch any good director's work to see how -- or look at the paintings of
any decent artist.  A skilled writer can capture an atmosphere in text
quite well, yes -- but when an unskilled writer tries to, the result is
more often painful to read than atmospheric.  Quite often, it's
bludgeoning -- the writer *telling* the player how his/her character feels
instead of trying to use words which will *make* the player feel the
appropriate emotions.  You can't *tell* someone how to feel with a picture,
so it is harder -- but the results are better, since you're having to
actually create a mood in the viewer.

>> A simpler, but similar, idea would be this:  simply give players who are
>> "walking through" a room on their way to somewhere else a briefer, less
>> detailed description.  Those who are willing to move along one room at a
>> time the old way will get more description, but it will also take them
>> longer to get where they're going.
>
>The idea was not to speed up movement. Rather (at least that's my impres-
>sion) the intention was to create a more natural 'feeling' of movement.

My impression was that the idea was to give those who are simply walking
through a room instead of stopping in it a less detailed description of
the room.  My note that moving along one room at a time will take longer
wasn't describing an effect of changing the descriptions -- it was simply
noting that if someone wants to read the full description of each room
he/she moves into, it will take longer -- which is true regardless of the
implementation.
--
      |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
     |,4-  ) )-,_..;\ (  `'-'        rec.games.design FAQ:
    '---''(_/--'  `-'\_)      http://www.io.com/~efindel/design.html