LMud

Introduction

LMud is a Multi-User Dungeon (MUD) implemented in Common Lisp. It is both a MUD server and a vanilla MUD game implemented atop the server. It is written entirely in Common Lisp, and relies extensively on the Common Lisp Object System (CLOS) and the two major features of generic function based polymorphic method dispatch and multiple inheritance. It requires a threading system provided by the underlying Common Lisp implementation, as well as a TCP/IP sockets interface. It is designed for Unix-based Lisp systems but could probably be ported to non-Unix Lisps without an extraordinary amount of effort.

Although that previous paragraph sounds very inviting the truth is that LMud is nowhere near ready for playing, much less actual public use. It’s not even playable at all yet, since the command processing stuff isn’t finished. However it is under active development. Please join the LMud-devel mailing list (see below) if you’re interested in helping. I’d absolutely love help on some random part of the system, even if it is as mundane as adding user commands.

The working system will have your usual MUD interface, a prompt where you type such exciting commands as “go north” and “eat mushroom” and “cast ICBM at Moscow”. The command processor is based on that described for CLIM, modified somewhat for use in a nongraphical environment. The command line will use something like CL-Ncurses and Linedit to provide a pleasurable experience to the extent that the client terminal allows it. It will also include a simple interface (ie, single server, chat only interface) to IRC where the player can partake in IRC discussions in a room within the MUD. Creator characters will also have access to a Lisp listener from within the MUD to poke at system internals and add and modify objects and code. The MUD will be persistent, savable into an object database which can then be reloaded and started in another session.

Initially the prototype MUD will have to be developed in ‘pure’ CLOS, although eventually the hope is to have a set of defining macros that wrap up all the messy details (inheritance, locking, etc) within an easy interface for implementing and extending basic MUD objects. Naturally, some objects will require access to the MUD’s internals, but this should be minimized.

The basic structure of the MUD server can be broken down into four distinct components: Driver, Object Infrastructure, User Interface, and Game Implementation. Below is an outline of their design.

• Driver – The Driver provides the interface between the MUD and the underlying system. It handles the object management, threading, startup, shutdown, and persistence. The term ‘driver’ is a canonical MUD term for the implementation basis of any MUD.
  • Execution System
    • Thread Management
      • Spawn Thread
      • Find Thread
      • Pause Thread
      • Kill Thread
      • Locking System
        • Get Lock
        • Release Lock
        • Steal Lock (forcibly take lock from another thread, possibly killing that thread in the process)
    • System Management
      • Initialization (initial startup)
      • Startup
      • Save
      • Pause (pauses all nonsystem threads and game clock)
      • Shutdown
  • Sockets Interface
    • TELNET server
    • Listener (spawned as part of TELNET server)
    • Interactor (spawned by listener, provides client UI)
  • Other Network Protocols
    • IRC, HTTP, et cetera
    • SLTP ‘Secure Lisp Transfer Protocol’ (provides an authenticated interface for transferring Lisp code, could be used for intermud communication or remote programming and debugging)
  • Packaging
    • ASDF
    • ASDF-Install script for fetching required libraries
• Object Infrastructure – The Object Infrastructure consists of the code that provides the basic classes of objects in the system and their interface methods and management.
  • Persistent Object Store (CL-Prevalence et similia)
    • Save Object, Load Object, Save Universe
  • Base MUD Classes
    • Universe
    • Persistable Object
    • Unique Identifier
    • Printable (slots below)
      • Description
      • Noun Phrase
      • Name
      • Detailed Status Info
      • Unreadable Print Form (for debugging)
    • Place (see Game Implementation)
      • Limbo (an vanilla instance of Place)
    • Thing (see Game Implementation)
      • Character
        • Player
        • Nonplayer
      • Object
        • Money
        • Tool
        • Clothing
  • Vanilla Generic Functions for Interaction
    • Getting Information
      • Look At
      • Examine
      • Noun Phrase (for use in automatically generated sentences, eg “I see no NP here” or “The <adj>* NP bars your way!”)
      • Name
      • Detailed Status (eg “broken’, “bleeding” &c)
    • Create Object
    • Find Object in Universe
    • Store Object in Universe
    • Remove Obect from Universe
    • Duplicate Object
    • Destroy Object (remove all references throughout universe)
• User Interface – The User Interface provides the text-based interaction between the human (via the client) and the server/game.
  • Command Processor
    • Command Definitions
    • Interaction Method Wrappers (called by commands)
  • Display System
    • Printing
    • Screen Paging
    • Help
    • Muffles
  • Terminal Handler
    • Line Editing
    • Terminfo (‘what terminak is this?!’)
• Game Implementation – The Game Implementation is where all the fun lies. It provides the various classes and methods which make up the objects that are processed in the game. Rules are not explicitly coded but are encoded in the classes and methods that provide the basis for game objects. The Universe provides the top level container for the game implementation and all game objects are stored within the Universe. The base classes of the Game Implementation are found in the Object Infrastructure where their basic interfaces to other classes and components are implemented. From these base classes the Game Implementation specializes the actual classes that are used in constructing the Universe.
  • Universe (each MUD may need to specialize this for various purposes)
  • Clock and Calendar (specialized per MUD)
  • Things
    • Characters
      • Players
      • Nonplayers
    • Objects
      • Money
        • Coinage
        • Precious Gems and Minerals
      • Tools
        • Weapons
        • Readables
        • Light Sources
        • Containers
      • Clothing
        • Clothes (I suppose the difference between clothes and armor is that one provides an AC increase, the other doesn’t)
        • Armor
      • Comestibles
        • Food
        • Drink
      • Miscellany
        • Rocks
        • Furniture
        • Scenery
  • Places
    • Nowhere (aka ‘Limbo’)
    • Outside
      • Forest
      • Plains
      • Mountains
      • Highway
      • City Street
      • Sky
      • Outer Space
      • Water Body
    • Inside
      • Building
      • Cave
      • Vehicle

The outline above is not a true inheritance diagram because multiple inheritance is not represented. Eg, a magic weapon might be a light source if it emits some sort of visible radiation, and would thus inherit from both the class of weapons and the class of light sources. More facetiously, edible underwear would inherit from both the class of clothing and the class of food, thus supplying body covering (appearance), some measure of defense (against say cold temperature), and some amount of nutritional value (when eaten).

Also, the outline above will probably be moved to its own page soon and changed over time as the system develops.

Mailing Lists

• LMud-devel – Development discussion.
• LMud-CVS – Automated CVS log posting.
• LMud-Announce – Announcements.

Download

There are no released files yet. Please see the CVS repository.

CVS

You can browse the CVS repository or download the current development tree via anonymous CVS.

Back to Common-lisp.net.