The BACCHUS project is a project to create a Multi User Environment. BACCHUS stands for Built And Compiled in C++ for Halucinations of Users to be Shared. Most MUD engines these days have a catchy acronym, so I figured why should mine be any exception. Take Advanced Dungeons and Dragons, put it on the internet, soup it up some, and voila - thats pretty much what BACCHUS is.

Anyhow, enough of the jocularity. The project has some serious goals that seem to have been overlooked by many of the classes of MUD engines currently around. Firstly it has to provide a realistic object model. Messages should be produced and received more in parallel with real life so that it might acheive a much higher degree of realism in copmarison to previous engines. A good example of this is the seemingly simple task of walking into a room.

When you walk into a room, you don't see every little detail of the room at first glance, and you may not even notice some of it's occupants if the room is bustling with people, then you may only notice around 20% of the occupants.

And you might also notice what some of the occupants are wearing. If for instance you are a character that has a primary trait of magic, then you might notice other magic casters before you notice other Warriors. If however you notice a warior, then you might also perhaps notice what kind of weapons he is carrying, but those of most note to you would be those that could potentialy do you the most harm, therefore, you would 'see' those first.

The BACCHUS system tries to organise messages so a more complex information processing system is available to do this kind of information filtering and text generation.

One other major strength of the BACCHUS system is it's core and command design. The entire command system is loaded in the form of .so libs in Linux using dlopen(). This means that the entire set of libraries can be reset at run time, allowing upgrading of the system whilst it is still running producing only a minor pause in performance.

The Object Oriented nature of the system, and the passing of a fully encapsulated Message Object to each and every of the command functions allows very easy access to the members that pertain to each command. Which in plain english means that the command set is very easy to make additions to, and extend beyond the original functionality.

The penultimate point in BACCHUS are the plans for the Java tools. BACCHUS will include two main set of Java/Web tools. Firstly the configuration utilies which will autogenerate #include information so that when you compile the MUD you can select exactly which modules you want to include, and what message you wish to customize. Hopefully all but the core modules will be completely plug-and-play. This is a feature that is in the pipeline, and somewhat on paper, but is planned for future versions.

The second set of tools will most probably be mainly web based for ease of the user. They are going to be online building tools that will allow you to edit the content of the MUD from a simple interface on the MUD's webpage. The interface will log in as your character and act like a custom client, allowing you to communicate on the standard MUD communication channels through a comms window, and also, which is the main point of the tools, to create and design rooms/objects etc... online whilst the MUD env is running. This of course means that testing is much easier, as it can be done in parallel with the creation.

Of course because the MUD uses a system of soft property inheritance, very little coding should ever be required to build new objets because hopefully the designer (ed: i.e. ME atm) will anticipate almost all common functionality and write commands for it that can simply be 'plugged' into the object you create. This means the testing of custom commands is already done, allowing a great degree of long term stability to be acheived, and reducing the amount of testing required by the end user or MUD Admins/Coders.

Lastly, and only lastly beccause it's something that I don't envision will be acheived for perhaps another 12 months or so is the plan for a fully distributed system.

I have designed a set of interface levels with a passing similarity to CORBA, and I may even end up using CORBA for the main framework, as it will allow the Java tools to be designed better and perhaps allow someone (maybe even me) to write a design set in GTK+ or QT for X. The levels will allow entire servers to be mirrored, giving a much higher level of stablitliy. Also satelite areas of the MUD can be held on less expensive systems with a lower bandwith to reduce the overall cost of the project (after all, I am just one guy building and paying for the server space). Another side effect of placing the satelite modules and zones on other servers is that if the smaller servers fall over, then all we loose are the non-essential services that can be quickly relocated and rebooted by the Distributed System Framework with only minor upset, although some loss of data will be innevitable withoug incurring higher financial cost or more mirroring (which of course costs twice as much, but may only produce a very small improvement in product performance). There are also plans to allow this system to interface with other MUD/Talker products to produce a 'web' of talker/MUD system more like Casinos on an Las Vegas street where you can simply walk out from one, and into the other. A soft variable store is kept at the center of the system where all information from each system is held so that the user can seemlessly move back and forth between completely heterogenous system without loosing any information that either one needs. This again is a long way off, but is in my mind at least a very important project goal.