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

[Robert Zubek]

Joe Andrieu writes:

 > The idea is that recipients subscribe to publishers for the class
 > of events they need to pay attention to.  For example, objects in
 > a magical (autonomous) bag probably do not need to receive the
 > "tick" even the bag processes. However, they may need to receive
 > impact_damage events, perhaps even modified by the bag. So, if
 > the bag is "hit" with impact damage from a fall or combat, the
 > bag would propagate an impact_damage event.  If so designed,
 > perhaps the magical bag reduces that damage by 50% or whatever,
 > but it manages the propagation of the event to its subscribers.

hmm, that could really help extend message handling. just to sketch
out a possible implementation:

- when an object enters another's containment (agent enters a room,
  coin gets dropped into a purse), it subscribes for its preferred 
  set of events; when it leaves, it unsubscribes.
- each object gets a chance to process each message it receives, but
  then has to propagate it (though possibly changed) to all contained
  subscribers for this message type. 
- there's a global clock that sends periodic 'tick' events.
- all players and autonomous agents subscribe to the global clock's
  tick event at startup. 

this should work much better than just attaching handlers to each
object and letting the container propagate all of its messages, in
which case all messages would have to traverse down a strict
containment hierarchy, whereas in the subscription model they can
form arbitrary subscriptions (such as to the global clock). the only
down side i can think of is the bookkeeping associated with changing
containment, but it shouldn't be too bad.

(this suggests a possible three-tier propagation: each message first
gets sent to an appropriate local handler. if none was found, or the
handler failed, the message gets sent up the class hierarchy. and
finally, the message gets send to all the subscribers. the return
value for this message is then some function of the results of these
three propagations. hmm, i'll have to map this out in greater
detail.)


 > On the other hand, you must consider how much work you want to
 > put in to writing the ideal system compared to how much you want
 > to explore AI in that context.  You can readily simplify and cut
 > out a lot of hassle, at the expense of scalability,
 > extensibility, etc.

well, i'm happy to take the time to explore design issues - even
though i might not be able to implement some of them (such as full
transactional rollback, or good object persistence), it's still good
to know what the best solutions are. besides, lisp has a way of
rewarding clean designs with quick prototyping turnaround. :)

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