I get it, there’s a huge focus on mobile games which means flat UIs to be poked and jabbed at, and the end result is that game controllers have fallen by the wayside.
Which means that controlling the UI focus with up/down/left/right navigation has obviously not been battle-tested.
Sometimes focus is lost entirely when using navigation, sometimes elements are completely ignored while unexpected elements grab the focus instead, and there are little annoyances like when you shift the focus to a radioButtonGroup, it doesn’t automatically focus the currently selected button, and when you shift the focus to a listView, it doesn’t automatically focus the currently selected element.
Patching all these glitches is a massive time sink.
I’ve had a lot of success designing my UI around playing with a controller, as opposed to implementing support for controllers afterwards, if that make sense.
Needless to say there are a lot of various UI layouts and types of controls that don’t mesh well with controllers at all, even if we had better focus support. It’s better to opt to just not use these at all.
You only need to look at games that are focused around playing with a controller and take inspiration from their UI to get good results. Good examples are the two recent Monster Hunter games. The way the UI is structure works perfectly with controllers.
I took a similar approach to said game with my UI and have found I haven’t needed to do any extra work with focus and navigation.
This isn’t to say the current focus support shouldn’t be improved. It would be great to get something like we had with uGUI. But how you approach your UI is probably going to have more of an effect.
I like the ideas you put forth but I’m attempting to present my UI as a faithful representation of an older BIOS interface, along with the various conventions it has.
I can’t budge from this because of how the UI fits into the ingame lore, plus I’m making it based on my own experiences with older computer systems. In any other game I’d be doing the things you’ve suggested.
Then I made a scriptable object class to store all the metadata pertaining to any Visual Tree Asset where I need custom data. More on that later.
I made a routine that can find any element that’s been tagged with that “.uid” class. In the case of dynamically-generated sub-elements (such as radiobutton groups) that cannot be manually tagged, my routine will dig them out and expose them, adding an index number to them.
I also made a crude editor for these visual element metadata files. It displays all exposed elements as nodes, and includes little handles so I can quickly connect them.
I also made a routine that, at runtime, will scan through an instantiated Visual Tree and pre-tag any elements with tgt_{TagId} classes, making it trivial to find them later with the Query system.
The metadata that gets attached to each tagged element is only navigational (up/down/left/right) strings that can be used to point to any other tagged elements, which is enough for my rudimentary needs. Later on I can add localization information to this metadata so I guess it’s good enough for now.
Better than sitting around, dead in the water, waiting for Unity to fix the problem for me.
Hello! First of all, I wanted to say that your BIOS UI looks very cool
About the issues you are having, I’m glad that you were able to find a workaround, but if there’s anything that doesn’t work the way you expect please feel free to report a bug so we can investigate and address it.
