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

[John Buehler]

Zak Jarvis writes:

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

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).

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

In some respects.  Neither game lets a newbie do very much.  The
number of casual activities available are fairly minor.  Both games
rely on killing stuff in order to get involved in any activity.  Both
games permit significant power accrual, producing social
stratification and a need to catch up to buddies.

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

I never played Asheron's Call with other people because I wanted to do
some casual gaming after a year of hardcore EverQuest (blech).  While
it can be done, it gets kinda boring without the social interaction.
Given that the group things to do in Asheron's Call are all about
killing stuff and accumulating power, I didn't want to get back into
that element of gaming and gave up on Asheron's Call.

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

You're assuming essentially zero investment in time to go get my own.
Suppose the NPC who knows the password is part of a moving caravan?
Or is in a town on the other side of the world and I got the password
last month?

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

For what it's worth, what I'm hearing here is very much the way I'd
like to go as well.  As I've said before, it is permutations of
scenarios that truly provide new content and entertainment.
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.

>> 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?

Not much, given that somebody wants to 'game' the game.  But at least
the password can only be obtained by travelling to that town square.
You're also using hardcore techniques for slight gain.  Remember that
obtaining that password isn't that big a deal.  It unlocks some new
entertainment, so it's at least that valuable.  But there may be
companion elements to the password.  For example, if we implement
faction, then being able to get past the guard who accepts the
password might be accomplished, but once inside the area nobody will
talk to you.

Game systems can always be gamed.  The question is whether gamers
attracted to my world would bother.  Because I haven't implemented it
yet, I'll claim that they generally won't spend much time with it.

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

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
figure out how many passwords we all need to know for the Pointy Hat
Club given that a certain number of players go there nightly.  If the
guy at the door is remembering all these names, why isn't he objecting
to people using each other's passwords?  If he doesn't mind that, why
won't he let us all in if we have any of the passwords?  It's an
artificial in-world mechanism, while mine is an artificial
out-of-world mechanism.

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

As I say, the result in gameplay is entirely intuitive.  It works like
the spoken word, but the game interface to it is klunky.  I'd far
rather have that than a mechanism that produces unintuitive results to
gameplay but is intuitive to use.

JB

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