Open scrblue opened 2 years ago
The controllers do currently work based on events, but the plugins will add a default_input_map
system that hardcodes the bindings.
As a workaround, you could make your own Plugin
that uses all the same systems, except for the default_input_map
.
But I could also try to make the plugins generic over an input bindings system.
Not urgent for my use-case, just something I noticed. I'm planning on implementing my own controller as of now, but if I make a PR with it, I would like there to be a standard for generic bindings.
Perhaps a solution could be to expose an events enum with more "input"-y variants -- something you could map one to one with a button press. As of now the events used aren't much more abstract as using the the LookTransform
itself.
Perhaps a solution could be to expose an events enum with more "input"-y variants -- something you could map one to one with a button press.
I assume you mean something like the amethyst Bindings
type:
Basically a mapping of bevy's Input
and Axis
types.
Consider the FPS controller event:
pub enum ControlEvent {
Rotate(Vec2),
TranslateEye(Vec3),
}
I don't think abstracting over Bindings
works very well here because in some cases (mouse + keyboard) you want a Input
to control the TranslateEye
and in other cases (gamepad) you want an Axis
to control TranslateEye
. The amethyst solution is to have "emulated" axes using buttons. But that seems like a feature best left for bevy proper.
So that's why I think it makes sense for controller to define their own event type to be as abstract as possible. Another crate could provide the abstraction you want in order to generate the events from Bindings
.
As of now the events used aren't much more abstract as using the the LookTransform itself.
I disagree. The controller implementations require a fair bit of complexity that is hidden by the event interface. Many different input schemes could be implemented by "simply" generating those events.
So that's why I like my idea of making the plugins generic over an entire input system. And in Bevy, that's as simple as not implementing the input system at all. The API can be "you just need to run a system that generates ControlEvent
s." That gives an enormous amount of flexibility and control, while still offering a specific way of controlling the camera.
After looking at the current controllers in more detail, I think the current ControlEvent
s are sufficient, but making the generic over an input system is still a goal for sure.
As implemented, the controls are hardcoded. This is not a practical design for any serious game.