Welcome, guest | Sign In | My Account | Store | Cart

Notice! PyPM is being replaced with the ActiveState Platform, which enhances PyPM’s build and deploy capabilities. Create your free Platform account to download ActivePython or customize Python with the packages you require and get automatic updates.

Download
ActivePython
INSTALL>
pypm install grailmud

How to install grailmud

  1. Download and install ActivePython
  2. Open Command Prompt
  3. Type pypm install grailmud
 Python 2.7Python 3.2Python 3.3
Windows (32-bit)
0.1a3 Available View build log
Windows (64-bit)
0.1a3 Available View build log
Mac OS X (10.5+)
0.1a3 Available View build log
Linux (32-bit)
0.1a3 Available View build log
Linux (64-bit)
0.1a3 Available View build log
 
Author
License
GNU GPL
Dependencies
Imports
Lastest release
version 0.1a3 on Jan 5th, 2011

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:

System Message: WARNING/2 (<string>, line 41)

Literal block expected; none found.

staff.addListener(GoblinChiefLogic())

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

Subscribe to package updates

Last updated Jan 5th, 2011

Download Stats

Last month:1

What does the lock icon mean?

Builds marked with a lock icon are only available via PyPM to users with a current ActivePython Business Edition subscription.

Need custom builds or support?

ActivePython Enterprise Edition guarantees priority access to technical support, indemnification, expert consulting and quality-assured language builds.

Plan on re-distributing ActivePython?

Get re-distribution rights and eliminate legal risks with ActivePython OEM Edition.