Matt Chatterley root at mpc.dyn.ml.org
Thu Jun 5 18:01:26 New Zealand Standard Time 1997

[Adam W:]
> [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?

I use 'mud' to group them all as well, and distinguish by server type when
necessary too. Partly because of some of the problems that can crop up by
distinguishment - if you refer to a MUSH, many people assume it's just an
RP-central game - where infact it could be a talker, or even something far
more abstract.

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

Heh. LP is a little bit different from all(?) other mud bases though,
because it is *so* flexible. You could imaginably use it for something
completely abstract from muds. When you use it for a mud, its a mud
though, obviously :P
> > 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.

Given some of the excellent ideas and concepts bouncing around this list,
I'd venture that all the 'stock' bases look dated (excluding LP drivers,
since they are more an 'OS' to build a mud upon.. but including LP libs).

MUSH servers (tiny, penn, mux, etc) fall into the same category as LPs.

If I recall MUSH type code correctly, the minimal effort to create a crude
command (online) is something along the lines of 

&fubar object=$beep:@pemit %#=Beep!

In LPC, something like:

#include <std.h>

int cmd_beep(string str) { 
	return 1;
Both pretty simple, and easily done online with no hassle - something
which gives these kinds of servers an enormous leg-up on the more typical
stock bases such as Diku.

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

Yup. Quite true on all counts. On a side note, another reason I like LP
style muds, is the amount of flexibility that creators have for
area-building. Of course, this can be both a good, and a bad thing.
> > 	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:

It looks like complete rubbish to me, and I can't even be bothered trying
to work it out. 'vnums' is the only part which makes even a slight amount
of sense.
> 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.

Yup. To further an LP example, it is truly trivial to learn to build
rooms, make NPCs, and create items (even fairly neat ones with nifty
functionality, although the latter can get tricky). It is far from trivial
to make a coherent, fun area that fits into the environment well.

I'm part way through writing a guide to the prefered way to construct
areas for Caffeine's future builders - since things will have to fit quite
strictly into certain places, and although creators are not exactly
'limited', they must fall within the bounds of 'sense'. No areas that just
have monsters chucked in them for instance.
> > 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." :)

<g> I also want to stress the point that there are (at least) two levels
of RP (well, it's a continuous thing, not discrete, but for this purpose,
two levels). Firstly you have those who enjoy playing in a well built
atmospheric game field, where things are 'in character' and make sense.
Then there are those who enjoy high-density roleplaying games. The former
is what I'm aiming for - things will make sense, and be 'in character',
but the game will have something of a 'powergame' slant to it - a bit like
D&D, where players don't roleplay in depth, more rollplay, but without the
munchkinism ;)
> > 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 thats a slightly moot point though - if someone is having all the
problems the original poster describes, (s)he is not really in a good
environment to be building. If the admin run a hacked up base, with poor
documentation, it shows a distinct lack of effort on their part. Of
course, Caffeine is falling apart and not even 1/4 documented right now,
but on the other face of the coin, I do not pupport it to be anywhere near
ready for creators.
> > 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.

Right. Especially with some of the more flexible code bases, or the
possibilities of building something up from scratch. MUSH types work well
for RP or social environments 'out of the box' because of the 'lack of
automation' in many views - more because they're bare bones, and it's hard
to setup things such as time-based combat (hard, NOT impossible, I've
written semi-realtime systems on them in the somewhat distant past).
MUSHcode is pretty horrendous stuff IMHO though (although it has some
niceish string handling stuff).
> > 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.

Definitely. CompSci is a pretty good analogy, as is yours, Adam. :)
> > 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.

Definitely. I built (with the aid of two friends) a (one time) rather
successful MUSH (which pretty much crumbled due to some horrible
circumstances, several of them personal matters, after about 18 months),
and have served as 'RP' admin on two others (only one at the moment, and I
have no interest in any others.. I simply love the theme of Riverworld),
but have also built extensive areas on two LP style muds, one ROM (a long
time ago), and am developing my own (well, not exactly *my* personal own)
LP style mud, with a group of colleagues. Of course, it may just be my
imagination that I put different things into areas than others (more
finickety details); for instance, some creators might describe a bush of
bright red berries, and put in detailed descs of it.. I prefer to go
further, and make it possible to pick the fruit from it, uproot it, and so
forth. This annoyed creators whose areas I had to 'approve' no end at one
> > 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.

It's a horrible task, but quite essential. Having nifty code is no use if
noone understands how to use it properly.

	-Matt Chatterley
"He can't stop us, we're on a mission from Glod!" - Soul Music (Pratchett)

More information about the MUD-Dev mailing list