Leafwing-Studios / leafwing-input-manager

A straightforward stateful input manager for the Bevy game engine.
Apache License 2.0
616 stars 92 forks source link

Analog input range modification #505

Open MickHarrigan opened 3 months ago

MickHarrigan commented 3 months ago

What problem does this solve?

This allows a mapping of a certain range of analog inputs to different actions, such as walking or running on the same input.

What solution would you like?

An example of the intended usage is akin to this:

enum Actions {
    Walk,
    Run,
}

// with expected usage similar to this
let input_map = InputMap::new([
    (Actions::Walk, DualAxis::left_stick().with_range(0.0, 0.5)),
    (Actions::Run, DualAxis::left_stick().with_range(0.5, 1.0)),
]);

where bounds could be set on some analog input such that different actions are tied to either the x, y, or magnitude component of an analog input.

In setting this up you could have a 3d game in which the walking or sneaking or other similar movements tied to the distance from center for a joystick, or in a 2d sense have a method of understanding a slight tilt for look up and full tilt being a jump. There definitely is a lot of wiggle room on this concept, and it may not even be best practice to do these things in this way.

[Optional] How could this be implemented?

My (very minimal) thoughts would be to put this with the definition of the axislike::SingleAxis as it would affect both the single and double variants.

[Optional] What alternatives have you considered?

I am honestly not sure if this functionality exists already or if there is a clean way to do this, but from my reading of the docs I was unable to find something that seemed to do this and haven't been able to find any specific outside tooling that does this. I would love to be proven incorrect though!

Related work

In #322 a similar concept was brought up but focused on the sensitivity of the input values rather than parsing the values from some input device.

Shute052 commented 3 months ago

When I was thinking about #491, I considered that option, but it doesn't quite fit the bill as a processor. Maybe we could create something called "Only" or a similar processor.

But I feel like it should be implemented in #483 because returning Option or Result in the internal implementation would be better than returning 0.0 or Vec2::ZERO. Otherwise, we won't be able to easily determine which Action was actual triggered.