java - Polling vs event driven input

I'm developing a game using polling for the input method. However, now that I'm delving deeper into the game menus and other UI components, I'm finding that I'd probably like to have event driven input. Perhaps even having both, using event driven for the UI and polling for the "world" input. I'm curious on what the best way to go is.

I'm defining polling as: each update loop I check what keys are press, where the mouse is, buttons pressed, then run through them and do actions based on the info collected.

I'm defining event driven as: interrupt based events, when an event happens and interrupt is triggered and a code block is run based on the event.

Do you think it's best to go all event driven, all polling, or is a combination of both acceptable? If you have pros and cons for either please list them. Thanks.

EDIT

The game is Java/OpenGL based, so will be released to Windows/Mac/Linux. The possibility of extending that to mobile devices is low. The game is RTS style, 3rd person 3D.

EDIT 2

I'm still not totally happy with the way I've implemented this, but what I'm moving toward is catching events in my UI and if they're not handled by any of my UI components, I pass the event on to the "World" for picking/selection. Something like:

@Override  
private boolean handleEvent(Event event) {  
    if(hud.handleEvent(event)) {  
        return true;  
    }  
    return WORLD.handleEvent(event);  
}

This way I don't get clicks leaking through the UI to select objects behind buttons and what not.

Currently my camera controls are still based on polling, and that seems to be working for now, but I may update that later on.

I appreciate all the answers, sorry I could only pick one!

Answer

It depends on the requirements of your game and hardware. Most games are usually interested in changes to input state, i.e. user presses the fire key and their weapon starts firing, user releases the fire key and their weapon stops firing, user presses the move key and starts moving, releases the move key and stops moving, etc., so an event-driven input system makes the most sense in those cases since the information is already in a suitable format. Plus on the Windows platform, you already receive events for changes to keyboard and mouse state, so it's often a 1:1 conversion from low-level input events to high-level game events. With polling, you'll often find yourself having to generate such events manually by comparing state between the current and last frame. Basically, "which buttons are pressed now?" tends to be far less useful information than "which buttons have been pressed/released this frame?", and given an initial keyboard/mouse state when you initialize your input subsystem, the former can be inferred from the latter anyway for those cases when you need it.

That being said, on certain platforms you're stuck with polling input at a low-level and there's no way around doing the edge checking yourself. However, I've always achieved the best results using events for all high-level logic since that's naturally how those systems tend to operate.