Implement a player select screen

[Piturnah]

The player select screen should have the following functionality:

• Four empty cells with a prompt to press a key or controller button.
• When a button is pressed, the empty cell becomes a player sprite preview.
• There should be a button to start the game.

All UI must be controller friendly.

Extra scope

Eventually, players should be able to choose their fishy avatar in this screen, but this may not be necessary for the first iteration (MVP version) of the feature.

Notes

Investigate kayak_ui

[erlend-sh]

The safe & easy path here would be to reuse the player select screen from jumpy/punchy, made in egui. I highly recommend that for MVP, unless you have a strong itch to try out kayak.

We will definitely revisit kayak and other options later, since egui is more geared towards tooling-UI.

@zicklag could you lay out the basics of the player select screen in egui?

[zicklag]

Unfortunately the UI setup isn't a simple as I'd like, but it does function quite well.

The foundation for all the UI stuff can be found in the ui.rs module. There are some things that would be good to know about how it works. Starting at the top of the module:

• We use the bevy_egui plugin for integrating Egui, as you'd probably expect
• Near the top of the module you'll see the WidgetSystem trait and a widget function. These are used to create self-contained widgets that can access the Bevy world, without you needing to pass in a massive list of bevy queries, resources, etc. into widget function calls.
  • See the main menu widget for an example of how the WidgetSystem trait get's implemented, and how the widget function can be used to add child widgets.
• Also in ui.rs you'll see the WidgetAdjacencies resource, which is the technique we use to say that when a user presses a certain direction on the keyboard or the gamepad, which button the focus should switch to.
  • You only need to use this when the default egui tab order isn't correct
  • You can see here for an example of marking one widget's position relative to another widget.
• The handle_menu_input system is important for taking game inputs and using them to drive Egui actions such as focusing on the next button or clicking a button when the user presses a button on the gamepad.
  • we use the leafwing_input_manager for collecting the UI actions, such as pressing up, down, left, right or W, A, S, D, etc, but you don't have to. You can do that however you want.
• update_egui_fonts works together with our custom font asset loader to load fonts into the Egui context.
• And finally, the update_ui_scale system is an optional system for making sure that the egui scale matches the game pixel scale.
• Oh, and to get 9-patch support, we had to make our own egui widgets for buttons and panels, which you can find here.
• And before you can use a texture loaded with Bevy in Egui, you have to be sure to add the texture handle to the egui context like we do here.

Again, I'm sorry this is all so complicated! I'd love for this to be much simpler, or at least packed away in a Bevy plugin or something so you don't have to deal with all the nasty details, but it is what it is for now.

If Kayak was easy to use and compatible out of the box with a font loader and support for gamepad inputs, then it may actually be worth considering for the MVP, but you'd have to try it out to find out whether it would do what you need.

The biggest advantage the egui setup has is that I know I can make it do almost anything, and that it works great for editor UIs, but it isn't necessarily the simplest thing to use in the context of Bevy.