From: rgs@megatek.com (Rusty Sanders)
Subject: Re: Let's bring graphics to MUDs
Organization: Megatek Corporation, San Diego, California
Date: Sun, 11 Oct 1992 20:59:40 GMT

From article <RANGER.92Oct11135657@titan.ucc.umass.edu>, by ranger@titan.ucc.umass.edu (John C. Tennyson):
> In article <1992Oct11.171938.3240@daimi.aau.dk> pjunold@daimi.aau.dk (Peter Joachim Unold) writes:
> :[lots of stuff deleted]
> :
> :Now suppose I see an orc. If the MUD knows of a picture, in one of the picture
> :files it supports, of an orc, it might send the client something like:
> :\some_control_char orc@picturefile. 
> 
> :If the client knows that picture, it simply displays it. If the pic is unknown
> :the request is simply ignored. I don't imagine these pictures(mpics) to be 
> :[lots of stuff deleted]
> 
> Nice idea but you may want to put in provisions so that custom pictures can be
> dl'ed to the client i.e. after it sends \some_control_char or@picturefile
> have it expect and wait for \some_other_control_char if the client had the 
> picture or \some_other_completely_different_contol character if it didn't...
> If it didn't have the mud download the picture to the client and ask the mudder
> if he/she wants it incorporated in their picture file that way non-fantasy
> muds can have their own pictures (like space stations, etc....)
> 
The ideas behind the lysator graphics protocal look pretty good for this,
with downloadable objects and scenes (rooms, actually) being keyed by
an ID. Currently it looks like the MUD keeps track of what scenes and
objects have been downloaded, and I think this should change it true.

So, when you enter a room the following would happen:

from mud				from client
SCE <room number> [<room rev>]
					RQS <room number>
DFS <room number> <room desc>
VIO <obj number> <pos> [<obj rev>]
					RQO <obj number>

followed by however many objects are in the room.

The translation of this goop is:

The mud sends down a displat SCEne command, including the room
number to be displayed and optionally the revision level of the picture.
If the client has already seen that room (at that revision), or has
saved that picture in a file previously it just queitly displays it and
doesn't send the RQS (the lysator client doesn't appear to save graphics
between sessions, so the first time in any room for that session it has
to download... annoying). The revision is required because while it's
unlikely a room will change much during a session, it obviously can
change between sessions.

If the client requests the room the rooms polygon based and text base
descriptions (both brief and verbose) are sent down in the DFS respons.
Unlike the lysator protocal which sends data pretty much in clear text
the protocal should use ascii encoded binary (code at end) to transmit
the binary definitions. This would improve download performance over
the lysator method. Another extention to the lysator protocal is the
inclusion of the brief and verbose room descriptions. This also
improves performance and reduces net bandwith, as now the only
thing that gets sent down when you enter a room is something like:
<esc>S <_  $
when you enter room number 2751 revision 4.

Objects are handled in a likewise fashion, so each object in a room
looks like:
<esc>O #* "X '{ $0  "
for object 296, (x,y,z) = (248, 763, 400), revision 2.
If the client doesn't know that object, he'll request a
download. Again, as an extension, the brief and verbose description
of the object is saved locally, to improve performance.

In addition, messages should also be encoded with the player number
of the sender, and message specific items. If emotions and such are
given codes this could also be used to reducde network traffic.
<esc>E  '  1  #
says player 7 sends emotion 18 to player 3.
If the client doesn't know who the players are, or what emotion 18
is, it could ask.
Coding messages in this way would allow the client to have seperate
room and message windows, greatly releaving clutter.

Stats and hits could also be encoded in this fashion, allowing a client
to keep an up to date window on the players condition.

Anyway, those are just some quick ideas. Let's have at it.

/* code to convert a reasonable size number to 3 printable characters
   This code doesn't handle negative numbers (although it should be
   easy to add), nor numbers over 96^3 (884736). It does require ASCII */

#define BASE 96

convert(value)
        int value;
{
        int i;
        int digit;
        int divider;

        divider = BASE*BASE;
        for (i=0; i<3; i++) {
                digit = value/divider;
                printf("%c",digit+' ');
                value=value-digit*divider;
                divider = divider/BASE;
        }
}

-- 
----
Rusty Sanders, Megatek Corp. --> rgs@megatek.com or...
         ...ucsd!    ...hplabs!hp-sdd!    ...ames!scubed!   ...uunet!