[MUD-Dev] Usability and interface

[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.  Now, particular systems may be more or
less interesting to some folks - I doubt everyone thought that learning how
to bake bread in Ultima 7 was terribly exciting.  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.  But given the ingenuity and curiosity of the types of people
that play these games, I feel that it's better to overshoot a bit on complexity
and have it take a little longer to figure out, as opposed to them getting
bored with it quicker.
I hardly think elements of 'What if?' make a terribly bad game.  Whether or
not you personally enjoy stirring hemlock is only an aesthetic choice.

> > What's a class?  I thought many on this list advocated abandoning
> > this concept in favor of skills.  Not that there's anything wrong
> > with classes.
> 
> I for one find classes a convenient way to represent a starting group of 
> skills. If you want to spend an extra half hour in character creation, you 
> could always modify a class slightly, or if you're completely insane you 
> could go in and design frmo scratch.

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 like
me can fiddle around with numbers all day long.

> P&P is not the same as online. For one thing, it is close to impossible to 
> provide appropriate body language, facial expression, and accents online. 
> On the other hand, online, you never need to roll huge handfuls of dice and 
> lug forty books around in a backpack. Languages in P&P can add a lot to the 
> game; languages online add absolutely nothing.

Careful with those unconditional statements, now.  The first mud I played
had languages, and it was one of the things that drew me in right away.
First of all, I never found languages in P&P terribly interesting.  The
DM tells you, 'He's jabbering in a language you don't understand'.
Mildly interesting, but nothing to get excited about.  My first time on a
mud I saw two high elves chatting in market square.  For some reason, actually
seeing text which I didn't understand but which I knew translated to a real
dialog was extremely intruiging to me.  I actually went out of my way to
make my character a language master of sorts, travelling the lands in search
of teachers of strange languages.  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>.  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); and my personal favorite - a quest designed by
my future coding partner Orion in which there was a maze of rooms with
illusionary walls, hidden/backstabing NPCs, and all the rooms had a forced
magical silence.  Not only could no one cast spells, but no communication was
possible.  The ~12 person group disintegrated into chaos for approxiamately
five to ten minutes as they were scattered every which way and unable to
communicate.  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...

So I have no trouble conceiving of ways that language can add to a mud.

> do them. What people here actually *do* tend to do a lot of is point at 
> game mechanics and server details as though they are discussing a game. 
> These are not the game, any more than the player's handbook is AD&D. You do 
> not NEED them. They are there strictly in a supporting role.

First things first.  D&D without the handbooks would have been silly.
By the same token, usually what I see on this list is discussion of how
specific game mechanics support certain goals.  I could prattle on all
day about our philosophies and ideas for what the game should be, but
concrete examples are a lot more useful, both for the example itself
and for the purposes of illustrating the 'higher' purpose.

> > What seems to be lost in this is you have described a game with a
> > SINGLE overriding goal.  The traditional HnS goal of killing to
> > advance, advancing to max level, getting the best equipment.
> 
> This is quite patently not true. What I have described is the simple fact 
> that when you make a game overly complex, you can not realistically manage 
> it and game balance goes straight to hell. It is not difficult to balance a 
> penny on a pencil eraser. It is rather difficult to balance a dinner plate 
> there, and balancing a stack of twelve dinner plates on it is a fool's 
> errand.

Game balance on all early games usually is terrible.  You work it out.
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.

> I am not discussing any specific game or any specific goals.

Which is probably why you are so often misunderstood.  When JCL or Nathan
or Jon or Chris G talk about some specific topic, I know pretty much
right where they are coming from, because I know both details about their
own game(s), as well as their gaming philosophies.  I'm still confused as
to where you're coming from exactly, despite having read many of your posts.
Perhaps you're trying to avoid being pigeon-holed, but...

> > Different does not make it hard to learn.
> 
> Bad documentation does.

Welcome to NewMUD.
> help
Yeah, you're gonna need it.
> quit

> > Different does not require programming in any shape or form.
> 
> Atomic low-level commands encourage it, providing significant advantages to 
> those who do.

Yes, this is true.  Some folks are trying to design a game this way
on purpose, and make no bones about this fact.  I am not trying to do this,
at all.  Certainly this is something that needs to be decided early on
on the development process.  Does the user interact with simple building
blocks which are, over time, built into more complex commands, hand
crafted by each user?  Do they create them beforehand?  Do they need to
be quick with commands, or is it more like a chess game?  Can they set
automatic responses for their character(s)?

We wanted a game that felt very real-time without necessarily requiring
lightning-fast reflexes or even fast typing.  We wanted a system which
did a lot of things automatically for the user in certain situations, but
we wanted to be sure that the user could turn those automatic reflexes off
with options.  We wanted commands to be sort of like interjections into
a story - the user watches things unfolds, and modifies their character's
behavior as they see fit by interjecting simple commands.  Most everything
can be appreviated with three letters or less, and if you leave out
certain 'parameters', the system assumes things for you.  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.

> > Different does not entail a difficult to use command set.
> 
> Complex does.

Not sure where this is going - is 'difficulty' considered a bad thing?
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.

> > Different DOES entail turning off hundreds of Diku-expectant players.

Mmmm, more pigeon-holing.  People don't like different things, usually.
I do.  But the only way to advance the field is to introduce something
new.  'Something new' is usually defined as different.
This doesn't mean you have to go out of your way to make it more difficult
to adapt to.  We have certain bits of the help files aimed specifically
at folks with experience with some of the standard mudbases, simply to
help them make the transition a little easier.  On the other hand, I still
believe that people who have never played a mud before will have an easier time
than those who have, because they don't have all those old mud-expectations
running around in their heads.

> > For me, yes. I still don't see how a richly detailed world relates to
> > a more complicated user command set or harder to play.
> 
> Are you even thinking about it? I mean, if a rope is just an item, well 
> hey: get rope, drop rope, no problem. But what if it's a tool? Throw rope. 
> Tie rope to <x>. Pull rope. How about adding fabrication into it? A rope 
> can be used to make a net, a snare, a tripwire, even a cat o' nine tails. 
> Do you expect functionality to just *happen*? How does the user use this 
> functionality?
> 
> Complexity and difficulty of learning is inherent.

*shrug*
Let's say that, on Day 1, there exists a rope.  The user can pick it up
and drop it, nothing else.
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?

I for one would rather have a system where I'm always discovering new things,
rather than one I can learn every aspect of in my first visit there.

> > How about...
> 
> 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.  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.

> > I hate artificial restrictions and inconsistencies like
> > 'You cannot pick up another player'.
> 
> Artificial worlds will impose artificial restrictions.

Yes, but the above statement implies that you *can* pick up NPCs, just not
players.  I find this to be massively inconsitent and unnecessarily 
restrictive.

> > The success of Macintosh,
> > Windows, and WWW interfaces are not solely predicated upon user
> > stupidity.
> 
> I have a vast number of things to add to this, but they are almost all 
> off-topic. Suffice to say that in many places graphic interfaces are not 
> actually appropriate, and MUDs are one of those places. Graphic interfaces 
> are inherently limiting in expression, which I think we all agree is Bad on 
> MUDs.

Although I agree with you 100% on this matter, perhaps I should qualify that
statement for you.
A mud which is based around the same premises as a good PnP game or, better
yet, a good book, relies on the kind of expression one can only get from
language (or, at least without complete VR, and I'm not sure even then).
A mud like Tron or Ground Zero would probably do *better* with a graphical
interface and a joystick with ten or so buttons for control.  Then again,
that's why I don't really consider those 'muds'.
Incedentally, I think that you could easily have a visual MOO.  The creation
process would naturally be quite a bit different, but the basics of the game
itself could be quite similar.

> > I see no need for player
> > documentation to be printable or downloadable.
> 
> If I can't download the documentation and look at it while I'm not on your 
> game, it's harder for me to learn my way around. If I can't print it, it's 
> harder for me to find information on commands. Hardcopy and local copies 
> are important. But as the game's designer, or as one of its primary 
> founding players, you won't understand it... it's easy, see, not that much 
> at all.

These are just convenience.  I try to never limit user convenience unless
it's going to gain something extremely specific in terms of the game.  If
something is accessable to any player that logs on, you might as well
make it more or less publicly availible.

> > I like consistent themes.  I wouldn't find it amusing to run into
> > Elvis in Babylon.
> 
> I would find it vastly amusing, provided he wasn't presented as 'Elvis' but 
> as 'An aging and overweight man with long sideburns, wearing a bright white 
> gem-studded suit and dark glasses. He jerks his head and gyrates his hips 
> at odd times, and seems to have some form of nervous disorder.' Dropping 
> Elvis into Babylon is stupid. Dropping someone that *looks* like Elvis into 
> Babylon is funny.

All depends on the mud's theme.  I dislike objects like sunglasses and
polyester suits in fantasy muds; on a futuristic mud I'd like this much better.
I like humor, but I'm not willing to sacrifice the theme in order to get
a chuckle, since there's plenty you can within your theme.