GUIs seem to be a staple in terms of ease-of-use when dealing with unfamiliar programs.  That's usually because all of the options you have available to you are right in front of you, and no obscure command is necessary to dig out more options.  Because of the text-based nature of most muds, we have a greater learning curve for new and different options simply because they're not immediately in a player's sight.

Many muds have a number of configuration options that can be modified by the player: Dimensions of the screen for automatic word-wrapping, ANSI color, channel options for chat and clan talk, wimpy settings, autoloot, etc.  There are of course other options for administrative use: Wizlock, newlock, banning users, etc.  These things are usually accessable through specialty commands that you can find through a help menu of some sort.

I propose that we blur the line between the game world and the administrative duties of that world.  Doing such a thing would give us many of the advantages in ease-of-use and plain coolness that GUIs have, while still maintaining the automation benefits of our text-based environment.

For example, consider how a player might toggle ansi color in a typical mud:
One could give it an object or a switch in a configuration room in the player's head:
Administrators could also have their own in-game configuration area:
Something like this is, of course, much more complex than a few simple commands.  But it makes up for it in neatness-factor and the ability to learn it quickly, given rudimentary knowledge of the pre-existing game world.  One can also "see" all the options that are available to them in terms of the gameworld that they're familiar with, so there is no need to learn new interfaces for each command.

Thoughts?

Well, as an admin, I think I'd find the admin interface a little...
bulky. I'd prefer something just quick and easy to deal with
pests.

Though after some thought, I think many of the ideas you
presented could be a lot of fun if implemented correctly. Say
you are playing a med. fantasy game. If you were really
there, you're simply living your life. There isn't much in the
an interface of any kind going on. So your proposed system
might be a little overkill. *For my tastes*

BUT, take for instance a MECH game or something similiar. A
game where you are someone with that sort of interface
necessary in your daily routine. It would be fairly interesting
to actually have to jump from panel to panel to correctly
simulate being inside the MECH. Actually, I'm not much into
MECHs so my opinion probably isn't a valid one. But it sure
sounded good at the time. *mull*

For those new to MUDding, it would probably be a good idea.
Since if they get familiar with going room to room, then it
should theoretically be easier for them to just go to another
room to configure their character through that. Theoretically.

Personally, I'm just more a fan of being able to 'toggle'
something on or off at my whim.

Of course, as am I =). I don't think that such a system would replace those things, but act as a supplement. Although some concepts could still be used that contemporary systems often ignore, such as representing all states (e.g., a bi-state switch or a slider with minimums and maximums etched into a plate), or only the current state (e.g., a display for one value, the thread indicating that the player was following GroupLeader) of an object in a central area.

The beef of the post, dealing with configuration-as-interactivity, is purely for fun rather than productivity, although I'd be interested in hearing if anybody can see productivity gains from a system like this. With all other things being equal, it seems that such a system would have a leg-up due to the standard interface. But the entry into this interface may be prohibitive for one-off commands.

Well, although I kinda like the looks of it, I think that especially for the admins using the system will be far too much hassle, and they'll stick to the much briefer, purely command-driven system. As for the players: From my experience, you usually don't configure your input/output options very frequently. So, the disadvantage of disappearing from the game when entering your "configuration room", or, even worse, being unable to react to the things that happen around your character won't be weighted up by the nicer interface. If you have a PK-system, you have a problem in either case: Either people will use it to escape PK by stepping into the config-room, or they probably will not use it, as it will render their char helpless while their mind is configuring.
All in all, I believe you're better off with investing the energy needed for such a system into a good interface to your help system, and newbie-friendly standard options. Having only a single command for configuration with sub-commands being displayed at each step further down also helps a lot to flatten the learning-curve.

Another way to do this, although for a more limited audience, is to use MXP.

Same for the spammer:

This is so ironic, because they're probably using a graphical mud client on top of a graphically oriented operating system =).

If you'll read the post directly above yours, you'll see that I suggested that this "act as a supplement", and that it was "purely for fun".

This is easy to solve: Simply pop the user out of config mode when something happens that requires his reaction.

Only a very poorly designed system would be prone to these problems, I've already given one suggestion.  Another is to disable entry into the configuration room much like you disable the movement and quit commands =).

Teelf: I've never heard of MXP, so thanks for the info =).  I just did a little research, and it seems that there's a few clients that support it.  Hopefully I can find a unix client that does =).  I do agree that hyperlinking is certainly a step-up in text-based interfaces.  Without client support, I suspect it can be approximated with context-sensitive areas, though:

The context sensitivty sounds like a great idea.  Perhaps builders could specify which keywords expand to which commands?  This would also tie in perfectly with my original idea of interactive game objects: The context-sensitive ansi switch would expand to the traditional command for toggling color.

I think MXP has a lot of potential especially since it's an open specification and anyone can join in.  Here's an example from the Dawn of Time codebase.



Notice the 'tabs' on the top?  I thought that was pretty neat.

Unfortunately only MUSHclient and zMud support MXP right now and are for windows only.

Context sensivity is a very good idea.  But, naturally, without an MXP-like interface it would be much more difficult and CPU intensive.

I think what most people worry about is time. A comprehensive control system for a game would be great, but each would be unique. Most Staff find they have trouble keeping up with the basics and would not be able to keep their control rooms up to date.

Personally I have always constructed rooms for myself that helped me to get things done. Making displays handy, and adding special controls that were not for general use, but it was very personal and usually locked to myself alone.

I would love to see this level of functionality added to standard codebases, as a registered Zmud user it works for me.

A.T
(-)