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