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)
- 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
- 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
- Miscellany
- Places
- Nowhere (aka ‘Limbo’)
- Outside
- Forest
- Plains
- Mountains
- Highway
- City Street
- Sky
- Outer Space
- Water Body
- Inside
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
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.