Level up your code with game programming patterns: Model-view-presenter | Tutorial

In this video, you’ll learn how to use the Model-view-presenter design pattern in your Unity projects. This pattern can help neatly organize your code so it’s easier to manage, less error-prone and more flexible for future updates.

Timestamp:
[0:00] Intro
[0:17] Model view presenter overview
[1:02] View overview
[2:07] Presenter overview
[2:57] Recap of model, view and presenter
[3:34] Adding an “on/off” button
[4:56] Model view presenter and the QuizU sample project
[5:24] Unity’s UI Toolkit

#unity #unity3d #gameprogramming #unitygamedev #gamedev #gamedesign

[Bloompix_Studios]

Whoever came up with the idea of creating this video series about Design Patterns deserves a salary raise.

[rod-abreu]

A simple comparison between MVP, MVC and MVVM:

Model-View-Controller (MVC):
- Coupling: Moderate. The Controller interprets user input and updates the Model, but the View is often updated directly by the Model.
- Complexity: Lower. More straightforward for games where the UI is less dynamic.
- Use Case Suitability: Ideal for simpler games with a distinct separation between game logic and UI, like turn-based or puzzle games.

Model-View-Presenter (MVP):
- Coupling: Lower. The Presenter acts as an intermediary, reducing direct dependencies between View and Model.
- Complexity: Moderate. Offers more structure, useful for games with complex UIs.
- Use Case Suitability: Suited for games where the UI frequently updates based on game state, like strategy games or RPGs.

Model-View-ViewModel (MVVM):
- Coupling: Lowest. The ViewModel binds to the View, minimizing direct interaction.
- Complexity: Higher. Offers a robust framework for dynamic, data-driven UIs.
- Use Case Suitability: Best for complex, real-time games where the UI needs to reflect rapidly changing game states, like real-time strategy or action games.

Sometimes we can also use a mix of any or some parts of them, when it makes sense for the project, like:
Event Driven MVC, MVP with ECS, Data Oriented MVVM, Hybrid between MVC and MVP, Component based MVVM, Service Oriented MVC or MVP (with the Service Layer), State Driven MVC etc.

[jacobs.]

Love those!! One of the best series so far! Only constructive criticism I can add: please add more examples. 10/10

[rohanvishayal]

Loving these Programming pattern videos, keep 'em coming.

[GTZ-]

These programming pattern videos are OP! Love it.

[GrayFoxware]

I appreciate video's like this. Thank you.

I hope to see more tutorials.

[hermitcat]

This is the most important video I've ever watched

[Aranclanos]

These kind of design patterns are noob traps for people who come out of college and have little work experience, following it ends up in complicated systems that do not help the overall organization of the project. Although a similar pattern can be useful in a multiplayer setting depending on your network framework, with the idea of separating server and client code.
Remember that simplicity is key for maintainable code.

[vakuzar]

This series is great, but I feel like something is missing to solidify why I would want to build like this. These examples are so simple that I don't feel like this would do anything other than take longer than if it was all one piece. I think either a follow up video, a second more complex example or even a take home assignment would help solidify these concepts giving reason to when its worth implementing vs when it's not.

[rod-abreu]

I don't like the idea of having Models as Monobehaviors, this approach tightly couples the Model with Unity’s framework, making unit testing and reusability outside of Unity difficult. Not to mention that it will add an unnecessary layer of Unity’s lifecycle methods which could introduce performance overhead, especially if the Model doesn’t need these features.
ScriptableObject would make sense sometimes (especially if you want to make the life of designers and artists easier), but plain C# classes would be better.

[nullx]

I love the idea, but having model as monobehaviour is just weird. It kinda goes against what MVC is made for and what it means... I appreciate you guys are putting effort in this because it's much needed but please fix the model part. I know it complicates the video, but better than teaching all these programmers a wrong base.

[bonitapersona]

The big problem here is making everything a MonoBehaviour. Anybody minimally experienced in Unity knows that the priority is to make as few MonoBehaviours as possible. Model and Presenter shouldn't be a MonoBehaviour: Model doesn't need it at all, terrible practice. Presenter also shouldn't, and its lifecycle should be controlled from another of our scripts, unifying the execution order of our scene to a single point that carefully manages the dependencies, initialization and closure.

[joshuareeves]

Isn't this just MVC (Model View Controller)? I remember learning to code iOS apps in Objective-C and later Swift with this pattern. Love it.

[disobedientdolphin]

How is this different from regular MVC pattern?

[mehmedcavas]

I like mvc too which I can recommend for others to check out. Model view controller where models and controllers are non mono behavior classes and views which are monobehaviors. thanks to this the controller handles and updates data in the model and the views update them self when something changes in the model. lets say if you have a chess game, you have the chess board in a model class and make changes there. than the views (monobehaviours) changes visuals in the real scene. thanks to this, your code is more clean, scalable and really really easy to test with unit tests and other kind of tests like normal test scenes. One more thing to add, views do not contain any game logic. just maybe some basic if else things to update their visuals other than that they just send event requests or do visuals.

[Temasdin]

I use hybrid MVP/MVVM architecture + DI (Zenject) of course for each of my games. The flow is: bind models -> bind views from scene -> bind presenters (they are injected to states where they are presented via custom attribute and Domain) -> bind states -> rise init state via statemachine. No monobehaviours other than views, no update methods, everything is done via reactivity

Btw, I guess you did everything as monobehaviours for simplicity, but come on

[ramvenkat]

I really wish to understand them but in my opinion, these are not designed for beginners. I have a tough time understanding these can anyone suggest me any other videos to learn the programming patterns.

[enriquemorenotent]

Hasn't it been always called "Controller" instead of "Presenter"?

[dirtydevotee]

First of all, based on what you're saying at 3:00, it's a "model-presenter-view" pattern. So your video title is wrong. Second, there's no reason why you need an entire group of classes known as "presenters" when you could simply have a single "conversion" class. When you "present" something, it's so that people can "view" it. However you specifically said that class converts data from model to view. That one conversion class can have a ton of "returnOutputFromInput" functions and a single passthrough "conversion" method that applies the functions using an "input_data_type" argument and "input_value" argument.