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

[Robert Zubek]

J C Lawrence writes:

 > The guts are actually minorly messy and somewhat intricate,
 > especially below the executor.  If you're interested hit the
 > archives and look into the whole business of the Compare&Commit
 > model and event rescheduling, etc, or if you're really
 > interested, ask.

I took a look through the C&C model, and it has an interesting
approach to transactioning, rollback, and dealing with contradictory
concurrent actions. This seems like a whole new can of worms, so for
now I think I'm just going to punt on solving concurrency problems
by making event handling strictly serial, and rely on programmer's
ingenuity when dealing with defeasible temporarily-extended events
(such as spells that could be interrupted). :) I'm not expecting to
let users write their own objects, so perhaps it won't be too big of
a problem.

 > As for how the look up is done, how message-to-XXXX is translated
 > into either f(XXX) or XXX(), well, that's pretty simple: function
 > pointers are your friend and tables of function pointers are even
 > better.

 > All message targets devolve to object methods references, which
 > gives my a simple tuple of ObjectID, MethodName, and
 > MethodArguments.  Each object carries a hash table of mappings
 > from MethodNames to entry points so a simple hash dereference
 > gives me the entrance point to the method code to start the soft
 > code interpreter on.

So in your system, are the action handlers general? In other words,
if there were a HandleAttack() method attached to an agent object,
would it process the attack message regardless of whether the agent
object was the attacker or the victim? Or do you have a separate set
of handlers for agents vs. patients of an action?

 > I've been (was mostly) a fan of contextual binding and so
 > restricted all object methods to only being able to mutate their
 > parent object (I transparently exposed exported object attributes
 > via hidden accessors).  As such everything else devolved to
 > message passing among objects.  I did this explicitly so as to
 > provide a clean abstraction layer for database distribution,
 > modeling off CoolMUD's YO protocol.

That seems like the way to go - doing everything via message passing
between all the entities involved in an event. This destroys data
dependencies between the agent and the patient of an event, which is
good because it makes the representation much cleaner, but it also
means now I'm going to have to invent a whole new zoo of message
types. Oh joy. :)

Rob

PS.

 > BTW: I'd much prefer it if you lost the e e cummings bit and used
 > proper capitalisation.

In all honesty, you're the first person to ever take note of my
writing style. After years of using it, lowercase feels as natural
to me as dropping pronouns or beginning sentences with
conjunctions. :) But since that bothers you, I'll be happy to do
mixed caps when replying to your emails.

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