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

[Adam Wiggins]

[Caliban:]
> MUDs, on the other hand, lack a lot of flexibility. In order to make

Hmmm, methinks we ought to get our terms straight.  I use mud (capped or
not) to group Tiny, LP, Diku, and everything else we think of as
being online, text-based role-playing games into one giant lump.
If I wish to reference a specific codebase (MUSH, MOO, Diku, MUX, LP,
Abber, Ya..) I will do so.  You seem to use MUD as anything that is not a Tiny?

> much of any modification to a MUD, you have to drop into the hardcode
> and muck around, usually breaking something. When you do go trying to

Are you familiar with LPC?  I'm fairly certain LP counts as a mud, regardless
of your terms.

> modify things online in a MUD, you deal with a complex set of cryptic
> commands that generally bear close resemblance to the actual
> implementation and must be used in proper combination and sequence. On

What you seem to be thinking of as muds are worlds with fixed physical
characteristics.  These are not changable.  If you drop something, it
will break.  Coding around this is a major hack.  If you wish to add
a material type 'ether' which has no substance, feel free.
I grant you that some codebases that attempt this don't do it very
well.  Diku is now 8 years old, and showing it's age, I'd say.

> 	I created a fountain in the middle of one of my areas. It
> 	doesn't load up into the game when I start the server, though.

Totally unrelated to any sort of source-level programming in any
codebase I've ever seen.  Only possible flaw is somewhere in the area
definition file - likely they have the fountain in the wrong place, set
to load up after a fixed amount of time, or just have an object other
than the fountain set for loading.  If people can't figure this out,
they have no business whatsoever running a mud.  Most area writers
I know have little to know knowledge of programming and manage to write
areas just fine; if you can't manage this, there's no way in hell
you're going to be able to handle actual source level programming.

> 	I did an oxlpt of the vnums to my qmrfs, and then a cdrflp of
> 	the smrflgn. After I assigned the aflexm, I unset the qrblnt
> 	flag and frmbldorped the horgn. What have I done wrong?

I am not familiar with this, so I can't comment.
Since it seems to be nonsense (if not, it was some *very* poor
acronym choices.. smirk), I'm not sure what solid example it serves.
A standard answer to this question would be:

Type 'show object fountain' to see how many are currently in existance
in the world.  If there are none, then you have loaded the wrong object.
Type 'load object fountain', 'at <room> drop fountain', and 'save area
<area>'.  Might want to find out what that extraneous object you managed
to add was, too.

Is there any codebase that does *not* work like this?  (Substitute in
@ symbols wherever you like to make the commands more familiar.)

> (Side note: And you wonder why most MUDs use the same areas.)

I'd say it it because creating even a mildly worthwhile area is a time-
consuming and arduous task with only the somewhat nebulous reward of
'a job well done'.  Actually learning how to create an area is trivial;
my friend's 12 year old brother figured out the basic format for rooms and
had several up and running the first day he tried.  He knew nothing about
muds, really, so of course they were terrible.  But they worked.

> This is an interface problem. As I've said before, RPers want to get to
> the business of playing the game. In order for a MUD admin to get areas

Hum...is there anyone that doesn't?  This statement is the equivlent of,
"Most RPers dislike intense and prolonged physical pain" or "Most RPers
type with both hands." :)

> built, he has to gain a pretty intimate familiarity with the internals
> of the code, hack the server itself all to hell, and spend hours on end
> playing with these unintuitive and mostly undocumented commands to get
> his areas up and working. The reset syntax for areas is a total mess and
> looks almost like line noise. 

Still trying to figure out what codebase you're refering to.  I've
worked with just about every one in existance (and a few that aren't,
yet, in existance) and I've never encountered what you're referring
to here, nor do I see what it as to do with "RPers".

> I think there is a LOT of potential for MUDs as an RP environment. The

Me too.  For instance, most of the stuff in the MUSH side of the mud family
does pretty well, though I think it could be done a lot better.  That's
part of what bugs me about muds - they only show how much more can
really be done with the medium.

> problem is mainly that huge bunch of stuff you have to learn; it's not
> like gaming, it's like computer science. What this ends up meaning is

Mudding is complex, agreed.  I like this; it's not Doom or Duke Nukem.
Learning how to step into the role of a character in a world which is
somewhat similar but mostly very different from our own is a big enough
step, but on top of that you most learn to view this world through the
somewhat limited window of endless scrolling text.  'Tis no wonder
that the community stays as small as it has despite the internet
exploding.

> that the type of person who makes a good RP-centric game designer is not
> generally the type of person who makes a good MUD builder, and the
> converse also holds. The learning curve is steep. The problem is not so

Hmmm, don't know that this is true.  I've found that a good builder is a
good builder, and a good builder is a hell of a hard thing to find.
In my mind it's identical to a good author - they may have their strengths
and weaknesses (fiction/non-fiction, sci-fi/fantasy/modern day/western,
tragedy/romance/heroic/horror) but generally a good writer is a good writer
at whatever they choose to try their hand at.

> much that the commands themselves are bad, but that there's too little
> documentation and what there is tends to be incompletely indexed. 

Oh, yes.  An offshoot of being a part-time project of college kids who
generally only want to fool around with things that are fun for a while,
and then move on.  Something like keeping docs up to date isn't really
all that much fun.