[MUD-Dev] RE: Knowledge Modeling -- WAS: -- Interesting EQ rant (very long quote)

[John Buehler]

Zak Jarvis writes:
>> From: John Buehler [johnbue at msn.com]

>> Um, the password stuff isn't really related to addressing casual
>> gamers.  But I agree with the simplification process.  It's true of
>> any piece of software with a user interface.  If you want to put it
>> in front of novice users, you have to use a variety of techniques,
>> including a well-integrated help system and progressive disclosure
>> of application features (which must be clearly presented).

> Well, it's semi-true. There are plenty of graphics people who
> utterly loathe Bryce. I happen to love the app, and still use it for
> any of the things it's strong. Of course, this doesn't actually
> invalidate what you said, as the people I'm talking about tend to
> specifically be *not* novices.

Yup.  Novices need to be lead.  Experts have formed the mental model
of how they want to operate the controls.  Generally, the mouse is for
novices and the keyboard is for experts.  [Disclaimer: I said
*generally*]

> All that aside (and this is getting ahead of myself in the reply,
> but I'm going to be trimming some for brevity and clarity), who
> exactly IS the password knowledge modeling system for then? It
> strikes me (along with introduction systems) as a very solid barrier
> to entry for casual gamers.

No more than having doors on buildings is a barrier.  Players have to
figure out how to get them to open, just like they have to figure out
how to talk about secrets in the game.

Realize that I cannot possibly imagine the password mechanism being an
isolated mechanism.  It cannot be the only gain from an entire user
interface mechanism.  Other game elements must comingle or merge with
the password stuff.  The notion of managing character knowledge will
be part and parcel of game activity.

To answer your question, the password stuff is for everyone who is
interested in having in-game scenarios that involve the passing of
information between characters.  Characters can teach each other
skills, describe other characters, give directions and so on.
Information becomes one of the 'things' that you can collect.  A bit
like playing cards, except that your character can actually do stuff
with them (and you can't).  It alters the entertainment that a player
enjoys.

>> Eliminating classes and letting players move their characters
>> around the skills map permits lots of unique combinations of
>> characters to interact.  As groups of character encounter a
>> challenge, they fish about for ways to deal with it.

> Actually, I think for attracting casual gamers, the better bet is a
> better defined system of rigid classes and removing skills and
> levels, but that's a whole 'nother discussion.

Well, for fear of taking this exchange one step farther out, my
opinion on classes is that they are a Bad Thing.  An irrevocable
decision is a Bad Thing.  Thus my post asking folks' opinions on the
use of races.  Selection of races is an irrevocable decision unless
you use the 'whamo' machine.

Anyway, the element of classes that should be retained is the notion
of organizations that provide tutelage and goals.  A class *forces* a
player to follow a line of behavior and a certain path of
entertainment.  I don't see the need to literally force a player to do
much of anything.  I far prefer the idea that I am offering some
career opportunities, and the player will be told what is expected of
them.  More adventuresome players can try to just make up some
entertainment.  If they get stuck, they can look to an organization to
see if that would work any better.  And vice-versa.  Starting out in a
warrior organization, then switching to a different organization that
is interested in warrior skills, but they also throw in some stealth.
Or an organization that uses engineering skills in war.  Or a whole
cadre of organizations unrelated to warfare.

>>> What is accomplished by having password knowledge be modeled?

>> Not much, given that somebody wants to 'game' the game.  But at
>> least the password can only be obtained by traveling to that town
>> square.  You're also using hardcore techniques for slight gain.
>> Remember that

> First, it's a mistake to assume that just because there is slight or
> no gain that players won't do it. Often players will do something
> precisely because they feel you don't want them to do it. (Zak
> raises his own hand at this point and pleads guilty).

> Sure you can decentralize and break up the world so that it still
> takes some effort to reach the password disseminator, but that
> presumes that there won't be a guild which sets up bots in the town
> square of all your cities to hand out all the passwords to anyone as
> a recruitment technique.

As I was saying in a post in another forum, what is the value of being
transported by helicopter to the other side of the rain forest when
all the entertainment was IN the rain forest?  Newbies will have the
password and that will let them get into the second part of the maze.
But they've missed out on the first part.  Why reduce the amount of
entertainment that you have access to?

My goal is to reduce the cheeseheads out there by enhancing the mazes
and limiting the cheese.  If that doesn't work, I'll try something
else.  When I get fed up, somebody else will try other permutations.
It will continue until somebody finds the right recipe to permit a
game that doesn't need to get 'gamed' by the players.

>>> Porkmelon. Theodore can't make it to the club that night, and
>>> William goes, the password is accepted and all is well. The next
>>> night they both go, this time William is stopped: Porkmelon is
>>> already here. Go away.

>> Is that good?  Is that intuitive to the players?  I'm only dumping
>> an game interface mechanism that isn't intuitive, but which can be
>> learned.  The net result is entirely believable.  If I introduce a
>> game internal mechanism that isn't intuitive, then I have to deal
>> with the repurcussions of its funky behavior.  For example, we
>> start to

> From my experience, unintuitive game interface is vastly more
> limiting to players than game internal mechanisms. As others have
> pointed out, it is *not* entirely believable that as a player I must
> know the command to share passwords and cannot simply tell or be
> told. The basic problem is that neither method is entirely
> believable and I posit that choosing to put the burden of a
> non-intuitive mechanism on the interface instead of the world limits
> exactly what I think I've heard you saying that you desired; casual
> gamers and an easy-going attitude.

I will agree that it doesn't matter how good your application is if
nobody can figure out how to use it.  I'm not assuming that I'll
present any significant barriers to access in my choice of interface
mechanisms.  We'll just have to wait and see if I can pull it off - if
I ever get that far.

JB

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