[Yui Unifex]

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:

Originally Posted by > ansi ANSI color toggled on. > ansi ANSI color toggled off.

One could give it an object or a switch in a configuration room in the player's head:

Originally Posted by > enter configuration Configuration You are standing in a large room with blinking panels and flashing lights.  Directly in front of you is a panel of switches.  A silver thread connects you to GroupLeader, indicating that you wish to follow this person wherever they lead.  Situated on the far wall, a caricature of yourself fleeing from battle has an indicator that reads "20 hp". > look panel The panel is made up of two perfectly straight rows of bi-state switches. Switches toggled on: ANSI, Autoloot, Autosac Switches toggled off: Autoflee > toggle ansi You reach out and flick the ANSI switch down. ANSI color toggled off. > cut thread You have severed the thread to GroupLeader. You have stopped following GroupLeader.

Administrators could also have their own in-game configuration area:

Originally Posted by * Bob spams! * Bob spams! * Bob spams! * Bob spams! > take Bob You reach out a hand and scoop Bob into your pocket. > goto adminconfig A vast plane stretches beneath you.  Vats are layed out in concentric circles along the ground, each one with a seperate purpose.  The vats are labeled "Ban", "Delete", "Hell". > put bob in ban You toss Bob carelessly into the vat labeled "Ban". Bob has been banned from the game! > look ban Peering into the vat labeled "Ban", you see shadows of mortal men.  Their names are: Annoyance, Spammer, Griefer, Bob.

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.

[Yui Unifex]

Originally Posted by (TG_Nek @ May 29 2002,11:10 am) 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.

[Yazracor]

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.

[Teelf]

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

Originally Posted by >look panel Options: ANSI ON Autoloot ON Autosac ON Autoflee OFF Leader: GroupLeader >(Player mouse clicks on ANSI) ANSI color is OFF. >(Player mouse clicks on ANSI) ANSI color is ON. >(Player mouse clicks on Leader) You are no longer following GroupLeader.

Same for the spammer:

Originally Posted by * Bob spams! * Bob spams! * Bob spams! * Bob spams! >who [ 5   mag  Bob TheSpammer] [10  war   Tom TheAnnoyer   ] ... >(Wiz clicks on Bob) Name: Bob        Class: Mage Race: Elf Description: ...       Imm Commands Ban    Delete    Hell >(Wiz clicks on Ban) You toss Bob carelessly into the vat labeled "Ban". Bob has been banned from the game! and etc.

[Yui Unifex]

Originally Posted by (Yazracor @ blah) 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.

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

Originally Posted by (Yazracor @ blah) being unable to react to the things that happen around your character won't be weighted up by the nicer interface.

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

Originally Posted by (Yazracor @ blah) 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.

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:

Originally Posted by Town Square You are standing in the town square.  In the center of the square is a fountain. > (User clicks on fountain) You drink from the fountain. > (User types "fountain", or "f") You drink from the fountain.

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.

[Teelf]

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.

MXP Example

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.

[Alexander Tau]

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

[mhc]

I do much of the sys-admin mud-admin work directly logged on to the MUD host. Then, a 'ban' of a spammer can look:

mv mortal/b/bob.sav banish/b/

and I can make a swift alias for it in my shell. If I want graphics, I can wrap it in some Tcl/Tk code, or I could have a local webform, with the web-server running on the host, or even *gasp* written in LPC using the socket efuns...

The possibilities are endless, and here I am, staggering under the load of my own imagination.