[MUD-Dev] World Event Model

[Christian Loth]

Greetings,

On Fri, Aug 04, 2000 at 11:05:30AM +0200, Christoph Seifert wrote:
> Hello!
> 
> I read through the ideas for making events and even downloaded the
> example by Adam.
> 
> The mud I code on - The Realm of Magic (http://rom.mud.de) - uses a
> system for
> events as well, but with a different approach on priorities. Events in
> there
> are actions or something that goes over several rounds or for a longer
> time. 

Once I also coded for the MUD Realm of Magic, and it was me who
gave the first initative for its event system, though it developed
in a direction that I didn't like very much. 

Since then I started my own MUD Project called 'Gidayu', and I also
developed an event system, based on my basic ideas for the RoM-event
system, but this time I developed details on my own, and I'd like to
report how they turned out.

In Gidayu, events are also periodic occurances, that have an interval
of execution. Gidayu is supposed to be a heavliy event-driven MUD,
more even than RoM, therefore my goal was also to design an event
system that could easily hold several thousands of events, without
showing runtime issues.

SCHEDULING
----------

First: priority based scheduling
Gidayu events are sorted in a priority queue. An events priority is
a 64 bit unsigned long long (GNU C extension). The priority consists
of two 32 bit unsigned longs, where the first one is the time slice
when the event will be executed next, and the second is the event's
running number. The time slice count is 0 at Startup, and increases
by one ever 25 miliseconds, so that we have 4 slices in a second.
This is a nice granularity, which will give us the opportunity to 
implement speed-based (I call it pseudo-realtime, but realtime is
an overstretched expression) instead of round-based combat.

Second: type based scheduling
There are 7 event-types (social with action, social, combat, magic,
death, action, and detached). Normaly an event is attached to an
instance in the world (room, item, npc, player, etc.). Upon creation,
it is checked, if an event can be scheduled at all, depending on what
events are active in that instance (e.g. a fighting character will
have a hard time dancing!). After that, it is checked, if that new
event purges an already existing event (e.g. a dancing player, if
dragged into combat, will start fighting and stop dancing). These
checks are done with two tables having two dimensions each, where
each event type is checked against the other event types, and either
is 'true', or 'false'. A special case are the detached events, which
work independent, and are not scheduled by type (this is e.g. used
for system events, like Auto-Player-Saving, Date/Time bookkeeping,
several kinds of Updating Events, etc.).

The Event Handler
-----------------

The Event Handler is the class that manages all events (e.g. it is
the class that contains the priority queue). For one, it counts
the slices, which are used for calculating an event's priority.
Then it is responsible for executing all events that are to be
executed in the current time slice. It also keeps track of the
event managers (see below) and the discarding queue (see also below).

Event Managers
--------------

One point I didn't like about the event system of RoM was, that it
often crashed because an instance in the world was deleted, without
it properly telling it's events (see Christoph's remark about
avoiding crashes) or the events simply asserting that it was still
there. It was dissatisfying, that each instance in the world had to do its 
very own checks for events, and vice versa. Therefore I implemented
a proxy class in the Gidayu System, which keeps track of events for a world
instance, however when that instance gets deleted, the proxy is still there.
It will then get placed into the discarding queue, and all events are
properly signaled, that the world instance has gone. The Event Manager
keeps on existing as long as the events that once were using the world
instance for something still exist - maybe that world instance was not
critical for the event, or proper cleanup work still needs to be done. 
Of course this is hard to do when all event data is stored with the actual
instance. With the help of this proxy class I neatly got the 
'validation code' for events centralized, thus sparing me a lot of 
maintainence work and danger of crashes.

Events themselves
-----------------

There is a great deal of flexibility for Gidayu Events. Just like the
events from RoM, events are able to trap commands, overriding the
actual execution of a command, and using special code in it's place.
Then they regularly execute code. It can be used for regular updates,
or for regular validation checks (which, if failed, might set the
event's state to 'finished' which will delete the event at next
opportunity). The interface is pretty general, and can do almost anything
at a very nice granularity of time. The generality also provides that
the code of the event system is kept relatively simple, and thus
easily maintainable.

> Anyway, I am not 100% satisfied with the priority handling, although I
> didn't think it up
> in one day.

Actually I agree with Christoph that RoM's events were (at my time of
leaving) awkwardly scheduled, however I am very content with Gidayu's
scheme, and must say it works nicely so far. However, at the moment with
Gidayu being in alpha development phase, I didn't have any great
stress setups, but just very limited sandboxes, so Gidayu's system
didn't survive any stress tests yet (though I must say, high uptimes
surely boost your ego ;) ), though I'm very positive it will.

> 
> I would appreciate any comment or discussion on it.
> 

Whether Gidayu's event system is evolutionary or degressive compared
to RoM's, I think only the future can tell (or maybe any of the
true gurus on this list ;) ).

- Chris


--
Christian Loth
Coder of 'Project Gidayu'
Computer Science Student, University of Dortmund
chris at gidayu.mud.de - http://gidayu.mud.de



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