I am developing a driving/racing sim, which involves a number of adjustable parameters, including a ColorPickerButton to select a paint color for the player's car. Driving/racing games are best played with a gamepad, or with a wheel (once Godot integrates more support for those), and the player might not always have their mouse and keyboard handy. Games in other genres may offer similar cases.
Describe the problem or limitation you are having in your project
By default, sliders and certain other Control nodes are difficult or impossible to select/manipulate without clicking on them or entering a value on the keyboard. D-pad input does not work like keyboard input, and nodes react to changes in analog input, not sustained input. (Which leaves me unsure whether this belongs here or as a bug report -- sorry if I chose wrong)
The default ColorPicker(Button) behavior is particularly odd, because it allows focus to move between all the elements except to choose a color.
This affects the flow of UI navigation and how one must arrange a GUI to make it user-friendly.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
When the problematic nodes acquire focus with a keyboard or gaming device, I suggest highlighting them like a button and allowing the player to choose whether or not they intend to adjust that parameter, or if they are trying to get to another one. Once focus is acquired, the player may press 'ui_accept' (or whatever) to begin adjusting the parameter, and break away with other inputs.
This functionality could be made optional with a new parameter for the relevant nodes.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
I have solved the limitation in my own project, so I am attaching an interactive mock-up of the idea. I am a novice programmer, so it is a surface-level fix using invisible buttons and signals.
If this enhancement will not be used often, can it be worked around with a few lines of script?
About 150 lines of script, so no. It impacts the usability of every instance of a slider, so I think it would be used often.
Is there a reason why this should be core and not an add-on in the asset library?
I expected sliders and the ColorPickerButton to behave the way they do in my demo by default. It is a very conventional sort of behavior for UI elements in many games, and easier to use.
It's worth adding that this change would also improve accessibility for players who may have a disability preventing them from using a mouse, or a keyboard.
Calinou
commented
3 years ago
Describe the project you are working on
I am developing a driving/racing sim, which involves a number of adjustable parameters, including a ColorPickerButton to select a paint color for the player's car. Driving/racing games are best played with a gamepad, or with a wheel (once Godot integrates more support for those), and the player might not always have their mouse and keyboard handy. Games in other genres may offer similar cases.
Describe the problem or limitation you are having in your project
By default, sliders and certain other Control nodes are difficult or impossible to select/manipulate without clicking on them or entering a value on the keyboard. D-pad input does not work like keyboard input, and nodes react to changes in analog input, not sustained input. (Which leaves me unsure whether this belongs here or as a bug report -- sorry if I chose wrong)
The default ColorPicker(Button) behavior is particularly odd, because it allows focus to move between all the elements except to choose a color.
This affects the flow of UI navigation and how one must arrange a GUI to make it user-friendly.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
When the problematic nodes acquire focus with a keyboard or gaming device, I suggest highlighting them like a button and allowing the player to choose whether or not they intend to adjust that parameter, or if they are trying to get to another one. Once focus is acquired, the player may press 'ui_accept' (or whatever) to begin adjusting the parameter, and break away with other inputs.
This functionality could be made optional with a new parameter for the relevant nodes.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
I have solved the limitation in my own project, so I am attaching an interactive mock-up of the idea. I am a novice programmer, so it is a surface-level fix using invisible buttons and signals.
gamepad_friendly_range_controls.zip
If this enhancement will not be used often, can it be worked around with a few lines of script?
About 150 lines of script, so no. It impacts the usability of every instance of a slider, so I think it would be used often.
Is there a reason why this should be core and not an add-on in the asset library?
I expected sliders and the ColorPickerButton to behave the way they do in my demo by default. It is a very conventional sort of behavior for UI elements in many games, and easier to use.
It's worth adding that this change would also improve accessibility for players who may have a disability preventing them from using a mouse, or a keyboard.