Bluemud is an ambitious project to develop a multi-layer mud server that gives in-game coders the tools they need to build truly unique and complex online environments.
Bluemud has a multi-layer architecture that allows admin to replace layers without re-writing the entire system.
Our ideas come from experience with LPMUDs and also other projects such as POO and Varium. Bluemud will share many characteristics with LPMUDs--moreso than MOOs and MUSHs, though we don't see any reason the Bluemud base couldn't be used to build MOOs and MUSHs.
The Bluemud architecture is composed of four layers: driver, mudlib, worldlib, and world code. The Bluemud project is focused on building a driver, a mudlib (or more than one), a sample worldlib and some sample worldlib code. We will provide these in two separate packages:
Terrible depiction of bluemud architecture layers:
- OS - ^ ^ | | v v =---- DRIVER -------= c (base server) ^ . . . . . . . ^ . ^ | . . . . . . . | . | v . . . . . . . v . | =---- MUDLIB ---= . | python (theme, superclasses, mechanics) ^ . . . . . . . ^ . | | . . . . . . . | . | v . . . . . . . v . v =---- WORLDLIB -----= python (hundreds of item classes and such) ^ . . . . . . . . . ^ | . . . . . . . . . | v . . . . . . . . . v =---- WORLDCODE ----= python (your world)
This is the engine of the system. It handles the event queue, handles incoming connections, handles incoming data, provides interfaces to the file system, handles security, handles logging, handles bootstrap, handles configuration, handles persistence, and tries to abstract the mudlib from the operating system.
It's currently coded in Java with Jython. At some point this may be re-written in C with Python extensions.
All the driver code is located in:
The org.bluesock.bluemud.driver package contains the driver code. The org.bluesock.bluemud.lib package contains the base classes which are subclassed in the mudlib.
The mudlib forms the base classes for an actual mud. There would be mudlibs per theme (sci-fi mudlib, fantasy mudlib, ...) and also by MU* type (MOO mudlib, MUSH mudlib, ...).
This layer contains the superclasses that have the functionality specific to the mud they're working on. This is where the mud theme is likely to be defined as the theme will affect things like combat, magic (or lack thereof), character classes, races, guilds, occupations, land types, armor, weapons, statistics, skills, ...
The mudlib also holds a series of utility functions for handling text formatting, pretty-printing, interfacing with the driver, and a series of defaults for things like login and commands that will likely be used across the board on any mud.
The mudlib is carefully built so as to allow maximum sharing between different mudlibs centralizing the differences into a few key files. This will make creating new mudlibs without re-inventing the wheel much easier.
With this architecture, the mudlib will be the brunt of the code in the system. It'll be huge.
Python.
./code/mudlib/
This is the layer that would hold Controllers and things that override the default things in the mudlib (as specified in the aliases.conf file). If you had your own login controller, it would be defined here, for instance.
This is also where you define all your item types. Torches, armors, weapons, objects, ...
Python.
./world/domains/lib/
This is where the world is defined. Places to go, NPCs to meet, items to wear, monsters to defeat, quests to solve....
Python.
./world/domains/*