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

[Caliban Tiresias Darklock]

On Tuesday, September 23, 1997 4:48 AM, Chris Gray 
[SMTP:cg at ami-cg.GraySage.Edmonton.AB.CA] wrote:
>
> This is exactly what I aimed to assist with my "graphics-aided" client.
> I open another window, which I divide horizontally in two. The left half
> is used for scenario-generated maps, which are totally ugly, but very
> useful in orienting oneself - you can see which directions have unhidden
> exits. The right half has a set of clickable buttons for the various
> directions, and a central one for "look around". The final step was to
> enable single-keystroke commands - you can use the numeric keypad for
> moving - just use the key that is in the proper relative direction from
> the '5' key. Another addition for mouse-users - allow clicking on the
> map area to move the character in the indicated relative direction.

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

> Has this become a "graphical MUD"? You judge. Can you do less with it
> than a straight-text MUD? No, since you still have full access to the
> text window. Is it easier for many to use than a straight-text MUD? I
> would answer that with a strong yes.

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

Hey, this is a really nifty idea. I like it. I'm going to go think about it 
some more, and maybe come back with more thoughts... does anyone else think 
the idea of a 'client port' and 'plugin port' would be useful? I'm really 
starting to see a lot of possibilities for this -- even under a text 
environment, you could have a TSR type popup program that gave you some 
additional info. Given a good protocol, you could allow all sorts of 
information exchange. I'd suggest that the port not actually be used to DO 
anything (although one program could certainly handle both ports for 
automation of the session), but just to exchange data. I like this idea a 
LOT. Cool. :)