[DGD] Current state of MUD-dom

[Jas]

David Jackson wrote:

> I am worried about OLC systems for LP MUDs, although I recognize their 
> necessity.  When I was striving to put up a MUD a few years ago, my 
> biggest problem was content creation (I was making the Melville lib 
> more robust, so I had no time to design rooms, etc.)  I dug around and 
> posted everywhere for builders, and I got a goodly number of them.  
> But, not a single one of them were coders, and as everyone knows, 
> being an LP MUD builder means being a coder (even if not a very 
> innovative one).  Then I was stuck with a dozen or so people who 
> wanted to build, and make content, but didn't know how to code.   
> Suddenly, my time was spent trying to train these individuals, and 
> most of them had absolutely -zero- interest in coding.
>

I think where many LP's go wrong (and always have) is by following the 
old "make wizard, you get to code" mentality.  I'm not just talking 
about LP's *other* people run; games I've been involved with over the 
years (whether merely as a wizard/coder or as a member of the upper 
echelon of the game management / owner of the machine) were just as 
"bad" that way.

A player kicks butt and makes level 20, so now we expect him to be not 
only an old-hand at programming but have some creative or artistic 
abilities as well.  In reality, what makes someone a good player (or 
merely a good macro/mud client operator), and subsequently helps them 
achieve level 20, does not necessarily make them a good coder with 
flowing creative inspirations.

> A good OLC system for LP MUDs will only be useful if it's flexible 
> enough to allow for creative design, and powerful enough to handle 
> multiple edits and re-edits.  My feeble attempts at room-makers / 
> object-makers so far hasn't produced anything that I felt was flexible 
> enough for anyone besides myself to use.


I've come to realize that a text-based game really needs three layers of 
game management / support staff:  (1) administrative types to manage the 
game, keep the other staff on task, and deal with the day-to-day issues; 
(2) programmer types to code the game; and (3) artisitic/creative types 
("artsy fartsies") to provide grammatically-correct and coherent content.

Sometimes these roles can co-exist in the same individual, but my 
experience has been that very few people possess all three at the same 
proficiency levels.  Personally, I tend to be especially strong on item 
one, of average capability on item two, and well-below-average on item 
three.... except in rare moments of creative genius, usually while under 
the influence of whatever the chemical-du-jour was in college or after 
extended periods of sleep deprivation. 

For games I run, knowing my own strengths and weaknesses, it's important 
for me to have at least one or two hot-shot coders to help me in areas 
I'm weak in and lots and lots of artistic/creative staff to add powerful 
content to the cool technologies the gearheads put together.  When it 
comes to whip cracking and skull thumping, they leave that to me, as 
handling the day-to-day stuff is right up my alley.

> For me, in the vein of non-commercial MUDs, it's a balancing act.  You 
> have to have enough content to attract players, to establish a player 
> base, and hopefully from that player base will emerge some builders.  
> Who will keep adding content, while you can devote yourself to 
> maintaining the innards of the lib.
>

Hopefully from that player base will come some of each of the three 
types:  administrative managers, programmer/coders, and content 
producers.  It might be unrealistic to look for all three qualities in 
high levels within one specific candidate, considering how MUDS are 
historically geek-oriented player based.

> 2)  We need OLC creation tools, to inspire non-coders to become 
> builders...


I think this should be done at the game library (mudlib) level, maybe as 
an optional include libary or set of daemons or command objects.  That 
way, games that opt to not give coding privileges to any of the players 
don't have to decontruct anything to start with.

> 3)  We need tools to link the web browser to the MUD, so that getting 
> into the MUD can be seamless for the novice...


Java or Javascript applets may be the way to go here.

> 4)  We need a stock lib with enough playable content so that the 
> average guy will be inspired to set up a MUD in the first place...


While I'm personally against the idea of building and releasing a 
ready-to-open game (like the venerable 2.4.5 mudlib, ala Genesis), I'd 
have to agree that the stock libraries provided with game drivers need 
to be slightly more substantial than they are currently.

I think the old TMI-2 mudlib (for the MudOS driver) was a decent example 
of what I'm talking about.  It wasn't really ready to open the second 
you untarred it, but it had enough structure to encourage a programming 
team to build the house from something more than just a concrete foundation.

I don't think any of us want a fully-fleshed out game; we just want 
something more than theories about building skeletons from molecules.

> I think the original idea for the 2.4.5 lib is a valid model for 
> today; players play until they exhaust the content, and once they do, 
> they are then in charge of creating new content.


I think I'd like to see something closer to a "2.4.5-lite" kind of 
mudlib than a ready-to-open game.  I liked what I saw with the Melville 
0.9.2 library for DGD, if it was taken a couple steps further.

Then again, I can't even count how many "new" LPMUDs I logged into over 
the years, only to be hassled by Harry the Affectionate or Trixie the 
Harlot!

Harry the Affectionate says, "Why did you snicker, Katmandu?"

> -David Jackson
>

Cheers,
Jason D. Bourgoin
aka Katmandu

_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd