Are There Any Best Practices for Unity GUI Coding?

(I mean the PC web-browser/standalone executable versions of a Unity project, rather than iPhone/Wii. While I have nothing against the iPhone - it seems that development for it, especially interface design/development, is a completely separate category.)

So - are there Best Practices for coding a Unity project GUI? If so, what are they? Or if not, what are some of the reasons not?

Is the GUI system easy enough to use, that people just code up quick-and-dirty solutions, each time they start a new project?

Or are Unity projects so diverse, that there really isn’t anything in common, in the GUI of one project compared to another project?

This forum post was inspired by the Unity Question: What’s the right way to code a GUI? In asking for the “right way”, SpikeX is, in essence, asking for a set of Best Practices.

What are Best Practices?

To quote from Wikipedia: “A Best Practice is a technique, method, process, activity, incentive, or reward that is believed to be more effective at delivering a particular outcome than any other technique, method, process, etc. when applied to a particular condition or circumstance.”

I think of BP as rules of thumb that I can use to make a decision on how to code a particular section of a script. When writing a GUI script, there are dozens of decisions to make, such as the questions that SpikeX brought up - Where do you place all your Texture references? How do you handle Strings? How do you combine GUIStyles with code? (That last definitely bothers me :slight_smile:

I’m new enough to Unity that I certainly don’t know how to give good answers to these questions - I can certainly answer them, and I have created GUIs with code. But is it good code? There I’m lost.

What are some GUI Design Principles that Best Practices help achieve?

A few sample principles:
Aesthetically pleasing
Clarity
Consistency
Efficiency
These are really goals, or outcomes, that you want in your GUI. And BP are how you write code to achieve those goals.

Suppose I want to make my Buttons look consistent.

Example: Say I want to make a set of Buttons that have a consistent appearance across multiple Scenes. Obviously I need a single GUIStyle object, that is shared between the levels and applied to each Button. What is the best way to do that?

My first exploration into the Unity GUI documentation turned up GUIStyles and GUISkins, so I tried to make a GUIStyle in the Project Tab (where it would be accessible to all the Scenes). I failed to do so, and eventually discovered that only GUISkins could be created in the Editor. So I programmatically create a GUIStyle, then assign all the values to the various States that I want:

GUIStyle myBtn = new GUIStyle();

Although this works for the Scene I was currently in, it obviously won’t be globally available, unless I do something to make it so.

Or maybe this is a completely wrong approach - I should be defining the individual Styles in a GUISkin, then pulling that into each Scene’s GUI script object. The point is, I don’t know what is the best way to build consistency into my GUI.

One thing I’m concerned about (and not just doing GUIs), is approaching Unity the wrong way - as a programmer, I’m used to writing code (no surprise). The idea of having Objects, that I modify in the Inspector, including Script variables, takes some getting used to :slight_smile:

So what, if any, rules are there for coding a GUI? How do I think about all the various elements, and how do I manage them, whether in code or the Editor?

John C>
“For all your days, prepare, and meet them ever alike;
When you are the anvil, bear - when the hammer, strike.”

I really need to see people replying to this thread. So Bumping it to the top.

I would not only like to see Best Practices with GUI but also with other aspects and tools within Unity. Using Managers is something I would like to see a best practice guide for as well.

I’m still looking into GUIs at the moment but this is what I’ve discovered thus far:

#1) I would say that one best practice might be to write functions with the format

property = MyGUIFunction(property);

An example of this might be

isInitialized = InitializeGUI(isInitialized);

where the body of the function might look like

bool InitializeGUI(bool isInitialized)
{
      if (isInitialized == false)
      {
             DoSomethingToInitializeGUI();
             isInitialized = true;

      }
      return isInitialized;
}

The example might be a bit trivial but I think the idea of it for this “Immediate Mode” method of GUI construction, it seems reasonably sound.

#2) A pure readability best practice might be wrapping Begin/End block with {} code blocks with indentation.

		GUILayout.BeginHorizontal (GUILayout.ExpandWidth (true));
		{
			// Control Panel
			GUILayout.BeginVertical (GUILayout.MaxWidth (300));
			{
				DrawLeftPanel();
			}
			GUILayout.EndVertical ();
			
			// Drawing Area
			GUILayout.BeginVertical ();
			{
				DrawRightPanel();
			}
			GUILayout.EndVertical ();
		}
		GUILayout.EndHorizontal ();

There’s a couple of things on the wiki which could make good examples

http://www.unifycommunity.com/wiki/index.php?title=MainMenu
and

The above seems a little redundant. If you’re passing in the same variable that you’re storing the method’s return bool in, you might as well either skip it as argument, or return void and set it in the method body. I.e. either:

InitializeGUI(out isInitialized); or isInitialized = InitializeGUI();

(The out keyword is a C# feature that indicates it is the responsibility of the callee to set the passed parameter. It requires isInitialized to only be declared before passed, and it requires InitializeGUI to initialize the passed parameter somewhere in its execution.)

Would this not modify the lifetime (scope) of variables defined inside the curly braces?