[MUD-Dev] MUD client popularity

[Sean Middleditch]

On Thu, 2004-01-29 at 14:06, Travis Casey wrote:

> I did sometimes wonder why no one had ever created a mud server
> that used curses or something like that... I thought about it, but
> didn't know enough about curses to easily hack it to support
> multiple terminals instead of just one.

I've thought of this, but it breaks down for several reasons.

First, users need a real telnet/terminal client.  Most MUD clients
don't actually implement a real terminal interface.  People tend to
like the features that clients like zMUD and others offer them that
no text console UI could (mapping, paper dolls, graphics, etc.)

Second, it puts all of the work in the server.  The more work the
server does, the slower it will run and more lag will ensue.
Sending just the raw data whenever possible to the client and
letting the client do the fancy display work makes much more
efficient use of the available processors (those in the server and
those in the clients). Unfortunately, very few MUDs actually *do*
anything nifty in the client.

Finally, the telnet control interfaces (like ncurses) don't work
nearly as well as people would hope.  You can see these things on
your own by telneting/sshing between several UNIX systems and notice
how things don't quite work as you'd expect - keys change meaning,
some keys stop working, etc.  Every vendor and version of curses has
slightly different terminal information databases, it seems.

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.

Another idea is to make a telnet MUD client proxy system.  I.e., the
user connects to the proxy host/port, which just offers a telnet
client that connects to the actual MUD (and only the actual MUD).
This way, users with local clients are free to connect directly to
the MUD, the client interface and MUD logic are multi-process "for
free", you can leverage the work already put into an existing
console client, and you could even split the client proxy and MUD
onto separate hosts to get better performance (if you have so many
users that it makes that kind of difference).

--
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