The world changes. And as the world changes, some things stay the same. A number of changes in the MU-niverse in recent years have resulted in a great deal of this document becoming technically obsolete. But this document was never intended as a technical manual. It's a starting philosophy... an illustration of a far off land as seen from a local mountaintop. With that in mind, I have made notes within this document (in bold italics like this message) as well as a few comments below specific pages. I have, for the most part, left the 'theory' in place... even in those places where it's become technically inaccurate.
This document should now be considered a combination of "history" and "planning"... a sort of snapshot image of where this project came from and where it intended to be going (and should sort of still be intending to go).
For years there have been some rumblings about making a decent set of 'core components' for a 'slightly more than minimal db' for PennMUSH. I'm fairly certain there have been similar rumblings among other MUD server flavors. Some evidence of that can be seen in the recent emergence of the Sandbox Globals Project (kudos to Audumla and her team for their diligence in bringing that to fruition). Nonetheless, there is still a 'core' lacking in even this development.
This page attempts to explain what is meant by the concept of a MUD 'core' within the context of this web book, and outlines the goals of the WARPEDcore project.
This history of this project is, for the most part, restricted to M*U*S*H (the Social MUSH run by Javelin, former maintainer of the PennMUSH source) and several players there who expressed their interest. Twice in the history of M*U*S*H, there have been very intense discussions and bboard interactions on various aspects of this whole 'core' notion. What should it contain? How should it be designed? Who should be responsible for it? Etc. Although both of these more intense discussions eventually degraded into a thousand different opinions, a great deal of overall insight was shared. And from that experience (I, Trispis@M*U*S*H, attempted to actually coordinate the second of those interactions -- sorta like trying to harness a thunderstorm in a paper sack.), I learned that most of the people involved just wanted "something". Their differences of opinion were not nearly as significant as their common desires.
And just what were those 'common desires'? Well, mostly it boiled down to some sort of standardization -- some natural and/or intuitive means of standardizing certain components of MUSH (to reduce inter-MUSH disparities, to reduce the 're-learning' requirements when changing from one game to another, or any number of other syntactic versions of the same thought).
With that in mind, I studied the various individual requests and assertions, and I discovered something. In order to provide *any* form of standardization at an inter-MUSH level, there needed to be a 'core'... far deeper than simply a 'common set of globals' (+finger, +who, etc.). There needed to be a central, interactive, accessible, maintenance feature. Something that even disassociated softcode packages (Myrrdin's Bulletin Board, Places/Mutter, Keran's Weather, softcoded dynamic space systems, etc.) can 'hook' themselves to.
So, that's where I decided I needed to apply myself -- to the creation of a MUSH 'core'. And I began to outline some conceptual approaches to this. And, in so doing, I found myself inevitably returning to the concept of a 'db kernel' with a 'registry' -- a system of tracking and maintaining installed softcode packages (such as those mentioned in the previous paragraph).
A 'db kernel with a registry', yeah... and some maintenance utilities, yeah.
THAT's what a MUSH "core" is... It's something that is central to *any* and *all* installed packages. Even if a softcoded package isn't designed around the concept of a 'core', the core itself can still provide useful services around and/or for that package.