[MUD-Dev] Questions about my MUD design

[kressilac at insightbb.com]

--<cut>--
Note: This message was written via the list web archives.  There is
no guarantee that the claimed author is actually the author.
--<cut>--
Original message: http://www.kanga.nu/archives/MUD-Dev-L/2002Q4/msg00568.php

On Wed, 11 Dec 2002 22:17:03 -0800
Peter Harkins <ph at malaprop.org> wrote:
> On Wed, Dec 11, 2002 at 12:32:26PM +0100, Christer Enfors wrote:
 
>>   2) As is probably obvious to most of you, this is one of those
>>   over-ambitions projects that are never finished. I know, I've
>>   been there before. What can I do to overcome this obstacle? One
>>   thing I will probably do is aim for an early public alpha, when
>>   only the most basic features are implemented. If I get even
>>   just a few players into the MUD, I think their feedback will
>>   help keep me motivated. Or would that be a bad idea? Will I
>>   just make a poor first impression by allowing players into a
>>   half-finished MUD?

> It's also frustrating that the people that tend to be attracted to
> coding on an unestablished mud are the ones either with no
> experience at all or very odd ideas.

I never really realized how many new programmers there are until I
(along with others) formed a company and announced a MMO game.  Of
all the resumes I have from job seekers, 90% of them are from people
with very little prior game development experience.  Its hard to
tell them no because you don't have the proper mentoring structure
setup in your organization.

> All things considered, I'd say that opening for alpha was a good
> thing for us. The infusion of talent (and warm bodies to talk to)
> is helpful and is what has kept the project going. The feedback
> is, in some ways, really a lifeline. It's frustrating to have to
> spend time on clueless or rude players, but I try to look at it as
> good practice for when we launch. (It's not always easy -- just
> had to ban our first griefer for emoting a rape scene last night.) 
> Recruitment of wizards is really, really good, but I wish we'd
> known a while ago how to better separate out the people who'll
> require a lot of handholding and/or disappear entirely after a few
> weeks.

When I was working on MozartMUD and later, Gateway to Karnos, we
dealt with new players by appointing one or two middle level
immortals to the task.  Luckily we had a very nice woman on our
immortal staff that took the the job with enthusiasm.  She basically
created the position for herself and it freed content implementors
and coders from the task of inviting players into the game.  Besides
she had far more people skills than all of us combined.  It proved
to be a very worthwhile position for her and the future of the game
as a project.  Veterans would see us an leave like you mentioned,
but some would stay as well because she gave them such a positive
impression about the game.  Even when someone took a look at us and
decided we weren't feature complete, they rarely left with bad
thoughts about the game so we never had really bad press issues to
deal with.

As for the disappearing act that immortals can show or the
handholding, again we used a hierarchy.  We created immortal levels
surrounding the functionality of our OLC commands.  When you first
became an immortal you were given a set of rooms, the next step was
objects and after that mobiles.  Once you were done with all of
those levels you were given commands to zone your area and submit it
for review by our content admins.  This did two things.  First it
weeded out the immortals that did not want to work for the game.
The only way to the higher levels was to get content built for the
game.  Its how we judged lower level promotions.  Second, it removed
much of the handholding from the higher level immortals who were
typically programmers and content implementors.  All in all it
worked well, as long as we kept the ranks populated such that any
one part of the workflow didn't become a burden to a single
immortal.  By the time immortals were ready to be promoted to higher
levels, the top immortals had adequate interaction time with the
immortal, had been able to judge and see his/her sense of judgement
when dealing with players, and had time to assimilate him/her into
the overall vision of the game.

The only exceptions we made to this policy were for coders that
either came recommended by another already established coder.  All
content positions were generated from within and pulled from the
player base.  When it came time for us to allow a new coder to
participate in the game, we typically started them off working on
something that wasn't core to the game, a mobile behavior procedure
or something similar that once implemented would have a minimal
effect on the game should it not work properly.  When they
demonstrated an ability to program relatively bug free code, bigger
assignments came until finally, they were a full part of the code
team and they could pick and choose what they wanted to do along
side us, though always marching towards the shared vision.

Derek



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev