search

bevyengine / bevy

A refreshingly simple data-driven game engine built in Rust
https://bevyengine.org
Apache License 2.0
35.25k stars 3.47k forks source link

make Userinput for gamepad and touch more intuitive #5163

Open PhaestusFox opened 2 years ago

PhaestusFox commented 2 years ago

What problem does this solve or what need does it fill?

I have been making a tutorial series for bevy and currently working on user input.

1:I find it very confusing and unintuitive the way gamepad is split into buttons and axis with there being no clear cut-off between what is a button and what is an axis.

2:The touch input system is also confusing and unintuitive, but for different reasons. primarily that all the functions have different names than their corresponding Input equivalent. such as iter() and get(). and secondary the coordinate system is different to the curser coordinate system, curser has lower left being 0,0 but touch has top left being 0,0

What solution would you like?

  1. can we make all the buttons and axis into one enum an then simplify the interface so that it has just one Input that returns pressed and released like a key press based on the setting and thresholds. and one Axis That represents the raw position of the buttons.

I feel having both input and axis for the buttons for only a single trigger is confusing and messy.

  1. I don't know if it's too late to make a breaking change like this but could we rename the function to follow the convention of the rest of the input structs. and for the coordinate system that seems like that could easily be changed but could introduce bugs for anyone already using it.

What alternative(s) have you considered?

  1. could simply move the trigger2 to the axis enum instead of the button enum, this would remove the need for Axis

Additional context

at the end of my video I talk about it if this makes no sense. https://youtu.be/PjLozjlOgJ4

alice-i-cecile commented 2 years ago

Firmly in agreement. I've been quite frustrated working with this for leafwing-input-manager and attempting to provide a clean abstraction. That said, this should probably be two issues, so we can track the work more comfortably:

  1. Gamepad buttons should encapsulate triggers.
  2. Touch input API should be consistent with other input methods.

It's definitely not too late for breaking changes like this: we're pre-1.0 with a big disclaimer on stability.

Related to but distinct from #3224.