InputMap Plugin

[PradeepKumarRajamanickam]

It would be nice to have an InputMap system like in godot or unreal's ActionMappings. It will convert user input from different input hardware into game specific actions.

eg,
Keyboard "Space" or Joystick "A" can be mapped "Jump" Action.

This allows game code to not be tightly coupled with a particular key event. It also makes key rebinding possible if we add support for storing keybindings in an external json file (or something similar).

Godot Input Map
Unreal Action Mapping

[cart]

Yeah I think this is a must-have feature for serious games. People can currently build their own versions of this on top of the existing input events, but it makes sense to build something standard that everyone can use.

[PradeepKumarRajamanickam]

I am working on a prototype plugin. Will share more info when I have something ready.

[PradeepKumarRajamanickam]

I have made some progress.
PR: #448.

Features
new* Input Map Example
new* Keyboard Key Mapping
new* Mouse Button Mapping
new* Mouse Axis Mapping
new* Action Strength
pending* Deadzone implementation

[PradeepKumarRajamanickam]

Note*
Active prototype plugin development has moved to https://github.com/PradeepKumarRajamanickam/bevy_input_map

Update*

• done* Deadzone implementation
• added* readme

[PradeepKumarRajamanickam]

Now available on crate.io
bevy_prototype_input_map = "0.1.0"

[PradeepKumarRajamanickam]

New version available on crate.io
bevy_prototype_input_map = "0.1.2"

Update*

• new* Ability to set custom strength curve
• new* Public API
• updated* example/readme to match new api

[PradeepKumarRajamanickam]

Bevy Prototype Input Map 0.1.3

Now available on crate.io
https://crates.io/crates/bevy_prototype_input_map

Whats New

• Binding Stack:
  Ability to Push/Pop bindings

• JSON/RON Support:
  Serialised strings can now be used to set bindings.
  Check out "example/binding_from_json.rs"

[Wcubed]

I think, while it is awesome that there are plugins that do this (three at this moment: bevy_advanced_input, bevy_input_actionmap and kurinji), it would be a good idea to have this feature eventually integrated with bevy by default and not as a plugin; given that it is something that (almost?) all games have to deal with at some point.

This would allow input mapping to be included in the official examples, and help guide new developers to using a mapping system, instead of reading the input codes themselves.

[alice-i-cecile]

I'm eventually planning on upstreaming https://github.com/leafwing-studios/leafwing-input-manager for this.

[alice-i-cecile]

Update from the future: an observer-based design based on https://docs.rs/bevy_enhanced_input/latest/bevy_enhanced_input/ appears better to me. It maps better to how input works, is more expressive, and has a better serialization model.

[Mantissa-23]

Update from the future: an observer-based design based on https://docs.rs/bevy_enhanced_input/latest/bevy_enhanced_input/ appears better to me. It maps better to how input works, is more expressive, and has a better serialization model.

Just wanted to comment having used both of these:

• It's nice to have the option to use push (observer) or pull (system query on input map), because different pieces of logic are easier to express in one or the other (for example, running a character controller's FixedUpdate loop reading directly from input is impossible to do in an observer as you'd get frames where the controller isn't running). I think it would be a mistake to go the route of JUST using observers.
• bevy_enhanced_input abstracts actions away as having an arbitrary input (from bool -> f32 -> Vec2 -> Vec3 I believe) and an arbitrary output (from bool -> f32 -> Vec2 -> Vec3). It also provides helpers for swizzling and extending inputs. This is really nice, as you can specify a triple-axis/vec3 Action like Move, and then bind, say, the left stick to the X/Y axes and then A/B to the Z axis. Whereas it's not clear or straightforward how to do this kind of mixing in Leafwing. I also just prefer the naming conventions- It can get a bit confusing in Leafwing to have ButtonLike, AxisLike, DualAxisLike and TripleAxisLike, then .button, .value, .axis_pair and .axis_triple to extract them in a system- The names just don't line up as well and there are a lot of types defined.
  • On the flipside, my biggest ergonomic issue with enhanced_input is that when reading an actionstate from a system, all of the types get erased! So if you define a Look action as Action<Vec3>, you then have to re-specify that type when querying it in a system. This is strictly for pull, it doesn't happen in observers. It's also not THAT big of a deal, and I'd take this tradeoff for having Action definition being generalized.
• I do feel like Leafwing's input processing pipeline gives more control than the modifiers enhanced_input supplies. I feel like it's easy enough to establish a circular deadzone on JUST a controller's joysticks in Leafwing, but I couldn't figure out how to do this in enhanced_input. Really, I feel like both libraries could benefit from separating processing pipeline and bindings to a greater extent... Like, it would be really nice to be able to define deadzones on arbitrary sets of axes (i.e. circular on left stick and right stick), and then map those entirely separately (i.e. to MoveX, MoveY, LookX, LookY). In Leafwing you HAVE to use a DualAxis Actionlike if you want to use a CircularDeadzone for example.
• I prefer Leafwing's approach of defining each Action as an entry in an enum, instead of enhanced_input's approach of each Action being a separate struct that later gets bound to a Context. I feel like it's possible with enhanced_input's approach to accidentally bind an Action to multiple Contexts, which... I feel like that could get confusing if you then bind two contexts with the same action to a single Entity. But the plugin seems to officially support this and consider it a valid workflow.