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?

  • \$\begingroup\$ From your question I am not sure whether you want to understand the design principles of unity or valid principles to design an menu GUI. Maybe you want to search for GUI modeling and implementation ideas in general, since UnityGUI does not really enforce any kind of design principle. \$\endgroup\$
    – Kronos
    Commented Jun 18, 2014 at 23:22

1 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.

enter image description here

enter image description here

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:

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

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

enum MenuItemAction:

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!


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .