Just a bit of musing

[Jon A. Lambert]

> From: coder at ibm.net
> 
> On 03/03/97 at 02:12 AM, Dmitri Kondratiev <dima at paragraph.com> said:
> 
> >Only newly built things need to be send to each player. Client can get
> >other stuff that hasn't changed from it's local cache. Cache contents can
> >be compared with world model on the server, every time client logs in to
> >it or new objects are created by other players. Similar to the way web
> >browser verifies documents in its cache with the ones on the server. Thus
> >only incremental changes are sent from server to client as soon as they
> >appear in the world. Besides server can send compressed VRML. If some
> >VRML browsers understand gzip-ed VRML, why MUD client can't do the same ?
> 
> Problem: Given a reasonably active player, pretty soion the client would
> end up with a full copy of the server's image DB.  This could get *really*
> expensive *really* quickly.  Even doing the Meridian 59 deal and dropping
> the local cache on CD still leaves you with a remarkably small world once
> the detail rate is fairly high.

I would agree with Chris's assessment of the problem.  While not being a big
fan of graphics in muds, I do think that some tasteful uses of them can provide a
better user interface.  I guess I should make some distinctions here about what
I mean by graphics and what might enhance your presentation without the 
above mentioned problems.  A few things come to mind.

Mud title screen - Many muds currently do this via entry points on a web page although
it can also be done via a specialized client.  This would tend to be downloadable once
or if changed would be automatically replaced on the users drive.  This may be useful for
enticing a potential player into your game or in setting the mood and frame of mind of
your more jaded players upon logging in.  A well done graphic might well be worth a 
thousand words of description.  It might also contain some animation.

Graphic Interface - This would be provided by a specialize client.  Most likely DLed once
or automatically updated while logging in.  I am thinking more in terms of text placement
and interface enhancement rather than replacing descriptive text with pictures.  Many 
current clients provide an output window, an input box, some configurable color, etc.
Check out Pueblo, an HTML-like interface, or TinyFugue which understands CML,
or ColdXs implementation of the HTML 1.0 spec.
  
For my server I have some specific things in progress along this line:

1) The right side of the screen contains a line drawing of a humanoid shape.  Wounding
is depicted on various limb parts through the use of color shading.  Clicking on on this
diagram returns a description of wounds and what is worn at this location.

2) Just below this are one or more meter controls, depicting players level of health, power,
etc.  These are user configurable via a prompt command.  Very similar to and inspired by the 
Rom 2.4 configurable prompt.

3) The current room's description is ever present at the top of the client screen.  It never
scrolls off.   I spent a lot of time writing this stuff, I like to give users a chance to read it.
There is some bandwidth savings here also.  A long description needs to be sent once and
only when locations change.  A "look" command does not need to send this again.

4) The ever present HELP button.  This is context sensitive.  Any selected text, words under
the current cursor position, limb parts or meter bars are sent along with the help command
for the server to process.   

5) Containers are represented as dynamically created icons next to the players shape.
Clicking upon these results in container contents sent to a scrollable list box, where an
additional click will cause item descriptions to display in the main output window.

6) Mouse dragging.  Items and containers may be dragged to and from limb locations for 
wearing and removal to storage.
 
7) A configurable set of command buttons along the left side of the screen.  Very similar to
Zmud's concept.

8) Avatars.  I don't favor this, I just bring it as a possibility.   While many players might desire 
this level of customization, it may be counterproductive to my theme.  I wish to blur the distinctions 
between player controlled characters and mud controlled characters.  This would tend to provide 
a strong distinction, unless great care was used to provide all the NPCs with proper avatars.
This would also require a fair amount of storage and updating at the client end.

Now all the overhead in this is handled by the client machine.  Auto-negotiation is done
unbeknownst to the user (almost identical to Pueblo except it is initiated by the client and
not by the server).   Bandwidth overhead is slightly above that of ansi color with no
overhead to those going through generic clients.
My current test client is using VBscript with ActiveX controls so this only runs under
Microsofts IE.  I have been learning Java in my spare time and the implemetation will most 
likely end up as a Java client, time permitting.