<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD-Dev] Circumstances & Situations -->
<!--X-From-R13: "Fenivf Qnfrl" <rsvaqryNcbynevf.arg> -->
<!--X-Date: Mon, 29 Dec 1997 20:32:19 +0000 -->
<!--X-Message-Id: 01bd1498$d2a8bc20$3bc22cc7#slip5,cs.fsu.edu -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: [MUD-Dev] Circumstances & Situations</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:efindel#polaris,net">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg01007.html">Previous</a>
| <a href="msg01009.html">Next</a>
]
Thread:
[ <a href="msg01004.html">Previous</a>
| <a href="msg01027.html">Next</a>
]
Index:
[ <A HREF="author.html#01008">Author</A>
| <A HREF="#01008">Date</A>
| <A HREF="thread.html#01008">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: [MUD-Dev] Circumstances & Situations</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <<A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A>></LI>
<LI><em>Subject</em>: Re: [MUD-Dev] Circumstances & Situations</LI>
<LI><em>From</em>: "Travis Casey" <<A HREF="mailto:efindel#polaris,net">efindel#polaris,net</A>></LI>
<LI><em>Date</em>: Mon, 29 Dec 1997 15:32:03 -0500</LI>
<LI><em>Reply-To</em>: "Travis Casey" <<A HREF="mailto:efindel#io,com">efindel#io,com</A>></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
Nathan Yospe <yospe#hawaii,edu> wrote:
>On Wed, 24 Dec 1997, 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.
>
> Well, yes. Also, attention to detail, sensory depth, alertness,
> perceptiveness, environmental factors (lighting, perfumes, background
noise)
> and all the rest.
>
> So what's your point?
My point is that there's a lot more to consider in creating such a system
than there seems to be at first glance. It's always a good idea to think
carefully about what will need to be done to implement an idea before one
starts to implement it -- you may find that it's more work than you want
to do for the benefits it will give, or that a different solution will
give all the features you actually want without requiring as much work.
If you still decide that you want it after thinking about it, of course
you should then go ahead and do it. Just be sure to go in with both eyes
open and knowing what you're getting into. I've seen a lot of projects
get started and then get abandoned because the people doing them didn't
realize at the start how much they'd need to do. A few hours spent
thinking now about what the project will require can save spending weeks
on something that turns out to be more than you wanted.
> :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. 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.
>
> Yes and no. You cannot make a person as much a "part of the story" in a
> graphical mud, at least in the current non-immersive proto-VR state of the
> tech. The advantages of text are vast. The advantages of graphics
likewise.
> My solution? Make the IO (graphical or text, keyboard or joystick) a
> seperate plugin element, and handle the 3D engine seperately. I even go so
> far as to make the IO a client side issue, and ignore it from the
perspective
> of the (purely 3D, locally limitless degrees of freedom) mud engine.
A very good solution. However, to expand a bit on my point about a
graphical presentation being easier for this kind of detail than a textual
one, I'd like to throw out a few imaginary situations:
Example 1:
Joe and Fred are characters who know each other. Fred walks into a room
where Joe is standing, and Joe is visible to Fred. Does Fred recognize
Joe?
This is really a complicated question -- it depends on how distinctive
Joe's appearance is, the angle Fred sees Joe at, how crowded the room
is, and many other variables.
There are two basic approaches to this which are possible:
1. make recognition of other characters a function of the character
2. make recognition of other characters the responsibility of the
player
(of course, intermediate approaches are possible, but I'd rather not
write a 12-page essay about this right now. :-)
Let's consider the second option (I'll talk about things relating to
the first option later). With a 3-D graphical presentation, Fred's
player will be shown a view of Joe from some angle. This might be
instantly recognizable as Joe (e.g., Fred has a good view of Joe's face)
or it might only be recognizable as Joe based on other information that
Fred's player has (e.g., the figure is wearing a red fur-trimmed cloak,
like Joe was when Fred saw him five minutes ago), or it may not be
recognizable at all (the figure's back is turned and there are no
distinguishing features that say "Joe").
All of this is handled automatically simply by showing a 3-D view of
Joe from the correct angle and distance. Contrast this with a textual
representation of the scene, which might describe Joe something like
this:
An apparently male human stands about five meters ahead and two
meters to the right of you. He's turned mostly away from you, but
you can see that he has a neatly-trimmed black beard and moustache,
curly black hair and pale skin. Black tights and a white doublet
wrap a thickly-built body, the whole draped with a red fur-trimmed
cloak.
This would probably be enough for Fred's player to recognize Joe from
if he knows what Joe's currently wearing. If not, it's enough to make
him realize that this might be Joe and take a better look. However, I
think it should be fairly obvious that generating descriptions this
detailed and context-sensitive (being sensitive to what's being worn,
distance, and angle at least) requires a fair bit of programming.
Now, imagine Fred walking into a room with fifteen characters, one of
whom is Joe. In the graphical case, it will take longer for the room
to be drawn, but the player still has a good chance of immediately
recognizing Joe, humans being as good at visual pattern recognition as
we are. In the textual case, however, the player now has fifteen
paragraph-long descriptions to wade through. Timing myself, it took me
about eight seconds to read Joe's description above (which, BTW, yields
a reading rate of about 450 word per minute, well above average).
Reading fifteen such descriptions, then, would take about two minutes --
meaning that the average time to recognize Joe would be one minute.
Example 2:
Joe walks into a room, takes a painting off the wall, and places it
behind a couch so that just a little of it sticks out. He also places
it to that the face is to the wall, and only the back can be seen from
the room. Joe leaves and Fred enters.
Now, in a 3-D graphical representation, this is easily handled --
the part of the painting that shows will be pictured when appropriate
and as appropriate. It will be up to Fred's player to notice it,
interpret what it might be, and take further action.
Imagine this on a textual mud, however. A simplistic implementation
may give too much information -- e.g., "there is a painting behind
the couch." A near-idea description would be something along the lines
of "the edge of something in a wooden frame can be seen peeking out
from behind the couch" -- but having the mud *automatically* create
such descriptions seems like it would be prohibitively difficult -- it
seems to me like something more suited for an AI project than for
a mud. (I'd dearly love to be proven wrong, though!)
Now, with the preceding examples in mind, a few thoughts about text-
based vs. 3-D graphical interfaces:
If what you want is simply to represent the environment in a way that
players can quickly understand and act on, IMHO a graphical representation
is clearly superior -- quite simply, humans are hard-wired for dealing
with visual data. Trying to describe a scene, especially a complicated
scene, with nothing but text is difficult, and the result will invariably
take longer to extract data from than the visual representation will...
particularly if you don't want to assume that characters will
automatically recognize every object in their environment.
However, a textual representation is superior in other ways. One that
I think is particularly important to a role-playing game is that it
allows a greater separation between character knowledge and player
knowledge. For example, how would one deal with the effects of a spell
which makes the target forget someone they know in a graphical
environment? The only real way to stop Fred's player from recognizing
Joe in such a situation is to alter Joe's appearance -- but that's not
what the spell does. One could simply hope that the player would
properly roleplay the situation, but on most muds, that's a poor bet.
With a textual representation, the game almost *has* to do character
recognition for the player, to avoid the situation from the first
example of having a dozen detailed descriptions to read -- and in
such a case, the effects of the spell can be at least somewhat
enforced by having the mud stop auto-recognizing Joe for Fred.
Whew -- this is getting much longer than I originally anticipated,
and is branching out a bit... but I think I'll plunge on regardless.
Nathan claims that "you cannot make a person as much a 'part of the
story' in a graphical mud, at least in the current non-immersive proto-
VR state of the tech." I have to disagree with this.
I assume that Nathan means that you can't make someone feel as involved
in the story; as much that they are their character. The only other
definition I can think of for being "part of the story" is the level
of influence the character has on the storyline, which IMHO should be
unaffected by the interface.
I think that the presentation that will make someone feel that they are
part of the story varies from person to person. Those of us who read
for pleasure find it easy to "slip into" a story with just text. However,
I'd like to submit that the majority of people today don't read for
pleasure much -- they're more likely to watch TV or go to the movies, and
thus, are more prepared to feel that they are part of a story through a
visual interface. (Of course, one could argue that they haven't been
prepared to feel that they are *part* of a story at all by TV and movies,
but that's another debate.)
It's been brought up before that more people can write than can draw. I'd
like to discuss this a bit.
It's true that more people can write passably than can draw passably;
however, I think that this is largely because most people's standards
for passable writing are much looser than their standards for passable
drawing. Personally, I often find text descriptions on muds to be
jarringly bad, because many of the people writing them are not good
writers. Indeed, I've been in some areas on some muds where the spelling
and grammar were so bad that it would often take me two or three readings
of the text to be reasonably sure that what I understood was what the
author meant. This level of writing certainly doesn't help to make me
feel like I'm part of the story!
In a graphical mud, I'd expect that only a few people would (or, I would
say, should) have the responsibility for creating the artwork. Many things
could be handled by "off-the-rack" components and textures -- walls, floors,
ceilings, common items, common monster types, etc. Such a system would have
the disadvantage of making all areas of the mud look pretty much the same --
but really, how much variation do you want in how the walls look?
Which leads me to another thought -- why try to do a realistic graphical
presentation at all? It might be much easier to use cartoon-style graphics.
Abstract backgrounds (e.g., a wall that's simply four lines filled in with
color) are an accepted part of such a graphic style, and people and objects
are stylized, making them simpler and faster to draw. And, as an added
bonus,
line art can compress *very* well -- if you're willing to limit yourself to
black and white (as many comics do) you can achieve even better compression.
A cartoon/comic-style mud would open up the creation of artwork to a broader
range of people -- most people can learn to draw comic-style artwork if
they're willing to take some time to draw, and producing such artwork is
much
faster than "realistic" art. At the least, people should be able to do
their
own front and possibly side view "rough sketches" for a better artist to
create
views from.
Although it's been mentioned here before, we should make sure to remember
that a "graphical interface" doesn't necessarily have to be nothing but
graphics and mouse clicks; there could be a scrolling text window for
conversations, etc., and the user could still give his/her input as text.
Also, graphical interfaces for muds don't have to be limited to a first-
person 3-D interface; there are many possible ways that mud interfaces
could be made more "graphical", some of which don't involve graphics per
se at all. To name a few: iconic interfaces, hypertext-style interfaces,
overhead views (which need not use true graphics -- a rogue/moria/nethack
style interface, for example), and graphic indicators of status (e.g., a
bar showing current hit point status).
Some of these are achievable completely from the client end, though perhaps
only in limited ways. For example, many muds offer status commands which
will give a quick breakdown of important character status indicators. Some
muds will even give this sort of information in the user's prompt. A client
could take this information and convert it into a graphical status display
without much trouble. For another example, at least one mud client has an
automapper which will make a map of the character's travels. It seems to
me that it would be fairly simple for the client to show the map in another
window, along with a "you are here" indicator. It could also allow the
player to move by clicking on the map to indicate the direction to go -- or
even by clicking on a spot to go to, and then finding the shortest path to
it. (I haven't used the client in question, so it's possible it does some
or all of these things.)
To semi-quote Nathan again, what's my point? Well, pretty much the same
as above: I don't think it's necessarily a good idea to try to jump to
a Quake- or Doom-style interface just because it's possible and people seem
to like those games. Before trying a new kind of interface, it's important
to think about what advantages *and disadvantages* it will have relative to
the current interface. There are many, many possible ways for a mud to give
information to a user and get information from a user; there's no need to
limit yourself to an either/or state of mind, or even to just two possible
interfaces.
On the flip side of things, though, there can be such a thing as too much
freedom in interfaces. You may *want* to restrict your users to a text-only
interface, because of the sorts of problems mentioned above -- how to limit
the player to what the character knows.
The ultimate point is that there is no perfect interface which will be the
best for all possible muds. You need to take your time and think about what
you want your mud to be like.
--
|\ _,,,---,,_ Travis S. Casey <efindel#io,com>
ZZzz /,`.-'`' -. ;-;;,_ No one agrees with me. Not even me.
|,4- ) )-,_..;\ ( `'-' rec.games.design FAQ:
'---''(_/--' `-'\_) <A HREF="http://www.io.com/~efindel/design.html">http://www.io.com/~efindel/design.html</A>
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg01007.html">The morality of logfiles [was 'Wild west']</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg01009.html">Re: [MUD-Dev] The impact of the web on muds</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg01004.html">Re: [MUD-Dev] Circumstances & Situations</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg01027.html">Re: [MUD-Dev] Circumstances & Situations</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#01008"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#01008"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>Re: [MUD-Dev] The impact of the web on muds</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="01009" HREF="msg01009.html">Re: [MUD-Dev] The impact of the web on muds</A></strong>,
Travis Casey <a href="mailto:efindel#polaris,net">efindel#polaris,net</a>, Mon 29 Dec 1997, 21:04 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00953" HREF="msg00953.html">Re: [MUD-Dev] Circumstances & Situations</A></strong>,
Travis Casey <a href="mailto:efindel#polaris,net">efindel#polaris,net</a>, Thu 25 Dec 1997, 00:28 GMT
<UL>
<LI><strong><A NAME="00966" HREF="msg00966.html">Re: [MUD-Dev] Circumstances & Situations</A></strong>,
Nathan Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Fri 26 Dec 1997, 09:57 GMT
</LI>
<LI><strong><A NAME="01004" HREF="msg01004.html">Re: [MUD-Dev] Circumstances & Situations</A></strong>,
Marian Griffith <a href="mailto:gryphon#iaehv,nl">gryphon#iaehv,nl</a>, Mon 29 Dec 1997, 19:52 GMT
</LI>
</UL>
<UL>
<li><Possible follow-up(s)><br>
<LI><strong><A NAME="01008" HREF="msg01008.html">Re: [MUD-Dev] Circumstances & Situations</A></strong>,
Travis Casey <a href="mailto:efindel#polaris,net">efindel#polaris,net</a>, Mon 29 Dec 1997, 20:32 GMT
</LI>
<LI><strong><A NAME="01027" HREF="msg01027.html">Re: [MUD-Dev] Circumstances & Situations</A></strong>,
Travis Casey <a href="mailto:efindel#polaris,net">efindel#polaris,net</a>, Tue 30 Dec 1997, 14:46 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00952" HREF="msg00952.html">OT: Merry Christmas</A></strong>,
Kris Kringle <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Wed 24 Dec 1997, 23:54 GMT
<UL>
<LI><strong><A NAME="00957" HREF="msg00957.html">Re: [MUD-Dev] OT: Merry Christmas</A></strong>,
Matt Chatterley <a href="mailto:root#mpc,dyn.ml.org">root#mpc,dyn.ml.org</a>, Thu 25 Dec 1997, 01:59 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00951" HREF="msg00951.html">The impact of the web on muds</A></strong>,
Greg Munt <a href="mailto:greg#uni-corn,demon.co.uk">greg#uni-corn,demon.co.uk</a>, Wed 24 Dec 1997, 23:31 GMT
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>
