[MUD-Dev] Re: World Event Model (Christian Loth)

[Christoph Seifert]

Hi!

I am sorry to bother other member of this list, but Christian Loth added
some
comments, which I don't want to be left uncommented.

> Christian wrote:
> 
> 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.

Christian is correct with being the one who initated the events idea in
the code - back then the scheduling was even more primitive (which was
not
the focus of my first post anyway) and did not include any priority
handling of
events i.e. of concurrency of events at all - events like kicking an
opponent
checked for an already existing kick event, but could not account for
any other
similar technique/event like dancing or jump kick. After all it was just
checking every character in the game once every combat round for an
event with
removal of an event in case the executing function returned false
finally.
The changes I introduced were a central scheduler, priority handling,
proper cleanup interfaces and miscellaneous interfaces like special
command
interpretation - following the idea of events being a time-dependent
(CircleMud-type)
special.

> Christian wrote:
>
> 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.

nice scheduling - just how do events get scheduled for which time-slice?
internal or external of the event class code?=20
After all it is reasonable to use these slices, as the timer in
CircleMud/Realm of
Magic have a very similar time slicing.

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

This is very similar to the event handling introduced by me into the
code of the Realm of Magic - whereas my system uses abstract activities
e.g.
movement, Christian's system uses less abstract activities like combat
or magic,
thus it is unlikely to have a jump kick (movement) and side-punch
(weapon
handling) in Christian's system at the same time, whereas the old system
in the
Realm of Magic could handle this. The expansion of activity types is
easier to code as
well - adding a new flag definition and that's it - no expansion of a
table
necessary. In the system RoM uses now, it is possible to change activity
flags
during the life-time of an event. An example would be to start a kick
(flag movement),
feigning to start a kick and in the next instance start a jump kick,
surprising your
opponent. If the attacker had waited a moment to long, the kick would
have get locked
and an override with a jump kick event would have been impossible.
A detached event isn't very spectacular, as the event code itself
handles to which
objects it gets added or not. What is still missing is the
implementation of suspending events e.g. chat, starting to dance and
continue chatting after the dance has stopped.
So far it didn't seem to be necessary to implement it for any type of
event.

> Christian wrote:
> 
> 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

I am glad to report that the events in the Realm of Magic don't crash
anymore. I say not anymore, because it took some time to rewrite the
events
Christian coded, so that they used the cleanup interfaces properly -
sorry, couldn't
resist.

The system RoM uses is simple enough - if an event is deleted, it tells
all involved objects to remove the reference to the event and if an
object is
deleted, it tells all involved events to remove the reference to the
object
and those events can react accordingly to the loss of the object -
simple and
effective.

> Christian wrote:
>
> 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.

I would like to have more details on that - it looks as if all the
references are stored in central lists. Either way, two links are
required
in every case I think - one that connects the object to the event and
one that
connects the event to the object. Also an object should have the list of
events
it is involved in as this makes it easier to check for concurrency
problems i.e.
don't go through all other events, but check all events on this object
alone.

> Christian wrote:
>
> 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.

Again very similar to the event system in RoM - having finished and
other miscellaneous flags.

> Christian wrote:
>
> 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 ;) ).

I assume that Christian is very convinced here, that "his" system is
better than the system used in RoM.
I agree that the scheduling of events in the RoM could be more flexible
in using smaller time slices. This way, the already existing timer
functions
used for example to make regurlar announcement could be integrated into
the
event system as "detached" events.
As for the priority handling - the main topic of my previous post - I
think that Christian copied the system in the RoM badly by using less
abstract
types of events.

Again I am sorry to comment in this way, but even back then when
Christian was
still a coder of the Realm of Magic, we both used to argue about coding
issues.

I appreciate any further comment on how to determine the priority i.e.
concurrency
of events.

thanks in advance,
 
   Christoph

P.S.:
Events implemented:
- kick
- random quests
- vampires
- wagers
- dream
- death
- drowning
- diving
- socials
- hack & slay quest (groups of npcs pillaging villages)
- etc.



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