[MUD-Dev] Remote client connection

[John Bertoglio]

> Phillip Lenhardt  Sent: Tuesday, June 20, 2000 3:14 PM
> 
> On Tue, Jun 20, 2000 at 03:52:36PM -0400, Travis Casey wrote:
> > Tuesday, June 20, 2000, 2:33:03 PM, Phillip Lenhardt wrote:
> > 
<cut>
> 
> > Now, for an adventure game, multiple choice prompts might work very
> > well -- but for a roleplaying game, they're very limiting.

Now, if we are talking about building linear channels of action for the
purpose of limiting choices for the developer, I agree. 

> Limiting, yes. "Very" limiting, debateable. After all, text interfaces
> in and of themselves are limiting and I would argue that the interesting
> possibilities of the text interface are far from exhausted; otherwise,
> why are we talking about them? :)

By their nature computer games limit choices. Until full natural language
parsers backed by quantum computers become commonplace, this will not 
change. A menu driven system need not be any more limiting than a 
text based one. A system with 200 emotes has a limitation, 200 commands. 
How those commands are called is an exercise in user interface design.
The key to interface design is to facilitate communication between
the user and the application (and in the case of MUDS, other users). 
While the traditional, cryptic text commands for emotes are easy for 
mud veterans, these, like most of the sophisticated features of MUDs
are very difficult to learn. Calling a menu with 200 radio buttons
may not seem like a good thing to a veteran player, but is a life 
saver for a newbie, especially if backed by an adequate help system.

After the first few times the huge emote page displays, the user might
be looking for a better solutions. One is a custom menu. Allow the 
player to mark their favorite emotes and call the custom menu instead. 
Then, you can take it to another level. Facilitate the creation of 
emote macros, which can be named and called from menus or speed key
combinations. What you will discover is that all but the hard cases
will switch to menus, at least some of the time. I can do file clean
up much faster at the DOS prompt, but usually use Windows Explorer
because it has a higher information density than a DOS window and
makes decision making faster.

Another option is to build "standard" custom menus for different
roleplay archetypes. These can allow a newbie roleplayer to quickly 
grasp how to express their character in the online world.

The same goes for other GUI solutions. My MUD has a text interface
but some commands will not be possible without using the GUI. Others
will be much faster from the command line.

Example: dr a<return> (drop all) is a pretty fast way to dump your 
inventory. But changing from war armor to party clothes (while 
possible, one command at a time) is efficient when each item presents
a number of buttons which allows a large inventory to be processed
quickly. Also, the GUI has a higher information density
than a simple inv command which might allow for more creative 
choices. 
> 
> I don't see limits as walls to run into, I see them as walls to climb
> towards new heights. 
> 
Limits are real. But they do not need to be expressed by the user 
interface.

John A. Bertoglio 
  _____  

PulsePoll.com <http://www.pulsepoll.com/>  
| 503.781.3563
| jb at pulsepoll.com|




_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev