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

[Nathan Yospe]

On Wed, 4 Jun 1997, Caliban Tiresias Darklock wrote:
:On Wed, 4 Jun 1997 20:02:47 PST8PDT, Adam Wiggins
:<nightfall at inficad.com> wrote:

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

:I used to do that. Then I figured out that they were so outrageously
:different that a MUSH and a MUD were entirely different animals. 

Bullshit. Had to be said. There is nothing exceptionally special about
tinys. Its a matter of degree. Familiar with LPMOO? You could model a MOO
or MUSH under Physmud++, with about the same amount of work it would take
to model a Diku or an LP. As a matter of fact, there was a Tiny at one
point that modeled a Diku. There is NO justification for this degree of
seperatism. Elitism sucks, and I have never seen anyone who claimed that
Tinys were not muds who didn't suffer from a healthy dose of elitism.

:>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?

:Pretty much. If the foo shits...

Sometimes you really annoy me. There is a huge spectrum out there. Get
familiar with more than a couple of colors before you form your opinions,
would you?

:As examples, I'm going to use TinyMUSH and SMAUG, which are the two
:things I happen to have on my hard drive at the moment. Note that this
:is not meant to be an argument that 'SMAUG is crap' nor that 'Tiny is
:king'. These examples are just that; examples. Period. They are not
:intended as any kind of reflection upon the specific server in question,
:but you want specifics, here they are.

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

:No, I'm not familiar with LPC. In order to get familiar with it, I would
:need to have some way of running an LP someplace so I could futz around
:with it. I don't have that kind of resources to invest in something that
:pointless.

Last I checked, DGD LPs were a lot more efficient than MOOs. Not that it
means that much... LPs are best experienced on someone else's machine.
They are that sort of animal.

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

:What the hell are you talking about? 

He is saying that, in a lot of Dikus, changing hardcoded aspects becomes a
game of hack the pasta. I think. Dikus are not the high point of muds.
They are a nasty accumulation on the sides of the pipe.

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

8 years old, and not designed to change, is the problem. I mean, Tiny and
LP are not young either. Or all that good, I think. But they have at least
been ground-upped a few times.

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

:It wasn't intended to be source level. However, I could post the code
:necessary to add a new class if you like.

And this is not universal, either. Even before Physmud++, I rewrote Rom
enough for Singularity 1 that just about everything that had configuration
was configurable without restarting the game or changing any code. Races,
classes, areas, rooms, and so forth...

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

:Well, gee. Why does this never seem to happen under Tiny? Could it be
:that maybe the interface is cryptic, undocumented, and difficult to
:understand?

Hello? It happens plenty under Tiny. Almost as much as under more advanced
Dikus. Just because you already got over that hump with one, and not the
other... The documentation for both off and on line creation for Roms, at
least, was fairly good. And I wrote an 80 page hypertext document for my
own system for Singularity. Its not at all how you portray it... the
problems with Dikus stem from a lack of complexity, not an overbearing
degree of it, in the creation process.

:>If people can't figure this out,
:>they have no business whatsoever running a mud.  

:Oh, piffle. I hear this all the time. "Why are you running a MUD if you
:don't already know all this?" -- well, because NO ONE WILL TELL YOU, for
:one. If you knew how it worked, well, you could cheat, or something.

No. The point is that these are things that most programmers can figure
out in under a minute. The code is hacked and spaghetti, and I REALLY hate
Diku... but I hate codebase bigots just a wee bit more.

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

:Most Visual Basic developers I know have little to no knowledge of
:programming. Your point?

Uh... your point? Dikus require their admins to be able to program in (non
ANSI) C. The areas are easy to pick up, and failure to pick them up in a
short order of time from an indexed document (which does exist) is about
as clear an indication of not having what it would take to learn C as I
can think of. Where does VB come into this?

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

:Well, okay, try this.

:	First I aassigned the area to myself, and aset the hi_obj to the
:	right vnum. Then I made the object and did an instaroom, ran a
:	savearea, aassigned myself none, and did a foldarea.

:Still looks like nonsense. Maybe I'm too Tinified. Ummmmmmm... 

:	I @create'd the object and dropped it in the room.

:Gee. Which would you prefer? I kind of like the wizardly aspect of the
:first, you know, but really I kind of like to get to the business at
:hand and finish the job so I can play.

Actually, the stuff you quoted above is all security issues, and is not a
repeated performance kind of thing. Except for the create and drop, it is
done once per area. After that, the OLC system is a lot like your @create
and drop. Oh, you DO have to remember the difference between CREATING and
LOADING... template and instance. No biggie, right? You are quibbling over
symantics, all fluff and no substance.

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

:What if there are some? Convenient omission there, I'd say.

Not really. If there are some, and one of them is out of place, maybe you
are loading it in the wrong location. Go kill theerrant one and then do
the following. Its just a sanity check, not a critical procedure, so the
ommision is sensible. (You almost never detail the catch block when
outlining a try/throw/catch enabled function. Mentioning that there is
exception handling present is enough.)

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

:See the above.

What, so he had to save his changes. I still think you are nitpicking. In
a BIG way. And missing the bigger picture.

:>> (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'.  

:Interestingly, I routinely build large MUSH areas and find the process
:quite fun. I never seem to crash the server, and I can have people using
:the area before I'm even finished with it. And if I shutdown before I'm
:done, everything's automatically saved. I have never encountered a
:problem on a MUSH where anything disappeared or was misplaced. Ever. And
:yet it seems to happen routinely on MUDs.

I might add here that while I have seen few GOOD areas on Dikus, and not
many on LPs (though more), on all the Tinys I have played, there have been
NO GOOD AREAS. A decent number of passable ones, but no GOOD ones. I
always attributed this to the @create and go design philosophy. (Sub
collections of rooms for areas where appropriate.)

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

:Hmmmm. Let me see...

:	#881
:	Door to Keep~
:	~
:	0 1073741824 1
:	D1
:	~
:	~
:	0 -1 880
:	D7
:	~
:	~
:	0 -1 882
:	D9
:	~
:	~
:	0 -1 898
:	S

:Uhhhh... What? I mean, I think I can figure some of this out. It looks
:like Vnum, Name, uhhhh... something, probably a description, then um...
:gee. I think that middle number there is some, uh, flags, or something.
:D1... hmmmm... I think that might be an exit. Probably going north. D7,
:um, are we counting clockwise or counterclockwise? D9, probably down...
:the strings, I mean those are strings right? Delimited by a ~ character?
:Probably name and desc again... uh, I think those numbers are um, well,
:let me make a wild guess and say that the first one is whether it's
:locked and the second is probably the vnum of the key, and the last one
:is the vnum of where it goes. And that S probably means end of record, I
:think.

:Now then, given that info, let me see... do I want to write an area?
:Hell no. Get this thing away from me.

Off line vs on line. Do you really think you would enjoy designing a MUSH
off line? I don't. Incidentally:

#AREA [
> mindscape {    // reference name 'mindscape'
F mindscape.are  // saves to file 'mindscape.are'
N The Mindscape~ // named "The Mindscape" in game
A FireBrand      // Author == 'FireBrand'
O mindscape2.are // Has occurance generatable alternate
}
]

#HELPS [
> {
 K mindscape~     // global information database entry
 D Database entry #000 - The Mindscape
A world without form, existing somewhere within the event horizon of 
the singularity XBC-3201, the mindscape is under code Omega edict.
~
}
]

#ROOMS [
> central {       // reference name 'mindscape:central'
 R Cocooned within the heart of the gray mist~, this single occurance of
clear, open air seems strangely cool... <s1>The faint scent of thick, 
dry fog wraps itself around you. </s><h4>A gentle hum fills the space 
within the mist. </h><v6>Tiny beads of water drift in and out of the 
near weightless center of the space, a rainbow trapped within each 
gleaming sphere. </v>
~
                  // default atmosphere = earth normal
 T none           // no ground
 G .25            // quarter strength gravity
                  // default temperature = room temp

 D -1 mist {      // an exit set for all directions to 'mindscape:mist'
  L The mist is inpenetrably thick.
~
  M As you approach the mist, tendrils seem to reach out for you, 
enveloping you in cool dampness. A final step, and it closes behind you.
~
  L $n disappears into the mist.
~
  E <h2>A faint sucking sound reaches your ears. </h>Something seems to 
have entered the mists. <v1>A shape resolves itself to your eyes as $n. 
</v>
~
 }
}
]

#FIELDS [
> mist {
 @ 0 0 0
 D -1 central{
  L A ^b glow illuminates the curling mist.
~
  M The mist parts, and sudden light, almost blinding, stuns you.
~
  E $n steps out of the mist.
~
 }
 @ -10 0 0 
 I rock
 @ 10 10 0
 I puddle
}
]

#ITEMS [
> rock {
 N rock stone~
 S $a rock~
 L A rock juts out of the mist.
~
 D There is nothing particularly extraordinary about this rock, outside
of its location. It looks strangely massive, as if it were too real.
~
 C stone
 M 10000
 S 50 50 50
}

> puddle {
 N puddle water~
 S $a puddle~
 L A puddle of water has pooled in the mist.
~
 D It looks like an unusually pure puddle of water.
~
 C water
 M 100
 V 1000
}
]

Looks terrible, doesn't it? Good thing the builders get to use an arrow
driven interface that conceals all this. And, no, this is not the worst.
This example has nearly zero markup.

:>> 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." :)

:Me, I like being able to use a simple and understandable command that
:does what it says it does. @create creates an object. @dig digs a room.
:@link links this room to another room. None of this annoying
:rcreate/pcreate/ecreate/ocreate crap. @set is @set. Not mset, rset,
:oset, aset, or anything else. Just @set. Bam, done. @set works with
:anything; attribs, flags, multiple objects. It makes sense.

Uh... what's the difference, really? No, I mean, really? Aside from the
obvious design flaws in Diku (the way they define rooms, areas, mobs, and
objects) the differences are all symantic, and not even very large
symantic differences. rcreate == @dig, you see. A Diku builder might well
wonder why you differentiate room creation from object creation with a
word like "dig" of all things? And what the hell is with all of these '@'
symbols? Why not just make them regular commands? </diku builder>

:>> 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, 

:Hmmmmmm....
:
:	E 0 818 0 9
:	M 0 813 1 877
:	E 0 811 0 16
:	G 1 824 1
:	G 0 802 0
:	M 0 814 1 879

:You know, you're right. That's *perfectly* intuitive. I don't see why I
:never noticed how easy it was before. 

What, is that the old style resets? Those were godawful. I released a
patch for Rom, way back when, to massively restructure resets, making them
room based and fully nested. And functionally room based too. I know Its
in use by a few of them, at least. (I released several patches.
Canibalized Sing1 for them. After all, I hacked so many fixes, might as
well let SOMEONE make use of them.)

:>nor do I see what it as to do with "RPers".

:It has nothing to do with RPers. It has to do with why MUDs are better
:suited for powergaming, and MUSHes are better suited to RP. 

Get it through your head... there is no black and white here, its all in
your mind.

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

:The major drawback to MUSH servers is that they require you to basically
:reimplement EVERYTHING. Even the core game system is absent.

*shrug* Some LPs are like that too. Strangely enough, LPs that implement
from that point tend to be more unique than the MUSHes that do the same.

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

:Actually, I can play a MUD using a basic familiarity with four to six
:commands. However, building on one involves crawling through mailing
:lists and newsgroups looking for someone who will quit insulting me long
:enough to tell me something useful. There aren't many docs, after all,
:and the ones there are have gotten pretty far out of date.

*shrug* I took the thing out of the box, played with it, and a few months
later, had one of the most unique Dikus in existance. Then again, there is
an assumption here... a natural talent for programming. You see, the way I
figure it is, if you are asking others, you are stuck with what they have
done. I don't LIKE what they have done. So I do what I want to do, and
would have had to pave my way anyway.

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

:I'd chalk it up more to the number of arrogant dorks who tell you how
:stupid you are when you ask a question. Plenty of people are perfectly
:capable of stepping right into this sort of thing.

Hmmm. Role Playing is easy, right off the bat. Design is hard, right off
the bat. Uh huh. Ever stop to think that the community is not homogeneous?

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

:Well, if someone would DOCUMENT THE INTERFACE maybe we could RTFM.

*sigh* There is always the "get it from the code" approach.

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

:That's because they write in one language that has documented and
:accepted rules, instead of forty incompatible half-assed command formats
:that nobody ever wrote down.

Not true. I'm a writer. Writing muds is a simple (oh, so simple)
extension of that. Now, programming a mud to write itself, for the most
part, which is what I am trying to do, is a bit harder... but I'm getting
there. See, most of the design of the mud is done on paper, then
translated. Translation does suffer in some ways, of course. There are few
choices available, there is no way to express the feeling of an open
prairie (why the hell do you think I have designed such a hard core code
consistant base?) or whatever. Linearity suffers when you have to account
for human variables.

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

:Then you shouldn't be writing a MUD.

Nah, just means you shouldn't be releasing your code.

   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            First Light of a Nova Dawn
 /   / / \ /_  /_) / \ /-|/ |/ /_/            Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe at hawaii.edu