Command built-in controllers via events or another keymap agnostic way.

[scrblue]

As implemented, the controls are hardcoded. This is not a practical design for any serious game.

[bonsairobo]

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.

[scrblue]

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.

[bonsairobo]

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:

https://github.com/amethyst/amethyst/blob/a4d87713f873d59bf5bad37b4c5f9074dd978daf/amethyst_input/src/bindings.rs#L17-L56

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 ControlEvents." That gives an enormous amount of flexibility and control, while still offering a specific way of controlling the camera.

[scrblue]

After looking at the current controllers in more detail, I think the current ControlEvents are sufficient, but making the generic over an input system is still a goal for sure.