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

[John Buehler]

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

First, I have a significant aversion to using 'magic' to solve
problems.  So I'll skip over that reference.

The use of a physical item is fine.  That's an approach that has an
equivalent in the real world and works great.  It has the
characteristic, however, of a key, not a password.  If I want to have
a password in the game world, I suggest to you that it should work as
I've described in previous posts.  If I want to have a
key/amulet/token in the game world, that's what I'd use.  The
resulting behaviors are different.

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

My only point was that the player and the character are not
interchangeable.  This is an obvious statement, but to read people's
posts, you'd never think that they believed it.  Depending on the
software, the balance point between what the player contributes and
what the character contributes to the game experience will vary.

I was simply offering a reminder that we shouldn't get too wrapped up
in the hybrid persona idea when it's important as game designers to
remember where the line is drawn between character and player.

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

I agree that a natural ebb and flow should exist between character and
player.  The greater the artificial distinction between character and
player, the less the sense of immersion or of ownership.  Or of
'oneness'.  Personally, it is a technique that I hope to use to keep
my players thinking casually.

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

Okay, we just disagree then.  Given what I see from players out there
on message boards, I'm quite convinced that game players are even
worse than users of commercial applications.

>> 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 hope to learn from your experiences.  If I'm wrong, I'm wrong.

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

What is down time?  It is the obligatory break in the intense
experience that a player is getting from a game, right?  Suppose the
experience isn't as intense?  Suppose the entertainment is far more
mellow, and the things that you call down time are, in fact, the meat
and potatoes of what my players want to be doing.

One of the really terrible things that go into intense games is the
juxtaposition of intense activities and boring activities.  I'm gonna
cheat and only provide the boring activities :) As insane as that
might sound, it's not really nuts.  It just says that the emotional
investment required of players is vastly reduced.  The very *reason*
that someone picks up my game is wildly different from why they pick
up your game.

By the way, I always enjoyed down time because I enjoyed the
socializing during the down time.  Beating on EverQuest some more, the
fight there seemed silly to me once I got used to how it worked.  It
forced me to stay away from too much conversation because I had to
keep being 'optimal' about attacking, kicking and spell casting.
EverQuest was enjoyable when I was with players who didn't take the
advancement stuff too seriously.  It was most boring when I was with
people who either couldn't or wouldn't converse and were only
interested in getting levels.

Player: "Powergaming sucks."

Powergaming is a byproduct of big chunks o' cheese.

JB

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