FW: [MUD-Dev] Interesting EQ rant (very long quote)

[John Buehler]

Jeff Freeman writes:

>> In truth, I'm not even thinking along the lines of quests.  I
>> presented the example of spells being embodied in 'secret' form.

> It's not a "secret" if 100,000 people know about it.

> Pretending a secret is not a secret doesn't make it a secret.  It
> just makes you delusional.

Okay, why do 100,000 people know the secret?  It has all the
properties of a secret.  If my character knows it and wants to tell it
to 100,000 people, then it's a secret shared by 100,000 people.

>> The password example could be to gain entry into a hunting area, or
>> to gain access to a black market area, whatever.

> That's where I'd say the password example, for a multiplayer game,
> is a Bad Idea.  Works fine for single player.  Bad for multiplayer.
> Whether it's in a quest or in something else.

> You can achieve the same result by using some other mechanic -
> something that makes sense for multiplayer games, say.

It would be of significant help to me if you were to provide an
example of a multiplayer mechanism that you believe would work.

>> Note also that I'm not drawing a distinction between characters and
>> players.  I'm bringing up the fact that it exists and that it is
>> important to understand the distinction.

> There is no such distinction.

Such as the fact that the character can cast magic and you cannot.
The character dies regularly, while you do not.  The character doesn't
move without your directions, while you move without its directions.
The character's perceptions are different from yours.  The character
can be deleted, while you cannot.

>> As a designer, if you don't remember that the two are different,
>> you'll be changing your view of game design.

> I changed it when I stopped playing PnP RPGs and started playing
> online games.

> You say that like it's a bad thing.

> Maybe it would be a bad thing if I was making a PnP RPG.  But I'm
> not.

It's always a bad thing when something that is true is treated as if
it is not.  This is the sort of thing that we'll look back over 10
years and say "Yeah, and there was a growing attitude that there was
no difference between players and their characters.  So we missed
seeing these subtle effects."  It's like the belief that players
behave in a game environment the same way that they do in the real
world.

>> As a designer, you can't afford to think like a player.

> Oh please.  What kind of Ivory Tower mindset it that?  The players
> *are* game designers.

Yes, and I'm also a user of commercial applications.  Do you know what
pure users of commercial applications think they want from those
applications?  It would produce a nightmare so fast it would make
anyone's head spin.  The designer of an application sees the big
picture and looks at the underlying principles that hold concept sets
together, etc.  I'm not being ivory tower.  I'm being practical, in a
sense borne from a long career developing commercial applications.

>> Having that mindset available to you is essential - but it should
>> not be your full-time view of game design.

> It is the end-all, be-all view of game design.

No, it's not.  The end-all, be-all view of game design is to entertain
players.  It is not the same as being a player.  As I say, it is
important to be able to see the player's view.  But it is not the
ultimate way to be a designer of anything.

> "Does this game suck?" is the only important question, at the end of
> the day.  It's one that players ask and answer.  Game designers
> don't seem to ask that question.  Or don't seem to be able to answer
> it correctly.

I agree that the net result of a player examining a game is pretty
simple.  I doubt that game designers skip over that question.  In
truth, I think that game designers DO ask that question.  And that's
the crux of my point: game designers act like players.  They ask the
question "Do *I* think that this game sucks?".  They want to play
their game, not build it for others to play.

JB

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