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

Freeman Freeman
Thu Mar 15 07:37:02 CET 2001


> From: John Buehler [mailto:johnbue at msn.com]

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

Essentially the "secret" is just a key.  Say you want people to have
to talk to NPC X before they are able to enter area Y.  If you make
NPC X tell the players a password, then they are able to bypass that
part of the quest - and go get the secret word from a website or
player.  Presumably this is bad, because then they won't know the
story behind the quest: Why NPC X controls access to area Y, what NPC
X wants before he'll give you access to area Y, etc.

Fantasy example: NPC X will give you a special amulet, not a password.
You can pass the area with that amulet.  You can even give the amulet
to another player.  But you can't put the amulet on a website (well,
other than eBay).  You can't give it to 100k other people.  If you
REALLY don't want the players to be able to grant other players access
to the area, you could have the npc "cast a spell on you" that will
allow you to enter area Y.

Functionally, that works the same as a "secret word" - but doesn't
require you to pretend that you don't know something which you do
know, etc.

> Jeff Freeman writes:
>> 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.

If you're just saying that a character is a collection of stats and
skills, then ok - I'm not my character.  But then you can't say that
my character *has* any "perceptions".  A collection of skills and
stats doesn't "perceive" anything.

If we're talking about the *persona*, that's me.

> Jeff Freeman writes:

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

I don't think it's like that at all, and I think a lot of the problems
faced un multi's is the result of designers trying to make that
artificial distinction between player and character (or rather,
between the player's persona and the character's persona).

> Jeff Freeman writes:

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

When it comes to games, yes.  I have no idea what auto-cad users think
they want from auto-cad.

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

Whatever works for you.  I think I'll stick with my current thinking,
inexperienced and naive as I am, and see if I can make another fun
game or two by looking at the game from the p.o.v. of the player.

I just get the impression that your approach would lead to things
like, for example, a huge amount of boring downtime alleviated with,
perhaps, an in-game Tetris minigame - whereas my approach would be to
chuck-out the downtime (since it is boring and un-fun), and then
address whatever repercussions not-having downtime causes elsewhere.

Game designer: "Down-time is good for the Big Picture".

Player: "Down-time sucks."

I think the player is *right*.  Not that I would ignore the big
picture, but that if we need huge amounts of downtime in order to
prevent problems with X, Y or Z, then my approach would be to
chuck-out the downtime, since it sucks, and then go *fix* X, Y and Z.

Even if it would be more effecient and effective to just throw in a
ton of downtime.  As a game designer, it's "the right way to do it",
but as a player, it's just bad.
_______________________________________________
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