[DGD] Current state of MUD-dom

[David Jackson]

At 03:04 PM 8/23/2004, you wrote:

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

Yes, but the model of "make wizard, you get to build" is still a very valid 
one.  Devote enough of yourself to the MUD, and then you have earned the 
right to add to the MUD.

But, I disagree in that I believe that good coders can have flowing, 
creative inspirations (and often do), and that those with flowing, creative 
inspirations can also code well.

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

I read this, and read it again, to try to understand why I faintly 
disagreed with it (after all, I am the one who said that OLC systems were a 
necessity).

I think that it's just that I don't like the term "artsy fartsies". :)

I believe that a coder can be a content developer as well.  But perhaps 
content developers shouldn't be forced to be coders.

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

This type of team works well if you are running a MUD as a business, or 
your team are all people like you.  However, it has been my experience that 
while everyone has their strengths, and areas that they might excel, they 
shouldn't be pigeonholed into roles that would limit their output in other 
areas.

I think that every manager should have some code development and content 
creation duties.  I think every coder should have the priviledge of doing 
some content creation.  And the content creators should be able to try 
their hand at coding (if for no other reason than it's easier for them to 
be able to add low-level features to their areas).

Yes, pigeonholing is a good word for it; limiting people to roles rarely 
produces a synergistic production environment.

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

I think that this is a fundamental difference in the way that you and I 
might think.  I personally believe that putting labels on people can be a 
bad thing.  It's better to say, "we're all wizards/devs/management", rather 
than create a tiered hierarchy which puts people in their place (and which 
they will rarely try to step out of, for fear of "whip cracking and skull 
thumping").

Unless, of course, it's a job.  And while I respect and admire those who 
have managed to have profitable commercial MUDs, I am almost certainly 
never going to approach my own MUD development efforts as anything other 
than a labor of love.

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

Again, with the labels.  Maybe in your world, geeks are idiot-savants who 
portray one specific skill to a high degree, but are completely lacking in 
every other area.  In my world, geeks are incredibly intelligent, creative 
individuals who are passionate about the things that they do.  In short, 
being a geek can be a good thing.

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

You'd be shooting yourself in the foot.  You might as well use Diku or Circle.

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

Finally we agree on something.  There are quite a few java telnet clients 
available.  And most modern browsers support execution of java applets.

But, we also need an HTTP daemon for the MUD itself, and possibly an FTP 
client.  This would solve many problems.  Tie the MUD to the website, and 
make entry into the MUD from the web seamless, and you have a dream come true.

>>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 think in some cases, we need a ready-to-open game.  This gives a 
structure to build from, and a set of traditions to share.  It also makes 
it easy for the novice MUD admin to get a start.  It's far easier to edit 
areas and make them un-like the original, if you have some "clay to mold 
into shape".

I admit that it's not a truly pleasant picture to consider 10-15 variants 
of a lib, with very few actual changes, running around, but any MUD admin 
worth his salt will take the time to customize and personalize his own.


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

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

Again, I agree.  A 2.4.5 lite that uses a consistent, uniform codebase, and 
which is easy to follow, so that new admins will be able to jump right in 
and editing things.


>>-David Jackson
>
>Cheers,
>Jason D. Bourgoin
>aka Katmandu

Cheers...
David Jackson
aka Anderon/Arkangel/etc. etc. 


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