Getting started - Step by Step

To get started with DikuMUD, you're going to need a few things.

First of all, you're going to need a host machine to run it on. It's easiest if this is one you own, but it's also ok as long as you have permission. Running a MUD means that there will be network connections to the machine and the to do that it's going to have to listen for network traffic. Those owning the machine might not take kindly to allowing these network connections. There's security risk involved, and there may be a cost involved for the traffic itself.

The MUD will run on a wide variety of platforms, but is written using (distribution), a LINUX host.

==== Pre-requisites ==== - stuff that has to already be installed on the platform include

   gcc/g++
   flex/bison (sudo apt-get install bison flex)
   boost devel (sudo apt-get install libboost-all-dev)

For CentOS:

   sudo yum group install "Development Tools"

should do it, but you may need:

   sudo yum install boost-devel flex-devel

To download a copy, you can pull down a current copy of the software from GitHub with:

   git clone https://github.com/Seifert69/DikuMUD3.git

While a lesson in using git is beyond the scope of this document, you're probably going to want a version control system at some point, and git is probably the most widely in use at this point. You could just download it in a package from GitHub and make a directory to unpack it to, but this will download the current version into a 'DikuMUD3' directory, create the local git repository, link it to the master on GitHub and give you an unpacked directory of files.

Now, what I'm about to say is dirty, and you shouldn't do it...but this document isn't meant to go into the nitty gritty of separating your development environment from your test and production environments, setting up a pipeline to configure development code and keeping pristine environments...this is the wild, wild west, and we're just going to run the MUD from your local repository....Just remember that I told you not to do this, so later when you're cursing me out for making your setup all messy as you're making copies of config files and figuring out what you should replicate and what you shouldn't, you can hear me saying 'I told you not to' in the background.

What SHOULD you do? Set up a production directory to copy this clone to that you'll run the MUD from, and figure out a good work pattern for pushing out production code. Make changes under source control, and decide if you're going to be a contributor to the main project. Separate the config data from the dev environment to the production one and protect any secrets from being accidentally pushed up to the main. In the end, you'll save some heartache. But if you just want to get started today....

Compiling the MUD

Now on to getting it up and running. What you have is a bunch of files, but what you want is an up and running world. That means it needs to be compiled to run on your chosen platform and linked in with all of the local support libraries. There's a method to this madness.

How to build & launch

First build the binaries:

   cd vme/src/
   make all # 

There is a flag (-j8) in the Makefile to compile on 8 threads in parallel. If you run into errors with the compile and you're on a machine with limited resources, this may cause a race condition during the compilation. Edit Makefile and remove this flag if the compile starts complaining about errors that should be reported to the compiler developers.

Make sure .def files are pre-processed:

   cd ../etc/
   make all

Then compile the zones:

   cd ../zone/
   ../bin/vmc -m -I../include/ *.zon

Running the MUD

Now you're ready to launch, the dev likes to four tabs in shell:

   cd ../log/                 # Do this before you start the tabs.  Git docs say to run from bin, but if you do, that's where it will log to.
   ../bin/vme                 # tab1
   tail -f vme.log            # tab2
   ../bin/mplex -w -p 4280    # tab3
   tail -f mplex.log          # tab4

There's a number of ways to get multiple tabs - from multiple Terminal windows, to using screen if your host environment isn't running a graphical windowing system.

Tailing the logs are optional steps - you'll definitely need tab1 and tab3 for your MUD to run.

You can also run these commands in the background using

    cd ../log                                              # So running the MUD logs to DikuMUD3/vme/log
    nohup ../bin/vme > vmenohup.log &                      # This starts the MUD engine
    nohup ../bin/mplex -w -p 4280 > mplexnohup.log &       # This starts a Websockets listener on port 4280 that will connect to your MUD

This will keep the MUD up and running in a background process even if you terminate your login on your host. Note that if you DO log out with the MUD running on nohup, your process will no longer be retrievable to the foreground (The & sends the process to the background, retrieved with the 'fg' command) on subsequent logins, since your next login shell will not be the parent. You may have to KILL the MUD to stop it if you can't log in and shut it down.

If you run it from tabs, terminal windows, or just get it back with fg you can terminate the running programs with Ctrl-C in the appropriate shell.

You can also launch a telnet mplex using e.g. mplex -p 4242 And then telnet localhost 4242. But telnet is best for debugging

Connecting to the MUD

DikuMUD3 comes with a web front-end client. To open the client directly if you're on a windowed distro:

   cd ../www/
   firefox index.html

If you're going to be hosting the MUD, you should copy the files in ../www to your web hosted files directory so they are available to your users at your web address. (If you own the box, probably /var/www/html or something similar).

If you're using the web client, the distributed version doesn't point to your MUD, it points to the author's. Edit the index.html file and find all of the host references (including the ones in the urls like www.valhalla.com) and replace them with your fully qualified domain name, IP address or localhost and set the port to match mplex (4280 if you used that).

Once you load index.html in Firefox (or browser of choice), you'll have the quick link to connect or can manually input a websocket host to connect to. Press connect and you're connected to a game from the 20th century with 21st century technology!