[MUD-Dev] Usability and interface and who the hell is suppo

[Chris Gray]

[Caliban D:]

:Remove the map window, and you have Nick Gammon's MUSHclient. Or keep the
:map window, and you have a reasonable approximate of zMUD with its
:automapper ;)

OK. Remember that I don't actually *play* MUDs, so I'm pretty out of
touch with such things (especially if they are PC based rather than
UNIX based). One difference, I suspect, is that in my case the buttons
on the screen are controlled by the server and the scenario. For example,
the building facilities can be run by sets of buttons that come up when
you start with the '@' button. I guess you could do that with a client,
since I also made sure there are command oriented forms of all of the
things that the buttons can do.

:I think I already said that the client and the server themselves are more
:or less out of the scope of the thread, except where they specifically 
:impact the MUD's command interface.

I hadn't realized that. I thought were talking in general about how the
user interacts with the MUD, rather than just with a text command interface.

:				     Most clients (even straight telnet 
:clients like NetTerm) allow you to create 'macros' whch will let you do
:much of the above, and don't require programming to do it; MUSHclient even
:allows you to reassign all the function keys, all the numeric keypad keys,
:and even several keyboard shortcuts. All of this is done through a series
:of dialog boxes which are easy to use and require no actual programming,
:merely pressing Control-G or selecting 'Game -> World Settings' from the
:menu.

It's quite possible that 'tf' can do some of that. I compiled it and run
it at work to connect to my little MUD server, but after a quick glance
at the customization stuff, I said "no way do I want to learn that",
and haven't looked since. It separates input from output, gets the prompts
right, and has input history - that's all I wanted.

:      the problem with tying your game to one client is that you create an
:ingrained O/S war; I would *rather* see an add-on client for the game which
:has a series of additional functions that you can turn on or off. The
:add-on client could connect to an alternate port on the server, say the
:usual telnet port + 1, and send and receive coded data via some proprietary
:protocol... if you release the specifications of that protocol to the
:public, others could develop for it, and you might end up with a larger
:installed base of clients which would end up being a Good Thing. You could
:also select an existing protocol for it, which would be suited to the
:medium; this could also jump-start your efforts in developing for it.

True enough. I've had some Java books on order for 4 months now (finally
phoned the ACM about them last night), with the intent of making a client
in Java - it seemed the most portable way of doing it, while still
supported the stuff that I currently have. I picked the ports this way:

    6666 - regular text-only port
    6667 - port for the custom client to connect to
    6668 - added to let things like 'tf' work better
    telnet - supplied because there was no reason not to

so, I've done the 'telnet port + 1', sort of.

Do you mean Netscape plugins for your 'plugin port'? If so, I wouldn't
be interested - I can't see running a pig of a browser when all I want
is fairly simple. If I can't do the above-mentioned client stuff without
requiring the user to run a browser, I won't bother.

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA