How are game menus logically structured?

Question

I've been struggling with making a game menu system in Unity for some time now. I spent time developing a way to help myself understand how game menus are connected together. Right now, I'm calling it the Screen-Menu relationship.

In this relationship, Screens (e.g. Main-Menu, Game-Over and Inventory screens) hold access to Menus (e.g. Options Menu, Level-Select menu). These Menus are accessed via MenuButtons (e.g. Options menu button via the Pause Screen).

Is this a valid way of thinking about how game menus are structured? How should I be thinking about it?

Answer 1

As someone who's just spent over a month creating an inventory system, perhaps my menu system can give you some ideas.

At its base, you have categories. Within each category, you can have multiple menu items -- items the player can select to view details about, and perhaps perform an action with.

Categories can have parent categories, too.

Consider the following screenshots. Player's character has approached a merchant NPC and is wanting to buy something.

My interface above is made using GUITextures and GUITexts. The logic is stored in classes and lists. I also use this interface system for my main menu and various options.

A pseudo breakdown of the different classes involved might look like this:

MenuCategory:
    title (String)
    breadcrumbTitle (String)
    titleIcon (Texture)
    menuItems (List of MenuItem)
    selectedMenuItem (MenuItem)
    parentCategory (MenuCategory)

MenuItem:
    title (String)
    subtitle (String)
    description (String)
    descriptionTexture (Texture)
    action (MenuItemAction)
    actionText (String)
    childCategoryToActivate (MenuCategory)
    correspondingGameObject (GameObject)

enum MenuItemAction:
    ActivateChildCategory
    ActivateParentCategory
    PurchaseItem
    SellItem

The above makes up the logic of the menu system. The trick is to then have your GUI:

1. Interpret the details of the current MenuCategory.
2. Display each MenuItem contained in menuCategory.menuItems.
3. Highlight the current selectedMenuItem.
4. Display the details/description of the selectedMenuItem. Perhaps interpret its correspondingGameObject to choose what to display (maybe it's a weapon, or a potion, or something else).
5. Display the available action based on what selectedMenuItem.action is set to.
6. Process user input, whether to set selectedMenuItem to a different MenuItem, or execute the current item's MenuItemAction.

The GUITextures don't change much -- it's the GUITexts that get edited depending on what the player has selected.

Now, this merchant NPC's top-level category is just one of several top-level categories. Your game's main menu could be a top-level category, with child categories like options, save game files, etc. A high score category could be its own top-level category, or could be a child category of something else.

Just a matter of having, say, a menu controller class that is in charge of knowing when to display what, and ensuring menus don't overlap with each other; I have a few other "menu" systems that don't follow the above structure, so a controller class handles what to show. End of the day, it's really up to you, as there's no right or wrong way of doing it.

Hope this helps!