Feat/menu nav

[thombruce]

By submitting this pull request, you agree to follow our Code of Conduct: https://github.com/thombruce/.github/blob/main/CODE_OF_CONDUCT.md

---

Internal use. Do not delete.

• [ ] Tests passing
• [ ] Coverage sufficient
• [ ] Manual review
• [ ] No A11y regression
• [ ] Translations provided or not needed

[thombruce]

This was a lot to figure out and we're still not all the way there yet. We haven't yet even got a settings menu to transition to.

Also...

• [ ] Test UI navigation with a gamepad
• [ ] Add settings menu and make values changeable/selectable

[thombruce]

I can now navigate to a settings menu... though I cannot presently navigate back to the start menu. Make sure we can do that - I'd like to be able to do so using "Esc" but a "Back" button is more user-friendly to avoid confusion.

Now I just need to figure out how to make each value (currently listed as a button) configurable...

• [ ] Window Mode (select-like)
• [ ] Language (select-like)
• [ ] Volume (range-like)

I feel like the easiest way to achieve all three is to utilise the unused left and right buttons (though I fear this may conflict with the crate I'm using). When pressing these, the state should change to the next value, the next, the next, and loop back. The range-like volume can handle this by using increments of 0.1 or 0.05 (preferably represented as an integer 0-100).

[thombruce]

The crate has this locking concept: https://github.com/nicopap/ui-navigation/#locking

For those toggleable values, I could first require that the user select the menu item, then lock the navigation system and use custom Left-Right controls to iterate through values...

Alternatively, though I don't want to get this advanced just now, there are sub- and sub-sub- and sub-sub-sub-menu examples which I'm sure we could control the visual presentation of. Think maybe each item is a sub-menu of the Settings menu, present on screen but requiring you to step into it and back out...

For now... I think the simplest approach is to just make use of the default select behaviour (Space by default, but I've added Return as a working key too). Just step through values as the user is pressing the action key. Not particularly ergonomic, but should get us basic utility with minimal effort (menus will be revisited eventually).

[thombruce]

Settings menu is actually really involved, so here's what I'm gonna do...

1. Remove the settings menu for now.
2. Remove the closing reference to #34 above
3. Plan to handle the actual settings menu separately

We made good progress here, getting in place a basic UI system. Could use some refactoring, but it does the job.

The settings menu needs to be much like this but also...

• Modify GameConfig resource values
• Reflect these changes immediately by updating systems, e.g.
• On language change, re-send locale.requested in a one-off system (Bevy 0.12 might have a new utility for this 👀)
• Be separated into rational chunks (i.e. each menu iterator I'm making should be a component defined elsewhere that we're able to reuse - the way I'm trying to cobble it together now is just unwieldy)