UNNOFICIAL Zen's EnvyMud patch Release 0.87j! (Ultra Envy2.2)
Wednesday, 10th December 1997

Zen             vasc@camoes.rnl.ist.utl.pt



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


-- I have the mud source package.  Now what?

You unpack the package using gunzip and tar.  Then you read the files
in the doc directory.  The README files give you the best quick start
instructions you can ever find.


-- I run Linux and the mud source compiled without errors.  Now what?

You change to the directory with the area-files and fire up the mud
with the command

% ../src/mud-executable &

This will put the mud process in the background and you can telnet to
the (in this case, default) port where your mud now waits for
players.  As you login you see the messages of the system log flash over
your screen.  If you want the mud to dump these messages in a log, you
can kill the process and restart with the command

% ../src/mud-executable >& syslog &

Technically, you have now a mud running.  But what if it crashes?  It
won't go up again.  You want your mud to be up 24 hours a day, so you
need to  run a shell-script as well, that checks if the mud is still
up.  Writing shell-scripts is an almost forgotten art but look through
the sources you down loaded from the Net; there might already be a
shell script there.  If it won't run, try changing your login shell to
the shell the script was 'written in'.  You'll see that in the first
line of the script.


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