You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This proposal is heavily based on the ideas in #12770. I strongly suggest you read the PR description before continuing.
The current way of doing input doesn't differentiate between different sources of the same type very well. This isn't an issue for keyboards and mice where we expect there to be only one instance of each, but gamepads break this assumption. Our current solution is to store the gamepad associated with the button and to provide the user with a resource that keeps track of all gamepads we know about. As #12770 points out, this leads to a lot of unnecessary boilerplate around working with gamepad input. Another issue is that gamepads may not implement all possible features (e.g. rumble). Treating gamepads as entities provides a good solution for both problems. Components help us attach unique state to each gamepad entity and if a gamepad doesn't implement a feature we can just not give it a component for said feature.
The actual problem statement
The assumption that there will ever be only 1 keyboard or mouse is wrong. For example, macro pads exist. Also there's no good reason why a local co-op games shouldn't let you hand a second keyboard to your friend. Currently, we don't have the tools to deal with multiple input devices of the same type at the same time and we can't even let our users build these tools since we don't expose which device produced an input event.
Input devices get their own entities with input components added based on their capabilities.
For scenarios where we don't care about distinguishing between devices I propose we add a new system param called Input. This type would be generic over input component. We could then specify methods for each type of input we can read.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
This proposal is heavily based on the ideas in #12770. I strongly suggest you read the PR description before continuing.
The current way of doing input doesn't differentiate between different sources of the same type very well. This isn't an issue for keyboards and mice where we expect there to be only one instance of each, but gamepads break this assumption. Our current solution is to store the gamepad associated with the button and to provide the user with a resource that keeps track of all gamepads we know about. As #12770 points out, this leads to a lot of unnecessary boilerplate around working with gamepad input. Another issue is that gamepads may not implement all possible features (e.g. rumble). Treating gamepads as entities provides a good solution for both problems. Components help us attach unique state to each gamepad entity and if a gamepad doesn't implement a feature we can just not give it a component for said feature.
The actual problem statement
The assumption that there will ever be only 1 keyboard or mouse is wrong. For example, macro pads exist. Also there's no good reason why a local co-op games shouldn't let you hand a second keyboard to your friend. Currently, we don't have the tools to deal with multiple input devices of the same type at the same time and we can't even let our users build these tools since we don't expose which device produced an input event.
My proposal
ButtonInput
,Touches
and others get turned into components.For scenarios where we don't care about distinguishing between devices I propose we add a new system param called
Input
. This type would be generic over input component. We could then specify methods for each type of input we can read.Other solutions
DeviceId
inKeyboardInput
,MouseMotion
,MouseWheel
,MouseButtonInput
,TouchInput
,TouchpadMagnify
andTouchepadRotate
so our users can implement their own solutions.or
Beta Was this translation helpful? Give feedback.
All reactions