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

[Travis Casey]

On 18 August 1998, Caliban Tiresias Darklock wrote:

A few random thoughts...

> 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. Roleplaying is impossible to code,

Roleplaying is impossible to code -- however, it is possible to
encourage or discourage roleplaying through both world background and
what you code.  Of course, opinions on this depend to a great extent
on what you think of as roleplaying.  As I've said before, my
definition of roleplaying is playing a character as if it were a real
being existing in a real world, instead of simply a playing piece in a
game.

Thus, from my point of view, increasing the "realism" of the game
automatically encourages roleplaying.  A mud's designers can also seek
to ensure that player characters are going to have to interact with
each other, can give the characters things to be concerned about
within the game world, and can create social structures inside the
game world.

None of these things will *force* anyone to roleplay, and none of them
truly *create* roleplaying... but they can encourage it.

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

Possibly.  No one's done it yet (that I've seen, at least), but that
doesn't mean it can't be done.  The subject of building a mud in which
new puzzles are automatically or semi-automatically created has been
discussed here before, and I think that some of the ideas that have
been bounced around would probably prove to be workable.

There are other ways to create problems to solve on a regular basis --
the other players can *be* the problem, or contribute to it.  An
example of this would be the idea that was recently raised of having
two muds in one, with the PCs on one being the NPCs on the other.

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

Combat, to me, is a subclass of problem solving -- killing something
is simply a way of solving some problems.

> I think much of the problem with MUDs comes from the "all things to all
> people" mentality. We want it all. That's natural. But the old axiom of
> being nothing to no one applies; if you try to do everything, you'll do it
> badly. A small, well-defined set of goals can prevent the game from
> becoming overly difficult to code and play.

I'd agree with that.  Limiting the scope of what you're doing always
makes it easier -- the trick is in knowing what's broad enough to stay
interesting for a good length of time while still being small enough
to be easy to implement.

--
       |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'
     '---''(_/--'  `-'\_)