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

[Sean K]

On Thu, Jul 26, 2001 at 11:49:54AM -0700, Joe Andrieu wrote:
 
> I also like Sean's calendar object.  A fine way to manage the
> master Tick queue.  Although I would again stress that the
> relevant unit time is one tick, rather than tie it to any realtime
> timeslice such as a day.

Just in case my original statement was misleading, I had suggested
that the calendar be set to contain N ticks where N is some easily
quantifiable unit like a game day.  By "game day" i mean a single
day within the scope of the MUD, not external time.  Depending on
space restrictions, it seems to make sense to choose a calendar size
large enough to accept scheduling tasks well in advance (to reduce
the number of dummy tick events that are called) while still staying
within memory requirements.  Choosing a game day would have made
scheduling recurring events simple as a task could set itself to go
off at "7PM" then when it is called, schedule itself again for 7PM
(the next day) -- ie. no calculations would have to be done to
calculate how far in the future 7PM is.

In case space restrictions are too tight and you settle on a much
smaller time period, I would probably randomize the first tick
interval rather than doing something like scheduling far-away tasks
on the last tick in the calendar.  In the last case, the final tick
before the calendar returned to position 0 would contain a huge
number of "reset" events that comprised long-term events
decrementing an internal counter and setting themselves at the end
of the next calendar day.

Here's are 2 simple examples.  Say the calendar size in both is 100
ticks and in each case I want to schedule 4 events 250, 300, 150,
and 10 ticks in the future, respectively:

  (a) non-randomizing example

    * schedule first event at tick 100 and decrement internal
      counter by 100 (leaving 150)

    * schedule second event at tick 100 and decrement internal
      counter by 100 (leaving 200)

    * tick all the way to 100

    * re-schedule first event at tick 100 and decrement internal
      counter by 100 (leaving 50)

    * re-schedule second event at tick 100 and decrement internal
      counter by 100 (leaving 100)

    * schedule third event at tick 100 and decrement counter by 100
      (leaving 50)

    * etc.

  (b) randomizing example

    * schedule first event at randomly determined tick 43 and
      decrement counter by 43 (leaving 207)

    * schedule second event at randomly determined tick 87 and
      decrement counter by 87 (leaving 213)

    * tick up to tick 43

    * re-schedule event at tick 43 to tick 43 (100 ticks in the
      future) and decrement counter by 100 (leaving 107)

    * tick up to 87

    * re-schedule event at tick 87 to tick 87 and decrement counter
      by 100 (leaving 113)

    * etc.

As you can see, the first, non-randomizing example encourages
clustering of longer-term events at the final calendar tick that
gets gradually worse over time as events pile-up.  While the second,
randomizing example (hopefully) evenly distributes long-term events
across the calendar so a minimal number of re-schedule events occur
on any one tick.

hehe oops... I'd planned to only clarify what I mean by game-day, I
guess I got a bit carried away :) In any case, that's the basic
idea.  I haven't actually implemented it but it seems like it should
be reasonably efficient.  Obviously, such a scheme only comprises
in-game events (which may include NPC AI).  Things with critical
recurring needs like rendering should be handled separately, before
the tick-event mechanism is processed.


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