[MUD-Dev] MUD client popularity

[Sean Middleditch]

On Wed, 2004-02-04 at 00:45 -0500, Zach Collins (Siege) wrote:
> On Tue, 3 Feb 2004, Sean Middleditch wrote:

>> I don't know of many that use any kind of GUI control interface
>> or whatnot.  This is one of my goals with ZMP (Zenith MUD
>> Protocol) however, and one of these days I'll get around to
>> implementing something in AweMUD/PyCL to show it off.  The idea
>> is, a single standard format package is developed in ZMP that
>> works across all clients implementing it.  Additionall, a GUI
>> control library, perhaps made by sending XML interface
>> descriptions over ZMP, would allow the MUD to do much more
>> intricate displays on the client.  Graphical dedicated clients
>> can also allow for paperdolls and automaps and stuff (perhaps
>> controlled over ZMP) to be easily readable and usable.

> I would recommend a look at the MCP project, which already has at
> least one working proof of concept at each end of the
> client-server chain.  As well as being a message-passing protocol,
> there is a GUI package also being developed for it.

>   http://www.belfry.com/fuzzball/trebuchet/mcp.html
>   http://www.belfry.com/fuzzball/trebuchet/mcp-gui.htm

I'll not get into the ZMP vs MCP bit, my view on that is well
documented in several places online already.  ;-)

So far as the GUI system, I honestly believe that sending an XML
document describing the dialog is by far the best choice.  Among
other things, it makes it possible for the server to stream the XML
description straight from a file to the client, which makes it very
easy for builders/UI-designers to tweak and update the UI without
needing to edit code.  It could also be used to allow the client to
cache the documents or supply over-rides to documents, so (for
example) users could craft updated UI descriptions for MUDs that
employ a UI designer with the usual lack of design sense.
Additionally, since the document would be delivered in one ZMP(or
MCP, whichever) command, it would make the client-side protocol much
simpler to implement, as it wouldn't need to retain tons of state
and commands; just interpret the document to build the GUI (possibly
using one of the dozens existing freely available XML-GUI
libraries), and update/event commands back.  It reduces network
traffic and the amount of code necessary.

Of course, that's all just talk on my part without a good reference
implementation of such a GUI framework.  ;-) One of a million things
on my TODO list...

--
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev