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

[Zak Jarvis]

> From: John Buehler [johnbue at msn.com]
> Sent: Tuesday, March 13, 2001 12:46 AM

>> I'm really not so keen on the idea of special commands to trade
>> knowledge with other characters, unless all communication were
>> equally abstracted.  It adds a needless layer of complexity to
>> communication.

> I'm not keen on it either.  To be honest, I haven't spent more than
> about 20 seconds trying to solve the problem at the implementation
> level.  The quickie technique of a special command was offered only
> to illustrate the idea.

I don't see any way around some sort of special commands or functions
for trading knowledge. I mean, I can envision interfaces (at least for
graphical games) which would work, but I'm basically unhappy with the
whole idea of turning that sort of knowledge sharing into a game
mechanic simply because it's an unintuitive level of abstraction which
I suspect will turn out to be a barrier to entry.

>From my perspective, you're tackling the wrong end of this hydra. My
personally preferred perspective (a little alliteration anyone?) on
the whole 'casual gamer' thing is that the game mechanics need to be
simplified to the greatest extent possible. I think that's somewhat
born out by comparing Asheron's Call to Everquest.

AC's great weakness is a learning curve like a brick wall. Right off
the bat you're presented with an enormous list of skills which
interrelate in all sorts of ways with a group of stats which you have
complete control over. As a newbie, you pretty much definitely end up
rerolling your first several characters (depending on how
single-minded you are in the types of characters you create). This is
frustrating and makes players feel like they're dumb because they're
not in on 'it'.

EQ on the other hand provides a relatively simple character creation
process. It's complexity unfolds as you play further. It's very newbie
friendly.

The irony here is that in the long term, AC (from my perspective)
provides a far more satisfying player experience for casual gaming.

The reason is very simple. Once I learned AC's rules, it allowed me
some distance and perspective. My friends in the game play more than I
do (it's tough to both play one game and develop another), but I still
can interact with them in meaningful ways through the game mechanics.

In EQ, if I didn't match my friends playing nearly hour for hour, it
wasn't long before I simply couldn't join them in gameplay. As a
bastardized Casual Gamer, AC turned out to be the far better game for
me, but I was only able to discover that by being 'hardcore' enough to
overcome its learning curve. Clearly EQ attracts significantly more
players, and I suspect this is the larger part of it.

>> A far better solution (though more complex from a development
>> standpoint) is not using puzzles or quests that lend themselves to
>> OOC 'spoilers'.  >From the simplest form where each character gets
>> a different password, to the slightly more complex method of each
>> character gets a randomly generated constellation of NPC's for his
>> personal quests, to the significantly more difficult broad, deep
>> random quest generation.  (Emphasis on broad and deep).

> I'd argue against the different password approach because it
> eliminates the possibility of transferring the password to another
> character.

Not if you can tell the other character how to get their own password.

> I'd argue against the constellation technique because of the
> single-player attitude that it fosters.

Agreed. It's a less than optimal approach, but it could have uses.

>> The latter approach is the one I'm personally most interested in. I
>> keep threatening to do a write up about this...

> I'd be very interested in hearing your thoughts.  The task of
> providing puzzles for a large player base is a very challenging
> task.  I assume from the start that they cannot be hand-generated.
> This means that they will run to some kind of a form.  This means
> that the entertainment derived from solving the puzzles cannot be as
> simple as completing the puzzle itself.  There have to be more axes
> to the entertainment surrounding the puzzle.

One of these days I really, truly will have the time to write this up
properly, but the essence of it is generating goals for players that
intersect. Basically, get players to do the heavy lifting of quest
generation. Goals can be simple, achieving them can be as complex or
simple as players would like to make it. Partly it means giving them
good tools to entertain each other, partly it means finding methods of
not forcing people to deal with people when they'd really rather
not. I haven't quite figured out all the details yet.

>> It seems to me that the more elegant solution here is the 'Eyes
>> Wide Shut' solution. The people you would give any such password to
>> know you shouldn't have it because you didn't receive it in the
>> normal way and set the 'I've got the password' bit. So giving the
>> password isn't effective. Sure Bob can tell you that the password
>> is Porkmelon, but you just aren't Bob and they know that.

> As I suggested earlier, I dislike that because it doesn't appear to
> provide a way to share a password, which is a perfectly reasonable
> thing to do.

Well, if it's perfectly reasonable, why not let them do it in the most
intuitive way possible? My main point is that there are lots of ways
of controlling the flow of information.

Here's a scenario for you:

The whole password bit is implemented, and there's a command to give
out the password.

  Theodore learns the password is Porkmelon by polishing the wizard's
  robe.

  Theodore proceeds to town square and then issues the command to
  transfer the password to anyone who enters the area.

  William decides this is cool, he compiles the most comprehensive
  list of passwords in the game and leaves his character online 24
  hours a day with a script running which gives all the passwords to
  anyone in range.

What is accomplished by having password knowledge be modeled?

Sure, you can put restrictions on the number of shares... Then you're
right back to the problem with players using knowledge their character
can't have. You can restrict the number of people who can use the
password, but of course that can be done just as easily without
modeling the character knowledge the way that's been discussed.

Back at the 'Eyes Wide Shut' method; Slithis the wizard, having gotten
his robe nicely polished by Theodore tells Theodore that he can get
into the Pointy Hat Club by using the password Porkmelon. Theodore
then tells William that the password is 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.

>> politics than one who knew the secret password. In fact, there are
>> about a million things that it would be outright impossible to
>> prevent -- short of totally restricting communication -- that I
>> would find far more disruptive than the commodification of
>> supposedly scarce knowledge.

> I really don't worry about the ones that are impossible to prevent
> when it comes to game systems.  I'm facilitating an action in the
> game world that is typically invalidated with characters being able
> to act on player knowledge.  As I've suggested before, once
> characters know information, it becomes possible to start doing
> things with that knowledge - such as morph it slightly when
> transferring it to another character.  I postulate this for
> character descriptions of other characters (an offshoot of an
> introduction system) and for character descriptions of map
> directions.

Basically, I'm questioning whether this is a useful place to spend
development resources. The impact this issue has is small and the
solution makes for a nonintuitive game mechanic.

----------------------------------------------------------------
"You can hear it in the valley Where live the lame and the blind
They climb the hill out of its belly They leave with mean black
boots on."                             -Nick Cave

-Zak Jarvis
 http://www.voidmonster.com

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