FW: [MUD-Dev] Interesting EQ rant (very long quote)
Freeman
Freeman
Mon Mar 12 07:19:39 CET 2001
> From: the_logos at www.achaea.com [mailto:the_logos at www.achaea.com]
> On Thu, 8 Mar 2001, John Buehler wrote:
>> 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?
Actually, in the example given, the assumption is that no one else has
ever done the quest before, even if lots of other people have done it
before. We're pretending that they haven't (otherwise the magical
sword or widget or axe or whatever it was wouldn't still be there, and
whatever NPC you're supposed to deliver it to wouldn't still be
wanting it, since he'd already have 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).
Again, the solution, to me, would seem to be to not have single-player
type quests in a multi-player type game. There's simply no way to
avoid breaking fiction: Whether you're telling the players they can't
talk to each other or not, you've still got this weird
fiction-breaking element: This NPC that wants a foo delivered from
some place, perpetually, no matter how many times other players have
already delivered the thing.
_______________________________________________
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