[MUD-Dev] Minimal MUD-kernel (was Re: Finer points of Telnet programming ...)

[Niklas Elmqvist]

On Sun, 23 Aug 1998, Caliban Tiresias Darklock wrote:
> >So I decided that I would design
> >as simple a MUD platform as I can
> 
> I've thought about doing something like this... I have this hairbrained
> idea of a modular MUD, where the internal networking code is in one module
> and everything else hooks into it from external plugins. So the question of
> room or coordinate based, combat or non-combat, programming interface,
> etc... all of that's basically irrelevant. How to make it portable and
> such, I have no real answer for... but ideally, I'd like to have a little
> plug-in module that doesn't do anything but accept and manage connections,
> then plug everything else in from there.

That makes two of us! My pet project involves a kernel-like core
executable (called the MoleCore) which contains just pure engine code
which dynamically links to shared libs (I call them plugins) that
provide the real functionality of the MUD. Since I'm developing in C++,
I've devised a cute little scheme for creative use of inheritance and
polymorphism across dynamically linked libs and a running executable.
Tentatively named "hidden inheritance", this technique allows me to define
skeleton base classes in the MoleCore (such as an Event class which does
nothing, merely defines the interface) and then subclass and redefine
these base classes in the plugins completely independant of the MoleCore.
This way, I can create subclasses such as MagicEvent, CombatEvent and so
on and introduce them into the EventManager of the MoleCore without having
to recompile it at all -- and this at run-time!

I've outlined this method before on the list, and I've written a short
text describing the process which can be found at 
<URL: http://artoo.hemmet.s-hem.chalmers.se/~crozius/resources/dynload.html>
Recently, I've managed to implement hidden inheritance on Win32 (earlier,
I thought the Windows dynamic linking mechanism would prevent this) and I
am in the process of writing a feature article as well as a new webpage on
this. As for making it portable, my article discusses how to use the
Adapter or Bridge design pattern to encapsulate platform-specific dynamic
linking calls into a coherent whole. 

One of the major problems, however, with having a kernel<->plugin
architecture like this is how to make the plugins work together. We don't
want to increase the coupling in the system by letting each plugin know of
the others. In MoleCore, I've opted to introduce a decoupled data path for
plugin messages (or Requests, as I'd like to call them) which I've named
the Request Chain. When bootstrapping a plugin (ie attach it dynamically
to the core), the plugin may attach itself to the Request Chain and listen
for Requests (sort of like putting its ear to a railroad track). Plugins
may then issue Requests to the chain without having to know whether there
is any other plugin out there -- in your example of a network manager,
this plugin could for example accept new connections and send a
NewConnectionRequest (or similar) as well as read data from sockets and
issue DataReceivedRequests which contains file descriptors and a data
buffer. Then it would be up to some other mechanism to capture and handle
the Request, the network manager plugin would go back to happily wait for
new data.

> I keep imagining having a single OCX control that I grab in Visual C++
> and drop on my project, and boom, there's a basic bare-bones telnet
> server that handles IAC DO/DON'T/WILL/WON'T sequences appropriately. (I
> can probably buy one of these, since I think I've seen something similar
> advertised, but I want to build one.) 

In my case, it would be a plugin-class which is part of a standard
DLL-file explicitly loaded at run-time. This plugin (TelnetPlugin maybe?)
would capture data requests from the network manager plugin and act as a
filter, handling all IAC sequences,  before passing on the data to the
Request Chain. And yes, adding this would be as simple as dropping the
filename of the DLL in a config file (or maybe logging  is as system
administrator in the MUD and loading the DLL and inserting the
TelnetPlugin manually, such as when testing and debugging the plugin). The
actual linking is performed at run-time, of course, opening some nice
possibilities.

More info on MoleCore (such as why it is called 'MoleCore', as well as
some random design documents) can be found at 
<URL: http://artoo.hemmet.s-hem.chalmers.se/molemud/ >

-- Niklas Elmqvist (d97elm at dtek.chalmers.se) ----------------------
  "A Thaum is the basic unit of magical strength. It has been 
   universally established as the amount of magic needed to create 
   one small white pigeon or three normal sized billiard balls."
		-- Terry Pratchett, The Color of Magic