[MUD-Dev] Removing access to entertainment

John Buehler johnbue at msn.com
Thu Dec 4 10:59:20 New Zealand Daylight Time 2003


Brian Lindahl writes:
> 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.

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

I've noticed that through time games have begun to eliminate the
annoyances of previous games.  One such example is a difference
between EverQuest and Dark Age of Camelot.  EverQuest assigned
weight to money.  Dark Age of Camelot does not.  In EverQuest, there
were times when I had to carry so much money that I would drag my
character from point A t point B.  And just transferring cash for
purchases got to be a hassle.  In Dark Age of Camelot, money has no
weight, so money never becomes a burden, literally or otherwise.  I
believe that Mythic chose to go that route because heavy money is a
barrier to their ability to provide the entertainment that they want
to provide.

Again, just becomes something is challenging doesn't mean that it's
entertaining.

> I think most of the issues you bring up target specific
> implementation flaws in the design of a game. Granted, you will
> always find implementation flaws in a game that will make it less
> fun. I don't think its sane to argue this point.  > Are you just
> listing off a bunch of common poorly implemented features and
> asking for more? I'm not sure I see your point behind bringing up
> this discussion.

What do you do for a living?  I assume that you're good at it. And
that you're good at it because you have examined the problem space
that your job addresses.  And that you continue to examine that
problem space because it will make you better at your job.  That's
what I'm doing here: I'm examining the problem space of game design
and discovering what I believe to be a valuable principle or
pattern.

My point is to get game designers to look at their problem space in
a way that they may not have considered before.  From what I've
seen, this is not something that has been codified for designers.
They seem to have a vague notion of putting in functionality that is
fun and keeping out stuff that's not fun, but separating the two is
hardly a structured process.

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



More information about the MUD-Dev mailing list