Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

This was a super interesting read! I had no idea default scrollview just preloaded everything like that in Unity. I'd guess that it probably works the same in other game engines like Godot too, because it's simpler to set up? I might need to steal your idea and implement such an optimized scroll view for my projects in the future.

What really intrigued me is how you approach settings menus. I hadn't thought of such a modular approach, but it makes so much more sense than hard-coding every option and slider by hand. Can you go into more detail on how it works?

I'd love to adopt this approach for my current project. It's basically done, but I've been procrastinating doing the menus and settings for a month, because UI is so scary and boring to me at the same time. (And also the sound lol).

Also thanks for fixing the bugs I reported on discord! ❤️

(2 edits) (+1)

Thanks dude! Yeah, so for the modular settings menu, the general steps are:

1. Figure out which UI elements you need to display your options: toggles? sliders? pickers? drop downs? something else?

Strictly speaking you can do it all with just a picker, so start there (pickers are those things with the selected option text in the middle and left/right arrow buttons on either side).

2. Build out each of these UI elements individually so that they work on their own. You can start with the picker and add more later. For a picker, the functionality you need is something like:

  • Set the list of picker options (e.g. an array of strings)
  • Page left/page right (decrement/increment the selected index)
  • Get the currently selected index
  • Set the currently selected index (and update the displayed string)

Each UI element will be a little different of course, but you do not need to have a common programming interface between them. You can smooth that over in the next step.

3. Once you get your different input methods working individually, now you need a single "option renderer" that has one instance of each type of input. The job of the option renderer is just to flip between these UI sub-elements and to read and write the values accordingly. Something like, if the option-type is "picker", return the currently selected index of the picker sub-component...if the type is "slider", return the current value of the slider. This is where you build a common read/write interface, so even if your slider uses a float value in [0, 1], you can just return an int in [0, 100] like RoundToInt(sliderValue * 100) or however you want to design it.

4. Finally, you'll create a sort of controller that manages a list of the option renderers from step 3. The job of this controller is to take your list of options data and then pass that to the individual option renderers to display the specified submenu of options. You'll need to figure out how you want your data structure to specify a menu of options should look. The YouTube video in this post basically shows how I did mine.

Whenever the user changes an option, you can have the individual UI element pass the message back up the chain to the controller, and this is where you'll have your game-specific logic do something meaningful with that input like change the game's volume.


(+1)

Woah, thanks so much for the detailed explanation! This really motivates me to finally tackle this UI headfirst :D
I'll try it one of these days :)