Re: Event based system

["Miguel A. Osorio" <maos@gbl.com.br>]

adam moss wrote:
> 
> "Miguel A. Osorio" wrote:
> > I'd like to know more about how to build a event driven game engine
> 
> If it's any help, I've written a generic synchronous event
> trigger/listener module in C that I was planning to release at some
> point under a BSD-style license.  It was designed specifically for
> a commercial game project; it's (meant to be) portable, small, simple
> and fast, allowing new types of events to be easily registered on the
> fly (and passed to/from a scripting language albeit via a bridge in
> the application<->scripting interface).
> 
> It's probably a few weeks of testing and interface-tweaking away from
> the point where I'm happy to release it.
> 
> It may or may not fit anyone's needs or definition of an event
> system, being sychronous and having other trade-offs in its design.
> But there you go.


	Great, I'd really enjoy to take a look at it; but still, could you
point out any article or paper, or whatever, on the basics of event
system design and principles - I'm still quite a novice on such matters.


	(...)


> I issue LOTS of types of events from LOTS of triggers all over the
> place without knowing if anyone is listening for that specific event
> type; the event system sorts it out quickly, and the event payload is
> a void* whose contents are agreed between trigger and listener for a
> particular event type, so I don't take a hit from copying around a
> chunk of payload data for no reason but this does also imply that
> event delivery is sychronous so I can cheerfully not have to guarantee
> that the payload's lifetime extends beyond event delivery (it can be,
> and usually is, a structure just sitting on the stack).  If the
> listener wants to preserve a copy of the payload data then it can take
> a copy, and it already knows how.


	Yes, yes, I was thinking of something quite like that, but does it
*have* to be synchronous to work?



Miguel A. Osorio.