=== How to be(come) a DikuMud Implementor - A Short Guide 

Authored by Zarniwoop@Dutch Mountains.  For an updated file check out
http://www.icce.rug.nl/remmelt/imp.html.  Comments/Corrections/Flames
to remmelt@kosterix.icce.rug.nl please.

First of all, we will assume that you have permission to run a mud from your
system administrator.  This article is not about how to persuade such people
to grant you your every wish.  Look elsewhere for that :).  So, you have down
loaded a bare bones DikuMud.  What to do next?  What do you need to know?

1. Knowledge of your operating system.  Hopefully this is a version of Unix,
and if you are able to develop your mud on a Linux system you're in luck.
MERC for instance was developed on Linux and will run almost certainly
without modifications.  More and more coders are able to run Linux on 486 or
a Pentium and more and more muds on the Net are run on Linux.  If you attempt
to run a mud on anything else you will likely get less support from others
(because they run Linux :)) and some of the technical things in this guide
will not apply to you.

2. Knowledge of C (and if you down loaded a mud written in C++, C++ of
course).  This document does not teach you to program in C.  The author does
not /claim/ to be a C programmer (at the most he is proficient in
block-copying).


-- Ok, I got the script running, and tested it by killing the mud process.
   It put the mud right back up.  It works!  I'll start inviting players!

Hold your horses, friend.  Don't you want to put a name on your mud?  Edit
the motd?


-- The what?

Message of the Day, the screen you see after you typed in name and password.
It is the file 'area/motd.are' The screen you get before you typed in your
name and password is probably 'area/greetings.txt'.


-- Ah, ok, I'll call it JoeMUD!  Is that all?

Just some food for thought.  The players you invite are probably not new to
mudding; they have seen all the things your standard distribution has in
other people's muds.  Do you think they'd stay if you don't offer them
anything new?  Would *you* play in a mud which looked exactly like the
previous one you played?


-- Umm..  I need a new area?

Possibly.  You could also think about the general look of the game.  Commands
like 'who' and 'score' are things which are viewed very often.  You could
start with that.  Consider coding with two or three people.  Three have more
ideas than one and get things done quicker than one.

-- Sure, I'll invite three of my buddies to start coding.  And I'll make my
   brother a god and my cousin also a demi-god.

You know, your friends are likely to invite a couple of /their/ friends and
make them gods too, if only because /you/ gave immortal characters out too.
Your wizlist could soon be filled with people who aren't necessarily
committed to the mud; after all, you gave your brother a god because he is
your brother, right?  Perhaps you could give him an immortal if he'd help out
with building the mud.  This will cause less trouble in the long run, and
this way mortals can't ask for an immortal and use the argument 'because HE
got a freebie immortal also'.

-- Hmm.  This all sounds very serious.  I just want to have fun!

Don't you want other people to have fun on your mud?  Of course, in the end
it /is/ about you having fun, but it can't hurt to start acting out /cough/
responsibly.

Chapter 2: First signs of a steady player base

-- I am furious!  I just spent the entire day writing my nifty mob_special
   and Bob overwrote the file I was working in!

Things are likely to happen if you work with more than one person on several
projects at once.  Consider working with rcs (or sccs), a Gnu utility which
can prevent things like this from happening.  And improve between-imp
communications as well.  :)

-- I am also pissed at Mike.  He doesn't want to debug anything anymore and
   is always in the game, chatting with players.
  
When in a group of implementors one person starts playing the popularity-game
and leaves the work to others, trouble is ahead.  It might be the first crack
among the immortals.  Players have a nose for cracks and exploit them.  When
you're a mortal, it pays off to know who's not on good terms with whom.
Gotten into trouble with Imp A?  Talk to Imp B and he'll straighten things
out for you, if only (or especially) because he doesn't like A.  You really
don't want this kind of situation to develop on your mud.  Talk to the person
involved and resolve the situation.  Mortals always side with each other, why
shouldn't Imps do so?  Don't hang out the dirty laundry.

-- This player called Bazooky wants me to lift the level-restrictions on
   grouping we have announced, or he'll leave.  He's very popular too and
   might take a lot of people with him.  What should I do?

This is blackmail, pure and simple.  If you want to give in to this guy you
might as well give him access to your code, because /that/ much influence you
will give him over your decisions.  Think about it.  This is /your/ mud, not
his.  On the other hand, if he presents reasonable arguments you could offer
a compromise.  It never hurts to be open minded.  And lastly, you don't need
to announce every change to the players.  Remember, you are an Imp, and Imps
set the policy.

-- A lot of players have complained that their class is too weak.

Weak in what?  Compared to what?  Usually players complain about their class
when they can't match the damage done by other classes.  Consider the class'
station in life; clerics for instance were never meant to hit hard, but
sometimes players just think they were.  If a class is truly weaker,
offensive and defensive, compared to the other classes, narrow the gap
between them.  That means, either upgrade the weaker class, *or* downsize the
stronger classes.  If you only make classes stronger you will soon find
yourself on an upwards spiral that will lead nowhere.  Have mortals of
different classes discuss this on one of the boards; any reasonable arguments
will crystallize after a while from this discussion.

-- How can I make my mud more appealing?

Make each class sufficiently different from the others.  When adding a new
class try to avoid combining two classes into one.  The Paladin class is very
likely to be just a cross between cleric and warrior.  * Remember that a good
skill does not necessarily involve a player's damage.  * Surprise your
players.  Make them re-evaluate their tactics and assumptions when giving
them new mobiles and/or objects.

-- Where can I go for more help?

Not surprisingly, your best resources are your players.  This brings to point
that you must develop a mutually beneficial relationship with them.  Your
players can offer you insights on the features they would like and how other
muds have solved problems you may be facing at the time.

Your second best resource would be the mailing lists.  If you run a MERC type
derivative (Envy, Merc, ROM, Smaug, The Isles, NiMud), you might consider
emailing merc-l@webnexus.com.