WEBVTT 00:07.630 --> 00:08.740 Welcome back. 00:08.740 --> 00:15.820 So far in our game project, we've been using the model View Controller architecture pattern to handle 00:15.820 --> 00:24.730 our UI and its relationship to our system, which we refer to sometimes as the model in the MVC architecture. 00:25.090 --> 00:31.810 Now we have some understanding about MVC model view controller, how it works, how we're using our 00:31.810 --> 00:34.690 widget controllers as controllers. 00:34.690 --> 00:37.570 The key part in that MVC architecture. 00:37.870 --> 00:45.190 Now MVC has been around for a while, and what exactly it is and how to use it has been the subject 00:45.190 --> 00:50.260 of debate for quite some time, and sometimes those debates are quite heated. 00:50.710 --> 00:56.770 Not all software engineers and developers and architects agree on the model view controller pattern. 00:56.770 --> 00:57.760 For that matter. 00:57.760 --> 01:04.810 Many of them disagree on many software engineering architecture patterns, but MVC is always a subject 01:04.810 --> 01:05.650 of debate. 01:06.130 --> 01:13.990 Now, Unreal Engine has just recently developed a plugin that we can add to our projects to harness 01:13.990 --> 01:21.430 the power of another type of architecture, and this one is a newer architecture pattern than MVC. 01:21.430 --> 01:30.250 It's called Model View ViewModel, and this pattern and its differences from MVC is also a subject of 01:30.250 --> 01:31.030 debate. 01:31.510 --> 01:37.540 And I'm going to link you to a really good article that discusses the differences between them. 01:37.540 --> 01:39.160 We'll discuss them here as well. 01:39.160 --> 01:46.990 But the article is by a person named Russell East who says in the article, if you put ten software 01:46.990 --> 01:52.480 architects into a room and have them discuss what the model view controller pattern is, you will end 01:52.480 --> 01:54.640 up with 12 different opinions. 01:55.210 --> 01:59.020 That's from Russell East in his blog, and I'm going to link you to that blog. 01:59.020 --> 01:59.530 Now. 01:59.530 --> 02:04.840 How can you have ten software architects in a room and end up with 12 opinions? 02:05.260 --> 02:13.180 Well, the reason is because there are so many opinions and so many convincing arguments that at least 02:13.180 --> 02:19.540 two of the software architects are liable to end up with more than one opinion on the matter. 02:20.140 --> 02:21.790 That's what we're dealing with here. 02:21.790 --> 02:23.680 So read that article. 02:23.680 --> 02:26.980 But the gist of that article is as follows. 02:27.490 --> 02:33.820 We're using a model view controller architecture with the majority of our UI in the game, which means 02:33.820 --> 02:39.850 we have a widget controller and it's getting its data from the model, which for our intents and purposes, 02:39.850 --> 02:46.990 the model is the system, the ability system component, the attribute set, those classes that contain 02:46.990 --> 02:51.070 the data that our widget controller is getting from it. 02:51.070 --> 02:54.730 The widget controller has the dependency on the model. 02:54.730 --> 02:57.880 It has include files inside of it. 02:57.880 --> 03:02.740 It has references to these classes that exist in our game, right. 03:02.740 --> 03:07.090 The game classes, the ability system component, the attribute set. 03:07.090 --> 03:10.780 Those have no idea what a widget controller is. 03:10.780 --> 03:15.100 There is no reference to any widget controller in our ability system component. 03:15.100 --> 03:20.980 For example, the widget controller is dependent on the model, but the model is not dependent on the 03:20.980 --> 03:22.270 widget controller. 03:22.630 --> 03:30.340 Now the widget controller has ways to broadcast data right to our view, and our view consists of widgets. 03:30.340 --> 03:32.560 Widgets which show data. 03:32.560 --> 03:38.530 And yes, they do perform some of their own logic, but all of that logic has to do with showing the 03:38.530 --> 03:39.940 data, right? 03:39.940 --> 03:43.660 How does that data look when presented to the user? 03:43.660 --> 03:48.430 And this widget controller class can broadcast to any number of widgets. 03:48.430 --> 03:55.600 We can have multiple widgets that assign events to respond to delegates broadcast by the widget controller. 03:55.990 --> 04:02.890 Now the widget controller uses lots of delegates, and delegates are an example of the observer design 04:02.890 --> 04:03.640 pattern. 04:03.880 --> 04:11.110 The observer pattern is another concept you can look up if you'd like to learn more about how that design 04:11.110 --> 04:11.680 pattern works. 04:11.680 --> 04:14.410 But if you've used delegates, you know how they work. 04:14.940 --> 04:21.600 Delegates can be broadcast from one class, and that delegate contains a list of functions that should 04:21.600 --> 04:22.530 be called, and. 04:22.530 --> 04:29.250 Other classes that bind to that delegate have their callbacks, and when the delegate performs a broadcast 04:29.250 --> 04:32.490 under the hood, it's going through all those callbacks and calling them. 04:32.490 --> 04:36.660 Now, this means that the widget controller is independent of the view. 04:36.660 --> 04:38.610 It's independent of those widgets. 04:38.610 --> 04:41.400 It's the widgets that depend on the widget controller. 04:41.970 --> 04:48.390 Now the model view ViewModel architecture pattern is actually very similar. 04:48.390 --> 04:56.670 We have the model, and we have these view models that act as intermediaries between the model and the 04:56.670 --> 04:57.360 view. 04:57.360 --> 05:03.480 But the difference here is that we have a 1 to 1 relationship between the view model and the view. 05:03.900 --> 05:07.110 There's one view model for one view in general. 05:07.110 --> 05:10.350 Now Unreal Engine does make the system more flexible. 05:10.350 --> 05:17.190 You could have one view model used in multiple views, but we have this direct binding going on. 05:17.190 --> 05:18.870 We have data binding. 05:18.870 --> 05:27.180 Our view model, which appears to just be playing the role of a widget controller, is actually closely 05:27.180 --> 05:32.790 linked to the view, and it binds variables in the view. 05:32.790 --> 05:40.290 The view has variables responsible for showing things to the user, and the view model is very closely 05:40.290 --> 05:43.230 linked to each of those variables. 05:43.410 --> 05:48.840 Now it's event driven, so there is no checking in tick or anything like that. 05:48.840 --> 05:50.880 We don't have this constant update. 05:50.880 --> 05:58.290 Something happens in the view such as user input, clicking on a button that sends an event to the view 05:58.290 --> 05:58.620 model. 05:58.620 --> 06:07.980 The view model then has the capability of making changes in the model, but really it's this 1 to 1 06:07.980 --> 06:11.640 binding relationship that really distinguishes the view model. 06:11.670 --> 06:19.710 The view model can be seen as a container that holds data and functionality that the view can be more 06:19.710 --> 06:21.120 closely linked to. 06:21.120 --> 06:29.040 But really, if you want to discuss the differences between MVC and mVVM, you can hop on to the internet 06:29.040 --> 06:33.240 and have some heated debates if you feel so inclined. 06:33.510 --> 06:40.980 They happen all the time, and for our purposes here, I'm really not interested in the debate side 06:40.980 --> 06:41.700 of things. 06:41.700 --> 06:48.390 I'm interested in learning how to use this mVVM architecture in our game, because Unreal Engine has 06:48.390 --> 06:51.390 this fairly new system in place now. 06:51.390 --> 06:57.960 It's pretty new at the time of recording this, which means it's definitely something you don't want 06:57.960 --> 06:59.700 to ship your projects with. 06:59.700 --> 07:05.370 For that reason, I've saved using it till the end here, but I thought it would be interesting to dive 07:05.370 --> 07:08.430 into it and see how it works and how we can use it. 07:08.430 --> 07:15.450 And maybe you can make the decision whether you like using these mVVM view models more than, say, 07:15.450 --> 07:21.390 using your own widget controller, or perhaps even a different system altogether. 07:22.120 --> 07:26.590 So for our load screen menu we're going to make a view model. 07:26.590 --> 07:33.520 And we'll learn exactly how the view model is going to have relationships to the widget. 07:33.520 --> 07:37.540 It will be bound to our load menu widget. 07:38.050 --> 07:43.510 So in the next video we'll enable this plugin and create our first view model and see how it works. 07:43.900 --> 07:44.890 I'll see you soon.