Type-level disparity between keyboard and gamepad input APIs

[alice-i-cecile]

What problem does this solve or what need does it fill?

Keyboard inputs are accessed with Res<Input<KeyCode>>, and their associated variant enum is KeyCode.

Gamepad inputs are accessed with Res<Input<GamePadButton>>, and their associated variant enum is GamePadButtonType.

This makes writing code which abstracts over both keyboards and gamepads (such as input mapping or UI navigation) frustrating.

What solution would you like?

Create a GamepadButtonType input resource, which assumes a single controller.

What alternative(s) have you considered?

Merge GamepadButton and GamepadButtonType, likely with the former's name and latter's functionality.

Work around this in end-user code, likely with associated types or additional optional generics.

Make keyboard input behave the same way as gamepad input, supporting multiple input devices.

Additional context

The fundamental reason for this divergence in API is that the gamepad version stores both which gamepad a button is coming from, as well as its button type. The keyboard API by contrast assumes a single input device.

[parasyte]

Kurinji, bevy_advanced_input, and bevy_input_actionmap provide configurable input bindings. Kurinji uses strings. 😢 bevy_input_actionmap can use enums or strings. And bevy_advanced_input uses enums. The latter two look intriguing to me.

I would caution against combining inputs from multiple sources under a single type (unless they are separable). I know I've had cases where gamepad controls and keyboard controls had important differences in games I've written. Throw in touch screen controls, motion controls, and other forms of input devices, and you have a lot of variation and unique edge cases to consider.