[MUD-Dev] DESIGN: Why do people like weather in MMORPGs?

[John Buehler]

Mike Rozak writes:
> John Buehler wrote:

>> You mentioned tracking in snow.  That's a good use of weather,
>> but to really apply weather, consider each action, skill,
>> ability, whatever, that your player can control through their
>> character, and think of how to vary that with weather excuses.
>> Vary.  Not impede.

> Good point about variation and not impeding, although somtimes
> impeding produces beneficial effects. See below.

>> Being unable to get through a mountain pass because snows block
>> it is not entertaining to me.

> Yes, but if you can't get over the mountain pass then goods become
> more expensive during winter, so an enterprising player can take
> advantage of the travel difficulty. Is a richer/deeper world worth
> the inconvenience?

If your players are seeking richness and depth of the world as their
entertainment, then I'm sure the inconvenience isn't even seen as an
inconvenience.  It is a variation that only enhances the richess and
depth of the world - the very entertainment that they seek.  "Look!
That's so cool!  The pass is actually blocked!  That happens in the
real world!  Commerce is gonna be rerouted.  Watch the price of
goods fluctuate.  So cool."

Unfortunately, I think that's entertainment for a designer, not a
player.  A designer is entertained by the composite experience (the
tapestry) of all the players running around in their fictional
world.  For any given player, they have a single thread of that
tapestry, and they want it to be an entertaining thread.  In order
to entertain players through richness and depth, a higher level view
of the game world would have to be available to players so that they
can experience that richness and depth.  Perhaps it would work well
in a game where each player is a land baron, but I can't see it in a
game where a player operates an itinerant adventurer.

I believe that a multiplayer game needs to be designed with the
experience of the individual foremost in the mind of the designer.
Choose the sorts of players that you want to attract, then make sure
that those players have a well-rounded experience with a number of
variations.  Because you're probably trying to introduce multiple
types of entertainment (combat, commerce, travel, etc), the next
step is to ensure that the variations and basic experience created
for one type of player doesn't serve as an impediment to other
players.

When that pass becomes blocked with snow, the players interested in
commerce may find it an interesting variation.  If you've designed
your commerce experience properly, they were already thinking along
those lines and the possibility of a blocked pass is expected.  But
the players interested in travel are now stuck.  That have an
impediment to their entertainment.  Which is why players who travel
take the underground route.  Some of them do that anyway, just
because it's an entertaining variation.  Closing the pass remains
similar to closing down a ride at a theme park for the travelers,
however.

"But," you say, "travelers might enjoy the challenge of figuring out
how to get to the other side of the mountain when the pass closes."
It depends on the type of travel experience you're providing to your
players.  An entertainment experience can be anything you choose.
If travel is intended to be a challenge, then that would be
consistent with the experience.  If travel is normally just a
sightseeing tour for the eye-candy-inclined, then bumping into a
closed mountain pass is going to be pure impediment, not variation.
The designer will know which is which based on their understanding
of the individual who is experiencing the travel entertainment of
the game.

Design entertainment for a type of player (probably an enthusiast of
a certain experience), and not for fellow designers.  If an
entertainment experience occurs and nobody but a designer can
witness it, does it truly happen?

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