[MUD-Dev] Re: PDMud thread summary
d97elm at dtek.chalmers.se
Fri Oct 23 10:00:32 New Zealand Daylight Time 1998
On Thu, 22 Oct 1998 ApplePiMan at aol.com wrote:
> At 10/22/98 6:20 AM Niklas Elmqvist (d97elm at dtek.chalmers.se) altered the
> fabric of reality by uttering:
> >IMHO, the driver should consist of a few primitives which provide the
> >minimal functionality of any game server. One such thing is an event
> >manager (c'mon! almost all games need one),
> Yes, as long as care is given to keeping the event manager low-level
> enough to not "box in" world designers. That is, make sure you're dealing
> with computer events and not game events, which could vary widely from
> game to game (and thus are perfect candidates for a module).
Allow me to once again to shamelessly plug external inheritance, which
would allow us to define a very generic event class in the core
executable (one that is a computer event, but with no functionality
besides that of an abstract event), and then promote this to game events,
system events or IO events, etc in the modules.
External inheritance is sort of a design pattern for C++ software systems.
I whipped together a little description of the technique yesterday which
can be found on
IMHO, this method is ideally suited to a project like this (but it would
almost require that we use C++).
> One thing that just occurred to me: are we going to allow module
> hierarchies? I suppose this actually comes back to the question that's
> been raised before re direct communication between modules: if we allow
> that, a designer could easily implement a hierarchy of modules.
If we use an OS-like pipe communication system (no reason, of course, why
we can't use other OS IPC mechanisms), this would be certainly be doable.
> An example of what I have in mind is that my commercial project calls for
> a Drama Manager that sits on top of, and can modify the results of, just
> about every other module. I realize there are ways I could handle that
> without having the hooks directly pre-built into DevMUD, but it might be
> a cool feature to support anyway (tho' I'm talking off the top of my head
> and possibly not seeing all the ramifications of supporting inter-module
> communication). Comments, anyone?
Hmm, this Drama Manager should only be concerned about things pertaining
to the game logic (right?). IOW, it should sit above things such as the
Physics, Magic, Movement, Senses, Quest and Skill modules, but *not* above
the parser, the command handlers (these call the game logic modules if
they need anything anyway), the VM, the DB handler, and so on. With a pipe
system for inter-module communication, the Drama Manager could just
position itself between the game logic modules and the parser and command
handlers, among others. This way, all messages that pass between these
would be routed through the Drama Manager, which may interfere and alter
them at will.
-- Niklas Elmqvist (d97elm at dtek.chalmers.se) ----------------------
"The trouble with being a god is that you've got no one to
-- Terry Pratchett, Small Gods
More information about the MUD-Dev