Directional navigation is too onerous to set up #21661
Description
What problem does this solve or what need does it fill?
Directional navigation allows users to change their focused element using e.g. arrow keys or gamepad inputs. This is useful for accessibility, and essential for games where menus should be navigated by gamepad.
The existing system offers a high degree of control to the developer, allowing them to create an arbitrary graph of nodes and the inputs needed to navigate them. This flexibility can be useful to allow devs to construct more advanced functionality, such as "looping" when inputs would extend off the end of a list (e.g. the main menu).
However, as shown in the directional_navigation example. setting this up is very tedious, and fragile when working with more dynamic UIs.
What solution would you like?
Add a way to construct the graph between visible nodes based on their observed positions and sizes.
The selected node should be in the direction of the provided input. Nodes that are close should be prioritized over those far away.
Ideally all nodes are reachable, but we can omit that for an MVP.
The generated graph can then be added to the scene by the developer, and tweaked manually post-generation as desired.
What alternative(s) have you considered?
The graph-based approach could be abandoned completely, in favor of an uncached "just look at the screen" approach. This has a few potential drawbacks:
- performance: in many cases, the correct graph is entirely or almost entirely static
- flexibility: more advanced use cases or behavioral tweaks become impossible to make
- unreachable nodes: without manual control, it may be impossible to reach some nodes under certain layouts. This is especially true when considering arrow-key-based navigation, with limited angular inputs