Sign in to follow this  

Message/Event Handling and Actions taken

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this