What MVC and MVVM are?

MVC is a pattern which allows you to make separate layers in your program for the main business logic of the program, the presentation layer (console/UI/web API output/...) and the glue which connects these to each other and user input from keyboard/mouse/touch/web API and other input methods. If you want a formal Wikipedia based definition, go read it. That's more beautiful and more formal.

MVVM is a kind of MVC pattern initially created in Microsoft and it needs specific so called enabler technologies for data binding but you can assume that it's normal MVC for the purposes of this article. MVVM names the model, View and controller: Model, view and ViewModel and adds a binder of data on top but essentially is the same thing with the additional group of really useful and beautiful ways of doing the job. It uses a declarative language and automatic data binding to achieve the relation and communication between the model and view. This is much better than purely predefined reflection based approaches which some other methods use and is the best way of doing MVC whenever possible IMHO.

Why we wanted to use MVVM?

Short answer: Did we? We wanted to build a framework for making a MMORPG's content without coding and it seemed an appealing approach to our customer.

Long Answer: We at www.nooparmy.com are working with a customer to make a MMORPG framework for him and his team. He is trying to put together a nice MMO with nice features and with good execution I really believe that he can have a place on the market. A place at least good enough to make a good amount of revenue and get the business going. After all everyone should not shoot for the next Minecraft! Right? There is nothing secret about the project, we have news about the reclamation project on our website and soon it will have a website, a playable demo and hopefully a lot more. The thing is that there is not much material out which I can talk about.

We want to make a framework for the customer to be able to make a fully customized game for himself. The customer should be able to define character classes, attributes, abilities and assign animations and effects to them, they should interact with the defined attributes which are fully customizable as well and ... pretty standard hah? Yeah! In fact there is a known strategy which can work really well. You build a framework and a set of data driven components which can be mixed and matched to build different kinds of scenarios without any programming at all. Also you can expose high level logic for visual scripting or Lua/Python but that's for a little more low level customers and those who cannot understand the language that you work with (In our case the customer understands C# well and for various reasons we don't have plans to provide any additional coding interface for their company). Because of the customer's request and initial appeal and our lack of knowledge of the matter we investigated a MVVM (Model View, View Model) framework for unity to implement the framework with.

I would like to write about our experience here to save others some time and help them to move in the right path and also learn from feedback obviously. I'll try to come up with a descriptive exploration of the usefulness of the MVC family of patterns for game development. I'll use MVC and MVVM interchangeably

What tech are we using?

This is not relevant and relevant at the same time. We are using Unity for game client and server logic and UnityPark suite is the middleware used for networking related stuff. MySQL is the database used for accounts and for game data we'll either use MySQL or a no sql key value store. Between these the important point is unity's component based architecture and relative ease of creating visual data driven tools in it. I mean even without MVVM, we can use ScriptableObject derived classes, some tool windows and some flexible components to let the customer design different kinds of behaviors (Damn you unity, I put u after o in my behaviours always :)).

In situations which these tools are not available MVVM might seem more attractive however still MVVM data bindings and ... require tools to be developed to make them easily customizable by designers (without coding) so they might be on equal foot with writing unity like data editors and tools.

Why MVVM seemed attractive?

Frankly speaking it wasn't attractive to me that much, the traditional approach actually works and separation of gameplay logic from rendering layer and input layer is what we and mostly all studios try to do in their codebases. Still you want to do something if it's good and when you don't have enough info you'll probably go and research it. I first read a little more about the MVC pattern and MVVM and all different kinds of them. They are really good for what they are designed for. They are made for making UI and logic of a normal software separated from each other. By normal software I mean some software which the relation between its model, view and controller concerns is not too complicated and doesn't happen too many times for all models and views and doesn't have much performance critical parts which can become problematic by using MVVM and can benefit from MVVM because first of all there is a high tendency in other ways of developing it to mix UI and logic and secondly because of the specific way of interaction between these three layers, A method based and kinda event driven approach works for connecting the layers together. The layers are defined in completely separate domains and have a good amount of distance from each other. Lines of business software, many of the websites which you see on the web and many other desktop applications which have graphical or even none graphical interfaces lend themselves well into the approach. The patterns are standard practice not only in Microsoft's WPF platform but MVC is very old and is very popular in web programming both on the server and on the client. Django python, ASP.NET MVC, Various PHP frameworks and ruby on rails are a few of the examples.

The question is that are they good for game development? Do they bring any additional complexity? Do they solve any problems better than the current approach? Does the specific MVVM approach which uses data binding using visual tools or declarative languages has a specific advantage in games?

Different layers in games and current implementations

In order to understand the situation, we should take a look at what's the current standard in implementation of games and game engines. The great Game Engine Architecture book beautifully describes the different kinds of game engines and I myself worked with or studied thoroughly Unity, Hero Engine, Big World and Game Maker. Also I’ve made a small game using OpenGL and C without any engines in a very old fashion manner (It was very delighting and fun actually). I've also implemented a good part of Unity's runtime in C# with the help of my super awesome colleagues. So know a thing or two both about the implementation of gameplay code and game engines. I'm far from mastery in any of them but did them for some time. I also discussed the matter with a few others which are quite experienced in their work and each of them are more than 5 years in the industry.

Game Engines and games usually define their different parts based on functionality like rendering, animation, physics, networking and scripting, in the scripting part also they try to fully separate game logic code from the code which drives it like AI and input and also from the code that changes the visuals as much as possible. Convoluted code exists and gameplay code is known to be very messy due to its nature as people say and also due to hard to live with deadlines and hard requirements. The layers are really well defined and in most cases they don't have any code mixed up with each other, Other than cases which they have to do so, like some kinds of integrations between physics and animations. Some parts of games might be sometimes messy but mostly the things which ship and specially more service based games which are becoming more and more relevant have really good code qualities. Open source games have good code bases most of the times as you can study online as well.

The scripting layer of games which we talk about it here can really benefit from having separated layers for different reasons. The code will be easier to read and write and maintain and it will be portable in the cases that it's needed. I mean you can use the logic part of the game in multiple places like web API and game server and client if required with little to no modification for specific cases. The code will be flexible in terms of usage so for example your car can be driven both by AI and human players and share a good amount of code and the code which creates the particles for tires is not inside the code which sets the engine speed and amount of tire spinning so different people can easily work on them. These things usually require different kinds of skills and having a mixed code which contains all of them is seen but is almost never good unless you are making a prototype which you want to just make and test something and commit to trash can if your studio's trash cans have version control available like ours.

How we usually make the code designer friendly?

Usually we make the code as data driven as possible and make our games based on horizontal components these days. If a designer wants to make an item which is eatable by players and craftable in recipes he'll add an eatable component and a craftable into it. We might use property based architectures as well which have kind of the same concept but the code manages all properties which are like each other from a centralized point. None flexible hierarchies of GameObjects still exist and are far from dead and are used in the games industry a lot but they are not the best approach for designer friendly architectures which don't want to rely on programmers or designer-programmers who make new classes in different parts of the hierarchy.

Usually also we allow designers to easily make relations between components using strings or other kinds of data types with tools which help them to don't make mistakes. With these approaches designers have a good amount of flexibility and without having to deal with too much complexity they can modify the game's behavior (I got you Unity in this case).

Many other approaches are used in the industry from fully Lua based designer tools to usage of LISP for making animation properties and from fully hard coded games to fully pluggable reflection based architectures. Based on studio's tools, culture, project needs and many other factors it can differ but I’m trying to compare the most relevant approach to MVC because a game which due to performance needs is made using many specific tools and sometimes in the hard way cannot use neither MVC nor our beautiful complexity killer component system. They just have to do it. These days most of games use good architectures and with the power available to devices these days not making components doesn't make sense in almost all cases but support of runtime reflection and related things is pretty different in different projects and platforms. Many game engines after providing the whole flexibility for designers to set animation and game properties using some data oriented manner will just compile all data to a binary form and generate C++ code to use them to gain performance (mostly on console platforms).

As I’ve said before for my comparison I’ll assume a component based/property based data driven general engine and will compare MVC/MVVM to it because other ways and hybrids of code/script and tools for design and behavior modifications are not the things which were the motivation for us. We wanted fully none code based design tools and I would imagine most people moving toward MVC/MVVM would want either code clarity or these design tools. In fact the framework which I took a look at talked about code clarity and good design as much as it talked about designer tools. They believe the code becomes portable and also cleanly organized which both are true.

What MVC/MVVM brings into the table?

MVC and MVVM will force you to create specific data models for your game like character model, character attribute model and attack model and then you'll create different instances with different data properties.

You'll have a control layer which takes input from user or other controllers and based on them applies logic to models. Also it fires events in views after properties of models change.

The view will listen for properties and based on events happening to the properties changes the visuals of the game.

MVVM specifically brings the capability of binding specific properties to specific events using a visual tool and automatic data binding. In WPF and newer Microsoft UI techs it's done using data binding in XAML files made with hand or visual studio/expression blend.

In MVC you should strictly follow these guidelines, at least you are supposed to do so. Most original pattern designers always say that you should change the patterns based on your needs if required but many still don't understand. People use it like religion while even religion should not be followed in that way.

What advantages/disadvantages does MVVM have as a helper for design tools?

In terms of the tools that it provides, the designer can hopefully add properties to models and change them and set the instance values. It allows hooking of changes of model properties to specific view events and attach specific controllers.

Assuming a car as an example I'll try to describe you how the pattern tells you to design it. you'll have a car model with all properties like acceleration, top speed, number of gears and ... It also contains all business logic which you call to apply the car simulation like Simulate() Break() and Turn() methods. Controllers for AI and player characters and maybe some other controllers for automatic and manual gear modes and ... as well. For view probably you can attach particle generation views to tires which hook their tire particle count property to car speed and...

This absolutely brings nothing new to the table. You can have a car component and a gear component and an engine one. For managing gears then you can add either ManualManager or AutomaticManager and so on. You have components which do controlling things, Visual tasks like particle related things and...

For adding specific kinds of new control types you need coding of new components or views/controllers so MVVM doesn't provide any additional tools for the designer. It's a hooking mechanism between different parts and I argue that it's worse than the component based approach for the below reasons.

Usually MVVM uses dependency injection so a gear and AutomaticGearManager can find each other easily but DI is a separate thing and can be used with component based architectures which don't use MVVM/MVC as well.

How's the situation in terms of code organization?

As said before good practice is to organize code in logical layers and things like having each data defined only in one place or having separated classes for logic, controlling and visual stuff is a standard practice where it makes sense. In fact the fact that makes MVVM not the best approach for games is impracticability of doing this fully in the way that MVVM does it.

Some people claim that with the force of MVVM even prototypes of inexperienced programmer will be organized and you know where to start but the thing is that if you don't have the experience then the organized code is still bad enough that it's not shippable and usable in shippable code and if you have enough knowledge and experience you'll either make the prototype really fast and just commit to TC or will make something which is reusable and becomes really good with a little refactoring. It's about time spent? Experience, goal and not pattern used. MVVM can make it slow compared to haphazard coding for a throw away almighty. If I want to spend time on it, I know how to do so to make it beautiful and if I don't know, you'll help in making the outer shell appear beautiful but you are not magic wand.

Why MVVM is not good for games?

Games are soft real-time multi agent simulations with deadly performance needs in many cases, changes happen a lot not only due to changes of requirements but in exploration of FUN and their presentation and control and logic layers are tight together enough that almost always strict MVC is a waste of time. An example from my awesome friend Peter, Do you want to fire an event for playing each foot step sound from your controller layer which checks position of the foot /character model or animation timing and fire an event in the AudioManager view? Does it help anything/anyone? Does it bring additional complexity? Does it make the code more portable? Does it hurt performance/sanity of the developer?

In games most of the times you need to have shortcuts in specific places, you should pull/read properties all frames sometimes, and one event per property can become too much for animation, sound, AI and networking. We use messages, method calls and events but this much?!? I don't think so, it will make a lot of additional code, probably hurts performance and doesn't add anything new to the toolbox or doesn't help in any specific way. Ok the code which runs the movement logic should get events for collision detection, the code which runs the animation should drive itself with messages sent from movement and collision and AI and ... and should not be mixed with the audio code as well but one class for each of these in a normal manner is really good and specially in graphical component based tools like Unity adding an MVVM tool on top doesn't seem to help at all. I mean it doesn't bring anything new so even if it doesn't remove anything which I believe it does and it makes code more spread and complex than it should be in many cases, it should add something to be considered a better practice. There was a big debate lastly on test driven development and the way that it encourages additional code spreading which was talking about a similar situation.

For prototyping the argument is said before so I’ll not repeat myself and you can see if you need organized code for a prototype or not and choose your approach based on that instead of a pattern and set of tools forcing it. Don't forget the version control tool for the trash can however.

Patterns are good because they force a way of doing things

They are not good because of this, they are good because they let you do things in a known way which works and can be understood by others which know the pattern easily. They should be used in the places which they work. Forcing makes code disciplined but in a game with a little of serious stuff you have to break the pattern in some places so it will not be all the same and the approach will be kind of like the component based ones. Sometimes you have separate layers for logic and control, sometimes not. Just the components are in a different way and heavily use events for each property change (which is not always desired). Sometimes you want to see the change x times a second only, sometimes after some threshold, sometimes you have to hook to it directly due to performance needs. Sometimes not using events in the MVC way makes the code more elegant.

Examples of most ready to use MVC frameworks for games make very simple games like chess or very small mobile games, Chess is a turn based pretty slow game and it's like the normal business app in many matters other than the AI which surely is implemented as control layer and model kind of and due to performance might not be that well-structured depending on AI goals and platform. Also simple mobile games don't have many objects and models and events so making them with any of these approaches doesn't make much difference. You should build MMOs with the MVC thing to see if it's good or not. You should make Halo.

So cannot we use it?

It can be used for some parts of the games certainly and shares a good set of properties of normal components which are like them and good for separate parts of the game but they are not good to be holistically applied like what they do to desktop/web apps. If you have some data which rarely changes and is not tight to the main game logic, then you can use MVC for it especially if it has UI, You maybe should use it for Inventory of your game to have a nice and standard code which is understandable. The point is that implementing a game in MVC in a strict manner is not a practical idea and even if practical for a game with less constraints, doesn't add much to the table compared to other approaches with separate layers and allowing mixing and matching like data driven component based architectures.

What about testability? They say it's highly testable?

Well view code is hard to test for a game and its testing methods are known and different (comparing graphical output with known images). You mainly would like to unit test controllers and models/business logic of the game. I would argue that if you have them separated no matter what patterns you use or lack of them, you can test the separated logic code/AI code. They can add discipline (again and again) but cannot be used with their strict discipline for all parts of the projects. Those parts which can be implemented with MVC without adding 100 method calls per frame and having implications on complexity and performance can be separated easily without MVC as well. The parts which are hard to separate, MVC cannot change with black or white magic.

Who uses MVC for games?

If you search MVC for games and MVVM for games, you cannot find a famous studio or title using it for a serious project (at least I could not find). You can see questions which people ask like why MVC is not used in games. You can find blogs people talking about goodness of them or lack thereof but if you can prove that it's useful for the whole game then you'll be probably one of the first who have done so. Someone should do it first after all. Property based and component based designs are less than 20 years old in terms of being mainstream as well. In early 70s you just had to make it work with the nastiest hacks man kind ever seen.

I would not be surprised if you implement Angry Birds with MVC and write tests for it and ... but I argue that a component based/property based data driven architecture with less potential complexity and less events and code jumps and layers can be made with code attributes better or just like the MVC one. It will have the same amount of testability and maintainability properties and will be designer friendly as much as the MVC version. It will have less unrequired events and callbacks per property and can do lots of things in a much more elegant and beautiful manner. It can batch some stuff in a way which at least are not strictly MVC compliant. It will be cache friendlier due to not using strict OO design patterns and will be friendlier to CPU code branching predictions due to having less number of virtual methods.

What do you think?

All this said I would be really happy to see a good amount of discussions below the post from your experiences. Our project is going well and customer is happy so I’ll not change the approach in the current project probably but who knows I might do in a next one if you show me the benefits.

If I want to innovate somewhere in coding and architecture of games, I'll try to use distributed simulations. There is an ongoing effort on making a game engine using Erlang which is an awesome idea. For networked games and game servers, it has been done commercially but for clients and normal game loops, not yet. I'm not aware of any at least. Let's put time on those stuff instead which yield important benefits if become true.