Event-driven?

[Adam Wiggins]

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

That's quite a question.  In a nutshell, it works like any other event
driven system - it only does something when it 'needs to'.  In order
to define 'needs to', however, you need very good flow of information and
control.  In other words, it's more difficult to both conceptualize and code,
and there's a lot more potential for things to go wrong.  But if you can
pull it off, you get what is essentially an optimal system - if nothing
is happening, then almost no processor time is being used; if many, many
things are happening then processor usage goes up to match this.  Versus
brute-force (polling/looping) which is fairly static - even if there's
no on online, it's still sucking down a fair amount of CPU time.
A simple and highly applicable example for this is strength versus
weapon wielded.  On a tick-oriented mud, where it updates everything
on a tick (typically 35 to 75 seconds long), if someone casts weaken
on your character or otherwise affects their strength in such a way that
they are no longer strong enough to wield their weapon, the weapon won't
fall out of their hand until the polling loop (tick) makes its scan of
all the characters and updates stuff like this.  Versus event driven, where
the weaken spell triggers a strength update event, which triggers a check-to
see-if-I-can-wield-my-weapon event.
Even driven is also much nicer once coded, because it's easy to just toss
an event on the queue and 'forget' about it.  When the given even goes
off (which could be hours or even days later), the appropriate handler will
be called.