[MUD-Dev] Ticks?

[Dave Richards]

David Anderson writes:

> Since I'm writing my mud from scratch (Java), I've found that
> there's a lot of issues I have to think about that normally with a
> stock mud I'd just accept as "already written".

I am in the same boat.  I am using LISP.

> I was thinking about skipping ticks & regenning every round, but I
> was worried about the extra processing that would entail (since
> that would mean I'd also have mobs regenning every round, so
> that'd be thousands of mobs, plus hundreds of players
> someday.. all regenning every couple seconds).

> What have other people done for regenning?  I'm just doing my best
> to have it make a bit more sense.

In the CD (LPMud) lib the healing is performed lazily.  In the query
routines for hit pointers, spell points, fatigue, etc. they compute
the difference in time between the last call and the current one and
heal as a side-affect.  It's not conceptually difficult to do, but
requires discipline.

In the CD.04.07 driver I re-implemented the networking code.  As a
side-affect of this we changed how ticks were handled.  What used to
happen was a 100ms repeating SIGALRM was delivered and drove the
delta-list processing.  When we changed it, we polled the current
time and processed the delta-list each time around the select()
loop.  This *sounded* like a good idea at the time.  What we
discovered was that it consumed a substantially larger amout of CPU
time because we were calling gettimeofday() and processing the
delta-list *much* more often, far more than necessary.

Some thoughts:

  1. If you can, handle ticks at fixed quanta.  Make the quantum
  fast enough to handle the most time-critical game events
  (e.g. combat and specials).  Don't process the delta-list any more
  often than you absolutely need to.

  2. Amortize anything you can related to time, i.e. use the hit
  point, spell point, fatigue access routines to perform the
  healing.

  3. Move combat onto its own list.  Don't share combat with
  non-combat tick events, combat just clogs up the delta-list.
  Preferrably, use one delta-list entry for all combat.

  4. If possible, two game engine threads make life easier.  One
  thread is triggered by communication (select() loop) and the other
  is trigered by delta-list (nanosleep()/sigpause()) expiration.
  Use a monitor to enforce mutual exclusion between them, so the
  core game engine only sees one thread.

	Dave

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