Archived

This topic is now archived and is closed to further replies.

stodge

Event queue and events in games

Recommended Posts

stodge    144
I was just wondering which method people preferred to use in Games for event handling: 1) Create some kind of Windows-like event (message) loop. Events are placed in a queue, and then later, the event-loop extracts the events and processes them. Events are prioritised, with the higher priority events being processed first. 2) The events are processed as soon as they are raised, so there''s no event queue. Which do you prefer and why? Thanks

Share this post


Link to post
Share on other sites
Dobbs    164
The latter. The only real advantage I see to the first option is that you can easily defer event processing until a later time, and maybe prioritize events by substituting a priority queue - for instance if you have lots of events whose processing isn''t very critical and you''d rather spend more CPU time this frame on AI updates instead. I imagine most people (or at least most people browsing these forums) prefer the first option since they are probably developing relatively simple/small games (I hope so anyway) that don''t have such concerns.

Share this post


Link to post
Share on other sites
stodge    144
I can prioritize the events; for example I have a log msg event that is raised. This would be the lowest priority event.

Thanks

Share this post


Link to post
Share on other sites
leeWinder    122
I personally think having a priority queue is a much safer way to handle the situation for one simple reason. Handling an event as it occurs means that the handling code could be called AT ANY TIME during execution of the code, especially if using threads. This can cause serious problems as the event may need to reference data/other events etc. and as you dont know when the event code is called, the state of memory is also unknow. By having a queue which you handle at a certain point in the code means you know the exact stuture and state of memory at that point and can do what ever you want. Of course it all depends on the type of event... Disk errors etc need to be called as and when, but sound events, controller events etc can wait till the next frame.

Share this post


Link to post
Share on other sites
PaleRaider    122
I prefer the first option myself. There are a lot of benefits to using a queue. As you mentioned you can prioritize message handling. Yet there a several other key benefits as well. One benefit of using a queue is that you have a built in ability to save a game for "replay", this is really only viable game feature for RTS games and the like.

It also allows for easy integration of network facilities. This can be accomplished by defining a Queue interface and having implementations for normal, network, and composite queues. Use the composite queue all the time and when you require network play construct a network queue and add it to the composite queue. Of course doing this means the composite queue is really responsible for the prioritizing and dispatching but that is an implementation detail.

For the OO inclined it provides a nice decoupling of the user input system and other parts of your game engine. I.E. you can create your engine first and be able to test it by generating events in code, this is great for brute force unit testing. Earlier I mentioned the ability to persist the contents of the queue; well this actually is VERY useful for debugging because it will allow you to exactly replicate the actions that were previously taken. This is really a key thing when other people are beta testing it for you, or your game is simply “out in the wild”.

In case no one else will mention this there is a GOF pattern called Subscriber/Dispatcher, I believe but I could be wrong on the name, that pretty much outlines the how to use message queues effectively and all their benefits.


[edited by - PaleRaider on January 30, 2003 7:52:58 PM]

Share this post


Link to post
Share on other sites