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

[Caliban Tiresias Darklock]

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. 

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-+[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/]+-