Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
Sat Apr 5 10:39:21 New Zealand Daylight Time 1997

[Michael H:]
:Precisely how does an event-driven mud work?  I understand the idea, but
:I don't see how it could be run efficiently, and be coded neatly...
:Can somebody enlighten me?

Nathan's explanation was quite detailed, so I'll give a simpler arm-waving
one. I have a list of events that need to be scheduled in the future. The
list is sorted by increasing date/time (I use an internal seconds count).
Each element also contains a pointer to the MUD code to run, and a pointer
to the PC/NPC on who's behalf it is to be run. Whenever the first, or a
new earliest, event is added, the server starts or modifies a timer for
that time interval. The server then goes back to doing whatever it was
doing before (typically, it continues executing the MUD code that just
scheduled the event). When the server goes idle (does its main 'select'
call), that call can be woken up by the timer signal. The server also
occasionally checks the time when it is busy, to see if it is getting a
long way behind. If so, it can stop processing incoming requests and do
some timed events for a while.

To process a timed event, it just sets the current identity to that in
the request, deletes the request (important!), and then calls the MUD
code of the request. It loops through the earliest events until it comes
to one that isn't due to run yet (re-checking the current time occasionally,
since doing all of this does consume time), or until it decides it has
done enough catching up for now and should go back to input requests.

So, to have an NPC that does things occasionally, the MUD code looks
something like this:

/* the routine which Frog executes on each "step": */
define tp_frog proc frogStep()void:
    int direction;

    if not ClientsActive() then
	After(60.0, frogStep);
	direction := Random(12);
	if TryToMove(direction) then
	After(IntToFixed(10 + Random(10)), frogStep);

(This is from an example file on NPC's that is part of my docs.) The key
here is the 'After' calls. They schedule an event for the given time
(in seconds) after the current time. Note that the MUD code they are
scheduling is the same code that is currently executing - this is quite
common on my system.

Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA

More information about the MUD-Dev mailing list