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

[Robert Zubek]

Joe Andrieu writes:

 > A long term event then is one that occurs over several ticks.
 > So, instantiate an object which is active for the appropriate
 > number of ticks and engages in the activity.  Regarding your
 > spell example, I have seen systems which spawn a shadow object
 > which attaches itself to the user and performs its action over a
 > long period of time. For example, a poison object which slowly
 > drains the character of 1 hp every tick for 50 ticks and then
 > deletes itself.

 > As long as objects are persistent and there is a periodic time
 > event, it is fairly straightforward to instantiate an object to
 > handle longer term events.

hi joe!

hmm, that's a very good point. i didn't even realize it at the
moment, but the event handler i was modelling didn't support
periodic time events at all, which was probably at the source of my
difficulty.

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

and the tick handler takes care of all the relevant events that got
queued up in the meantime.

compared to this, my original design had the entities be more like
static collections of stats and function pointers, manipulated by a
general event dispatcher, eg.:

  for each event in the queue
    process event (using all involved entities)

in this latter model, there is no concept of an independent time -
events are one-shots, and if nothing is happening an object won't
even notice the passing of time.

but it could mean that in this model, without a separate clock that
would poll the objects, objects wouldn't be able to act
autonomously. (curiously, this didn't cause me any problems with
npcs, because i figured i'd put those in separate asynchronous
threads anyway, since they will need to run at a higher frequency
that the main control loop. :)

hm, i'm going to have to rethink my approach to event handling. i
wouldn't want each creature's time tick handler to be doing too much
event processing, but perhaps something like the following would be
a good combination of event dispatching and asynchronous time
support:

  for each time slice
    for each of the first n events in the queue (where n is small)
      process event
    for each entity
      call the entity's 'time tick' handler

in which case the objects' tick handler could be very simple, and in
most cases simply null.

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