[MUD-Dev] Removing access to entertainment

[John Buehler]

Marian Griffith writes:

> There are a great many reasons both for playing a game and for
> incorporating certain features within a game, and then there are
> many motivations to do and like things.  Overcoming the game
> challenge is only one of those, and its importance likely varies
> from one player to the next. There will, undoubtedly, be players
> who appreciate the additional challenge as there are players who
> dislike the disadvantage darkness or other reduced visibility
> gives them.  There will also no doubt be players who enjoy the
> added uncertainty over precise control over what happens within
> the game.  Broadly stating that darkness and rain is 'no fun
> because you can not see everything there is to see' is far too
> simplistic.

And you in turn appear to be interpreting my statements far too
simplistically.  I said that in a game predicated on entertaining
its players with graphics, darkness is not entertaining.

This isn't about whether or not somebody in the game finds it
entertaining to not be able to see the graphics.  It's about whether
people in general find it entertaining to have something removed -
that was the very thing they came to the game for.  If I like to
fight in the dark, then I should be able to go find dark parts of
the game world.  Darkness is like enforced downtime.  Downtime as a
vehicle for socialization is just fine - but not everyone wants
downtime.  The very entertainment that the players came to the game
for (fighting action) is taken away from them because downtime is an
enforced game mechanism.  The same can be said of nighttime.  If
it's so entertaining, make it a feature of some part of the world
that players can go to.  If they really like it, they'll seek it
out.  When it's not optional, it's a barrier to entertainment to
some percentage of the players when it happens.

>> 2. I can see why people dislike mesmerization. No one likes not
>> being able to do anything at all.

> I am sorry, but I disagree here. Personally I may not 'like' to be
> paralysed within a game, but I very much enjoy the sense of thrill
> it gives. The sudden lack of control and uncertainty can be, in a
> sense, quite appealing.  If it is overdone then, like any other
> thing overdone, it gets to be annoying, but as a tool of a game
> designer it is one of the most powerful ways to invoke strong
> emotions in the player.

Ah, the 'evoking strong emotions' argument.  This is one that I am
emphatically in opposition to, especially when the emotions being
evoked are fairly random.  Some hate features, and others love them.
And those two groups get into vehement arguments about it.  And the
developers pronounce this as entertainment and goodness.  Frankly,
it makes me ill.  It's like saying that throwing a stick of dynamite
into a pile of lumber is a housebuilding technique.

I'm all for evoking strong emotions from players, but only when
those strong emotions are entirely delightful.  I had a strong
emotional reaction from being randomly attacked by a player in
Ultima Online.  And my reaction was to cancel my account.  I had a
similarly strong emotional reaction from being killed by the
gamemasters in an 'event' in Everquest.  Same result: cancelled my
account.  Frustration and anger are not the sorts of strong emotions
that our entertainment should be evoking - in my opinion.  Just
getting the peasants animated isn't enough.  Games should delight
them, not annoy them.

>> 3. Blindness. Most games have a method of blindness. I think that
>> an implementation of activity while being blind (albeit not at
>> the skill level of full vision) is key to overcoming this
>> challenge, if not curing the blindness altogether.

> See above. Blindness is essentially the same as being paralysed
> and has many of the same benefits.  In addition it encourages a
> social dimension in a game, since players must either wait out the
> loss of sight, or find some other way to overcome it, and this
> usually will mean enlisting another player to help.  This is a
> game design issue, not a player enjoyment issue. Just like
> 'enforced downtime' is, and disjunct class capabilities so that no
> single player can stand on her own entirely.

If you view enforced downtime as a practice of good game design,
then we are seriously at odds.  I think that enforced downtime is an
abominable design hack.  It's akin to taking my children and locking
them in a room together with nothing to do because they don't get
enough quality time with each other.

It's ALL about player enjoyment.  From the time they log on until
the time they log out.

>> 4. Slow travel in large worlds. Again, I think this is a serious
>> implementation flaw. Horses, carriages, etc. are a must need, as
>> is automated transportation so you can carry about something else
>> while you travel.

> Quick travel, as pointed out before, is a potential danger to
> coherency of the game.

When boredom is an element of retaining coherency of the game,
perhaps the game should lose some of its coherence.

> If too easily accessible it carries with it the significant risk
> of bleeding dry the game experience as originally intended. As
> Raph Koster pointed out players are motivated towards convenience
> not experience.  In mud terms it is most likely to lead to dead
> zones which are no longer the most optimal. For a game designer
> that is a waste of resources.

I keep reading this as "What the designer has in mind is really
important, and if the player has to suffer, that's okay because
they're suffering for the greater good."  These games are supposed
to be entertaining players.  That entertainment is only coming in
fits and starts, where the remainder of the time is spent enduring
the fiction of the game reality.

> For the player it threatens the social fabric of the game, since
> everything is ony a few mouseclicks away, and the game can all too
> easily deteriorate into a 'city of thousands of strangers' instead
> of a 'village of hundred familiar faces'.  The social experience
> is much stronger in the second case.

We're playing different games, obviously.  The only community that I
was ever involved with was my player guild.  And that has nothing to
do with the game fiction of colocation of game characters.  As
before, the fact that the game world is large and my community is a
player community tells me that the large world is a hindrance to
getting my character to where my fellow players have their
characters.

> Also, if the game world is big, it should *feel* big.  The key is
> to make it also feel *alive*. If traveling through the world is
> intrinsicly entertaining, or at least interesting, then it will
> not matter that it takes a long time.

Oh, I completely agree with the last sentence there.  The only
problem is that traveling through any of the big graphical games'
worlds is not intrinsically entertaining.  That's part of the source
of this post - the number of things that are not entertaining, but
which are prerequisites to what IS entertaining in those games.

> What if traveling to another town takes three of four real days,
> as long as plenty of things happen along the way, and the group
> making the journey can decide to leave the common path to explore
> a forest, or a set of caves, and when encounters with hazards
> scaled to the group can happen at any given moment?

That would probably be great.  That's not what we have today.  I've
been writing all this in hopes of getting designers to understand
that if they're going to put something into a game, it needs to be
intrinsically entertaining to those who are going to be experiencing
it.  And that can be on a large scale or a small one.  If I'm trying
to pick a lock, the entertainment for that should not involve
building an amusement park, where if I build a sufficiently
successful one, I've picked the lock.  That's the small scale of a
single experience.  At a larger scale, if a game is predicated on
the experiences of racing formula-one cars, I shouldn't be putting
all sorts of hassles into the game over managing endorsements from
sponsors.  It's realistic, but it's not entertaining to those who
just want to race cars.

> It is never good to define a problem in terms of current
> implementation . That is one of the first things you learn when
> you study architecture, but it really applies to every form of
> design.

You really did treat my post too simplistically.  I've been
illustrating a design principle for days now, using examples from
existing game designs.

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