relevance of paper RPGs (was Re: [MUD-Dev] D& D vs. MMORPG "complexity")

Troy Fisher tfcoug at hotmail.com
Thu May 15 17:37:03 CEST 2003


From: Travis Casey <efindel at earthlink.net>
> Saturday, May 10, 2003, 3:58:36 PM, Threshold RPG wrote:
>> On 8 May 2003, at 11:58, Travis Casey wrote:

>>> The same is true of paper RPGs -- some people consider D&D3 to be
>>> too complicated to be practical, while others consider it to be
>>> much too simple.

>> That's a nice point, but woefully off topic here. The point here
>> is whether or not D&D is "too complex" to be used in a modern
>> online RPG. Debating the relative complexity of D&D compared with
>> other pen and paper games is not the issue whatsoever.

> The original point, before the debate over whether D&D is
> "complex" or not compared to muds began, was whether or not
> knowledge of paper RPGs can be a useful thing for a mud or MMORPG
> designer.  Several people expressed the opinion that paper RPG
> systems are too simple to be of use, using various versions of D&D
> as their example.

> The point I'm trying to make is that whether or not D&D in
> specific is complex is irrelevant to deciding whether or not
> knowledge of *paper RPGs in general* is relevant.  It's the most
> popular paper RPG, but that doesn't mean it's the best one to
> learn from.

With the point at hand I think it is essential to 'lift' the design
of a paper system for use in a MUD.  In fact I would go so far as to
say anyone or any system that does not use design elements from
paper systems is broken, or will be broken.

Let me outline why I believe that this is the case: (Note these are
not listed in Importance, but just the way that I plan on detailing
them)

  - Development Time
  - Enjoyment
  - Playability
  - Balance

Development Time. It takes time to develop an RPG.  It's a fact.  To
create all the aspects of it from scratch is just a monumentous job.
Writing a Mud from scratch takes time.  Combining the two would be a
large time committment.  For examples: D&D 3.5 has taken 8 months to
workout and it's still not done.  For simple upgrade to a system 8
months!  For a more relevant example take a look at the development
time for a Final Fantasy game.  Each Game has different advancement
system, different skill systems, and different magic systems.  Then
they have to code it, it's what 2 - 3 years between FF games?  Why
spend the time developing your own system from scratch and waste the
time that could better be used developing your code, or playtesting
your system?

Enjoyment.  A Paper system has one goal in mind, to sell books!  So
it therefore has to bring enjoyment to someone.  Whether it's goofy
(Fuzzy, Ninja Burger, or Hackmaster) or dark (Call of Cuthulu, World
of Darkness) these systems are built to have fun with.  Why
shouldn't we borrow that aspect from the paper systems?  It just
adds another dimension to the fun of our MUDs.

Playability.  Most paper systems have had the snot tested out of
them.  But then this is where the big difference between paper
systems and muds differ. A game bogged down in mechanics isn't going
to have great playability, but the MUD and automation takes care of
that.  But most importantly it has been tested as being 'fun' or
'thematic' or 'boundary-pushing' and you can look at those reviews
and say, "That's what fits with my vision." And you can borrow it!

Balance.  This is the most important factor in taking paper systems
and applying them to a MUD.  First off, I have never played or heard
of a MUD that is balanced properly (I haven't played every mud!)
Most Muds apply patches to fix the balance issue, remorts, level eq,
etc..  Yet I have yet to play a paper system that is grossly broken.
Most Mud Algorithms get so grossly over balanced between highlevel
and low level development that it is painful to think that there are
places out there you can look that take care of that for you
already.

But then most MUD Developers are megalomaniacs anyhow.

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



More information about the mud-dev-archive mailing list