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

[Sean Kelly]

From: "Robert Zubek" <rob at cs.northwestern.edu>
> Joe Andrieu writes:

>> 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.

> 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

Probably more like:

  for each time tick
    call all existing handler's "tick" event

As potentially not every entity needs to know that time has passed
and you want to reduce the number of function calls to a bare
minimum.  Have handlers register themselves in a list upon creation
so you only process entities that need it.

I thought of a few other tricks that may have saved on processing
time (since technically you really only want to call "tick" events
for entities that actually need to do something on that specific
tick), but none offered the flexibility of just doing it this way.
Although...  I suppose if you wanted to get fancy, rather than a
straight list you could maintain a "calendar" class.  Entities would
register their next tick on the calendar and each tick would process
all the events registered for that tick.  At the end of the "tick"
call, the entity would register itself on the calendar for the next
tick it needed to be processed on.  Since the calendar is going to
be fixed-size (say a game day) and some time-bomb events may be set
not to go off for longer than that, they could register themselves
for a more recent tick and keep an internal tally of how many ticks
need be called before they actually fire.  You could get pretty
fancy this way and create events with complicated schedules and the
processing time would be quite minimal since you're only processing
tick events that explicitly need processing.

> 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.

And for sustained-duration events, like the poison example, or
delayed-fire events, like a bomb, this model doesn't work so well.

> 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. :)

Be careful with threads.  Often programmers consider the best thing
since swiss cheeses without considering the cost involved.  It takes
a measurable time for the operating system to switch processing
between threads.  In a pervasively multithreaded program, it's quite
possible that you could end up spending as much time switching
between threads than you spend processing the threads themselves.
Potential design needs aside, the ideal is still one thread per CPU.

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

See above.  No point in wasting processing time traversing an empty
function call or checking to see if a pointer is null :)

There's always the risk that you'll have more to do in a given tick
that you have time for.  You might want to monitor execution time in
two places.  First, that every tick completes within an acceptable
amount of system time, and that every specific tick event completes
within a predefined max time.  AI often faces this problem -- you
want to take as much time as you can to figure out what to do, but
no more :) The other option would be to just ignore this and if the
server starts running too slowly either buy more hardware or put a
cap on the number of objects simultaneously allowed in the game
world (which you'll probably have to do anyway).


Sean

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