TSR options menu

Working on menus can be a really thankless job sometimes. It’s one of those things in games where if it doesn’t work properly then there’s fires, rioting in the streets, etc. but if it does work well then nobody really bats an eyelid.

The options menu in particular is a necessity in any PC game, and I definitely undestimated how long it would take to do and how difficult it was to do even with all the functionality exposed through Blueprints. My first naive implementation was creating a new options menu widget that contained a mix of children widgets and just widget primitives in Unreal that would be able to run their own functions depending if the save or back button was pressed.

This got extremely messy as the save and back button functions in the options menu Blueprint got very long functions for when the save and back buttons were pressed. This also was obviously going to be a maintenence nightmare if we had any issues, and sure enough that was the main motivation for creating a second iteration. We found that when the save button was pressed, it would execute every single options as though it had changed (even if it hadn’t) which would cause flickering due setting the resolution or changing between windowed/fullscreen mode.

So, I went about designing my second iteration. During my time thinking about how I would do this, it occurred to me that Blueprint is actually a programming language and probably has things like interfaces. For some reason I just sometimes forget that because it feels so different to coding. So I set off to put all the functionality for each button into their own widgets that inherited from a common interface for reverting their settings and executing changes to the games settings so that I could just loop over every widget in the options menu and run the function as necessary.

To solve the previous problem I mentioned however, I added an additional “IsDirty” boolean parameter to each widget which would be set to true if they had been changed. This meant that now if the user hit save, I would only run the execute option function if the option had been changed.

Fortunately at the time when I did this rework, I did have some sense (though not too much) in my first iteration to put all of the key rebinding widgets into its own parent widget and fortunately that didn’t require too much extra work to fix as a result. As a bonus, due to the flexibility this new system offered me I was able to add in a separate control scheme for controlls as well as it had previously been keyboard only.

At the end of all this, I’m quite happy with how I set the system up. It’s much more flexible to add new options if required, and I could probably even port it to other games without too much difficulty. Menus may be a bit of a thankless job, but I feel a sense of pride feeling that I did a decent job programming them.