Settings Menu

[thombruce]

A way to adjust some of the game's features.

The user should be able to adjust volume here. They should also be able to turn on or off the game's shaders:

• Pixelation
• Chromatic aberration

---

The above I know reasonably well how to do. We should also consider:

• UI Scaling
• ...

These I'll have to put more thought into.

---

Trickier still:

• Language options for internationalisation
• Accessibility features like a colour-blind mode < this would require some change to many of the game's visual systems

[thombruce]

Remember that the settings menu should also be navigable via controller inputs.

[thombruce]

The game now has settings that are configurable from a verse.config.ron file in the assets folder.

Adjustable settings:

• window_mode
• master_volume
• locale

All we need to do is display these on screen in a menu, make them mutable and save the mutated values back to the config file...

Maybe there should be a defaults file as well as a user changed one, but we can work that out later.

[thombruce]

We could implement a simple settings menu using something like bevy_egui (https://github.com/mvlabat/bevy_egui). This wouldn't look great... but it would be very easy to use and implement.

Right now, there's just a real lack of features in the native Bevy UI system. To create a slider (e.g. for adjusting the volume), I would need to draw a line and a handle that could be grabbed and moved along its X coordinates on that line... We could do very rich looking interfaces that way, but it's a lot of work.

For now, what do I need?

• Window mode: Select
• Volume: Range
• Locale: Select

Keep in mind, the range doesn't need to be a slider. It could be a number field... but I'm not sure that Bevy even has native support for standard text inputs just yet. Text input, yes; text inputs, no. See: https://bevy-cheatbook.github.io/input/char.html

We could follow that guide and hack pieces together that look native... or we could implement egui as a simple temporary approach while awaiting better solutions. Or... a bit of both.

Check out an egui demo here: https://www.egui.rs/#demo It's... versatile. Versatile is the best description - it's very limited in how it can be styled, I understand.

You can do some pretty incredible things easily with egui though:

Both a blessing and a curse...

• Blessing: We could add a lot of planetary information to little egui windows
• Curse: We might have a hard time moving away from egui if we wanted to change the look to something more native

[thombruce]

While wondering about this, also worth thinking about other systems that require not-yet-implemented user interfaces:

• Start menu buttons: Continue, New Game, Settings, Credits, Quit (that sort of thing)
• Settings menu: Window mode select, Locale select, Volume range, etc.
• Character creation
• Ship building
• Inventory management
• Maps: Galaxy, System, Planetary surface
• Dialogue and conversation trees

And remember, each user interface should be comfortable use with either of a keyboard and mouse or a gamepad, which means menu items should be selectable by using cursor keys/gamepad directions and adjustable without having to type anything or select it via mouse.

We might emulate mouse on Right Stick by displaying a custom cursor on screen eventually (especially useful for map exploration), but this should not be taken as a given for navigating menus - it should always be secondary to navigation options that are more ergonomic.

[thombruce]

The above said... I think egui actually complicates gamepad support. So much so that actually there's a crate I've just discovered specifically designed to improve keyboard navigation and gamepad support: https://github.com/idanarye/bevy-egui-kbgp

I still think we're better struggling against the native implementations.

[thombruce]

So, I'm currently trying to implement my own menu navigation...

I've come up with the idea of using an enum with next and previous iterator-like functions:

#[derive(Clone, Copy)]
enum MenuItem {
    NewGame,
    Settings,
    Credits,
    Quit,
}
impl MenuItem {
    fn next(&self) -> Self {
        use MenuItem::*;
        match *self {
            NewGame => Settings,
            Settings => Credits,
            Credits => Quit,
            _ => *self,
        }
    }
    fn previous(&self) -> Self {
        use MenuItem::*;
        match *self {
            Quit => Credits,
            Credits => Settings,
            Settings => NewGame,
            _ => *self,
        }
    }
}

Thing is, I still don't know how to translate that into an effective utility within the UI itself. I could insert it as a resource and on specific inputs, shift the selection. We could then query that resource and render each button accordingly or execute whatever action is selected on a different keypress...

That's what I'm thinking now anyway.

---

In the meantime, I've also found this: https://github.com/nicopap/ui-navigation

They take a similar approach in an example in the readme, making use of an enum component to select and execute specific menu actions...

This crate could take the headache out of trying to figure this out myself, though I don't think it could handle the slider-like component I've been thinking about introducing for the volume...

It would be very handy for, say... inventory navigation, right?

Even if it is just a patch that helps us overcome the initial hurdle, and we do eventually right a set of more specific systems ourselves... that is sort of precisely what we're looking for.

[thombruce]

The above crate also has a Bevy 0.12 PR open: nicopap/ui-navigation#39 Though this is presently blocked by a Bevy pointer event crate, which is in turn blocked by two crates including one focused on ray-casting - feature sets I don't at all need (yet) and make me think UI Navigation is overengineered for my particular use case, though... I could definitely see these becoming handy later (viewing a system map, selecting and navigating UI nodes within that map)...

Okay.

Probably we make use of this. Remember to add it to the upgrade list in #85 if so.