CoolMUD? Cool++?

CoolMUD is an object oriented MUD server with a lot of nice features, like being able to connect several seperate MUDs running on different machines together seamlessly. It was originally written by Stephen F. White, the creator of MOO (from which LambaMOO was forked). It is now maintained (somewhat sporadically) by Robin Lee Powell.

Cool++ is a refactoring and rewriting of CoolMUD in C++. It is being written by Ryan Daum, Norman Nunley Jr., and Per Vognsen.

The SourceForge page for Cool++ is here.

What's a "MUD"?

One definition of a MUD is that of a multiple user adventure or role playing game. That is not really our goal, though Cool++ could be used for it. We think "MUD" means more than a kind of game, and we are only peripherally interested in the gaming aspect.

Think of an object database. Now think of a scripting language and its virtual machine. Now think of a multiple user chat system. Now combine all these together.

Imagine being able to have several dozen programmers all connected to a running image of objects which they can extend at runtime, adding methods and behaviours. Also imagine that these objects simulate or behave like some real world objects in a running real-time dialogue. That's what we have in mind.

For more discussion about MUD development in general, go to Agora.

What are your goals?

• Using standard types and libraries - By using the STL (standard template library) we avoid having to maintain and develop custom data structures and algorithms, and we can leverage a large amount of 3rd party code.
• Modularity - By refactoring CoolMUD in C++ we hope to end up with some generic components suitable for the construction of custom configurations and even new servers. It also makes it much easier for us to add new features.
• Taking advantage of features of C++ - Certain things are difficult to do in C that become much easier in C++. Reference counting, for example, becomes much easier with a reference counting smart pointer. The same goes for string interning, storage of variable types, and other things that the CoolMUD server relies on.
• Optimization - During refactoring we have already discovered many areas where our C++ version performs better than the original server. This is mainly due to the extensive type refactoring (replacing linked structures with vectors, for example) and the leveraging of C++ polymorphism where switch statements would have formerly been used.
• New features - See below.
• Fun - The most important.

What are some of CoolMUD's features?

• Embedded interpreter - CoolMUD has a fully object oriented scripting language wired right into the server, with which almost all behaviour of the MUD is written and extended on the fly.
• Object-based - Like LambdaMOO and some other MOO-like servers, CoolMUD uses a prototype-inheritance, object-oriented object model similar to Self, NewtonScript, etc. For a multiple programmer environment where objects can be modified on the fly in realtime, there are some serious advantages to this approach.
• Cuteness and simplicity - There are many other good servers. ColdMUD was a kind of successor to CoolMUD that is still being maintained. LambdaMOO has made some technical progress in the last 10 years. However, we liked the CoolMUD source because although its quite featureful, its design was quite simple and cute.
• Disk based - Every MUD server requires a persistence model. Most just keep every object in memory but run a "checkpoint" every few hours or at shutdown. This checkpoint does a manual dump of all objects to disk from memory. Because these systems (for example, LambdaMOO) use main system memory for storing potentially thousands of objects they often start swapping to and from virtual memory; because the locality of reference of many of the objects is not always optimal, this swapping can cause some serious performance problems. CoolMUD uses descendents of Marcus J. Ranum's UnterMUD disk basing and object caching routines to manage its own paging of objects to and from disk. Bonus: long "checkpoints" become unnecessary -- what's on disk is always up-to-date.
• Multiple inheritance - Some people like it, some people hate it. We think that mix-ins and multiple inheritance and other tricks are neat-o. LambdaMOO used single inheritance. We don't.
• Remote objects - CoolMUD has a protocol called YO, which runs over UDP and acts as a kind of "RMI for MUDs". Objects can transparently share objects by proxying method calls over the network.
• Data hiding, security - LambdaMOO uses a fairly intricate built-in permissions system similar to Unix's file security modes. CoolMUD lets the core database take care of security concerns by forbidding external access to instance variables and exposing only their methods as public. This allows the object itself to determine its security policy.

What features do you plan on adding?

• Encryption - We hope to provide public key encryption of both YO and player sockets, to allow for secure to- and inter-MUD connections.
• Native code method objects - Method objects which are made up of native code, and stored in a dynamically loadable library, will be able to be attached to objects by the system administor.
• Metaobjects - Provision for more flexible dispatch to allow for extensible, OO types.
• New types - We've already added floats. Sets and multimaps are next. Anything is possible.
• Better cache and db support - Because the design of server is now relatively object oriented, it is fairly simple to "plug 'n play" with multiple object databases. We initially support an optimized and cleaned up version of the Ranum cache and db. However, it will be simple to provide hooks for new storage mechanisms like LPSM or Simble.
• Support for new protocols - We are looking at providing support for BEEP, for example.
• More robust distribution - We plan on leveraging some of the last decade's research into agents, peer to peer networks, and object distribution to enhance the protocol or replace it with something roughly equivalent. Things we hope to accomplish: automatic peer discovery, routing optimizations, multicasting, security.
• New language and VM features - Scatter assignment and proper exceptions are two top priorities.
• Multiple syntaxes / languages - The parser and decompiler framework is being totally rehashed to allow support for multiple language syntaxes over one bytecode interpreter.

When do you plan on releasing?

What's in CVS right now runs, but with a certain amount of bugs. We plan on releasing when the right balance of buglessness and new-features has been found.If you're interested in a bug-free release, you can either wait a few months, or help out.

Can I help?

We are looking for C++-savvy developers to help out. We are also looking for people who want to write in Cool's native scripting language to add features to (or rewrite...) the core system database.

How can I get a hold of you?