An LPMUD is made of three major components:
- The driver, which generates the environment of the MUD and interprets the internal code. The driver is traditionally written in the C or C++ programming language. It generates the functions required for network communications over a telnet port and loads all objects currently in use on the MUD.
- The MUDlib, short for MUD library, which is a collection of base objects that forms the structure and mechanics of the MUD. The MUDlib is always written in LPC. In addition to objects used for inheritance, the MUDlib also contains commands that may be invoked by the users and daemons that perform maintenance functions for the MUD.
- The domain or realm files, which are the objects that are seen by the users (or players) of the MUD. These objects are also written in LPC. Common types of objects in this section are rooms, mobiles (or mobs for short), and items (including weapons, armor, food, and drink).
LPMUDs are most commonly found on UNIX-based systems, although many drivers can also be compiled on other systems as well (including MSDOS). However, the network drivers on MSDOS are traditionally not as robust as those on a UNIX system and the 8.3 file system mandated by DOS often caused a problem with the distribution files, which were designed primarily on UNIX systems.
LPMUDs offer these benefits over other types of MUDs:
- The workings of the MUD can be changed on the fly. Only changes to the most fundamental base objects actually require a reboot of the MUD. This benefit exists because the MUDlib, which controls the mechanics, is separate from the driver.
- The mechanics are easily modified. Especially in a well-organized MUDlib, a change can be implemented quite easily by simply making a change to the object containing the mechanics and compiling it. Also, since the system operates in a similar manner to a UNIX file system, it is a moderately simple matter to test the change before making it live.
- Most of the time, an error in LPC code will not cause a complete crash of the MUD. Instead, the driver will generate a runtime error to note the failure of an expression, allowing a coder to track down the code causing the error.
- Building basic domain objects in LPC is very easy, generally amounting to little more than filling in a template. Some understanding of the language is required, but it is very easy to teach. Once building the object is complete, it is a simple matter to take a look at how it works simply by compiling and loading the object.
Unfortunately, LPMUDs also suffer from a few drawbacks:
- Every object in use on the MUD must be loaded into memory. If you have an active MUD with limited memory resources, this can result in the necessity of rebooting the MUD on a regular basis. Many advanced MUDlibs have created a memory reclamation daemon to avert this. However, especially on MUDs with a large player base, the effectiveness of this daemon can often be limited.
- Although LPC is very similar to C, the differences can often be very confusing. The process of inheritance is markedly different than what one might be used to in C++ classes. It also greatly simplifies the process of creating arrays and the like, leading to sloppy coding which causes unnecessary memory usage (which leads to the problem listed above).
- Many older MUDlibs relied on a very simplistic security system to keep creators from accessing things they shouldn't. Unfortunately, given the nature of the LPC environment, it was often possible for a creator to make an object to perform an action that (s)he was not able to do him/herself. This has been addressed in some newer mudlibs, but still remains a problem for many MUDs.
- Since the LPMUD drivers generally use a line-input method for input (something which is common for basic telnet applications), advanced text editing tools like vi and emacs are not available to developers within the MUD environment. Although it would be possible to give all creators a shell account, maintaining such a system without compromising security would be very time-consuming. The only editing tool available within the MUD environment is the ancient command-line editing tool, ed. Although ed can be a very powerful tool, it is often somewhat cumbersome, especially to inexperienced users. The developers of TMI-2 created an LPC FTP server to relieve this problem. However, the server is very basic and often prone to errors. The most common method of coding, therefore, is using a text editor on the creator's local computer and then using cut and paste to get the text on the MUD.
Unlike the Diku and Aber derived MUDs, LPMUDs often have very little in common mechanically. Since the system is so easily customizable, many administrators have imposed their unique vision upon their MUD. Variety is, of course, a good thing. However, it also means that most MUDs have a steep learning curve as a new player must learn a unique combat, ability, and navigation system. Many MUDs have implemented a newbie zone or something of the nature to act as a basic tutorial on how to get around in the world.
One interesting functionality available to LPMUDs is the Intermud protocol, which allows MUDs running this protocol to communicate with each other, permitting common chat channels, remote finger and who commands, and gathering basic information about another MUD. This functionality made it much easier for creators on different MUDs to share information, support each other, socialize, and discover other MUDs they might find entertaining.
A good source of information on LPMUDs is http://cie.imaginary.com. This site is maintained by a few people who remain active in administering and developing MUDs and MUD code, including George Reese (Nightmare/Foundation II) and Tim Hollenbeek (Lima).