CODEWITHSUNDEEP
c#user-interfacedesign-patternsmodel-view-controllerunity-game-engine
Helixb
Helixb

Reputation: 67

Which architecture for Unity4.6 UI implementation

I'm working on a Unity project. It's a visualisation software, so most of the game mechanics are based on buttons, sliders, color-picker updating my GamesObjects.

I can't figure out how to organise my UI implementation. Is it a good idea to apply some kind of MVC pattern to unity, any idea how to do it (I found some article about that but they weren't clear to me) ?

Currently I'm adding UI elements in the scene. An empty game objets called UIManager is holding scripts concerning the UI. Those scripts hold references to UI elements, add a listener to them and contain methods called by the event.

My approach is correct? How to improve it?

My UI Manager contain scripts like this one : 

public class someMenuGUI : MonoBehaviour {

public Button enable;

public void Start()
{
    enable.onClick.AddListener(Enable);
}

public voidEnable()
{
    GameObject[] Objs = Object.FindObjectsOfType (typeof(GameObject)) as GameObject[]; 
// then do something on them
};

Upvotes: 1

Views: 622

Answers (1)

Max Yankov
Max Yankov

Reputation: 13327

That's a very good question without an answer that can be considered to be universally true. However, I would like to share my approach to this.

When I write Unity code, I have two categories of users in mind: players and designers. Essentially, since almost all Unity code is contained in MonoBehaviours, and MonoBehaviours are used in the editor, you're constantly writing a tool for designers that they use to actually create a game.

Even if you don't have a designer and work alone, it's useful to think about code in this terms. This way, you have a clear separation between code space and editor space: code doesn't have to make any assumptions about what happens in the editor; instead, designer has to be able to use your components to build what they want.

So, where do you draw the line? I think that if you're going to use the MVC pattern, the separation is quite clear: the controller logic should be contained in code, but the wiring up of the actual UI elements should be in the hands of the designer. Which, finally, brings us to the code.

A great way to implement the MVC pattern is to use events instead of solid references: this way the controller and the view don't have to know each other's types, they only have to know the model. But since you want the designer to hook events up in the editor, you can't use C# delegate events. Thankfully, there's a new feature of Unity's UI system just for that: UnityEvent.

UnityEvent in the unity editor

So, let's say that your script, which plays the role of the controller, has to have two-way communication with the view: from controller to the view to update the information, and from view to controller to run the user's action. Turns out, it's very simple to set up. Create a public UnityEvent (with a correct generic argument) for update of the data, public method for user action, and you're done with the code! All that designer will have to do is to set the Unity event on your script to update the UI, and to set up Unity event of UI element to call your controller's method.

Upvotes: 2

Related Questions