[MUD-Dev] RP=MUSH/PG=MUD

[Caliban Tiresias Darklock]

On Thu, 19 Jun 1997 20:43:41 PST8PDT, clawrenc at cup.hp.com wrote:

>It is a good question, and one I'd like to see taken a *lot* further. 
>How about a general post outlining what you see as the basic strengths
>and definitional features of an RP server and a combat server with
>possibly some talker aspects thrown in?  I wish I had time to join in
>right now...

Okay. To begin with, I see any given game server (GS) as having four
basic parts, as follows:

 +----------------+----------------------+-----------------------+
 |  GAME SERVER   |  (Internal)          |  (External)           |
 +----------------+----------------------+-----------------------+
 | (Technical)    |  Game System Model   |  Programming Language |
 +----------------+----------------------+-----------------------+
 | (Nontechnical) |  Game World Model    |  User Command Set     |
 +----------------+----------------------+-----------------------+

This illustration is slightly flawed as I present it, in that the game
system and game world are rarely a clearly defined pair of separate
entities, and on many occasions the programming language and user
command set are subject to significant crossover. Perhaps it might be
more effective to classify these as 'player-visible' and 'player-hidden'
in combination with 'hardcode' and 'softcode'. But this is semantics.
There are two different kinds of people in the world; those who divide
people into two groups, and those who don't. Whichever definitions you
find most clear are perfectly valid, and it may not even be applicable
to make these distinctions -- you could very well have an entirely
softcoded system with the user command set identical to the programming
language. (This is a model I personally find rather attractive, but
there may be drawbacks and problems I am not considering.) In any case,
every GS enforces two general ideas -- there are parts of the world, and
parts of the game; and then there are commands used to interact with the
world, and commands used to modify it. 

But where I think GS design breaks down is in the way we define them.
The game system model, we either peg on something rigid and inflexible,
or create as some one-size-fits-all brand of polymorphic interface that
is so abstract as to be irrelevant. As someone else on the list pointed
out, the D&D style game system used in many GS implementations is not
necessarily suitable for every game, and while a RuneQuest style system
might be *more* suitable for a particular game, the choices tend to be: 

     1. So much support for a radically different system that to change
        it requires almost a complete rewrite.

     2. No support for any game system whatsoever, forcing full 
        implementation from scratch no matter what game system you
        intend to use.

The latter type of system brings with it a sort of left-handed benefit.
Since everything in the system has to be reimplemented from scratch, the
designers and administrators of the final game tend to throw out a lot
of dead weight. This makes for a leaner and less rules-oriented game in
the end, and encourages roleplay. However, the former type of game locks
most designers and administrators into using what is already supported,
resulting in frequent bad simulations of something that they just don't
have time to do right. 

I know I'm generalising, and I'm sure there are a good number of places
out there that really have gone the distance with both kinds of GS. But
my own experience, whether as player or staff or sysadmin or developer,
has been that most people do fall into those two categories. 

The real problem, I think, lies with motivations. It seems like almost
every GS developer these days is involved in this for the technical
study; they want to make the best, fastest, most ungodly brilliant GS
you can run. They want full control over the whole thing from command
interfaces. But where this breaks down is where someone logs in and
discovers that they need to use some odd sort of syntax to represent
something. To use a completely unrelated concept in order to avoid
beating up on any codebase, imagine if Netscape required you to
explicitly call the method of a link to follow it:

	document.url=document.links[5].url;

Or to simplify it:

	ducument.links[5].onClick();

Somehow, I doubt the web would be as popular with something like that.
It does serve the purpose; it would work quite well, and really once you
got used to it it wouldn't be that bad at all. What often seems to
happen is that the developer designs something that needs to be
manipulated by the game's staff, so in a logical extrapolation he
designs a reasonable approximation of how it's implemented in the
hardcode. Having done this, he tests and expands and does all sorts of
things with it, and then when it comes time to write a command set he
often says "oh, that's simple enough, anyone can learn that" and doesn't
bother considering whether it's intuitive. To him, it is; he's used it
for months, it's second nature. But when 14 year old Bobby logs on to
his first online game and tries to play, he ends up having to type these
huge four-line commands with odd syntax that makes no sense to him. 

To compound the issue, a lot of old school gamers LIKE obscure and
difficult command sets. I'm one of them. So when the developer gets some
people to test the program, he gets other developers who probably think
a lot like he does. When they try out the commands, they see awesome
power and something that they can readily understand; in addition, their
ability to use this command set makes them feel clever, because they
are. They may very well say "Well, if you don't understand the commands,
then you shouldn't be playing". This does not help the community. There
is an associated awe factor to being able to place in the International
Obfuscated C Competition; likewise, there is a deep and profound respect
granted to those who can write complex and elegant one-line programs in
APL. But this sort of thing doesn't really belong in a game. 

The problem, as I see it, is that when the developer creates the game
server, there is rarely a middle-of-the-road approach. It's either very
very tight, making the server applicable only to a small number of
people, or very very loose, making the server applicable to absolutely
no one until the time is taken to modify it. 

Since the subject has wandered a little, let me put it back on track
with this. When the developer creates a server, he should give some
thought and consideration to who is going to use the server. There are
actually four different types of people who will use it -- 'server
hacks', who will modify the game system; 'builders', who will modify the
game world; 'coders', who will program the game world using the
programming language; and 'players', who will interact with the world
using the user command set. There is a significant crossover between
these groups, and each individual may be a member of any or all of them.
(Or none of them... there *are* people who seem to log onto a GS for no
particular reason at all. They connect, idle for an hour, and are
disconnected from the server automatically. Sometimes they even come
back and do this several times.) 

Most servers lean in one direction or another. They emphasize one thing
over the others. Where the programming language and command sets are
emphasised, the parts which are exposed to the users, the server will
usually be more suited to a roleplaying environment; where the internals
of the system and world are emphasised, the game will generally be more
suited to what many term 'powergaming'. Both styles of play are
completely valid, and both have their place and their uses. But I'm of
the opinion that if we balance the playing field a little more, placing
roughly equal emphasis on all four areas, we could create a GS which
could support both roleplaying and 'powergaming' -- in fact, a GS which
could allow each and every player in the game to determine how much of
each is right for himself and have a reasonable chance of enjoying the
game no matter which particular balance he prefers, even while
surrounded by other players who may have entirely different preferences.

I've got a lot more in the way of comments and opinions on this matter,
but I think this post is long enough already; furthermore, I'd like to
pause at this point and get a little feedback from the list so I can
clarify or correct any of the points I've brought forth here, as
necessary. Opposing or differing viewpoints are encouraged. This is
intended to be a dialogue, not a monologue. :)

-+[caliban at darklock.com]+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 I am here to grind your eyes harder into the miasmic bile of life; to 
 show you the truth and the beauty in the whisper of steel on silk and 
 the crimson scent of blood as it rises to meet the caress of a blade. 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+[http://www.darklock.com/]+-