<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: Graphic design, client questions -->
<!--X-From-R13: X Q Znjerapr <pynjNhaqre.rate.ftv.pbz> -->
<!--X-Date: Mon, 21 Dec 1998 14:47:23 -0800 -->
<!--X-Message-Id: 199812212246.OAA20702#under,engr.sgi.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 367A1A80.D0F1B391#bigfoot,com -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Re: Graphic design, client questions</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:claw#under,engr.sgi.com">
</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="msg01026.html">Previous</a>
| <a href="msg01028.html">Next</a>
]
Thread:
[ <a href="msg01028.html">Previous</a>
| <a href="msg01050.html">Next</a>
]
Index:
[ <A HREF="author.html#01027">Author</A>
| <A HREF="#01027">Date</A>
| <A HREF="thread.html#01027">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Re: Graphic design, client questions</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] Re: Graphic design, client questions </LI>
<LI><em>From</em>: J C Lawrence <<A HREF="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</A>></LI>
<LI><em>Date</em>: Mon, 21 Dec 1998 14:46:37 -0800</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
On Fri, 18 Dec 1998 11:04:00 +0200
Thinus Barnard<thinus_barnard#bigfoot,com> wrote:
> Caliban Tiresias Darklock wrote:
> As for text mode I see a few problems. 1. I can send the text
> description of the room and append the string needed for the
> graphics protocol. This seems like a waste if the player has got
> the graphics. Instead of sending 1 line of text for the graphics
> protocol I now have to send 5 lines of description plus the 1 line
> for the graphics.
> 2. Text/Graphics mode. Define two methods for displaying messages
> to the player. One method sends just text and the other sends
> just the graphics. Maybe define 2 different player objects, one
> that handles graphics and one that handles text. When the mode is
> switched the old object is copied to the new one and the old one
> destroyed, otherwise you will have to check everytime a message is
> sent whether the player is in text or graphics mode. A problem
> when the player is in graphics mode and a picture is not
> available.
> 3. Always run in graphics mode. When the client cannot find a
> picture request the text from the server.
> A combination of 2 and 3 is probably the best way to go.
This differentiation has been previously discussed on MUD-Dev, tho
not in huge detail
Another approach is to operate in only in grpahics mode, and for all
objects to have a defined graphic representation as a mapping from
their object inheritance heirarchy. An advantage of this system is
that it allows the client cache to operate intelligently and present
what it has, even if it is known to be inaccurate.
Thus the base object chair would have a graphic which representes
it, of a very simple, unfeatured, and rather ignorable chair.
Children of this base object would inherit their parent's default
chair graphic until they defined their own. From the client
perspective, upon encountering a new object (ie one the client does not
have a defined graphic in-cache), the client will instead display
the nearest (per the object's inheritance tree) registered graphic,
and will request a more correct graphic from the server for
subsequent use.
The result is that the client user will enter a room and initally,
for instance, see a dull gray room full of dull gray barely
differentiated objects. However, as he waits, the objects will
gradually refine themeselves. and redraw to appear "correctly",
finally resulting in a "correct" rendering of the scene.
A side effect of course is that a player surrounded by familiar
objects will be able to operate more quickly than one to whom
everything is new. Cache population then becomes a valuable
client-side player skill. This has questionable play-style and
world-view effects with easy arguments on both sides. A good
partial solution may be to implement a client-side configurations to
control graphic requests; perhaps detailing a max bandwidth consumed
by graphic downloads, and a minimum average even rate (rate of state
change for the player) to initiate new graphic downloads.
>>>The client can force the user to only enter valid commands.
>>
>> MUD and client versions would have to match... exactly. BAD idea.
> Not true. The server can tell the client what commands are
> available. The standard command set can be imbedded into the
> standard graphics resource. When a player enters a room the server
> tells the client what extra commands are available. When the
> player exits the room the client can remove the commands again. At
> least you can do some checking on the client and don't have to
> send everything to the server. You will need a very flexible
> client to really get good results through scripting. The client
> will have to display an inventory, display a body graph with the
> inventory for using items, define some buttons on the main form to
> easily get to the inventory, skills, spells, combat options,
> etc. Should be an interesting scripting challenge.
There are two approaches to this; guaranteeing command correctness
(which is doomed from the outset), and one which attempts only
sanity checking (and has a chance of working).
You don't want the client refusing commands because it "knows" that
they won't work in the current state due to missing objects. It is
too ripe for abuse and is almost impossible to guarantee
correctness.
Ahh! We'll just ensure that the requisite objects are present!
That way you can't "get cup" when the cup isn't there.
Right, that works all the way until, "summon bubba", or "forge
sword", "make bread", or any other variant command that operates on
non-present objects.
Well fine -- we'll allow specific exceptions.
And what happens when you "make bread" when no bread making
materials are present?
A simpler approach is define a grammar; to state that commands must
follow a certain set of patterns of verbs, nouns, etc, and to check
against that. Further, you abstract final authority to the server
(the one with all the data), and only use the client for light
weight pre-checking to exclude only the most obvious errors. In
this way you catch the majority of the typos (90+% of fluffed
commands) at the client, and allow the server to do the real work it
was designed for.
--
J C Lawrence Internet: claw#kanga,nu
(Contractor) Internet: coder#kanga,nu
---------(*) Internet: claw#under,engr.sgi.com
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00990" HREF="msg00990.html">[MUD-Dev] Re: Graphic design, client questions</A></STRONG>
<UL><LI><EM>From:</EM> Thinus Barnard <thinus_barnard#bigfoot,com></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg01026.html">[MUD-Dev] Re: Re[2]:[MUD-Dev] Re: MUD Design doc (long)</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg01028.html">[MUD-Dev] Re: Graphic design, client questions</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg01028.html">[MUD-Dev] Re: Graphic design, client questions</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg01050.html">[MUD-Dev] Re: Graphic design, client questions</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#01027"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#01027"><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>[MUD-Dev] Re: Graphic design, client questions</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00982" HREF="msg00982.html">[MUD-Dev] Re: Graphic design, client questions</A></strong>,
Jo Dillon <a href="mailto:emily#thelonious,new.ox.ac.uk">emily#thelonious,new.ox.ac.uk</a>, Thu 17 Dec 1998, 17:56 GMT
</LI>
<LI><strong><A NAME="00990" HREF="msg00990.html">[MUD-Dev] Re: Graphic design, client questions</A></strong>,
Thinus Barnard <a href="mailto:thinus_barnard#bigfoot,com">thinus_barnard#bigfoot,com</a>, Fri 18 Dec 1998, 10:51 GMT
<UL>
<LI><strong><A NAME="00997" HREF="msg00997.html">[MUD-Dev] Re: Graphic design, client questions</A></strong>,
Sunny Gulati <a href="mailto:sunnywiz#radiks,net">sunnywiz#radiks,net</a>, Fri 18 Dec 1998, 18:46 GMT
<UL>
<LI><strong><A NAME="01028" HREF="msg01028.html">[MUD-Dev] Re: Graphic design, client questions</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Mon 21 Dec 1998, 22:53 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="01027" HREF="msg01027.html">[MUD-Dev] Re: Graphic design, client questions</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Mon 21 Dec 1998, 22:47 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="01050" HREF="msg01050.html">[MUD-Dev] Re: Graphic design, client questions</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Thu 24 Dec 1998, 07:57 GMT
</LI>
<LI><strong><A NAME="00983" HREF="msg00983.html">[MUD-Dev] Re: Graphic design, client questions</A></strong>,
Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Thu 17 Dec 1998, 19:05 GMT
<UL>
<LI><strong><A NAME="00995" HREF="msg00995.html">[MUD-Dev] Re: Graphic design, client questions</A></strong>,
Jo Dillon <a href="mailto:emily#thelonious,new.ox.ac.uk">emily#thelonious,new.ox.ac.uk</a>, Fri 18 Dec 1998, 13:02 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="01000" HREF="msg01000.html">[MUD-Dev] Re: Graphic design, client questions</A></strong>,
Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Fri 18 Dec 1998, 21:21 GMT
</LI>
</ul>
</LI>
</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>
