[MUD-Dev] Re: A little help

[Ling]

Please attribute manually if your emailer doesn't.

On Tue, 29 Sep 1998, Marc Bowden wrote:
> [Ling]

> > One mud I visited admitted they used an internal numeric representation
> > for 'wiz levels', not because it is actually useful but so they can award
> > them to wizzes for actually doing something.
> > 
> > I personally find this distasteful, I hope never to use anything like
> > this but deep down, I know this horrendous Victorian approach works. 
> 
>   Yeah, well.
>   Your cast members are no different from the players in that they need to
> feel like they've achieved something, and need ways to benchmark those
> achievements. If they don't they drift lethargically away, or turn to
> more anti-social activities.

I do think the current model flawed.  As stated a long time ago here on
this list, players get a shock to the system when they become a member of
staff.  Having reached that desirable status, they find they're no longer
allowed to interact with the players.

In addition to the traditional constructing a new area, staff are expected
to assist in the day to day running of the game.  By this, I mean get
involved in playing npcs, twiddle with things and abuse the game.  Within
reason but I am going to allow plenty of freedom.

I also have an evil log system that randomly snoops on people.  Yes, it's
immoral.  Yes, I'll have a warning badge upon login complete with excuse
that it's to maintain high standards.  Which I hope it will.  Does it
actually exist?  If it does, do I read any of the logs?  That's another
matter entirely. :)

>   What are people finding is the life-cycle of the average immortal, etc?
> Over the last ten years, my perception of it has dropped from 18 months to
> closer to 6; why work your way up somewhere when you can start your own?

Six months of vague productivity is enuff for me. :)  I'm treading in the
tracks of Nathan's Physmud++ model.  The staff write areas by adding
things here and there as if it was Lego.  I only really want the staff for
their ability to set up new missions and to help run them.  My approach to
room descriptions is: rooms contain stuff.  The description is generated
by the character and modified by the character's status and attributes.  I
thought this was a kinda obvious 'next step'. 

Reasons include attempting to make the learning curve a mild bump, not
being allowed to code proper means no legacy code to maintain if the
member of staff walks and finally, probably the most important, instant
gratification of 'drag and drop' (albeit via text).  A side effect is that
the staff don't actually gain any knowledge of how my mud works on the
code level.

Hopefully, the magic and illusion that the mud runs on a supercomputer and
is an incredibly deep and complex piece of software will still stay even
upon reaching staff status.  I think the perceived if not actual smooth
operation of the mud is of utmost importance, even to the staff. 

  |    Ling Lo (fish)
_O_O_  Elec Eng Dept, Loughborough University, UK.     kllo at iee.org