All language subtitles for 012 The Model-View-Controller Family_en

So I have updated the UI here so that we still have a health drain going on here, but now to gain our

experience, we have to hit this button.

We gain experience points until we get to the point where we level up, still get our particle effect

like before and the health bar still replenishes.

But the difference is now we have to do this by the UI and instead of having a display happen in the

console, we've got it happening via our nice UI here.

So let's just have a look at what's changed in the code in order for this to happen.

So if we go and have a look, first of all at the health component, this is the simplest.

What we've done here is we've simply added a serialized field reference to an image component.

That image component is over here.

In the canvas view, you can see there's the bar.

That's what it points to.

So if I have a look at the observer example, you can see it points to this bar image.

And what it does is on the change.

A resetting of the health or the updating of the health that caused the update UI and Update UI simply

enters the fill amount of this image.

So the fill amount being this little slider here that allows us to fill that image from the left and

gives us health bar.

So the same principle is in operation over on the level.

We've got ourselves to theorize fields here, the display text for the level, the experience, text

for the level, and we have also got a reference to a button.

So what happens is we again have this update UI called on starts and called Omega an experience which

sets the text for these two pieces of UI, getting the level and getting the experience.

And we have an increase exp button, which when you click it essentially just calls gain experience

with 10 experience points.

So every time you click it, we gain 10 experience points.

Now, hopefully you can see that as a bit of a problem arising here.

They all this UI logic added to our level mono behavior is adding complexity, and it's also making

it a little bit harder for linking things up.

There's more stuff that could go wrong.

The Observe, for example, you can see we've got links that go from somewhere, some sort of gameplay

object all the way into the UI.

And that link you might forget to put in some places and stuff would break, and then there's more reasons

to need to change these classes.

So it's basically in violation of the one class deals with one thing rule.

Because here we're dealing with the game rules of the level we are dealing with handling inputs and

converting that into game rules.

We are dealing with formatting of text for the UI and linking it to the UI in general.

And then unity is dealing with the rendering.

So we're kind of triggering all the rendering and calling into the event system that E.A. is using.

So how do we typically solve this kind of UI conundrum?

Well, MVC is the traditional solution here, so you can see that we break this up into a model view

and controller.

And the fundamental idea is that the model would deal with game rules.

The view deal with rendering and the controller deals with input.

So how does this look in principle?

The View would initially get its data from the model.

It would render that data using probably the Unity UI system in our case, and the user or the player

will see that data in the uniform.

Then the user interacts with the UI.

The controller processes that interaction, and it will update the model on the basis of that interaction.

Now we use the observer pattern between the view and model for the view to observe changes on the model.

And so any on change event will get broadcast to the View without the model having to know that the

view even exists.

So any own change will trigger the view to update itself and render the new information so that instantaneously

the user provides input and sees the results all filtered through the game logic.

So how do the responsibilities break down here?

The model only handles game logic, often called business logic.

When you're dealing with business systems here, it's more game logic related.

So things like how many experience points does it take to level up?

That is the game logic.

The View deals with formatting, which we've seen with those text formatting pieces of code in there,

or perhaps translating a numerical value to a value on a slider that is formatting logic.

It also handles traditionally handles rendering.

Now we didn't see that in our code.

Rendering is mostly handled by unity directly.

And we just trigger that by manipulating stuff in the hierarchy.

Now, the controller deals with processing the input.

We saw that with our input binding, it also deals with events and handling those events.

Again, that's handled by unity.

But we just listen in on the hierarchy to get our input.

So this is traditional MVC.

Already, you can see that I was saying some things on here are handled by unity and some things are

handled by our own classes, and typically we can't really have this view do anything clever if it is

just that unity side of things.

So what we often see is an evolution of the traditional embassy.

We see this also for web development, where the view is basically HTML.

And so we don't can't do very much to manipulate the view.

You see a different sort of breakdown called the model view presenter.

And the idea is the same.

Let's try and break up that logic a little bit between the model, the model we don't want.

We don't want the model to depend on anything and just as game logic.

So in this situation, what happens?

The presenter will go and grab the data it needs from the model and it will update the view.

So the view becomes passive in this model, it doesn't go and listen to the model directly.

The presenter is responsible for updating it.

Then the view will be seen by the user.

The user gives some input.

Often again to the view.

So the view is now handling input as well as what we see.

And that seems to match a little bit better with how things work in unity, because the view in this

case could be literally this canvas view.

We can see that there's buttons here that would take the input from the user, but also simultaneously,

we're able to render the stuff in the view as well.

So, OK, this seems like a better match already than what happens.

We've got input come into the view now via bindings in the presenter.

We would get events coming through and then the presenter would update the model.

So the nice thing about a model view presenter is that now we've still got a oh yeah.

Also, we register for changes on the model just like we did before, so that the model doesn't need

to know anything about the presenters, and you could have multiple presenters hanging off of the same

model.

So the model still just responsible for game logic, it doesn't need to know anything about your UI.

It just needs to expose the data that it knows about.

The presenter now becomes responsible for input processing and formatting.

The two things that in unity we are doing in our shop code and the view layer now becomes responsible

for rendering an events, which is what unity is already doing for us in its UI canvas.

So this is a much better breakdown that fits with the unity way of things, and that's what we're going

to be trying to implement in the next lecture.

But before we go on to actually put this into practice, I wanted to talk about another variation of

model view controller called the Model View View model, often abbreviated to M.V. Am and you may have

heard of this one will come across in.

Pascal just wanted to clarify what that is here.

What we get is the model view model is acting very much like the presenter in our MVP model.

So here, the view model will get data from the model and then via a process of external data.

Binding properties on the view model will be bound to properties in the view and automatically when

a property changes in the View model.

It will get updated in the view and this is the fundamental difference.

Everything else is mostly the same.

The View model still updates the model based on an on change events and so on and so forth, or vice

versa as well.

Actually mean, but the crucial bit about the difference between the presenter and the View model is

this little magic binding layer, which if you have to use certain frameworks in order for this to happen.

But this essentially means that the View model knows nothing about the View, and The View knows nothing

about the View model, which is kind of nice.

So to summarise, what we have seen is MVC, where we have the model game logic separated out from the

view logic and the inputs logic handling in the controller.

Then we see the evolution of that, where the presenter does handle both the view logic and the input

logic.

But the view becomes more passive and only deals with rendering and event management.

And then we have the NVMe model, which is very similar to the MVP model.

With this extra magic of binding between the View and the View model, which allows us to have neither

of them depend on each other directly.

Great stuff.

I will see you in the next video where we will be putting this into practice to make this UI work a

lot nicer.