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

John Buehler johnbue at msn.com
Tue Mar 13 07:33:45 CET 2001


Jeff Freeman writes:

>>> My version of what's wrong with your approach: Having players know
>>> passwords is disruptive.  It damages the suspension of disbelief
>>> because the characters are exchanging the passwords, but the
>>> *players* know the passwords.  Players interact with each other in
>>> the real world (or just by using 'tell') and can communicate
>>> passwords in ways that are unbelievable to the game context.

>> Erm, no, the characters know the password too. How could the
>> character possibly use the password if he didn't know it?

> I see this as much more a problem with having single-player-game
> quests in a multiplayer-game than a problem with tracking
> player-knowledge vs.  character-knowledge.  Like matt, I don't like
> drawing this artificial distinction between characters and players
> (and certainly not in a massive, where it's guaranteed that 90% of
> the players will make no such distinction either).

I disagree with the assertion that it has to do with quests that are
in the single player style.  I consider such quests to be a bad idea,
as you do, but the notion of modeling character knowledge is
unrelated.  In truth, I'm not even thinking along the lines of quests.
I presented the example of spells being embodied in 'secret' form.
The password example could be to gain entry into a hunting area, or to
gain access to a black market area, whatever.

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.  As a designer, if you don't
remember that the two are different, you'll be changing your view of
game design.  As a designer, you can't afford to think like a player.
Having that mindset available to you is essential - but it should not
be your full-time view of game design.

JB

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



More information about the mud-dev-archive mailing list