About the Engine
The idea behind this engine is to create an base for a MUD making it easy for designers to create a MUD using pre-designed modules to organise how the MUD will behave 'under the bonnet.' The engine is being written in Python using. This is mostly because I had a bit of experience with it at the 'National Computer Science School' (http://www.ncss.edu.au.) Rooms will be programmed as Python scripts then imported by the engine.
Python is interpreted, not compiled. This has a few major advantages. The first is that it saves time as we don't have to compile it before we execute the server which makes programming it easier to change a few lines of code then test the server. The second is that the same script can be downloaded and ran on any system as long as you have a working Python interpreter. This means that you don't have to download versions of the server to suit your system.
I plan to have finished the first basic version of the MUD engine by Christmas this year (2005.) Hopefully in version 1.0 of the mud we will have a full working version up for download in our downloads section along with a demo test MUD to show off the features of the MUD
For version 1.1 I hope to include a web (HTTP) interface for the MUD to allow you to log into the web site then interact with 'virtual pages' which will interact directly with the MUD engine. Examples of where you could use this are 'setting up a communications page to allow you to talk in real time with the people currently in the MUD, post and view pages on forums, sell or buy items that are currently being auctioned within the MUD. This could all be done from work or when you don't wish to 'log in' to the mud but just look after your account. This also encourages the idea of making it a more online community then a game. The 'virtual pages' could also be scripted to e-mail a user when the auction goes through. There is no limit behind this idea.
For version 2.0 I hope to build a protocol and client for the MUD allowing users a more friendly environment to play in. This could give detailed information in tags (much like HTML) to split up the information and allow the client what to display and what to interpret. For example you could have a chat monitor which monitors and records all the information that goes back and forth through chat lines, graphics for rooms (linking a page to an image stored on a web server) and a map system that sends coordinates for each room and accurately maps them out as you move through the world. (Unlike the implementation 3K used with portal, this would be supported by the server)
All this sounds cool but let us just worry about version 1.0 for now hey? (we are not even up to 0.1)