[MUD-Dev2] [DESIGN] Rewards
John Buehler
johnbue at msn.com
Tue Apr 24 22:39:51 CEST 2007
Sean Howard writes:
> "John Buehler" <johnbue at msn.com> wrote:
> On the other hand, if you build a LEGO skyscraper, just because you enjoy
> it, you need never finish it to find the experience enjoyable. In fact,
> you could decide halfway through that you didn't want to build a
> skyscraper, you want to build a pirate ship. You aren't rewarded for
> finishing a project. You aren't punished for not finishing a project. You
> aren't rewarded for building it one way over another. The experience
> itself is rewarding, the goals are malleable, and the enjoyment comes from
> the freedom and lack of controlling structure.
Exactly so.
> > So literally, let's pick an activity and dissect it. Combat? Crafting?
> > Stamp collecting? Sneaking around? Deer hunting? Politics? Running a
> > business? Fashion shows?
>
> How about playing a MMOG? :)
The very purpose of my post was to suggest that a finer-grained examination
of the experiences is needed. Current games look at entertainment as
"playing an MMOG", which is why they have certain challenges. Throwing all
the bits and pieces of 15 experiences in a virtual setting and letting
players in produces a self-organizing society, but not one that permits any
depth of experience. Ergo, the intrinsically rewarding experiences are few
and shallow.
Examining a specific experience from the standpoint of the enthusiast will
help us to understand what must be part of the experience so that it is
intrinsically rewarding to those enthusiasts. If something must be part of
the experience, then steps must be taken so that other players will not (or
cannot) damage that something.
> > Any depth of experience requires a carefully sculpted setting. It would
> > be kinda difficult to carry off Deus Ex while a swarm of players is
> > zerging the facility, wiping out the NPC guards.
>
> I agree that SOME depth of experience requires a sculpted setting, but
> who's to say that a swarm of players zerging a facility doesn't have it?
The players, of course. The player I was describing was seeking a sneaking
experience. He didn't get it. If he was seeking a way to get into the base
and was stuck with sneaking, then the zerg showing up was good news. But
the very focus of what I'm talking about is having players get enjoyment out
of the activity that they're involved in. I picked sneaking because it
contrasts with the typical game experience. So the player was enjoying
sneaking. He wasn't just trying to get to the loot in the camp. He wanted
to sneak in. He may just sneak out again without doing anything. In any
case, he cannot do that if a zerg shows up. He cannot do that if many
things happen because of the fragility of the experience.
> Depth is merely something which has one or more of the following:
> A) a variety of viable solutions.
> B) a variety of viable paths to a solution.
> C) a systematic dependency on other systems.
>
> The third one there - the systematic thing - that requires a different
> type of sculpted setting that you are suggesting. One that could easily
> scale with players.
The only time that player population size scales with depth is when the
players are all playing essentially single player games. Where there is
interaction, depth is compromised because of the variety of player agendas.
If there are a initially a variety of viable solutions and other players
remove then all (likely unintentionally), then depth has been eliminated.
If you consider that scenario a call to action to find solutions to the
blockages, then you completely miss the point.
> > Or playing Deer Hunter with the Silly Dance guild doing a conga line
> > through the middle of the woods, scaring off all wildlife within a half
> > mile.
>
> One might argue that this could only improve the Deer Hunter experience :)
That single statement lies at the heart of the point I'm trying to make.
The single player game Deer Hunter does not have such interruptions because
people who like to hunt deer do not like to have the animals scared away.
JB
More information about the mud-dev2-archive
mailing list