[MUD-Dev] Usability and interface

[clawrenc at cup.hp.com]

In <Pine.SV4.3.93.970926015912.6649D-100000 at online1>, on 09/26/97 
   at 12:51 AM, Broly <gunther at online1.magnus1.com> said:

>On Thu, 25 Sep 1997, Nathan Yospe wrote:

>> On Wed, 24 Sep 1997, Caliban Tiresias Darklock wrote:

>> :On Wednesday, September 24, 1997 4:48 AM, Maddy [SMTP:maddy at fysh.org] 
>> :wrote:


>Not really a problem (IMHO) with design.  Consider:
>
>1.a loin vs. a kitten, or
>2.a Sherman tank vs. a Honda Accord, or
>3.a gun-wielding mugger vs. grandma.
>
>The real world has vastly different power levels, and any of the
>above battles would end as soon as the first object attacked, barring
>some miracle.  Yet there are plenty of kittens,Accords, and grandmas. 
>Kittens rarely deal with lions, the tank driver would be shot for
>blowing up Accords, and wise old grandma knows better(we hope) than
>to start fights with gun-wielding muggers.  So there really isn't a
>balance problem after all.
>
>In mud terms, the balance can be reproduced for each of the three
>scenarios.

The difference is in the level of personal investment. That sherman
tank driver  has a considerable investment in his life, as does the
Accord driver, the average MUD player inc omparison is all too aware
than he's 20 keystrokes away from having a new and different character
on the same game.  This has a large effect on the internal economies
as compared to RL.

>1.  sequestor the really nasty mobs.  There's no real reason to send
>a horde or rampaging dragons thru the heart of newbie country.  

<sigh> I *really* dislike newbie, or otherwise "level targeted" areas.

>2.  Have some sort of justice system,  and create reasonable mobile
>code. Mobcode will prevent the town sherrif from going on a killing
>spree..well maybe once...And a justice system will keep
>out-of-control players in check.

Here I'd argue with you.  Compare the justice system on Island (or at
least Keegan's reports on it here).  The result is that the justice
code becomes yet another game mechanic to be constructively used and
taken advantage of.  FWLIW This was the primary principle in designing
the justice system i proposed here a few months back.

>Perhaps the worst death is 'typo death', but there really isn't too
>much a coder can do in the way of design to prevent it without
>ruining the game. You could ask for a confirmation before allowing
>players to enter dangerous places, but that would result in something
>like the following:

>  >w
>  The forest parts to reveal a small meadow.
>  >n
>  You follow the shrub-line at the forest's edge.
>  >n
>  A slight downward slope leads you toward Acorn Valley.
>  >n
>  You approach the cliff.
>  >n
>  Do you really want to do that? (go/stop)
>  >stop
>  >look
>  You stand on the edge of a sharp cliff overlooking Acorn Valley.
>  There are small grasses common to this meadowland that grow on the
>  fertile soil all the way to the edge of the cliff.  You can take
>  flight by going north over the edge of the cliff, but it is not
>  advised unless you have managed to grow some wings, or you could
>  head back off the cliff to the south.
>  >look north
>  You see that the cliff drops down some 300 meters below you. 
>  You	would squash like a bug if you went this way.
>  >look down
>  Its a long way down, but you think you can make out one or two
>  distinct splat marks at the bottom.

>Note that the player is not taking any notice of his/her surroundings
>until prompted by the game.  Players are smart enough to learn when it
>would prompt.

SHADES takes a bivalent approach to this.  Some areas prompt you (eg
the Shifting Sands, and Chasm) others don't (eg East Tower).  The main
difference in selection between the two is that the non-prompting
areas are up-front known to be dangerous to missteps, and the
prompting areas aren't.  SHADES also uses this constructively; hiding
some areas behind false warnings -- the player has to persist beyond
the warning to get there.

I like this approach.

>One design change I made away from the standard was the "stop"
>command. As a player I used to pretype up to 10-15 commands becuase I
>was a slow typist when I first started mudding.  Most games queue the
>commands, then pull the commands off the queue and execute them one
>at a time.  With my design, commands are parsed asap and their
>execution is delayed.  When a player issues the 'stop' command, the
>queued actions are stopped.  stop with no arguments kills all
>commands, 'stop XXX' kills the next XXX command, while stop all.XXX
>kills all XXX commands.  'Stop stop' doesn't work.  (I include this
>here in the discussion on how players end up dying because most of my
>own deaths could have been avoided if I could have avoided the
>temptation to pretype commands...)

This is more or less exactly what I do except that I don't have the
command stack variations on the STOP commands (mostly as I've yet to
find a need).  I do however have action specific STOP modifiers (eg
STOP DIGGING). The driving reason behind this are the common
possibility of very long actions (cf DIG PANAMA CANAL).  STOP allows
such a long command to be interrupted or altered, or multiplexed with
other such commands.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...