Re: Event based system

[adam moss <adam@gimp.org>]

"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.

> One other thing... I was wondering if it is possible to build a game
> engine which is event driven and make this scheme work transparently
> with networking, like, the programming interface for sending a message
> to a local object is the same as for sending messages across the
> network.

It's certainly possible, though it imposes some design
constraints.  Events would have to be delivered asychronously (for
latency), plus any event-specific data would have to be totally
serializable (no void* pointers! :) ), very likely in a manner specific
to the event type (unless you want to assume identical software versions
and architectures on both ends of the wire, or anything else that might
make binary structure layout non-trivial to send over the wire) which
would be painful.  Wouldn't be that bad if you were happy to write
any structures that needed passing in IDL, accepting the constraints
thereof.  Might be able to nick some of CORBA's on-the-wire protocol
for the serialization of such structures.

If your event structures are simple, manually serializing is not a big
headache.  Either pre-define the various event types in the event
system or allow the application to dynamically register event-type-
specific callbacks to handle its own de/serialization.  Using something
like IDL and then autogenerating the de/serialisation code seems like
The Right Way, but you have to have quite a lot of different and
complex event structures for it to be less effort than just kludging
things by hand.

You'd have to know that the listener cared about your particular
event type before you sent it over the wire, at least if you
plan on issuing a lot of events.  Not tricky, you just get
listeners to register their interest in events from certain
emitters beforehand (probably asychronously again, and you'd have
to resign yourself to possibly missing some such events in the
meantime).

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.

--Adam
-- 
Adam D. Moss   . ,,^^   adam@gimp.org   http://www.foxbox.org/   co:3
"You could make a mince pie mountain and
carve yourself a lair inside to live in."