Jump to content

View more

Image of the Day

#indiedev  #indiegame #screenshotsaturday https://t.co/IwVbswGrhe
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

Game Event System

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 Kanefa   Members   


Posted 06 March 2014 - 04:19 AM

I was reading the Simple Event Handling article and I noticed every class that inherits IEventHandler registers as a listener for all events.  The class then implements the EventHandler member function and handles the events it is interested in.  


This is a bit different that what I expected.  In a more complex event system wouldn't the game event manager class register the listener and a specific event?  Then the game event manager class is tasked with matching the event with the listeners.


I just want clarify that this is a simplified implementation and not a mistake in my understanding.



Next, I have a question about integrating something similar to the Simple Event Handling article into my game.  My confusion stems from the fact my game loop already polls for events and then feeds these events to my already existing HandleEvent functions that cascades through my game.  I assume both these systems are necessary, but I would seem to need two different HandleEvents functions.  One for events coming from the OS and then one for events that I create at a much higher level.  I am having a hard time visualizing how I imeplement both these systems independently of each other in the same code base.  Any help would be much appreciated!






#2 Strewya   Members   


Posted 06 March 2014 - 05:09 AM


I'm just going to point you to this great post by L.Spiro.

The events you get from the OS are NOT the same thing as gameplay/high level logic events. You translate OS events into gameplay events where applicable (mostly input events), and the others are fed into certain systems directly or by translating them into system specific function calls, but not by going through your high level events system.


Of course, this can be done in many different ways, but the general idea is that you should not treat OS events the same way you treat your high-level-game-specific events.


As for how event dispatching can be done, depends on the use case, in certain situations you need to propagate every event to every listener, in other situations you should filter them out. Do what suits you best, and whichever solution makes you feel good when using it.

Edited by Strewya, 07 March 2014 - 01:50 AM.

devstropo.blogspot.com - Random stuff about my gamedev hobby

#3 haegarr   Members   


Posted 06 March 2014 - 05:35 AM

There are many possibilities to dispatch events, and there are many solutions of how to supply your game sub-systems with informations. Of course, it depends on your overall coding philosophy and the particular purpose you are interested in.


Registering to be notified for each and all events may be as bad as registering for each single kind of event. It depends on how many kinds of events exist, how high the rate of events is, how many listeners there are, how many kinds of events a listener is interested in, how many virtual functions need to be invoked for dispatching an event, how high the administrative effort is to manage listeners / listener plus event filters, and perhaps more. Dispatching inside the listener by using a switch, registering with distinct event queue's, using a filter on events before invoking the listener, … are all valid approaches. Perhaps a mix of several of those is the way to go in the end. However, the article is titled "Simple Event Handling" ;)


In the OP you are speaking of input (and perhaps other OS / windowing system generated evens) as events as well as game related "high level" events (without further specification). It is probably not wise to mix them up. Besides the fact that the solution I'd prefer don't propagates input at all, you may think of translating input into game events in an early stage. E.g. if a handler detects a specific input situation when investigating the current input queue (I mean a self implemented queue here, not the OS provided queue), then it generates a game event accordingly to an input configuration (you know, the player likes to map her owned input devices to game events).

#4 jHaskell   Members   


Posted 06 March 2014 - 07:40 AM

If this is your first experience with implementing your own Event System, I recommend just sticking with the Simple method to start.  Once you've gotten that fully functional you can think about enhancing it.  


One simple enhancement possibility:  Instead of maintaining a simple list of listeners and sending all events to all listeners, maintain a map of event type keys to list of listeners values.  Then each listener registers for a specific event type, or even registers for multiple event types, and your Event Dispatcher will only send an event to those listeners specifically registered for that event.

#5 Kanefa   Members   


Posted 07 March 2014 - 09:35 AM

Thanks guys that helped clear it up.  Also, I really like that idea of using a map with lists of listeners.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.