Better game event handling?
(somewhat C++ question...)
Hey everyone, I come to you today with a simple conundrum that's been puzzling me over the last few days :(.
I am using SDL for my event handling, and I often see people cramp over 100 lines of code of event handling in their main loop that does everything from key presses to mouse movement. In order to avoid this I decided to roll my own simplistic event handling code, however I think I missed something because I am under the impression that it may not be sufficient (for anything).
So far I wrote something fairly simple and much like the "Simple Event Handling" article (though I didn't rip it) :
Each class that wants to handle events inherits a constructor from an abstract parent class(that registers the class as an event handler and adds it to the big vector that gets processed in the main loop) and a pure virtual method performEvent() that contains events as series of if/switch statements. The vector of events is then processed in the main game loop (while()). Both the registering and processing methods are public and static. I am sure some of you have seen this approach before.
However, I can't quite put my foot down on whether this is sufficient for a game, considering there can be a lot of events to handle, from enemy moving closer to the player, to the player shooting, moving, and so forth.
Can anyone point out a better way of handling events in games?
First, I'd separate external events from internal events. External events, such as key-presses and mouse movement, should be handled together in an input system which transforms them into internal events compatible with the way you're managing all the other events.
Second, my usual approach is to place all internal game events in a scheduler, each being associated with a delay. Once the delay is over, the event is pulled out from the scheduler and executed. This allows a bit more flexiblity over the simple "event handler list" without associated times, since you can specify delays much easier.
Other than that, I've found this more than enough for most game concepts.
Second, my usual approach is to place all internal game events in a scheduler, each being associated with a delay. Once the delay is over, the event is pulled out from the scheduler and executed. This allows a bit more flexiblity over the simple "event handler list" without associated times, since you can specify delays much easier.
Other than that, I've found this more than enough for most game concepts.
Events are generally directed to an entity or a group of entities. Then it turns into a message, that gets dispatch to the relevant handlers. How you decide which entity would be interested in that type of event (keyboard, screen size change, mouse move, game state change, network packet, ...) depends on a lot of things.
just my $.02.
just my $.02.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement