BGP Week 6-7: Main Menu

The last two weeks of BGP! In between the random polish that had to be done, I also remade the main menu. For reference, all of the images in this post were stripped of environment and skyboxes and the like, in order to only show the actual main menu UI.

We had received feedback that the original main menu felt too “clean” for the feeling we wanted to convey with the game. Due to this, and also the way the original main menu was structured codewise, I decided to remake it from scratch.

I wanted to keep the same layout (ish), both since I felt that it looked good and was functional, as well as it being how the original UI was designed. The screen was split into two pieces, with piece A taking up roughly one third and piece B taking up the remaining two thirds of the screen. The entire system revolves heavily around enabling and disabling objects in order to show or hide them.

The Menu List

Piece A contained the menu list, which was basically just a list, where each “selectable” menu was a child object consisting of an image and a text. When moving the control stick up or down, a new menu would be selected as active. This was indicated by the round selection thingy appearing next to that child, as well as the transparency of the text going from 50% to 100% along with the font size increasing. An index would also be sent to piece B, telling it which content to display. Since this piece doesn’t really do anything, it’s easy to add more menus: simply create a new child and set it up as desired. The script handles the rest.

Piece B contained the actual menu to be displayed, also known as the content. each menu was once again separate children, which had a script deriving from an abstract class in order to make it easier to store and access each script. This abstract class had two abstract functions, Activate() and Deactivate(). This allowed me to run specific code in each content, if desired. These functions mostly got used to show and hide all children of the content, to give a feeling of the menus actually changing. You could also freely change between these contents without them losing track of where you were in those menus (which really only mattered in the start menu, but hey, it could be useful for the settings too, if we ever choose to implement them).

Start menu

The Start menu contained one square for each player, which could have four different states: Free Spot, Vehicle Selection, Track Selection and Ready. Each of these states were individual objects, which were toggled on and off depending on the active state of the square. The states also had a script attached to them, which, like the “large” menu, derived from a base class, with the functions OnConfirm(), OnCancel() and OnEnter(). OnConfirm() would assign to various variables to carry over to the next scene, while OnCancel() would return those values to their default. Both of these functions also disabled the children of that particular submenu, while OnEnter() enabled the children in order to display them.

Highscore menu

The Highscore menu was fairly straight forward. It contains two columns, one for each track. When opening the highscores for the first time after loading the scene, it reads the highscores from a text file, and creates 10 children, filling in the highscores. If you then choose enter the highscore screen again, it just reuses those objects.

The Credits does nothing fancy. It’s just a bunch of text objects, neatly positioned in the center of the content piece. It’s so non-fancy that I won’t even bother showing it.

So, reflections. I’m quite happy with how the system in itself worked out. However, upon seeing it in action at GGC, I realized that the design of the entire menu wasn’t quite as intuitive as we in the team felt it was. People often switched menus by mistake, at which point the promptly froze for a short period since they didn’t expect a new menu coming up. There was also no real room for the logo to fit in without it either looking misplaced, or barely being visible. Same thing with the menu list. If I were to remake it, I would probably lock the player to the current menu until a deliberate attempt to leave it occurred (probably by pressing a button or something like that). However, the actual “press A to join, select vehicle, select track, play”-flow worked quite well, and we could more or less leave the game unattended and people could still figure out how to play it.