When creating user interfaces, the Model View Controller is frequently utilized. It separates the relevant program logic into three distinct but linked parts. This enables us to return to Single Responsibility by separating the various game mechanics from one another. There are several variations of this paradigm now in use, including Model View Presenter (MVP), Traditional Model View Controller (MVC), and Model View ViewModel (MVVM). Although all three employ the same fundamental idea, their verbiage and communication styles differ slightly.
Traditional Model View Controller (MVC)
- Model — Business logic, or in game development the Game logic.
- View — What the user sees. This is responsible for the formatting and rendering. It Observes the Model and responds to On Change Events (Observer Pattern).
- Controller — Controlling the way the user interacts with game/application. Takes in user inputs and updates the Model.
Model View Presenter (MVP)
This is what Unity normally uses, as well as certain web HTML. The main distinction between this and MVC is that the controller has been replaced with a presenter, which is a major change. The main cause of this is that we are limited in what we can do with the View, and rendering is performed internally or behind the scenes. With Unity's UI system, which includes built-in events for interacting with the view and receiving input events, we may modify how game items are rendered.
- View —What the user sees (Rendering) and takes inputs from the user. Is updated by the Presenter and sends Input Events to the Presenter. Unity is already doing this for us.
- Presenter — Responds to the Input Events from the View (Observer Pattern) and Updates the Model based on the Input Events received (Input Processing). It also updates the View (Formatting) when a On Change Event comes from the Model (Observer Pattern).
- Model — Game logic is controlled by the Presenter. Sends the Presenter a On Change Event (Observer Pattern).
Model View ViewModel (MVVM)
if using the new UI, used in Unity. When creating UI with UXML, it is also utilized in various Windows Form apps and Web applications.
With the exception of the ViewModel replacing the Presenter, this is identical to the MVP. Data bindings are used to connect the view and viewmodel together.
- View — What the user sees and takes inputs from the user. Is updated by the ViewModel and sends Input Events to the ViewModel by data bindings.
- ViewModel— Used To Communicate between View and the Model. Communicates with the View using Data Bindings. The Model On Change Event will cause a variable that is bonded to the View to Update. When one of the Input Bindings in the View is changed a variable that is bound to it is changed, the view will then update the Model.
- Model — Game logic is controlled by the ViewModel. Sends the ViewModel a On Change Event (Observer Pattern).
Conclusion
- Model View Controller: Model game logic is isolated from View logic and handled by the Controller.
- MVC evolved into MVP. The input logic and view logic are handled by the presenter. The View simply handles rendering and event management and is therefore more passive.
- Like MVP, but with binding between the View and ViewModel.
The Model View Controller Pattern is the subject of several articles on the internet. MVC, MVP, and MVVM are all variations of the same paradigm, which first made it difficult for me to understand. Based on the limitations of the system you are dealing with, how they are really implemented differs. Knowing this, all you need to do to use the new UI system in your project using UXML and Unity is to copy the Presenter and make it the ViewModel, then use bindings to connect the View and the View Model. | 
