That’s right, I said it. It looks like some web developers want to bring their habits to Unity with them. I understand that you expect it will be easier this way. But I think it may be easier for you (at the beginning), but not for other game developers. Especially not for Unity developers. I came across a couple blog posts, and I saw in the comments that people that thank for the “MVC for Unity tutorial” are the ones that are already familiar with MVC and want to do something in Unity. I find it a quite dangerous approach. It looks like they don’t know what MVC is for, WHY do we even use it. Main benefits of using it shatter in Unity when understood wrong. When I want to learn Unity, I should look for “Unity tutorial” in Google. Or “Xamarin tutorial,” or “Ruby on Rails tutorial.” Looking for something like “How to make a web page in Unity” doesn’t seem the most effective path, though it may be an interesting adventure. It’s a good idea to explain some new concepts basing on the ones you are already familiar with (i.e. Unreal Engine for Unity developers). But then you should familiarize with the new framework and its “culture.” And don’t get me wrong, it’s totally okay to try new, even weird, things. It may only develop you as a programmer. Go, have fun, make a game in assembly or banking app in Unity. But if you really want to learn something new, then learn something new. Don’t stick to your habits just because you feel safe. Let’s get to some technical details.

Content

What is MVC and what it gives us
How we work in Unity
Where is the MVC?
My problems with that understanding of MVC
Summary
Some links

What is MVC and what it gives us

MVC is an architectural concept that separates application to three domains.

Model – Data and data access. It does nothing except containing data and (eventually) providing API for data management.
View – The visual presentation that is responsible for displaying Model in some way (tables, scroll views, etc.) The View never changes the Model directly.
Controller – A bunch of scripts that interpret user input, change Model according to it and deciding which View to display next.

Through all these years (the oldest paper I found is from 1979), MVC got many varieties. You can approach different definitions of MVC if you ask different people with different development backgrounds. I’ll provide you with sources I based on. Anyway, MVC has been adapted to many platforms, and Unity is one of them.

Alright, that’s the basic idea, but what are the benefits of using MVC?

Separation of a back-end (often – a model and a controller) from the front-end (a view), so web designers can focus on a page look and developers on managing data, connections with databases, etc.
Controller separation, so if we want to add or change the way data is processed (application behavior), view and model don’t care,
View separation so that we can have multiple views (i.e. for different platform/browser) or we’re able to reskin web page easily, without bothering developers.
Probably more. Can you add something?

How we work in Unity

I’m assuming you know Unity, or at least its architecture based on components and how to combine them to make something work. We’ll need an understanding of “class cohesion” as well.

When we (me and my teammates, whatever a team was) made a game, everyone who worked in Unity was a Unity developer. Unity was a front-end. A separate server (i.e. GameSparks, something on Azure) and a database were a back-end. Unity talked with the server via a REST API (Get, Post, etc.) if a game needed it. The server was responsible for communication with the database. Artists worked on graphics and sound assets, and very often they didn’t have Unity installed at all. Designers worked on scenes (level design, aligning UI) and tweaked values in the Inspector.

Where is the MVC?

We can look for MVC architecture in the project in a couple of ways. Everything depends on how far we zoomed out our perspective.

F2P or multiplayer games usually need a server and a database (back-end). Users data and values for level definitions/difficulty are kept in the database. Game logic (the rules; how you play the game) are scripted in Unity. But some of the things, like if a player should win a reward, should be implemented on the server to prevent cheating. Okay, so what in that case is M, V, and C in our MVC concept? For me, it looks like the database is a Model (data part), the server (with a bunch of scripts) is a Model (data access part) and Controller (method for random reward winning), and Unity is a Controller (game logic) and a View. If you’ve got a different perspective of that, remember to share it with us in comments.
Singleplayer games usually don’t need a server or database (maybe for analytics). In this case, Unity is responsible for all the letters in “MVC,” and forcing MVC concepts here is risky. In this very popular blog post about it, the author cuts a Player to three different scripts (one per M, V, and C). I don’t agree with that concept, and here’s why.

My problems with that understanding of MVC

MVC adds another level of complexity you have to manage and maintain. It’s not natural for Unity projects, so it is harder to get used to for Unity developers.
Unity supports building for different platforms and does the hardest part for you. Is it Android or iPhone UI? For Unity, in most cases, it doesn’t matter. You can do a reskin in the editor. It doesn’t matter if a reskinned object has some behavior on it or not. Designer updates only one of its component anyway.
It kills and pees the encapsulation. A Player object that has some scripts on it, another PlayerView object with a Renderer and yet another one with Health field? It’s not like object-oriented programming works. Classes are collections of data and behavior. MVC (in above understanding) separates these two things from each other.
It does the same to hermetization (hiding) and makes reasoning about a code much harder. “This access will allow every MVC class to reach every other.” Without any constraints, the code flow may (and will) complicate very quickly. Hermetization is one of the most important (if not the most) OOP paradigm (though it is often described as a part of the encapsulation).
The sentence “By splitting the thinking process into data, interface, and decisions, developers can reduce the number of source files that must be searched in order to add or fix functionality.” is just not true. It’s exactly the opposite. Instead of one Player script, now we have three of them. To handle a new parameter you’d have to update THREE files and the code communication between them. Every change is much harder to manage.
It’s slower. Instead of managing the Player in a Player script (it sounds obvious, right?), you’re wasting resources on sending messages.

Summary

As you probably noticed, it seems like successfully applying MVC architecture strongly depends on what you consider being M, V, and C. Don’t adapt known concepts to new environments just because it seems possible. First, you should probably try to learn the new environment to some extent, how it works and what practices are the most broadly used before you consider changing it. Probably. The decision about that shouldn’t be based only on the convenience or discomfort you feel while thinking about The Great New. Work with others, ask more experienced developers what they think about your idea. MVC is a great architectural concept, but like every other pattern, it shouldn’t be adapted to new situation carelessly, just because it worked perfectly somewhere else. Maybe someday someone will show great examples of “MVC for Unity.” Don’t stop looking for better workflows and don’t forget to inform me if you find something interesting.