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

[Robert Zubek]

Caliban Tiresias Darklock writes:

 > 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.

yes, a kind of 'gems of mud server design' would be very cool. i
realize there's been quite a few of those posted on this list, but i
agree, unless one asks explicitly, it's really difficult to find the
particulars. but so it is with most highly specialized knowledge. :)

 > 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)

so the server doesn't actually do any event processing at the
beginning, it just parses the command, passes it to the subject, and
then if the subject is willing to perform it, it's expected to send
it back to the server for general processing, right?

were there any specific reasons (difficulties with certain actions
or other such) that suggested doing the server handling after the
actor, rather than before the actor?  (just curious...)


 > 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.

hey, good old MIX. :) although i'm curious how well an assembly
language would deal with issues such as complex data types (strings,
structs) getting used by the handlers, or the need to interface to
other parts of the system... you could, of course, implement MIX as
a virtual machine language, and then add a compiler from your
favorite high-level language... :D

rob

--
Robert Zubek 
rob at cs.northwestern.edu
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev