Events programming
Author
I'm sure this may have been asked before since a search of "C# Events" turns up a TON of hits so please refer me to any relevant topics you may know of.
In the past I've always heard that using events in games wasn't a very good idea because you can never tell when the event will get sent to the game. While I agree with this for things like character movement and shooting does it also apply for interfaces?
A while back I took a shot at writing a UI with DirectX, I have my buttons (texture mapped quads), panels, etc and had a scheme to figure out what was clicked based on mouse position and z-order of the widgets. After that, it because difficult to follow where to go in the application.
Now I am thinking that I could have my button class public an OnClick, OnHover, etc events that I can subscribe to anywhere. So in theroy, I would still perform the DirectInput checks of mouseposition to see (ok, I just moved over a button) But then, is it feasible to raise an OnHover event or do it the old way like
RenderUI()
{
if mouse is over button a
{
highlight button a
}
etc
}
Also, I got to thinking about events for other um...events.
Say you have an NPC that reacts to a player hitting a door with a hammer.
Do you
A: Every loop check if the player is performing the hit action and has a hammer equipped and if so queue the NPC to perform the action or
B: NPC listens to the OnDoorStruckWithHammer event which is raised when the character hits the door with the hammer.
Basically a difference of procedural versus event driven programming.
Thoughts?
Thanks,
Webby
Events can be very useful in game systems. They are commonly used in RTS games and in quite a few others to some degree or another. If you use an event queue you can send events into the world from any source helping to reduce dependencies amongst components (too much?). It is also only a step away from sending those events out across a network for network play. Debugging can be tricky, in the same way that network debugging is but there are huge benefits. You can have an event queue that is added to by anything and each event has a time stamp and target entity. For example if the AI decides a bot should throw a grenade it can send a 'throw geanade' event to the world which can then spawn a grenade. In addition the grenade when spawned can send an event to itself with a time stamp of 5 seconds in the future to 'explode'. Other possibilities arrise as well if you allow anything to 'peek' at the events e.g. a bot fires a weapon and another bot sniffs the event and decides to duck.
Moved to 'Game Programming'. [smile]
Event based is conceptually more useful and you will probably write cleaner and less complex code, which indirectly will possibly improve performance.
Writing a polling/procedural implementation may be less intuitive and therefore lead to slightly more confused/complex code that actually executes less efficiency.
Basically, operating 'to the metal' and avoiding convenient abstractions may be a false economy [wink]
Another consideration revolves around the move to parallel/multi-threaded architectures. These, by design, have unexpected and OoO execution patterns - so this idea of procedural polling might well be more aligned to the 'old school' approach. Mere speculation on my part, but figured it was worth throwing it into the debate [grin]
hth
Jack
Quote:Basically a difference of procedural versus event driven programming.I'd imagine the difference is negligable if anything at all. I would go so far as to say that the change in programming paradigm is more important.
Event based is conceptually more useful and you will probably write cleaner and less complex code, which indirectly will possibly improve performance.
Writing a polling/procedural implementation may be less intuitive and therefore lead to slightly more confused/complex code that actually executes less efficiency.
Basically, operating 'to the metal' and avoiding convenient abstractions may be a false economy [wink]
Another consideration revolves around the move to parallel/multi-threaded architectures. These, by design, have unexpected and OoO execution patterns - so this idea of procedural polling might well be more aligned to the 'old school' approach. Mere speculation on my part, but figured it was worth throwing it into the debate [grin]
hth
Jack
Quote:Original post by WebsiteWill
In the past I've always heard that using events in games wasn't a very good idea because you can never tell when the event will get sent to the game.
So?
What should the game care when particular events occur? Most events don't care. If this event occurs, do this reaction. Those that do care (say... player joins the game) can easily keep or query the game state to change their reaction based upon that info.
Yes, event driven code can be a little entangled at times when debugging, but if you keep your modules properly contained then they provide a powerful mechanism to allow access and interaction independent of the source.
Author
Most excellent advice. :) Thanks for the move also, for some reason I had intended for the question to be more DirectInput focused and as I was writing I realize it was basically a generic of to event or not to event.
I prefer the event driven paradign actually since I'm more accustomed to it in my daily chores. I had always stayed away from it because of stuff I read in old DirectX books and I think on here that event driven programs generally weren't a good idea because you could never predict exactly when an event would get heard.
I guess we've progressed to the point where this is ok. I'm ok with that. :)
Thanks all,
Will
I prefer the event driven paradign actually since I'm more accustomed to it in my daily chores. I had always stayed away from it because of stuff I read in old DirectX books and I think on here that event driven programs generally weren't a good idea because you could never predict exactly when an event would get heard.
I guess we've progressed to the point where this is ok. I'm ok with that. :)
Thanks all,
Will
There is a difference between what old DX books would refer to an event (usually a message placed into a queue which is later picked up... sometime) and what a C# event is (a signal/slot mechanism which runs the listeners immediately).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
