When it comes to working on game UI, I try my best to follow the Principle of Least Astonishment. Yes that's a real thing. It's more fun to say than "user expectations".

I would expect the TAB key to switch between text inputs. It's amazing how quickly I get irritated with any app that doesn't respond to the TAB key properly. It's not working in my COOPERRATA prototype, so I need to fix that.

Unity's UI system has an automated navigation feature, but it's mainly for gamepads, doesn't use TAB and breaks overall on text-inputs. It also leaves highlight ghosting on buttons, which is their design, but not what I'd consider expected-behaviour-- in fact nearly every tutorial I read / watch suggests turning navigation automation off, but that's not what I want either.

So I intend to modify Unity's navigation feature. That's a daunting task. Unity provides source code (on BitBucket) for their UI system (yep, they open-sourced that part of Unity). So I could make changes to the system directly, but maintaining my own DLL variation of the entire Unity UI is an idea that gives me nightmares. Instead I could extend some classes, that would probably be wise. I've poked around on that, but it also seems like a headache.

I think the route I'm going to take is to write my own overseer code that will toggle the navigation system on / off as needed (to avoid that ugly ghosting) and add some controls for text inputs specifically.

This is the kind of task that reminds me of that game development adage: The last 1% of your work takes 50% of the total time. These little details that seem mundane or simple end up consuming more effort than you expect. I'm tackling this one early on, rather than leaving it for the last 1%.

Though I'm very tempted to wait until Unity adds tabbing as a feature, but it's been on their to-do lists for more than a year.

Oh here's the Wikipedia page for that principle, in case you're curious: https://en.wikipedia.org/wiki/Principle_of_least_astonishment
Photo
Shared publiclyView activity