Skip to main content
Join the official 2020 Python Developers SurveyStart the survey!

A Python MUD server

Project description

grailmud is a MUD server written entirely in Python (though optimising bottlenecks in C, and a more restricted language for builders and untrusted coders to work in are options which will be considered in the future) with a loosely coupled design between the game logic and the display logic for players, as well as a more loose than is traditional coupling between object logic and object state. grailmud also leverages Twisted, pyparsing and durus, so a bare minimum of low-level (networking|parsing|serialisation) code has to be written.

These points make grailmud different from other (aspiring-to-be) production-ready MUD servers in this area (ie, MUDs written in Python). PythonMOO, POO, et al, have used a custom scripting language for programming game logic in, wheras grailmud uses Python for this task. Buyasta, wordplay, et al, have a tighter coupling between display and game logic. nakedmud reimplements a -lot- of stuff in C (ick!) which is already done in some library, or which can be done painlessly in Python. There are many, many hackish little MUD servers written (I wrote 2 or 3 of them before I got the design more-or-less Right), but none of these are really suitable to build a whole game in.

One result of the decoupling of display and game logic is that the difference between player avatars and NPCs becomes the ‘controller’ (the object that receives the object’s events and acts upon them) for players is linked to a socket (via the bowels of Twisted) and a few extra instance variables and methods on the player (eg, the player’s password hash, and the method to take a line of input and dispatch it to the appropriate command). In more tightly coupled implementations, players and NPCs are different beasts entirely, possibly resulting in ridiculous duplication like different ‘take away X hitpoints’ routines for each type, which should reside in a common base class.

Decoupling object logic and object state results in promoting ‘controllers’ (or as they ended up being called in the codebase, delegates, in the Self tradition) to first-class objects which can be added or removed from objects at will. So if you want a staff to suddenly start acting like a goblin chief, it becomes as simple as this:

staff.addListener(GoblinChiefLogic())

rather than having to delve into the StaffObject’s code and add the goblin logic in there.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Files for grailmud, version 0.1a3
Filename, size File type Python version Upload date Hashes
Filename, size grailmud-0.1a3-py2.5.egg (80.7 kB) File type Egg Python version 2.5 Upload date Hashes View
Filename, size grailmud-0.1a3.win32.exe (101.1 kB) File type Windows Installer Python version any Upload date Hashes View
Filename, size grailmud-0.1a3.zip (114.0 kB) File type Source Python version None Upload date Hashes View

Supported by

Pingdom Pingdom Monitoring Google Google Object Storage and Download Analytics Sentry Sentry Error logging AWS AWS Cloud computing DataDog DataDog Monitoring Fastly Fastly CDN DigiCert DigiCert EV certificate StatusPage StatusPage Status page