Welcome back.
So far in our game project, we've been using the model View Controller architecture pattern to handle
our UI and its relationship to our system, which we refer to sometimes as the model in the MVC architecture.
Now we have some understanding about MVC model view controller, how it works, how we're using our
widget controllers as controllers.
The key part in that MVC architecture.
Now MVC has been around for a while, and what exactly it is and how to use it has been the subject
of debate for quite some time, and sometimes those debates are quite heated.
Not all software engineers and developers and architects agree on the model view controller pattern.
For that matter.
Many of them disagree on many software engineering architecture patterns, but MVC is always a subject
of debate.
Now, Unreal Engine has just recently developed a plugin that we can add to our projects to harness
the power of another type of architecture, and this one is a newer architecture pattern than MVC.
It's called Model View ViewModel, and this pattern and its differences from MVC is also a subject of
debate.
And I'm going to link you to a really good article that discusses the differences between them.
We'll discuss them here as well.
But the article is by a person named Russell East who says in the article, if you put ten software
architects into a room and have them discuss what the model view controller pattern is, you will end
up with 12 different opinions.
That's from Russell East in his blog, and I'm going to link you to that blog.
Now.
How can you have ten software architects in a room and end up with 12 opinions?
Well, the reason is because there are so many opinions and so many convincing arguments that at least
two of the software architects are liable to end up with more than one opinion on the matter.
That's what we're dealing with here.
So read that article.
But the gist of that article is as follows.
We're using a model view controller architecture with the majority of our UI in the game, which means
we have a widget controller and it's getting its data from the model, which for our intents and purposes,
the model is the system, the ability system component, the attribute set, those classes that contain
the data that our widget controller is getting from it.
The widget controller has the dependency on the model.
It has include files inside of it.
It has references to these classes that exist in our game, right.
The game classes, the ability system component, the attribute set.
Those have no idea what a widget controller is.
There is no reference to any widget controller in our ability system component.
For example, the widget controller is dependent on the model, but the model is not dependent on the
widget controller.
Now the widget controller has ways to broadcast data right to our view, and our view consists of widgets.
Widgets which show data.
And yes, they do perform some of their own logic, but all of that logic has to do with showing the
data, right?
How does that data look when presented to the user?
And this widget controller class can broadcast to any number of widgets.
We can have multiple widgets that assign events to respond to delegates broadcast by the widget controller.
Now the widget controller uses lots of delegates, and delegates are an example of the observer design
pattern.
The observer pattern is another concept you can look up if you'd like to learn more about how that design
pattern works.
But if you've used delegates, you know how they work.
Delegates can be broadcast from one class, and that delegate contains a list of functions that should
be called, and.
Other classes that bind to that delegate have their callbacks, and when the delegate performs a broadcast
under the hood, it's going through all those callbacks and calling them.
Now, this means that the widget controller is independent of the view.
It's independent of those widgets.
It's the widgets that depend on the widget controller.
Now the model view ViewModel architecture pattern is actually very similar.
We have the model, and we have these view models that act as intermediaries between the model and the
view.
But the difference here is that we have a 1 to 1 relationship between the view model and the view.
There's one view model for one view in general.
Now Unreal Engine does make the system more flexible.
You could have one view model used in multiple views, but we have this direct binding going on.
We have data binding.
Our view model, which appears to just be playing the role of a widget controller, is actually closely
linked to the view, and it binds variables in the view.
The view has variables responsible for showing things to the user, and the view model is very closely
linked to each of those variables.
Now it's event driven, so there is no checking in tick or anything like that.
We don't have this constant update.
Something happens in the view such as user input, clicking on a button that sends an event to the view
model.
The view model then has the capability of making changes in the model, but really it's this 1 to 1
binding relationship that really distinguishes the view model.
The view model can be seen as a container that holds data and functionality that the view can be more
closely linked to.
But really, if you want to discuss the differences between MVC and mVVM, you can hop on to the internet
and have some heated debates if you feel so inclined.
They happen all the time, and for our purposes here, I'm really not interested in the debate side
of things.
I'm interested in learning how to use this mVVM architecture in our game, because Unreal Engine has
this fairly new system in place now.
It's pretty new at the time of recording this, which means it's definitely something you don't want
to ship your projects with.
For that reason, I've saved using it till the end here, but I thought it would be interesting to dive
into it and see how it works and how we can use it.
And maybe you can make the decision whether you like using these mVVM view models more than, say,
using your own widget controller, or perhaps even a different system altogether.
So for our load screen menu we're going to make a view model.
And we'll learn exactly how the view model is going to have relationships to the widget.
It will be bound to our load menu widget.
So in the next video we'll enable this plugin and create our first view model and see how it works.
I'll see you soon.