So i’ve read a lot about design patterns, but not much on MVC. What I have read is that it’s very common in software design and I was going to give it a try within Unity. However, all the MVC tutorials and explanations i’ve read say the same thing, but never make it all that clear. For example “The model handles all the business side of things”… that comes up a lot, but it’s a bit of a vague explanation in my opinion. The view is to show the visuals and the controller is a mediator between the two.
Could someone please help me understand in more detail, by putting it all into the context of a real world, useful example. Please show me a bunch of skeleton classes with members/ skeleton methods/events in the appropriate places.
Brief: A touch-rotatable “dial” that when turned, adjusts a displayed value. The output value can be within a range.
I have picked this as an example because I feel it covers a lot of things. You have internal values, user input handling and visuals to update.
However, i’m still confused over the placement of methods. I mean, just to rotate a dial and update a value on screen, a number of things needs to happen, such as:
Detect a touch down on the dials visual handle, and then detect finger/mouse position to determine rotation amount and direction.
Update dial’s internal value
Update the visuals of the dial to show the rotation
Update any number of other values that relate to the dial (observers?)
Where do all these methods/events live? Under which parts? Please could you basically list them out for me as i’m really unsure of which parts would have which responsibilities.
Also, why is it that Unity does not lend itself to MVC? Is it because of its component-based nature? What if game elements are created through script and therefore not always monobehaviours and component-based objects?
MVC is a strategy of code coupling, so you have certain classes that are “Model” classes, “View” classes, and “Controller” classes. Generally, the rules of MVC state that the View is not aware (coupled) of anything other than itself (the view). The Model is not aware of anything but itself. And the Controller is what does the “hook-up” part (glue code) and makes the view represent the model accurately. When implemented correctly, the view and the model should be reusable, but the controller should not. The controller will only ever be used in that one program and not in future software.
About MVC in unity - Generally I read that MVC doesn’t make total sense in games. The reason is because in games, there is no hard model that needs to be represented super accurately. In games, nothing is off bounds as you could have a particle system be just visual, but at the same time give it a collider and apply damage to the enemy. So what category would you fit this particle system into? It’s part of the model and view at the same time.
I’ve recently discovered that MVC can actually be really helpful in certain parts of unity, particularly Unity/Editor GUI.
I do still have one query about the most suitable place to put certain methods. The method for doing the rotation on the dial’s transform for example. If the view has a method “SetRotation()” then it’s still only aware of itself. However it’s the Controller that would call upon this method. Equally though, the Controller could have all of the code for rotating the dial itself, by simply getting the view’s client game object. What would you recommend? I would guess things like that would exist inside the view.
Thanks also for clarifying the unity and MVC thing, I feel it’s a lot clearer now.
You’ve got a dial, which the user manipulates (touch or whatever). That dial needs a script with interprets the user input and rotates the graphics etc. ultimately the dial will have a float (or whatever) data value which represents it’s current state (it’s at max, data value = 1, it’s at min, data value = 0 etc.) the dial doesn’t need to know or do anything else. This script encapsulates only that user input and feedback about the state of the dial.
You’ve got a display, it’s script takes some sort of input and puts it on the screen. It doesn’t care about anything else, it just takes an input and turns it into pretty graphics.
Then you’ve got some sort of control script. It has a reference to the dial and to the display, when it updates it reads the dial’s current state, figures out some stuff and tells the display to show whatever.
You can take that dial code and reuse it anywhere else, you can take that display code and use it anywhere else… that control script, it only does specifically what it’s been coded to do.
Basically, you’ve got some part of a software system which is designed and implemented as 3 distinct interacting components:
A “model”, which is an object representing a set of data (ie: variables) and the rules (ie: functions/methods) defining how it can be manipulated.
A “controller”, which is an object which takes and/or interprets user input (ie: button presses and so on) and requests changes of the model (ie: calls the public functions of the model).
A “view”, which is an object that gives a visual representation of the model for the user (ie: draws a graph, renders a model, whatever).
One of the key benefits of MVC is that you can swap out some of those components without any component being aware of what other components it is currently working with - all you need to do is ensure that the interfaces match up. For instance, if you had a model which represented a set of values over time, you could have one view which rendered them as an XY plot and another which played back the values over time via an object in a 3D scene. The model doesn’t care what the data is being used for, it’s simply supplying the requested values to a view with a compatible interface. Similarly, you could have different controllers which populated the data set in different ways, for instance one recording the values in real time and another calculating a set of predicted or idealised values. Similarly, the model can be swapped out - lets say one stores the values to memory and another sends/receives them over a network. None of the components care how the others implement their part of the overall job, all they care about is that the appropriate interface requirements are fulfilled. You can often even swap them out during runtime, making your programs nice and flexible.