Jump to content
  • Advertisement
Sign in to follow this  

Message/Event Handling and Actions taken

This topic is 3985 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Couldn't figure out what to title this post, but I have a question concerning event handling in games. I have a small event handling system in the game engine I am building. For example, if a user presses a key, a keyboard-down event is fired. Then, based on the state of the game and the key binding, another event may be fired. If the user presses the key that binds to walk forward, a move-forward event is fired. The question I'm pondering concerns when more than one 'system' receives an event. Going back to the move-forward example, I can think of two systems that want to examine this event: the physics system, and the animation system. What I don't want to do is fire two events (physics-move-forward, animate-move-forward). It seems logical and ideal to fire just the move-forward event and allow the listeners to do their own thing. But there's the problem. Say I fire just the one event, move-forward, and pass it a relevant parameter (the entity who is being moved). Now the physics system and the animation system both receive the event with the entity. But how does the animation system know that the entity has a model? I could only think of two solutions: use the visitor pattern to determine the type of entity (assuming a tradition inheritance hierarchy - entity is the base class which is passed in the event, derived types such as PlayerEntity are known to have a model for example) or use a component-based entity design (in the animation system, syntax might looks like: if( model = entity.GetComponent( 'model' ) ) { ... } ). I've done the component-based entities in a previous engine and it worked out OK, but I wasn't crazy about it or anything. Thoughts? Or should I just fire off two separate events? Right now, the player is firing off it's own events based on keystrokes (although this could change in the future), which would make it the perfect candidate for knowing which events it needs to fire (physics-move, animate-move, etc.. )

Share this post

Link to post
Share on other sites
I fail to see the problem.

In event systems, you have producers and consumers. When a consumer receives an event, it reacts. It doesn't ask itself where it came from or why, events are dogmatic.

What you pass in the event is up to you - but receiver will act upon that.

Perhaps greater problem here lies in wrong approach to causality. Physics may stop player from moving, but animation will still play uninterrupted.

So perhaps a better approach is:

input -> physics -+-> animation ---> Renderer
+-> world state -> Event handlers

Physics determines who moves where and can prevent it. When it has established that, it notifies other systems with this new information. For one, animation will play, and world state will be updated with new player location.

Animation system will now receive a notification that it should play animation_x from frame 7 to frame 28.

World state however notifies any event handlers that player's position has changed, and it gives them a chance to react.

How you choose to pass the events, and what they contain is up to you. The choice depends on isolation (how much access to entire system do you want to give to each subsystem) and programming model (stack-less approach is to pass everything via messages, shared memory model uses global storage and applies locks as needed).

It's really up to you how you structure individual systems, and how they'll interact.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!