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

[Caliban Tiresias Darklock]

On Thu, 25 Sep 1997 08:47:14 PST8PDT, cg at ami-cg.GraySage.Edmonton.AB.CA
(Chris Gray) wrote:

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

Personal philosophy, I don't really think that someone who doesn't play
MUDs is the best sort of person to be designing one... although as a
programmer, I'm often called upon to write special purpose software for
a group of people I'm not a member of, so I'm certainly not saying that
you can't do it. 

This particular situation, however, is easy to remedy -- fire up tf or
any other client (even raw telnet), and hit a few MUDs. In a matter of
maybe two to three weeks, you can slot right in and see how it all looks
from the player end; after all, the interface doesn't really change much
over the full span of your character's career. I'd recommend this, but
once again it's not really a *must*, just personal philosophy.

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

It's important to supplement the graphic interface with commands, for
various reasons. I'm quite pleased to hear you've done so. :)

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

Just a clarification, the command interface does not necessarily need to
be text: however, I'm trying to avoid turning this into a client or
server based discussion. And certainly for purposes of example, whether
it be an example of how things are or how things should be or what have
you, it's unavoidable to have mention of some client or server -- be it
existing, theoretical, or whatever. There's a grey area in here, because
the interface is virtually never a separate module.

A command interface can certainly be something binary along the lines of
an ISR, with the actual text or graphic interface handled by the client;
however, at that point, the text commands or buttons pass out of the
domain of interface and become of peripheral concern for example
purposes. You could certainly use something like that to entirely avoid
the question of usability in the first place, provided sufficient
facilities are presented for people to build effective clients.

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

Well, tf can actually do *all* of that, but is too similar to
programming for most people's tastes. It's also very extensive and a
little confusing to learn.

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

Realms of Despair has a Java client, which is somewhere on www.game.org;
you may want to look at it and see how they've done things. They also
have their own dedicated Windows client available on the same site.

>Do you mean Netscape plugins for your 'plugin port'? 

NO! Yuck! That's an absolutely horrible idea! The concept is similar,
though, as you would have basically two interfaces... I envision it like
this:

	Port 1638: Standard text interface for players
	Port 1639: Binary ISR-style interface for clients

Basically, port 1639 would enable someone to devise a client which
actually *is* completely binary, and doesn't require as much data to be
sent over the network; it would also serve as an additional port usable
by someone with a normal client, where they could connect something like
a small control panel which kept a readout of some statistics or
something and maybe kept track of certain game events. In order for
someone to connect to the MUD, they would need to use one of these
ports, and could potentially use both. 

I call the additional port a plug-in port because while both ports
produce everything necessary to play the game, you have to plug
something specific into the plug-in port for it to be useful: you can't
expect to just hook anything up to it and be able to work with it. Sort
of like a SCSI port as opposed to an IDE port; you can't interchange
them. 

It's also more or less expected that the player will use a 'normal'
client to connect on the main port and use the plug-in port to perform
some supporting role. This, however, is not necessarily the case; a
single client could very well run both ports (perhaps consider this like
the control and data ports of FTP?), and of course you could very well
write a client which only dealt with the plug-in port if the binary API
is well documented and comprehensive.

=+[caliban at darklock.com]=+=+=+=+=+=+=+=+=+=+=[http://www.darklock.com/]+=
"It must be remembered that there is nothing more difficult to plan, more 
doubtful of success, nor more dangerous to manage than the creation of a 
new system. For the initiator has the enmity of all who would profit by 
the preservation of the old institution, and merely lukewarm defenders in 
those who would gain by the new one."                      -- Machiavelli
=+=+=+[We are the music makers and we are the dreamers of dreams]+=+=+=+=