[Question] How are main menus/UI systems generally done in Unity?

Basically the title. How developers usually design/code main menu systems in Unity? I was going to re-design the main menu of my game that was controlled by a placeholder script that I made just for functionality (using the new UI system that was introduced in...I guess 4.6?), and well, that question came to my mind.

I know that a menu system will change depending on the needs of the game itself, but, yeah...
I was thinking of using interfaces, so I could reuse the code not only in this project, but in many others but I don't know if it's a good, or efficient way (in the lack for a better term) to do it.

 

This sort of question sometimes provokes somewhat dismissive replies, since it addresses a matter subject to personal preferences. That is, there may not even be any way that UI systems are "generally" done. On the other hand, though, it does seem that, from time to time, one discovers that a certain idiom, paradigm, pattern, or whatever, is a popular enough choice for doing one thing or another that, if one isn't using it, one eventually discovers one is doing something "wrong" (the scare quotes here are to emphasize that "wrong" means "not like most of the rest us").

But UIs are just the sort of topic that does lend itself to, if not one, maybe a few widely practiced methodologies. So I hope people with UI experience (and I am not really one of those) will post a few comments. Perhaps the question to be answered is not really how are they "generally done," but, instead, how do you do them? What advice do you have to offer those of us who haven't done much UI work yet? For example, I think theMasky's point about using interfaces looks appealing, since that would lend itself to a model/view/controller pattern, which might work very well for a UI. Anyone done it that way? Or any other way?

 

What we've found is that menus tend to not be very reusable across games.

The easy part is doing things like having buttons you can press and making the menu transition into a different state. The hard part is making that look good for your game, and make decisions about how to transition into the play state and load stuff and all of that.

Reusable code is often slightly more cumbersome to work with than bespoke code, simply because you can't change it exactly how you need for this specific problem.

So you're taking code that's very easy to write and spending time on making that modular and reusable or whatever, and making the code that's hard to write even harder. So I'd advice against it.


Also there's the general advice - don't create an abstraction that there's only a single example of. That's just a bunch of extra work you're doing because you're speculating that it'll be useful in the future, without knowing which needs you have in the future.

 

A few things I've templated into prefabs are buttons--setting/deactivating states, as I typically don't use some of them, so I'll set those colors to be the same. Also set font styling from the default. I don't use OnClick(), I use the EventTrigger OnPointerDown() for ease of interaction so there's no need to release button to select. The accompanying code might include a string or int parameter for the interaction so I know which button was pressed, that way I can re-use the script for many similar buttons and use a switch statement in the code. I did similar things with a template slider, particularly making the hit area larger than the default very thin slider width.

I also made a single-choice button row. This works automatically in an EventSystem as long as there's only one, and no other buttons (if I'm wrong let me know!). But this is not always the case, so I set up the row with the logic to highlight/unhighlight as each one was chosen, and to act as a standalone unit---just put in as many child buttons as you want, it loops through to unhighlight all and then highlight the one chosen.

For toggles, I'd rather control the colors myself and not have a checkmark turning on and off, so I set all colors to a mid-gray as a default off state, set them all to off in script, and change the selected color to match when it's on or not (you have to use a ColorBlock intermediary, you can't set the toggle state colors directly in script afaik). This makes a standalone toggle as opposed to one that relies on the EventSystem. I know there are other ways to do this, but tbh the EventSystem and the different states of UI elements are a bit mysterious at times...

 

I hate writing custom UI code so I try to keep it simple. I also always use my Datasacks package because then the presentation and inputs can be replaced without changing any actual game logic code.

Here is how Datasacks work:



Datasacks is presently hosted at these locations:

https://bitbucket.org/kurtdekker/datasacks

https://github.com/kurtdekker/datasacks

https://gitlab.com/kurtdekker/datasacks

https://sourceforge.net/projects/datasacks/

 

Wow...I guess this answers my question. Almost every comment said something radically different. I guess I'll just simply hard-code my menu, it's not that complex, but it does have the basics as graphics settings, audio settings, general settings, etc.

 

Definitely a very viable approach. You can do that forever, or right up to the point you start feeling the pain of UI changes, and then think about other approaches.

 

Yeah, I was actually hardcoding the menu, but then I thought that maybe there was some kind of "pattern" or something like that, since I've been seeing a lot about design patterns and principles in many places. I just wanted to make sure I wasn't doing anything overly complicated or even wrong at some extend. Thanks!

 

Some great answers here. This one really speaks to me:

Game programming is an art and a science. This means getting something "right" depends both on what you are trying to do at any given moment, and on the path you took to reach that moment. So go ahead and try something you think will work, while keeping an open mind. By the time it's working, you'll almost certainly have devised a better way to do it the next time.

 

And it's important to not feel like the first way was somehow a waste of time...it wasn't!

I like to think of it in game terms, like leveling up...being able to do similar procedures more efficiently, with more flexibility, better structure, etc., there are lots of ways to improve.

Also, as you develop re-usable bits, that becomes your "inventory"...

 

This is so true, yet it comes hard to some of us. Fifty years ago, when I got my hands on a copy of "BASIC BASIC," and had some access to an HP-2000 computer, programming came naturally to me. I didn't know most of my code was crud, because it worked and there was no one to critique for me. Over the years, I did improve and, for most purposes, I can be pretty confident that I write decent stuff.

But then came game programming, which is a whole 'nother topic. I couldn't just assume my code was up to par with industry standards. That took some humility, but it was a breakthrough moment for me. It meant I stopped trying to get everything right the first time. Instead, I look at every new challenge as an opportunity to learn by doing, including learning by doing it wrong a few times. Or, to be more precise, to learn by doing it better over the course of several iterations.

So I think what seejayjames has said here is an essential part of the answer to theMasky's question: however you do it, the important thing is to learn by doing it and, the next time, do it even better than before.