[MUD-Dev] Usability and interface

Adam Wiggins nightfall at user1.inficad.com
Sat Sep 20 19:22:52 CEST 1997


[Caliban:]
> On Fri, 19 Sep 1997 21:43:02 PST8PDT, Adam Wiggins
> >[Caliban:]
> >> I have. I've seen people give long complex descriptions of mixing poisons 
> >> and other nifty things, which is really a great idea for the cerebral 
> >> types, but some of us don't want to scratch our heads and go 'Now HOW does 
> >> that work again? Do I stir *before* I add the hemlock, or after?' -- while 
> >> it's a neat academic exercise, it's a terribly bad game.
> >
> >I disagree very strongly with this.  I consider the exploration/discovery
> >element to be the defining feature which differentiates a 'standard' linear
> >game and a true gaming world.  
> 
> All I'm saying is that if everything is a collection of small simple
> commands, it lends itself very badly to play but very easily to
> scripting. Ultima's reagent mixing was an example; it was almost a form
> of copy protection, as you had to have the game reference handy the
> whole time. In time, you memorised certain combinations for common
> spells (An Nox and In Mani Corp, for example), but you still had to have
> the spell list available. If I could have written macros, these things
> would have been single-key. 

Yeah, but I see this as a serious flaw with Ultima's spell 'system' - it
wasn't a 'system' at all.  It was just a list of reagents which were combined
to make spells.  There was no element of what-if; you couldn't decide to use
a little extra mandrake to make the invisibility spell last longer, or a little
extra spidersilk to make your fireball hotter.  You simply jumped through
the right hoops to get the spell you want, no different from puzzles
in a static adventure game (which, as I've stated before, I usually despise).

> Note that whether you intend it or not, people will almost always come
> up with a way to script.

Sure.  You could write a script for your *life*, if you had a complex enough
computer and way too much free time.  Humans conduct themselves more or
less in a rule-based manner, and everything we do pretty much reflects this.
Once you know all the rules, it's easy enough to create some boolean logic
that will have the effect you want.

> The above example of mixing a poison would be
> trivial for someone who had coded it into a script; the script would
> probably be on some web page; and the *spirit* of the process would be
> lost. 

Yeah, and this is the number one pitfall in designing a system.  You want
it to be complex and random enough so that it's difficult and not terribly
productive to script, yet intuative and logical enough so that it doesn't
seem like a bunch of completely arbitrary effects with no causal relationship.
A tall order, but this is what I've chosen to focus on for my own mud.

> On the other hand, if you count on people scripting, then people who
> don't know how to script or where to find scripts end up having a real
> pain of a time trying to play the game. It's a double edged sword.

Not only that, but I don't find writing scripts all that fun, and if I have
the choice, I'd rather do it myself.  It's just that it's easy for game
designers to come up with busy work which I quickly tire of.  If the rest
of the game is good enough, I'll write a script so that I can ignore the
busy work and get onto the fun parts.  Busy work is defined as a set of
actions which I need to do to get a desired effect.  If those actions are
all done the exact same way every single time, I get bored of it.
Some examples (which I know you don't like, but other might):

  To make a potion which cures poison, combine hewingroot and thistledown.
  Boil for fifteen minutes and administer two spoonfuls to the patient.

Or:

  To make a potion which counters the effects of black lotus, combine
  hewingroot and thistledown.  Boil for around fifteen minutes, but if the
  hewingroot was dried (it's only in season for part of the year), boil for
  an extra twenty minutes.  St. John's wort can be substituted for thistledown,
  however you need twice as much, and it needs to be seperated from the husk
  before use.  If the potion is to be administered within an hour of the
  consumption of the lotus, give them two tablespoons.  If the symptoms do
  not clear up immedaitely, adminster another tablespoon.  Note that minotaurs
  and ogres are resistant to the effects of hewingroot, so if you used this,
  double the portion.  For best effect, adminster with food.  If the black lotus  from which the poison was made was harvested at midnight with a prayer to
  the dark goddess Yurga, the countermeassure must be blessed by Imo, god of
  life.  If the lotus was from souther Stygia there is a more effective
  countermeassure in the form of a potion made from...

The two aren't fundamentally different.  The second only has enough elements
to keep human players interested, while making scripting both difficult and
not very worthwhile.  IMO, most of your time playing should be doing things
you are famliar with, but the *exact* thing you are doing you have never
done before.  This requires a system which is logical and consistent.

A technical note: making randomized messages is a great way to make scripting
more of a pain and the game more interesting for players.

> >IMO, the more involved,
> >the longer it's going to hold your attention.  Now, if the interface is
> >difficult or there's no easy way to gain a foothold into the system (ie,
> >learning a simple part of the system to get a feel for it) then it can
> >be frustrating.  
> 
> I'd most prefer an interface which is simple to learn and easy to use,
> but can be increased in application to complex tasks easily. One way to
> achieve this is to have all the atomic, low-level commands in the MUD,
> and then have pre-written scripts built into the server which allow new
> players to play without learning everything first; for example, my
> concept of 'grip sword handle right' could be scripted into a 'wield'
> command, allowing the player to choose whether he wants to be complex or
> simple. While 'wield sword' is equivalent to 'grip sword handle right',
> they serve different purposes and are both useful.

Ya.  Also, having extra parameters for commands.  The following things
all work on my mud:

> shoot
> shoot orc
> shoot bow
> shoot arrow in bow at orc
> shot bow at orc to north

The 'shoot' command by itself will try to fire whatever ranged weapon you
have in your hands with whatever ammo is the most handy at whatever target
you were last firing at.  If you want to specify different ammo, a different
weapon, a different target, or whatever you can put all of those on the command
line.  Even 'shoot orc' is making a lot of assumptions - that you want to
shoot the arrow loaded in the bow in your hands at the orc nearby, not
that you want to make use of the orc as a ranged weapon.

Also, we are considering having play 'modes' for players.  Not sure what
this would be, but possibly something like:

> mode lp
You are now in LPmud mode.
> eq
Unrecognized command.
> inventory
You are carrying a bow and two arrows.
You are wearing a shirt and pants.
> mode diku
You are now in DikuMUD mode.
> eq
You are wearing a shirt and pants.
> i
You are carrying a bow and two arrows.
> mode none
You are now in normal play mode.
> eq
Unrecognized command.
> wield
There is no 'wield' command here, just pick something up.
For more info type 'help hands'.
>

Etc.  It will probably just give you a set of aliases, most of which are
just "echo There is no 'X' command here, see help on Y."

> >FWIW, I though the PC game Daggerfall had a nice balance of this sort.
> >A newbie could have a character in three mouse clicks, while old grognards li
> >me can fiddle around with numbers all day long.
> 
> I'll have to go pick up a copy. I don't buy many games, because they all
> tend to annoy me these days.

I wouldn't bother, it's not all that good.  A co-worker of mine bought it
and I was fooling around with it.  Pretty descent spell creation system,
though.

> >This actually turned out to be quite useful,
> >as players there frequently muttered things in their native language, or said
> >things only for the benefit of their fellow <insert race name>.  
> 
> In my experience such things rarely happen online. Maybe I've been
> playing the wrong games. 

A lot of it is how easy it is to actually switch languages.  Ie,
if you have to do:

> speak giantish
> say Damn dwarves...
> speak common

It's not really worthwhile.  If you can do:

> alias mutter say in giantish $1
> mutter Damn dwarves...

it's a little more practical.

> >These skills actually came in handy in 'real' situations, too: you had to say
> >'friend' in elven to open the door to Moria; you had to say a phrase in demon
> >to solve a certain quest (which I have detailed on this list before); many
> >spellbooks were written in different languages (written being a different
> >skill than spoken, of course); 
> 
> I don't find that any of these are terribly additive to the game. You
> lock anyone who can't find an elf out of Moria; you prevent anyone who
> can't speak demon or conjure a demon out of a quest; and you lock
> spellbooks out of the accessibility of people. Languages are like locks,
> you slap them on something and then the player ends up with this simple
> binary 'yes/no' thing as to whether they gain any benefit. 

Might I assume, then, that you also dislike actual locks on doors?  They lock
out anyone with a key or a thief that can pick it.  Large monsters lock out
weaker characters.  Long distances lock out people that don't have a lot
of time and/or stamina.  I like obstacles, and what's more I like varied
obstacles.  I'm not saying I'd like every single puzzle in the game to
require you speak some language.  I'm saying that I like as many varied devices
as possible so that each 'puzzle' can have a semi-unique solution, instead of
all of them requiring either 'kill monster X' or 'retrieve item Y'.

> In P&P, all of these things are just as possible, but you have many more
> options to get by them. In all the games that I've played, I've never
> seen one of them offer a translator for hire. I guess only PCs are
> supposed to do that. 

Yeah, now you're talking.  Introducing a new element like languages allows
you to put in some much more than just the actual languages themselves.
You've got translators, teachers, or others who actually employ themselves
based on languages.  You've got the fun of mistaken translations ("You
said WHAT to me?!"), people overhearing things that they aren't supposed
to ("I didn't know you knew language X!")...the later of which is pretty
interesting on a mud where there's no mechanism for completely private
communication.

> >Eventually a friend and I started collecting party members
> >and communicating via sign language.  Unfortunately only about half the part
> >had ever bothered to learn it; the other half had to sit there and watch us
> >wag our fingers and wonder what the hell was going on...
> 
> Cute solution. Note, however, that the majority of the party was
> completely screwed.

I take it by this that you think that this is a bad thing?
All my best mud stories/memories usually involve someone, somewhere (usually
me) saying 'Shit...I/we are TOTALLY screwed'.  For example, the story above.
Everyone running around in a panic screaming worldlessly in those twisting
coridors was one of the funnest and most exciting times I've ever had on a mud.
I suppose it sort of parallels that scene in Aliens where the marines first
get attacked by the aliens.  Chaos, disorder, dissention, and a chance to
go up against a difficult (impossible?) situation are 'fun' for me.

> Languages are applicable and useful only in certain
> small, rare situations in my experience, and many of the real uses of
> language are completely overlooked on MUDs. 

Which doesn't mean that they are completely useless, stupid, and worthless,
which is the statement I was responding to.  Yes, most of the elements
that go into a game are comparitively small in and of themselves.  All
of these elements combine to make what we call a 'game'.

> >First things first.  D&D without the handbooks would have been silly.
> 
> You've never played completely without the books? You don't know what

Yes, only after everyone knew them all damn near by heart, and knew
exactly how the game way played.  If D&D was published without any
specific rules it never would have worked, despite the fact that most
experienced players ignore and/or modify most of the rules.

> you're missing. We used to do this routinely on the school bus, and it
> was truly fascinating. 

Although the rules are not 'the game' by themselves, they do make up the
game.  Do you believe that D&D should have been published as a vague
list of ideas on how to sit around and create fantasy stories with your
friends?  Even the act of having a character sheet for writing down stats
and objects gives the game a real sense of solidity.  It's not that
writing down 'AC4' *is* the game.  But it's important nonetheless.

> >Someone's got to push up the ante; if everyone decided that doing something
> >a little more interesting was just too dang hard, or 'a fool's errand',
> >we'd all still be playing Pong.  Actually, Pong would have never been
> >invented.
> 
> What? Of course we have to up the ante, but let's not do it by stacking
> eight million new things on top of what we have on impulse, okay? You
> can't just hang a multitude of new things off an existing framework and
> expect it to run properly. 

Nuke the existing framework and come up with a new one into which the
multitude will fit properly, however, and you're on the right track.

The way we arrived at our conclusions about how we wanted the mud to play
was mainly through details.  I thought about things that had happened on
other muds, what was 'good' about those situations, and how we could make
those fit into the game.  Once we knew more or less how we wanted things to
work on the player level (which is all about details, events, and elements),
then we steped back to look at the big picture.  Without those concreate
details as guidelines, though, we would have been just flailing around
blindly with vague notions.

> Modern gaming isn't pong with fifty paddles, after all ;)

Heh.  I'm more intereted in taking what's *good* about current games (that
is, what makes me enjoy playing them to begin with), ditch what I don't
like, and then add in things I think I'd like to see.  Certainly there
are plenty of muds that go the fifty paddles route, however - check out
all the adds for '1000 levels!  27 classes!  18 races!  warriors with
25,000 hitpoints!'  I think it's pretty obvious that no one here is
trying to do that.

> >Some many not
> >like this approach, but we love it, and once we had solidified how it worked
> >with a few basic commands, we expanded the concept to work with everyone
> >possible command we wanted.
> 
> I certainly think this sounds like a fantastic idea, and I'd love to
> hear a little more background on it.

Hum, okay.  Our main desire was, first off, that you are interacting
with your character, telling her what to do or where to go, and then getting
sensory input from her about the results of those actions and the actions of
others around her.  But the player is *not* the character, and we absolutely
wanted the character to seem less like an impassive lump of clay and more
like a living being with fears and predjudices, whose cortex you just happened
to have dropped into.  We wanted the character to react to stimuli without
player intervention, but we wanted the player to be able to intervene at any
point to modify or create new actions.

Some things I hate:

Bubba crashes into you in a thundering collision, knocking you to the ground!
> 
Bubba stomps on you with his boot, blood sprays out of your nose!
You ought to stand up...
> [lag]
Bubba stomps on you with his boot, blood sprays out of your nose!
You ought to stand up...
> [lag]
Bubba stomps on you with his boot, blood sprays out of your nose!
You ought to stand up...
> stand
You clamber to your feet.

Not only do I think your character should consider getting to his feet
#1 priority, I think it should be *difficult* to force him to stay on the
ground - a test of willpower, should you desire to do it.

Naturally there are tons of options you can set to determine what your
character's responses will be.  Ie, normally you'll try to avoid incoming
attacks however you can (assuming you see them as dangerous).  If you
decide, however, that parrying with your current weapon (The Glass Sword of
Demon Slaying) is a bad idea, you can turn parrying 'off' by accessing the
parry toggle.  Ditto for dodging.  You can also set what body part you'd
like to try to catch blows on - by default you go for fleshy areas (shoulder,
arm, and thigh) but if you've got the Mithril Arm of Defence you can try
to catch all blows there.  Aggressiveness and visciousness are very important.
Aggressiveness ranges from Ghandi (you'll try to avoid harm, of course, but
will not fight back at all) to berserk attack, where you'll take every
opportunity to attack that you can.

Most of the commands, though, are interjective, as I mentioned.  Thus you
can set your aggressiveness to Ghandi and manually type 'swing' when you
see an opening.  Naturally at normal aggressiveness levels the system
will decide for you what an appropriate 'opening' is, which is particularly
handy for laggy connections or slow typists, but if you're fighting an
opponent with a special weakness you know about or you just want to do
it yourself, you certainly can.

Most of the actions you can take also have time associated with them.
You never just:

> pick lock
You pick the lock.

It's more like:

> pick lock
You start picking the lock.  [pause]
You slip a lockpick into the lock.  [pause]
You probe gently, looking for the guard-latch.

etc.  Just about anything you can do works this way - you initiate an action,
which begins to execute.  Naturally the [pause]s above are only like half a
second, but the amount of time it takes you to pick a lock may be anywhere from
five seconds to ten RL minutes depending upon your lockpicking skill, your
tools, the complexity of the lock, any distractions which might occur.

Thus the flow of combat or any other action usually looks like:

> start action
Text
Text
Text
> interject command
Modfied Text
Text
> interject command


I believe Nathan uses something pretty similar as far as the flow, although
I'm not sure about his individual actions.

> >> > Different does not entail a difficult to use command set.
> >> 
> >> Complex does.
> >
> >Not sure where this is going - is 'difficulty' considered a bad thing?
> 
> A difficult command set is Bad. A difficult game is Good, provided the
> difficulty varies to fit different players...

What I mean is:
Most folks consider vi to be difficult to use.  I find it one of the
best interfaces I've ever used, even though it took me a while to learn
all the nuances.  I find using a normal text editor an excercise in
frustration, even with all the bells and whistles they put on 'em nowadays.
Is vi Bad or Good?  Is pico Bad or Good?

> >There's a difference between difficulty and simple obscurity, of course.
> >Difficulty is learning all the different nooks and cranies of the
> >system, and how they interact.  Obscurity is not being able to either find
> >out how something works (via experimentation and documentation) in the
> >first place.
> 
> Obscurity should be punished in truly heinous fashions. Difficulty is a
> good thing provided it's difficult to MASTER, not to learn. 

As a side note, we also have a flag NEWBIE for accounts.  This causes
extra output on errors, like so:

> put sword in bag
It won't fit.

With the newbie flag on:

> put sword in bag
It won't fit.
Newbie note: objects fit into other objects based on the physical space
they occupy.  For more information, see 'help put' and 'help containers'.

> Standard human resistance to change, which of course is something I hit
> a lot. I've been impressed by some recent game efforts, such as Dungeon
> Keeper which still amuses the hell out of me. I've been looking at some

Heck yeah.  Just like all the Bullfrog games - Populous and Magic Carpet
being my other two favorites.  Most people couldn't quite deal with them,
since they were so different from anything else out there.  As a result they
appeal only to a small niche of gamers.

> of the newer games and thinking about how GUIs could be used to enhance
> the MUD experience; I've been thinking about some things that can make
> the building process a lot simpler for the admin staff, but I really
> don't see a GUI being of much use for the players. Administration can
> certainly be enhanced a great deal by GUI tools.

I'm still waiting for a GUI that will actually make me *more* productive.
At best they are just mildly amsuing (XWindows).  At worst they actually
waste huge amounts of my time with configuration headaches and slow,
under-powered interfaces (MSWindoze, which I am forced to use at work).

> >On Day 2, they can still do both these things, but they can also chop it
> >into little bits with a knife, roll it up, and smoke it.  Does the user
> >need to know this?  Do they care?  Does this impair their ability to pick
> >up, or drop the rope?
> 
> As you add commands to existing structures, the probability of creating
> a command which is incompatible with another grows. This sort of
> incremental and additive modification makes the game unreliable and
> annoying. 

Well again, you want to add functionlity without adding new commands.
On the other hand, having a single command do too much can actually
cause problems.
Something that just now came to me - how about a 'verbs' command that
can be used on objects?

> verbs rope
You can: get, drop, cut, tie, or pull the rope.

This would be easier on a verb binding mud.  I would probably have to
just look up the object type and print out a custom listing in order
to implement it on mine.

> >> An example is by nature nonspecific and incomplete. You can draw all the 
> >> examples you want. I stopped at one or two because the message was already 
> >> too long.
> >
> >Personally I find examples to be much more illustrative, rather than vague
> >statements about how things should or shouldn't be.  
> 
> I don't feel that an example particularly invites other examples for no
> good reason other than to force a reevaluation of the question. I
> offered an example which dealt with levels. I was answered with
> questions about what if there were no levels, or no classes, or no real
> concept of power, or different types of power. Well, fine, then there's
> a different scale; no matter how you measure it, the question still
> remains to be answered.

Well, part of the trick is drawing a relavent example.  How this is defined
is subjetive, of course.  I find that thinking about levels, experience, and
classes is a pretty worthwhile line of thought since you get rid of quite a
few game constructs (most of which suck, IMO) once you ditch them.  Thus,
my only answer to a question about exp balance is, "Get rid of experience,
and that problem goes away."

> >See my 'example'
> >about languages above.  I could have responded, "You're wrong!  Languages
> >can add quite a bit if done right!"  However, I doubt this would have
> >convinced anyone, except people that already agreed with me.
> 
> It was a good example. But I still don't think that languages can't be
> replaced by something else; I mean, a language is -- in every situation
> you mention above -- just another skill that you have to have at a
> certain level to accomplish a specific task. Languages in all those
> situations could have been replaced by other skills, and the puzzle
> would have remained the same. Even the silent room could have been dealt
> with using a 'writing' skill. 

Yes.  I consider writing to be in the realm of languages - perhaps
'communication' is a better term.  As I said, I see pretty much all skills
and game mechanics to be interchangable in this way.  You pick the ones that
you think are interesting.  I'm interested in varied mechanics - certainly
sign language is more interesting to me than a writing skill for that
situation (plus writing wouldn't work so well under water).  This doesn't
make writing less valid, I just don't like it as well.

> As far as picking up NPCs, I would expect that trying to pick up an NPC
> would result in the NPC taking some sort of action (presumably hostile),
> whereas the player might not do anything at all (particularly if he's
> idle). 

Certainly not the case for us.  As I've mention above, your character
doesn't just stand around and let people do whatever they want to him.
Plus, PCs and NPCs are indistinguishable as far as the system is concerned.
It's actually difficult to find out which is what from within the code for
normal game commands.  All input and output for a character just goes to
their 'brain', which may be a script or a descriptor.  As of yet there's
no member function on brains which allow you to query which one they are,
and I don't plan to add one.

> Theoretically, in the real world, you would be able to pick up the
> player provided you could carry him and all the weight he was carrying. 
> Realistically, I certainly hope you don't walk down the street picking
> people up.

One of the details we talked about when coming up with the mud was that
we really wanted people to be able to pick up anything they liked.
It's typical that when a group of small creatures attacks a large creature
with opposable thumbs that the large creature will grab one of the small
ones and throw him at his buddies.  I find this tons of fun both to do
and to watch.

> >From the administrative angle, if I logged onto a MUD, and some dork
> picked me up and took me off someplace and dropped me, I would be pretty
> pissed. Especially if he was able to put me into a room without going in
> himself, in which case he could toss me into a trap or into a vicious
> gang of dragons. Considering these possibilities, I would be very
> hesitant to allow people to pick up other players, and very wary of
> anyone who disliked this restriction. This comes under the heading of
> bad things happening to my character without any kind of consent.

*shrug*...we have a completely 'realistic' world as far as being able to
do anything you want to any other player.  This can result in another player
sticking his axe into your skull without your consent, and yes, I can
see how this would disturb you.  But we like it.

> Another concern: High-level character picks up low level character,
> turns invisible, and takes him to an area he can't normally get to.
> High-level character drops low-level character. Low-level character gets
> in fight. When low-level character is badly hurt, high-level character
> grabs him and runs off to heal low-level character. Repeat ad nauseam.

I don't understand.  First off I'll admit we don't have any concept of high and
low level characters, invisibility in the way you mention, or areas which are
designed for a certain 'level' of character.  But all that aside, what is
gained by the above?  At best nothing; at worst the high character doesn't
manage to heal the other in time and she is permantently injured or possibly
killed.

> I might provide special circumstances, like the ability to pick up a
> player *provided* he was unconscious or dead. But this still has
> potential for abuse. 

As you said yourself: being able to interact with anything in any way whatsoever
has potential for 'abuse'.  I don't worry about such things.

> And this is just the sort of game balance idea that looks simple and
> easy until you stop to think about how it could be used. ;)

You'll have to enlighten me further.  I still don't see any problems.
Carrying another person is cumbersome and unwieldy, and makes it very difficult
to do anything whatever.  Certainly if both characters are in good health
they will be much better off in terms of movement (walking/running), combat,
or anything else they want to do if both move under their own power.




More information about the mud-dev-archive mailing list