@@SECTION Setup Setting Up DGD

The first step in learning any new programming language is to set up the tools. For most languages, that means the compiler or interpreter and possibly a debugger. For DGD, that means setting up the DGD driver, sometimes called the DGD server or DGD interpreter.

You'll need to download the DGD driver from the internet unless you have a copy on other media. Make sure to get a recent copy of DGD, version 1.2 or later.

@@SECTION Setup.Installing Installing DGD

The DGD driver changes a lot from year to year, so any instructions on installation may be out of date. These instructions are valid as of early 2005 (DGD version 1.2.101), but if you have any problems with them you should try a Google search on "DGD", "compiling DGD" or "installing DGD" to find out more about the latest instructions. First, and more importantly, you should read any documentation that comes with the package you downloaded about how to install it.

It's possible that you'll be able to find DGD in an easily-installable form like RPM files or FreeBSD's ports tree or a self-extracting archive with an InstallShield installer. The usual choice, though, is to download a simple archive file (.zip for Windows, .sit.hqx for Macintosh and .tar.gz for Unix) and install it for yourself.

To install DGD, you'll need to compile it. This means you'll need a compiler, such as GCC on Unix, CodeWarrior on the Macintosh or Visual C++ on Windows.

I'll refer to the directory you installed DGD into as dgd in this section. So if you installed DGD into C:\PROGS\DGD then the path dgd/src would be the same as C:\PROGS\DGD\src.

First, look in dgd/doc/Platforms. You'll see a chart like this:

DARWIN          Darwin/OS X.  Also works for NetBSD, FreeBSD, OpenBSD and Linux.
LINUX           Older versions of Linux.  Copy src/host/Makefile.sysv to
                src/host/Makefile.
SUNOS4          SunOS 4.x.
SOLARIS         SunOS 5.x.  In src/Makefile set LIBS to -lsocket -lnsl.  Older
                versions also require src/host/Makefile.sysv to be copied to
                src/host/Makefile.
DECALPHA        DEC Alpha.  Copy src/host/Makefile.sysv to src/host/Makefile.
BEOS            BeOS.  In src/Makefile set LIBS to -lbe -ltracker, and copy
                src/host/Makefile.beos to src/host/Makefile.
WIN32           Windows NT or Windows 95.  Follow the instructions in
                src/host/pc/README.
MACOS           Mac System 6 to 9.  Follow the instructions in
                src/host/mac/README.
GENERIC_BSD     BSD Unix.
GENERIC_SYSV    SYSV Unix.  Copy src/host/Makefile.sysv to src/host/Makefile.

You'll need to follow the instructions for your platform. For instance, on Linux you'd want to copy dgd/src/host/Makefile.sysv to dgd/src/host/Makefile. For Macintosh or Windows you'd want to read the appropriate README file and follow its instructions. It'll tell you where to find a project file for DGD for your compiler. Normally those files ship with DGD, so the README file will just tell you the right subdirectory to look in.

If you have troubles compiling the server, you can ask the DGD mailing list for help. Please try a few web searches first to see if your problem is already known, and if it's in the DGD mailing list archives. You'll always look better asking questions on the list if you've obviously made an effort on your own behalf first. It makes people more likely to help you. The DGD mailing list is a very powerful tool, and has many of the most competent DGD users in the world reading it regularly. Try to be respectful of it, so that its readers will, in turn, respect you.

To find the DGD mailing list, try doing a Google search for "DGD Mailing List". You should be able to find a page that will tell you how to sign up for that list, and how to find the old archived messages from the list.

@@SECTION Setup.RunKernel Running the Kernel Library

You'll need to run the Kernel Library to do most of the exercises in this book. A copy comes with every copy of DGD. So if you've already installed DGD, you've already installed the Kernel.

Your copy of DGD came with a file called mud.dgd. Look in DGD's directory and you should find it pretty quickly. You'll need to edit that file before you can use it.

In mud.dgd, you'll see various lines assigning values to various names. One line will say something like directory = "/home/dworkin/dgd/mud". You'll need to change that path to the absolute path for the directory where you installed the Kernel Library. That's the mud subdirectory of DGD. For instance, if you installed DGD into ~alan/dgd on your Unix system, you'd change the filename in quotes to /home/alan/dgd/mud. If your DGD directory wound up in C:\Programs on your Windows machine, you'd change the line to directory = "C:\Programs\DGD\mud". The end of the line, the part surrounded by stars and slashes, is a comment. You can ignore it or remove it entirely (including all the stars and slashes).

Note that the path has to be an absolute path. That means you have to start it with a slash on Unix. You'd use a backslash or a drive letter on Windows. But you can't just start it with the name of the directory where you installed DGD and leave out where on the drive that directory is, that won't work. No relative paths. So /home/bob/dgd/mud and C:\Programs\DGD\MUD are fine, but DGD\MUD isn't.

Once you've done that, you'll need to run the DGD program. If you're running on Windows and you compiled with Visual C++, you can run dgd by double-clicking it and then choose the mud.dgd program from the menu. If you compiled on Unix or used the Cygnus tools on Windows, you'll need to run the program from the command line, with the .dgd file as an argument. For instance, from Unix, in the DGD directory, you might type ./bin/driver mud.dgd. Note that while Win32 permits you to run DGD from the command line, you won't get proper error output if you do. So it's recommended you run DGD and then choose a configuration file from the menu instead.

If you've done it correctly then DGD will print messages about what version you're running and various other things. Then nothing visible will happen. If you're not used to running your own MUD server, this can be a bit disconcerting. Don't worry, it's normal. In fact, if DGD stops and goes back to the command line (usually with an error message), that would be abnormal. The messages DGD prints will look something like this:

Jan 29 16:09:52 ** DGD 1.2.73
Jan 29 16:09:52 ** Initializing...
Jan 29 16:09:53 ** Initialization complete.

Once you're running the server, you'll need to telnet to your MUD. That requires a telnet client or MUD client. On Unix, the simplest method is to run telnet from the command line. The syntax is simply telnet <host> <port>, where host is the name or IP address of the host you're telnetting to, and port is the port number. If you leave off the port number, telnet will use port 23 by default, which is almost never what you want for a MUD.

On Windows, you'll want to download a MUD client like zMUD or a terminal program like TeraTerm or Putty. Do a web search on one of those names, or just on 'Windows terminal program' or 'Win32 MUD client' or similar.

Telnet back to your own machine, on the port where DGD is running. Normally your machine's address will be 127.0.0.1 when you telnet to it, which is called the localhost address. The Kernel Library will usually start its telnet server on port 6047, though you can check the file mud.dgd to be sure. You'll want to telnet to the telnet port, not the binary port, from that file. Your telnet program will attempt to connect to the wrong port if you don't tell it the correct port number.

The Kernel Library will ask you for a login name. Tell it you are admin. Then choose a password for this account. The admin account is special, and gets a lot of privileges that other accounts don't — you won't be able to do many of the exercises in this book except with a privileged account.

@@SECTION Setup.KernelOverview An Overview of the Kernel Library

To use the Kernel Library, you'll need a quick overview of what you can do with it. This entire section applies only to the unmodified Kernel Library -- any of this can be changed. But when you start, this section describes how the interface works.

You can quit by typing quit, which is useful to know. You can chat with others on the server by typing say, a space, and what you want to say. This will send the message to everyone else currently logged in. You can type people to see who is currently logged in. All of these operations can be performed by any user.

The admin user can also type shutdown to shut down the server. He can also use the "code" command, which you'll learn about in the next chapter.

The Kernel Library actually has a number of other commands, most of them only for administrators, not players. Those will be covered later as we need them.