[MUD-Dev] MUD client popularity

[Edward Glowacki]

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 believe curses itself can work with multiple term types, or the OS
does, or in some way term types aren't a terrible issue, I'm not
exactly sure where the magic happens.

In related thoughts, you see lots of software that just spews out
text line after line (MUD-like), considerably fewer that at least
use some curses routines (or simple escape sequences, stuff like
showing the percent complete by overwriting the previous numbers on
the screen), and even fewer that are full-screen interactive (most
notably text editors).  Having looked into this kind of stuff
before, it amazes me that aside from ncurses, which has a few
lower-level window and menu routines, there aren't a whole lot of
libraries available to actually build interactive applications with.
No widget sets (checkboxes, pick lists, menus, etc.) equivalent to
what currently exists in GTK, QT, MS Windows, Mac GUI, or heck even
web applications.  It seems the world pretty much skipped from
"spew" to "GUI", jumping over "console apps" altogether and leaving
a gaping black hole where they should have been.

Another issue with a curses-based MUD is one of screen management.
The standard window size seems to be 80rows x 24lines, which really
isn't a lot to work with.  Unless you have some decent underlying
routines to work with to manage that space (and even if you do),
fitting everything in will take a large amount of effort.

By comparison with a MUD client, a curses-based interface run
remotely could have a few issues with performance, namely
responsiveness.  With a mud client, you compose a command, send it,
and depending on how much lag you're suffering, the command usually
comes right back with a result.  With a curses-based interface, each
character would have to be sent to the MUD server and a reply echoed
back (or new text sent, or a new sub-window drawn, or whatever), so
any lag at all will make the interface unbearably unresponsive.  The
desired response time for echoing a keypress is something like 1/10
of a second, maximum, or the cause and effect won't seem to line up,
and that's not a whole lot of time considering internet latencies.

Don't get me wrong, I'd love to see a curses-based MUD, but
realistically it may not be practical to implement unless all your
players are on the LAN.

You could probably do a semi-GUI game, where the bulk of the content
is text based, but you have a custom GUI client that separates all
the information into various windows, buttons, menus, etc. on
screen, and maybe has some support for graphics or graphical
mapping, plus the usual triggers and aliases and such you find in a
typical MUD client.  That way you'd get the responsiveness of a MUD
client and the control you would have over appearance of a
curses-based game.  I'm pretty sure some of these custom clients
exist (probably JAVA based?) but I'm not sure how well integrated
they are with the MUD, whether or not the custom client is basically
REQUIRED to play the game or simply "suggested".

-ED

--
Edward Glowacki			glowack2 at msu.edu
A PBS mind in an MTV world.
	-- Author unknown
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev