[MUD-Dev] TECH DGN: a few mud server design questions (long)

[Caliban Tiresias Darklock]

On Wed, 25 Jul 2001 13:20:26 -0500 (CDT), Robert Zubek
<rob at cs.northwestern.edu> wrote:
> Caliban Tiresias Darklock writes:

>> (We REALLY need a design pattern web site for this sort of thing;

> i agree. it seems everyone develops these solutions from scratch,
> which just screams out for knowledge sharing. :)

Not so much for knowledge *sharing* as for knowledge *gathering*,
IMO.  The MUD-Dev search engine at kanga.nu is useful, but I really
don't like search engines too much... they return far too much
extraneous material, and when you don't know EXACTLY what you're
looking for it's almost impossible to filter through it. I'd rather
have someone intelligent take the bits and pieces he's found over
the years and put them on a web site where -- at least in his (or
her) opinion -- all the material is useful. I keep meaning to do
this with the "white papers" section of my web site, but I never
quite get around to doing it. Bartle and Koster have done a pretty
good job of this for the "soft" sciences of MUDs.

> so i understand it would be something along the lines of:
 
>  1. global handler validates the action
>  2. actor validates that it can perform the action
>  3. patient validates that it can receive the action
>  4. global handler calculates whether and how the action succeeded
>  5. actor modifies itself accordingly
>  6. patient modifies itself accordingly

Along those lines, yes, but my system goes more along the lines of
server - actor - server - patient - server - actor - server. The
actor and patient are responsible for *specifics*, while the server
handles general cases. There are actually two "patient" phases, but
they're right next to each other so I treat them like just
one. There's sort of a "pre-action" and "post-action" concept there:

  PRE-COMMAND SERVER (Valid command)
    PRE-ACTION SUBJECT (Subject adjusts it for specifics)
      PRE-ACTION SERVER (Server adjusts it for world effects)
        PRE-ACTION OBJECT (Object adjusts it for specifics)
          ---- ACTION ----
        POST-ACTION OBJECT (Object reacts to result)
      POST-ACTION SERVER (Server reacts to result)
    POST-ACTION SUBJECT (Subject reacts to result)
  POST-COMMAND SERVER (Ready for next command)

The "action" isn't actually an event, it's a "fall-through or break"
decision in the object based on success or failure.

> this is quite cool. how would you say does this impact
> extensibility of the mud? does this mean that adding a new type of
> action requires changing all three handlers?

I stole a page from MUSH in this respect, sort of: all handlers are
discrete objects. In effect, the player object is nothing more than
a bag of handlers and some identifying information, much the same
way a MUSH handles player objects as a DBref and a list of
attributes. If I want a new handler, I just code one up -- the
resulting object can then be dropped into the game, and I just have
to run off and buy one so I can test it.

Right now, these handlers are written in native C++ and handled by
chaining off to functions, but I'm working on turning this into a
scriptable interface. (With 600 handlers and counting, it only makes
sense.) I've been toying with the idea of using Knuth's old MIX
assembly language from "The Art of Computer Programming" and running
the handler in a virtual machine.

> hehe, yes, as i try to work out the design of the mud, i find
> myself repeatedly needing to simplify the functionality for the
> sake of cleaner implementation. damned tradeoffs. :)

I have the opposite problem. I have certain required functionality,
and it keeps requiring more and more complex approaches to produce
clean code. ;)

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev