[MUD-Dev] Re: Marion's Tailor Problem

jwilson at rochester.rr.com jwilson at rochester.rr.com
Tue Aug 18 19:14:20 CEST 1998


On Tue, 18 Aug 1998, Caliban Tiresias Darklock wrote:
>On 10:05 AM 8/18/98 -0400, I personally witnessed s001gmu at nova.wright.edu
>jumping up to say:
>>
>>The problem with disallowing PKill/PSteal is that a lot of people on here
>>are advocates of a more 'pure' simulation type game.  
>
>This is something I've had somewhat of a problem with for my entire time on
>the list. It seems like "MUD development" is often seen as meaning "Making
>MUDs more realistic". I always thought it meant "Making MUDs more fun",
>which for some people might mean making them more realistic, but realism
>and fun are not by any means synonymous. 

yes. one must be clear from the start which sort of mud you are
interested in.

>You always have the natural tendency of people to go out and do things that
>are fun for THEM at the expense of others. Dr. Cat has said that this is
>just not acceptable in a commercial endeavour, but when you think about it,
>the *reason* it isn't acceptable is quite simply because it upsets players
>and drives them away from the game... and I don't think that's acceptable
>in any game, commercial or no. Anything that causes players to become upset
>and leave the game is Bad. 

only if your primary objective is a mud that doesn't upset people. I for one
am less interested in popularity than in the inherent purity of the simulation,
and that's fine for me. others are the reverse, and that's fine for them.

>Another problem I see in MUDs is that they're often presented as being
>computer RPGs. With RPG style gaming on computers, you have an annoying
>problem. There are three major RPG pursuits -- roleplaying, problem
>solving, and combat. 

I would add strategy to these three. I find something like Civilization far more
engrossing than, say, Quake, though once in a while I go back and get the
adrenaline rush.

>Roleplaying is impossible to code, and *ongoing*
>problem solving is very difficult to code. Think about a game like "The
>Seventh Guest" -- lots of problem solving and puzzles, but after you play
>it once or twice, you're done. Combat, however, can be run effectively by
>the computer... so we worry mainly about creating "good" combat systems.
>Except those systems are *still* tedious and unchallenging. So we apply
>them to other players.

hear, hear. 

Problem solving in a multiplayer environment has the added problem that
players will tell one another how to solve the problems... I still remember
being a newbie on one mud where some bored player decided that
it'd be fun to show me how to solve all the problems that she'd spent
hours figuring out. She was so happy to show off how smart she
was, and I was so bored I never went back.

James




More information about the mud-dev-archive mailing list