Don’t bring web development toys to Unity’s kindergarten

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.


What is MVC and what it gives us
How we work in Unity
Where is the MVC?
My problems with that understanding of MVC
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?

  1. 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.
  2. Controller separation, so if we want to add or change the way data is processed (application behavior), view and model don’t care,
  3. 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.
  4. 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.


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.

Some links

Share these goodies:

Leave a Reply

4 Comments on "Don’t bring web development toys to Unity’s kindergarten"

newest oldest most voted
Notify of

I really don’t agree with you at all.
If maintain a MCV model it can benefit you in may ways. For example having a model that represents the state of you game you can just serialize that and you have a savegame. Also useful if you want to do some kind of ingame recording feature.
This is especially important in unity where you most like don’t want to save a every transforms position and every materials color.
Also decoupling the control from the view means you can easily simulate the game in apart from the view, this is useful in case of AI and multiplayer.


Sure, so you can just separate model for these modules. But do you have to do this for the whole project? I mean, put the pattern only where it’s needed.

Providing additional Serialization and Deserialization methods for saving/loading game where you chooses parameters that should be written/read from a save file also might be a good solution.

“Also decoupling the control from the view means you can easily simulate the game in apart from the view, this is useful in case of AI and multiplayer.” Can you elaborate? I’m really interested how do you do this in Unity!


Thanks for the article! I agree very much with it. I keep having discussion about exactly such things for more than a decade now. Seems that the majority of today’s dev generation has a strange understand of applying design patterns to just everything in order to give them the illusion of being superior clever. Opposite is the case. In my opinion we should stop the trend of artificial complication of everything and go back to use common sense more often. Done right, this leads to more simplicity, maintainability and efficiency of code.


I love what you just said, really. Too many design patterns might be as harmful as lack of patterns (more or less).
Leonardo da Vinci said “Simplicity is the ultimate sophistication.” and it is hard to not agree with him. I’m afraid that common sense can be gained only through the experience. It seems impossible to learn how to program right from the very beginning. What do you think?