In the menu system for our game (selecting levels, options, etc.), the player presses the a button on the gamepad to go to the next screen. I coded the menu system to wait until the button is released before taking any action (i.e., displaying the next screen). Some recent playtest feedback suggested that we do it the opposite way: take action as soon as the button is pressed. I am curious, what is the standard way this is handled, and does it even make a difference?
In a game which is controlled by a gamepad, where control inputs directly change GUI focus from one GUI button to another, those GUI buttons should be activated when a controller button is pressed.
In a game which is controlled by a mouse (or if a gamepad is used to move a virtual mouse cursor around the screen), on-screen buttons should be activated when the mouse/controller button is released over the same button on which it was pressed. (If the press occurred over one GUI button, and the mouse was then moved, and released over a different GUI button, neither GUI button is activated)
The reason for this is that people's mouse control skills are highly variable, and often people have a little trouble positioning the cursor exactly where they want it, or even telling precisely which GUI button they're hovering over at the moment. The theory is that people can press and hold the mouse button to make the GUI button highlight, and if that GUI button wasn't the one that they intended to use, they can move their cursor away from it before releasing the mouse button in order to avoid pressing it.
But if your game is being controlled by a gamepad, then you absolutely want to take action when the gamepad button is pressed, not when it's released.
Edit, five years later:
In the time since this answer was posted, a new standard has begun to emerge for handling mouse-style cursors which are controlled by gamepads.
In the answer above, I suggested that these should be implemented to work exactly like cursors which are actually being controlled by mice; highlight on mouse-down, activate on mouse-up if the cursor is still over the same GUI element.
But now, gamepad-controlled cursors typically activate a GUI action after the gamepad button has been held down for a period of time (typically about one second). If you're going to follow this system, you'll need to have an on-screen indicator showing how long until activation will occur (often this is a little ring around the cursor itself, which fills up as you get closer to activating the hovered-over button), and you still need to highlight the element which will be activated, during the time that the button is being held down (and it might be a good idea to do that any time the mouse is over an element, even if the button isn't being held). While the button is being held, the cursor should not be able to be moved, in order to avoid accidental activations of GUI elements if the cursor is jostled at the last moment.
The benefit of this system is that it allows a user whose mouse-style cursor is over the wrong spot to avoid activating that element by just releasing the button early; the mouse-style "move away from it before you release" is less natural to accomplish on a gamepad than with a mouse, and this approach allows a gamepad user to abort an unwanted click far more easily.
We're even starting to see a few games experimenting with this cursor interaction model even when their cursor is being moved by a real mouse. No Man's Sky does this, as one example. It will be interesting to see whether this approach to handling mouse-cursor interaction will become increasingly common and expected over the coming years.
I'd take action as soon as the key is pressed.
The best example where the action took place after the key was released was in Starcraft: Broodwar. When I would press the keys very quickly, I would often press the next key before completely releasing the previous one which led to some commands being ignored. (1A Click, 2A Click, 3A Click - the 2 would be ignored)
This was changed in Warcraft III and the game felt a lot more responsive to me as a result and I never had the 'sticky control group' problems from Broodwar.