General

Re: Which would you prefer....?

ShawMishrak — Mon, 28 Jan 2008 15:38:46 GMT

Perhaps this is another issue where feedback would be very useful.

Currently, the input state information is propogated around the engine as messages, as LordIkon has stated. This is a global event subscribable by all engine systems. Every time the input system detects input state changes, this event handler is called with appropriate event types. The system is very similar to the Windows message pump, with the exception of message types being derived classes from a common interface type. Engine-level code would see something like:

public void MyMessageHandler(IMessage msg)
{
    // Process message type and perform appropriate logic
}

To game code, this approach may become somewhat messy. However, this abstraction seems necessary to decouple the internal engine systems. To accomodate a more clean interface for game-level code, an input mapper will be created. This mapper will subscribe to and process input events, along with an internal key/button -> event name mapping, and maintain internal states. Game-level code will then be able to make calls like:

public void Update(GameTime gameTime)
{
    if(inputMapper.IsEventActive(MyEvents.MoveForward))  // Key/button bound to "MoveForward" is being pressed/held.
    {
    }

    if(inputMapper.IsEventJustFired(MyEvents.MenuItemActivate))  // Key/button bound to "MenuItemActivate" was just pressed this frame.
    {
    }
}

Clearly, input control is just one use of the messaging system.

Comments?

Re: Which would you prefer....?

Lord Ikon — Mon, 28 Jan 2008 13:29:39 GMT

The messages will be coming through the engines message handler via custom messages, and will be for mouse, keyboard, and gamepad.

Re: Which would you prefer....?

Johnhaw — Mon, 28 Jan 2008 12:07:58 GMT

I'd do with Method2 as well. I think the naming conventions are more descriptive of the controller state. I would want the threshold between Down and Held to be configurable.

Do these come as messages (a la Windows WM_LBUTTONDOWN), or as state passed to an update call (i.e. a replacement for MouseState)?

Re: Which would you prefer....?

Lord Ikon — Mon, 28 Jan 2008 09:54:11 GMT

Kafeen:
For naming conventions from your descriptions I'd say method 2 makes more sence. Pressed and Released sound the button has just been pressed or released on that frame, so that's a little misleading based on your descriptions. I also think that the functionality of the ButtonHeld is rather pointless since it's basicly going to provide the same information as ButtonDown with the exception that it won't report buttons that were only pressed this frame causing a one frame delay on any input using this command.

Sending messages whenever a button is held allows you to perform actions that will occur only when a button is held. One thing I've run into in the past is a camera that moves whenever you hold in a mouse button (similar to World of Warcraft), but whenever you click a single or double mouse click you wouldn't want the camera reacting because you're likely interacting with UI.

Re: Which would you prefer....?

Kamujin — Mon, 28 Jan 2008 08:54:23 GMT

ButtonUp = Single event for button transition from down to up.

ButtonDown = Single event for button transition from up to down.

ButtonPressed = Continuous events for buttons that are down.

ButtonHeld = Continous events for buttons that are down for longer then a configurable time threshhold.

Re: Which would you prefer....?

Mrmuzz — Mon, 28 Jan 2008 07:37:01 GMT

Hmm, I would have been tempted by #3, given its most similar to the ButtonState.xxx enum that you'd use via GamePadState...

But then I guess this is meant to sit about that, and include keyboard input too.

Re: Which would you prefer....?

Matthew Knowles — Mon, 28 Jan 2008 07:35:29 GMT

For naming conventions from your descriptions I'd say method 2 makes more sence. Pressed and Released sound the button has just been pressed or released on that frame, so that's a little misleading based on your descriptions. I also think that the functionality of the ButtonHeld is rather pointless since it's basicly going to provide the same information as ButtonDown with the exception that it won't report buttons that were only pressed this frame causing a one frame delay on any input using this command.

Personally for my own projects I have something similar to:
ButtonUp:           Buttons that are up
ButtonDown:       Buttons that are down
ButtonPressed:    Buttons pressed this frame
ButtonReleased:   Buttons released this frame

Seems to cover anything I need.

Re: Which would you prefer....?

Camp ELM — Mon, 28 Jan 2008 06:37:10 GMT

Based on your descriptions #2 makes the most sense to me. The third option makes it seem like you're checking for a button event like it was just pressed or released

Re: Which would you prefer....?

Nick Gravelyn — Sun, 27 Jan 2008 23:44:00 GMT

For those event descriptions I would go with #2. Reason being that the ButtonPressed event is relateable to the KeyPressed event in WinForms which is caused by a button being pressed and then released. So to ease confusion I would go with #2.

Re: Which would you prefer....?

Joel Martinez — Sun, 27 Jan 2008 23:41:42 GMT

I'd cast my vote for method #2 simply because I prefer the language "button held".

Which would you prefer....?

Lord Ikon — Sun, 27 Jan 2008 23:26:26 GMT

We're working on an engine right now (QuickStart Engine), and we've come across a simple question and would like your guys' input on it.

If you were using an input manager for controls for your video game, which would you prefer as an easy-to-understand button naming convention? Basically, which of the following schemes makes the most sense to you? And in your response if you could give a small comment on why it was the easiest to understand. And finally, if you think you've got a better one, feel free to post your suggestion. Thanks guys.

Method 1:
"ButtonUp": For buttons that are up.
"ButtonDown": For buttons that are down.
"ButtonPressed": For buttons that are down for more than 1 frame (being held down or pressed for a period of time).

Method 2:
"ButtonUp": For buttons that are up.
"ButtonDown": For buttons that are down.
"ButtonHeld": For buttons that are down for more than 1 frame (being held down or pressed for a period of time).

Method 3:
"ButtonReleased": For buttons that are up.
"ButtonPressed": For buttons that are down.
"ButtonHeld": For buttons that are down for more than 1 frame (being held down or pressed for a period of time).