An 'Event'ful day of implementation

Published September 04, 2008
Advertisement

Event SystemWhile putting together my fancy new GUI framework, I decided to bite the bullet and implement an actual event system as well. Prior to now, I had always used either a (very) simple message passing scheme or just tied to subsystems together to communicate information around the various parts of the engine. The primary goals of adding a true event system is to make a single point of communication, the 'EventManager', allow all systems access to one another without actually tying them together with headers.

I have implemented something similar to the Game Code Complete 2nd ed. trigger system. If you haven't read his book yet, Mike McShaffrey (sorry if I spelled it incorrectly...) has quite a bit of good insight into the games industry (especially for someone like me that is on the outside looking in!) and what experiences he has had. Some of the sample code is a tad on the beginner side, but sometimes that what you need - something to get you started.

So the basic structure is to allow the event manager to connect an event listener to a particular type of event. There can be multiple listeners for a given event, and there is no guarantee about if a listener will consume a message or not. If it does, then the remaining listeners don't need to try to handle that event. Seems pretty simple and easy to use.

My first implementation was seeming a bit tedious, and I only implemented a single message! The reason is that I was using separate classes for the event itself and the event data. I'm now combining the two classes, and an event will carry it's own data within itself - there's really no benefit that I see to keeping the separate. Anyhow, once this is changed over I should be able to hack in the remaining GUI messages and start getting some real interaction with the buttons and dialogs - it is kind of funny how you get excited about these silly things isn't it??
0 likes 3 comments

Comments

extralongpants
Sounds good. We use a similar system for events in the UI engine where I work. Having the ability to give events multiple listeners is really indispensable. I exercise that feature almost every day.
September 05, 2008 01:06 PM
Jason Z
Cool - its good to know that I'm not heading down a dead-end. So far it seems to be working out pretty well. One thing that seems to be unnecessary is the amount of memory allocation and deallocations while creating and deleting events. I'll have to figure something out about how to reuse a series of events instead of recreating them all the time...

So what type of work do you do? Games or something else???
September 05, 2008 08:47 PM
extralongpants
We're officially a game company, and we do make games, but we spend a lot of time on other, more reliable (not so fun) sources of income, like training programs for the military and edutainment titles.

Our UI engine does indeed have performance problems relating to an insane number of dynamic memory allocations and de-allocations, with events being one of the perpetrators. But to be honest, it still runs quite well in the general case, especially considering that many of our UI screens are very complex, and contain hundreds of controls.

In short, I wouldn't worry too much about event allocations yet. You can profile later and determine whether or not they are worth optimizing.
September 07, 2008 10:25 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement