[MUD-Dev] Removing access to entertainment

[Marian Griffith]

In <URL:/archives/meow?group+local.muddev> on Wed 03 Dec, Brian Lindahl wrote:
> On Fri 14 Nov, John Buehler wrote:

>> This is an observation about some graphical games that I've
>> played through the years, and a pet peeve that has been building
>> all that while.  I don't know if text games have this manifested
>> in any way, but the graphical games sure do: they remove my
>> access to entertainment as part of the normal operation of the
>> game.

>>   Example 1: Nighttime and rainstorms.
>>   Example 2: Mesmerization.
>>   Example 3: Blindness.
>>   Example 4: Slow travel in large worlds.

I can not fully agree with any of the following.  Certainly not as
long as it is phrased in terms of (all) players ... or simi- lar
terms that amount to that.  Nor do I agree with the original post.

> 1. I think night time and rainstorms become challenges to overcome
> - granted it does depend on the implementation. But at night,
> wouldn't it be best to have a light? Ok, so you get a light, where
> do you get this light from? This provides an avenue for
> entertainment and a means of overcoming the challenge. Rainstorms,
> I'm not sure why this removes access to entertainment. If you're
> talking about losing footing on dangerous terrain, why not get
> some boots/shoes with better tread? Again, a method of overcoming
> a challenge.

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.

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

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

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

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. 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?  Currently games are set up with encounters in static places
and players forced to travel to them. This is not the only way that
games can be set up.  Encounters can trail players as they move
around.  Minor threats can grow into major ones if they are not
dealt with soon enough (e.g. an orc tribe setting up camp near a
player city will eventually grow into a real threat to all players
until a large force of players removes it, or the orcs level the
player city of course).  This kind of organisation can make
traveling through the game decidedly 'fun' as well as challenging,
and not that many players would, I think, complain even if it takes
a lot longer than currently considered acceptable to travel from one
spot to another.

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.

Marian
--
Yes - at last - You. I Choose you. Out of all the world,
out of all the seeking, I have found you, young sister of
my heart! You are mine and I am yours - and never again
will there be loneliness ...

Rolan Choosing Talia,
Arrows of the Queen, by Mercedes Lackey
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev