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

[Joe Andrieu]

Robert Zubek wrote:

> do i understand correctly that what you describe is a kind of a
> multitasking approach? one in which the control loop looks like
> this:

>   for each time tick
>     for each living entity
>       call the entity's 'time tick' handler

You may also consider the generalization of this as a means to
handle event propagation.

This is essentially a subscription model for events.  Each "living"
object is implicitly subscribing to the "tick" events of the master
tickmaker.

I have also seen this used for managing the question of propagation
to rooms and containers and neighbors and such.

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.

You can do this for sounds, heat, wetness, etc.  I believe
ColdC/ColdCore has some nice mechanisms for exactly this sort of
thing. The point being that you classify events into some category,
and objects subscribe in order to receive events in that
category. And then designers use those category of events and their
associated cascades to implement category-specific behaviors (like
trying to eavesdrop), while limiting the unecessary propagation of
events.  You pay a price in data size and initialization, but IMO
you more than make up for it in processing if you have a well
designed categories and designers who know how to use them.

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.

-j

--
Joe Andrieu
jandrieu at caltech.edu
+1 (626) 395-8045

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