Hard Coded Menu Navigation

[IsaiahKelly]

Is there a good reason for hard-coding menu navigation into each menu type? For example the MainMenu class has:

public void OnOptionsPressed()
{
	OptionsMenu.Show();
}

But allowing you to actually define which menu you want to go to using an argument would allow you to freely setup navigate to any menu you want in the editor, without having to create an explicit method for each navigation you need. Something like this instead:

public void GoTo(Menu menu)
{
	menu.Show();
}

Are these explicit navigation methods just done to enforce a specific menu flow and prevent certain types of issues?

[Nezz]

The reason I prefer to explicity declare each Show method is that often you actually want to press some data the menu (model in an MVC pattern). For example if you have a loading screen, you might want to declare:

public static void Show(string title, string tooltip)

This requires you to explicitly declare the button handler functions.
Also, by explicitly declaring each button handler function it is easier to browse the code. For example you can easily find all references to the Show method of your menu.

[IsaiahKelly]

Thanks for the explanation. I still don't fully understand the real benefits here, but it's probably because I've never worked on a large project with multiple team members before.

My main concern is modulability and code duplication. I like the way Unity's MenuManager example lets you specify the menu prefab to switch to right in the editor without coding anything for that specific navigation. Doing this also eliminates the need to specify all the menus you want to access in the MenuManager itself and allows you to dynamically pre-load menu object references on demand without using the Resources folder or asset bundles because each menu prefab would already hold all references to all other menu prefabs it needs to switch to and load those whenever it is instantiated.

I also fear hard-coding the navigation every time could lead to multiple methods that all do the same thing, like OnMyMenuPressed() for every menu that wants to go to MyMenu, etc. I also really hate it when I want to modify a project that has a menu manager that has hard-coded all the menu objects references into the manager itself. Because then removing any menu I don't want automatically breaks the whole project! Your menu system seems a bit more resilient here, but it's sill something I'm concerned about.

I don't think I've completely grasped how this system works exactly, but as far as passing data along goes, could you not create just a generic GoToMenu(menu) method and just implement a custom Show() method for when you need to pass some data along? That to me would seem like the best of both worlds, or am I just (very likely) missing something here? 😁

[Nezz]

Unity makes game development more approachable by making it possible to change things in the editor without coding. However, these links are very easy to break and there is no error when someone breaks a reference. We prefer to code things because:

1. It is easy to see what is referenced
2. Refactoring is much easier
3. Broken things result in compiler errors

[IsaiahKelly]

Yeah, I've just started to retrofit a fairly complex game with your menu system to test it out better and I'm starting to really appreciate the design. I'm going to continue working on this and see where it takes me. Thank you very much for sharing all your knowledge on the subject with the Unity community. It's been very informative!

I guess some of this just comes down to personal preferences and design choices. However, I find the idea of creating systems like these that are both flexible and scalable for projects and developers of all types and sizes a very interesting challenge.

Like you said, Unity makes game development very approachable, but this comes at a cost or trade-off. I find the balancing act between chaotic creativity and orderly engineering to be quite fascinating indeed. Many times I'm not even sure which side I belong to, if any. 🙂