Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Had an idea for a modification to a game, however the core functionality heavily involves UI, and the API for the mod is event based.

The player will have there own custom data object, so I know one option could be

onClickEvent { 
if Player doing X task { player.doX}
if Player doing Y task { player.doY }
}

on ScrollEvent {
if Player doing X task { player.setXValue}
}

I have a feeling this is not the best approach, so my question is what is the best approach to an event driven UI?

share|improve this question
add comment

2 Answers

up vote 0 down vote accepted

There are many ways to handle events. Direct dispatch is the easiest, but least efficient in many cases. When an event happens, generate the event object and then pass it off to the HandleEvent method of any potentially interested game object. Since the GO does its own event filtering, this gets expensive as the number of events and interested GO list grows.

You can remove the manual filtering by giving each event object a virtual SendTo method that selects the correct handler. The InputEvent might call OnInput on the target GO, while the CollisionEvent might call OnCollision. The handlers can be empty virtual functions in the base GO class.

To get around the expense, consider using an observer pattern for some events. The GO registers which events it cares about and which handler to call. Then events are only delivered to the objects that are actually interested, not just potentially interested. You can keep the list of registrations in a Dictionary on the event emitter object (eg your InputSystem) easily.

It's common to have a mix of event delivery methods. Some events make more sense in an observer system, some in a direct dispatch system.

share|improve this answer
    
Thank you, this is what I was looking for! If I went for a direct dispatch design, it would be very messy because of the amount of possible functions one event could involve. So I was hoping to find a more OO approach and the observer pattern seems to be the answer! –  thedeadlybutter Feb 3 '13 at 22:47
    
@thedeadlybutter You could also try signals/slots, the famous Qt library uses this design, as with most GUI libraries. –  miguel.martin Feb 6 '13 at 8:51
    
signals/slots handle sending the message, not the logic about when to send it. signals/slots or a variant is a good way to implement message sending though. –  Sean Middleditch Feb 6 '13 at 19:57
add comment

It's very similar to non event driven and is a bit harder. This is what it would look like:

if (Mouse.isLeftButtonClicked && Mouse.isOverControl(Controls.addButton))
    Event.fire(events.addButtonEvent);
//ect

And:

void AddButtonClickedEvent()
{
    MessageBox("You Clicked The Add Button!");
}
//ect

So it's pretty much the same on the inside, and it uses more resources. Events are used by things such as Visual C# so it's easier for the programmer since you not making the events most of the time. It would have just been easier to do:

if (Mouse.isLeftButtonClicked && Mouse.isOverControl(Controls.addButton))
    MessageBox("You Clicked The Add Button!");

Some of the code is messier but it's still better.

Although if I were to go with events I would do something like my example of events above.

share|improve this answer
    
In my case, multiple events will have to be shared between different functions. Example, the on click event might do 3 different things based off some setting (Like copy, move, etc). In that case should I check the each setting if the event is relative to it, and then perform whatever action it does? As I said above, I could do this, but I'm interested if there's a more efficient / clean way of doing it. –  thedeadlybutter Feb 3 '13 at 7:23
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.