[MUD-Dev] Team management
talien at toast.net
Thu Feb 27 20:50:38 New Zealand Daylight Time 2003
Peter Harkins posted on Tuesday, February 25, 2003 4:41 AM
> Keeping track of wizards is another matter. We've got over a
> dozen, of varying levels of commitment and experience level. The
> hardest thing to know is what they're up to or if they're stuck or
> slacking. We've got a few newbies who sometimes need hand-holding,
> and they'll sometimes be reluctant to ask for help (though we've
> mostly gotten it through to them that we don't think they're dumb
> for asking questions) or they'll get stuck and disheartened
> without us realizing it. A few of the wizards that are experienced
> coders (and I'll admit I fall prey to this vice) are content to
> theorize and plan systems but not implement them.
Well, first things first:
1) Not everyone should be wizzed. Why would you want someone who
is low on the commitment scale? Coding is something of a job and
while the results are often fantastic, getting there seems
suspiciously like work. Coders must be committed or there's no
point -- it's a volunteer game, so pay's not the incentive. If
you're not committed, then it's difficult to reap the rewards:
satisfaction of a job well done, seeing it enjoyed by players,
admiration by other coders, etc. It's all intangible.
2) Create a sponsorship program. On RetroMUD, nobody wizzes
without playing the game for a substantial period of time. In
addition, our more advanced wizards MUST sponsor them. If you
can't find someone to sponsor you, then no wizzing. This also
means at least one person cares about what the new wiz is doing.
If the wiz fails, it's embarrassing to the sponsor.
> In a nutshell, we have a hard time knowing what everyone is up to
> and if they need help, a push, or something to do. So, on to how
> we've been keeping track of the team.
3) Ask. Once a month, an email goes out to the wizards to see
what they're up to. If there's problems, we step in as
administrators to figure out what's wrong and what needs to be
fixed. Tracking everybody individually is definitely challenging,
so why not the new coders make it easier for you by giving a
4) Wizards should not have total access. By scaling the coding
tasks, they feel less overwhelmed and are less likely to start
blowing your game up by accident (or worse, on purpose). We make
it a point of having a trial period of a few months. New coders
must produce an area during that time or, failing that, provide a
date when they think they'll be finished with it. If they can't
do that, they get removed.
In my experience, a new wizard's likelihood of success or failure is
determined within a week of their wizzing.
Mike "Talien" Tresca
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev