[MUD-Dev] User centered?

Richard Woolcock KaVir at dial.pipex.com
Fri Apr 9 19:56:00 CEST 1999


Ola Fosheim Grøstad wrote:
> 
> Are mud designers adding features, for the sake of adding features, or is
> the aim to optimize for the user's experience?

In my case, a little of both.  I enjoy adding features, but try not to do so
at the expense of the user whenever possible.

> For instance, in a recent thread there was a discussion about implementing
> in-game languages by translating the messages into something which couldn't
> be interpreted by players without the language skill.  When focusing on the
> MUD as a coherent fantasy world this sounds nifty. But wait!  The receiver
> won't know what the sender said, so what he receives does not matter at all.
> Presenting some random strings would have the same effect for less
> implementation cost, and indeed why present anything at all?

Most mud programmers create their muds for fun.  If feature X is fun to code
and has no impact upon the user, I see no problem with it at all.  If feature
X were to cause problems for the user then I might choose not to implement it,
depending on what it was.

> My next question is... Do players use these features? Or do they in fact use
> private tells (paging) if it is available?  How many MUDs have for instance
> implemented a mostly unused yell or whisper command? For languages which are
> race based... Do players care about race when they choose their friends?
> Meaning, do they have any need to selectively communicate with a race?

Well I don't have races, so I can't really comment about my mud.  When I play
muds that use languages, I generally find it to be a chore.  It doesn't really
bother me, but I don't feel it improves the gameplay in any way (although I
suspect it would do in a strong roleplay mud).

> It is my opinion that the interface should be kept small and effective. I
> think designers easily make the mistake of thinking "feature richness will
> buy me a rich world". However, understanding the individual user's
> experience and perception is the key to making a rich world. Experience
> isn't about what is present, but what the user expects and what he perceive.

You have to be careful there.  Probably most of the mudding population play
Diku-derived muds - does that mean future muds should try and stick to the
same style of interface?  My mud still uses a lot of diku-style parsing for
example, but I've had to make a few changes because of my parsing system.
The old "get 2.sword" will work just as well as "get the second sword", but
if you want to get the sword out of a backpack you have to type "get sword
from backpack" ("get sword backpack" would attempt to pick up a sword and a
backpack).  A very minor alteration to the user interface, but you'd be
surprised how many people get stuck trying to get equipment out of their
containers.  Equally, most people are familiar with Midgaard, but I certainly
wouldn't suggest that it's inclusion be manditory for a well-designed mud.

[snip]

> Add to this that changes are less welcome than additions.

Ah, you've really hit the nail on the head there, although I think you've
understated it a little.  I'd go as far as to say that - as a general rule
- players hate changes and love additions.

> So, what if designers "roleplay" their design before they implement it?
> Probably difficult.  Does anyone have any ideas about how to test out the
> soundness of ideas before implementation? Mockups might do it, but you still
> face the trouble of seeing your design as the unsuspecting user would see
> it.

It really depends on the feature, I suppose.  If you want to add feature X
the best thing to do is go and have a look at some other muds which have
already added it - if possible, have a chat to the coder about it as well.

If the feature is (at least to your knowledge) original, the only way to
really find out what it's like is to stick it in the mud.  If you've got 
a test site up you could always ask other staff members to give their
opinions, but the only true test is to go live with it.  If it doesn't
work, it can always be removed.

KaVir.


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




More information about the mud-dev-archive mailing list