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

[Robert Zubek]

Caliban Tiresias Darklock writes:

 > I can give you a basic description of how *I* handle various
 > things. I don't know if it's canonical, because to be honest I
 > haven't found much intelligible source that relates to these
 > questions so I've had to develop each of them from scratch.

 [snip!]

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

 [snip!]

i agree. it seems everyone develops these solutions from scratch,
which just screams out for knowledge sharing. :) there probably
isn't any literature on this sort of engine design - but with some
luck, as more people talk about their design approaches, perhaps
newbies such as myself will be able to piece together a more
coherent picture. :)


 > In short, the server is responsible for determining whether a
 > command is valid; the acting character is responsible for
 > determining whether it can be completed; the server is
 > responsible for determining whether it actually *is* completed;
 > and the target is responsible for determining whether it
 > succeeds. The target is then responsible for modifying its own
 > state, while the acting character is responsible for modifying
 > its own state. All of this is done on the server, NOT the client,
 > so integrity is (hopefully) guaranteed by the design.

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

so the functionality gets cleanly separated - the actor never has to
modify the patient's state, or anything like that, and the only data
that gets passed around is the information on the type of event and
whether it succeeded. the processing isn't localized in any one
place, all three handlers (global handler, actor's handler,
patient's handler) participate in the processing of the action.  (i
just realized this division would also make it really easy to
implement a permission system - so that some actions could require
the permission of the patient.)

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?


 >>  one could imagine a number of solutions inspired by operating
 >>  systems research - perhaps implementing a fake
 >>  continuation-passing style (as a kind of non-preemptive
 >>  multitasking: a temporally-extended action would be expected to
 >>  initialize itself, do a fraction of the necessary processing,
 >>  then put a new fake event on the queue saying "continue the
 >>  spell event", and exit).

 > This is the normal response. If I were implementing something
 > like this, I'd place these events into a time-sorted queue which
 > popped events off when they became due and passed them along. In
 > the meantime, I'd set a state on the appropriate objects that
 > caused other events to either fail or force the failure of the
 > pending event.

ah, that sounds good. i was trying to figure out whether there's a
clean way to hide the multithreading, so that temporally-extended
events would be indistinguishable to the programmer from regular
ones - but that doesn't look at all easy. and besides, the
programmer needs *some* control over the entrance and exit points
for the event.


 >>  each has a drawback: for the first (container passing the
 >>  message to its elements), there are cases when these messages
 >>  should be propagated further down to elements-of-elements
 >>  (eg. people in a cage in a room should be able to see what the
 >>  people in the room around them are doing),
 
 > Agreed. My system doesn't have that sort of thing, though; it has
 > single-containment only, and containment precludes
 > notification. Rather simplifies the tasks. I made a lot of design
 > decisions that restrict player activities to a domain that's
 > easier to handle. Sometimes "don't do that then" really *is* the
 > best medicine. ;)

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

perhaps for the prototype i should actually implement propagation
down to elements of elements, and see whether it actually causes a
noticable slowdown. maybe the extra message processing will not be
noticable with everything else going on? we'll see. :)

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