WEBVTT 00:07.050 --> 00:08.070 Welcome. 00:08.100 --> 00:14.100 Now, so far, there have been a couple of times that we've thrown a couple terms around that have to 00:14.100 --> 00:15.360 do with multiplayer. 00:15.360 --> 00:21.720 So I think it's about time we start to discuss multiplayer and its relationship to the gas system. 00:21.720 --> 00:28.830 Now, in a multiplayer game there exists a server and in most cases just one server. 00:28.830 --> 00:36.960 And this server is an instance of the game running separately and independently from the other machines 00:36.960 --> 00:40.290 that are also running their own version of the game. 00:40.290 --> 00:42.360 We call those clients. 00:42.540 --> 00:48.960 Now the server is different than the clients and we're going to discuss those differences in this video. 00:49.200 --> 00:54.240 Now, in a multiplayer game, the server can take on a number of flavors. 00:54.510 --> 00:57.930 For instance, there's the dedicated server. 00:58.410 --> 01:05.040 A dedicated server has no human player and no rendering to a screen occurs. 01:05.040 --> 01:12.910 It's just a computer running the game simulation now because there's no human player and no actual rendering 01:12.940 --> 01:14.170 to a screen. 01:14.200 --> 01:20.620 Don't let that fool you into thinking that things are not happening on the server machine, such as 01:20.620 --> 01:27.130 players running around shooting each other in a shooter game casting spells in a magic game, leveling 01:27.130 --> 01:30.250 up and gaining experience and things like that. 01:30.280 --> 01:35.470 Those are all things that can and do happen on the server version of the game. 01:35.560 --> 01:42.400 They just don't happen to be showing that by rendering images to a screen as the server doesn't need 01:42.400 --> 01:43.450 to do that. 01:43.480 --> 01:50.050 Now, aside from the dedicated server, there's another type of server model called the Listen server. 01:50.050 --> 01:56.770 Now this differs from the dedicated server in that the listen server is a human player, or at least 01:56.770 --> 02:04.480 it's a computer running a version of the game on which a human player is controlling a pawn or character. 02:04.480 --> 02:07.690 We say that that human player is hosting the game. 02:07.690 --> 02:15.070 Now the host has an advantage in the listen server model, and that advantage is that the host has no 02:15.070 --> 02:15.880 lag. 02:15.880 --> 02:22.060 Lag is the result of the time that it takes for data to travel across the network from the server to 02:22.060 --> 02:25.210 clients and from the clients up to the server. 02:25.210 --> 02:31.480 In a listen server, the host is the server and the server doesn't have to send data across the network 02:31.480 --> 02:35.860 to itself, so there is no lag for the hosting player. 02:36.130 --> 02:42.220 Now in Unreal Engine, we treat the server as the authoritative version of the game. 02:42.460 --> 02:45.430 Things are happening on each machine. 02:45.430 --> 02:51.370 Players run around, they change their positions and this happens on each and every version of the game 02:51.370 --> 02:52.210 that's running. 02:52.210 --> 02:59.470 But because of lag, your version of the character's location on your machine is going to be different 02:59.500 --> 03:05.790 than your character's location on another player's machine and on the servers. 03:05.800 --> 03:09.700 So we have to decide which machine is the correct version. 03:09.730 --> 03:16.480 We consider the server to be the correct version of the game, and for this reason we do important things 03:16.480 --> 03:17.580 on the server. 03:17.590 --> 03:19.570 Now what are those important things? 03:19.570 --> 03:23.200 We'll learn about those as we go along and program the game. 03:23.200 --> 03:29.740 But it's important to know that the server is always considered the authoritative version of the game. 03:30.100 --> 03:36.400 Now if we draw a dotted line between the server and the client, we can make some distinctions about 03:36.400 --> 03:37.960 certain game classes. 03:37.990 --> 03:41.380 The game mode exists only on the server. 03:41.380 --> 03:46.920 If you attempt to access the game mode on one of the clients, you will get a null pointer. 03:46.930 --> 03:53.200 That's because the game mode is responsible for things like rules of the game spawning players and restarting 03:53.200 --> 03:54.730 the game, things like that. 03:54.730 --> 04:00.130 And those are some of those important things we were talking about that should only be handled on the 04:00.130 --> 04:00.940 server. 04:01.270 --> 04:08.530 Now the player controllers for each player exist on the server, but they also exist on each client. 04:08.530 --> 04:15.130 So the server has an authoritative server version of each player controller and each client has their 04:15.130 --> 04:16.480 own local version. 04:16.480 --> 04:22.090 But notice that Client zero only has player controller zero on its machine. 04:22.120 --> 04:25.810 There is no player controller one or player Controller two. 04:25.810 --> 04:31.150 All the other player's player controllers don't exist on Client zero. 04:31.180 --> 04:37.170 It's only the server that has all of the player controllers in the game and can access them. 04:37.180 --> 04:37.780 Now. 04:37.780 --> 04:40.360 The player state is another story. 04:40.360 --> 04:41.770 The player states. 04:41.770 --> 04:47.770 For each player all exist on the server, but they also all exist on each client. 04:47.920 --> 04:55.600 Client Zero has a version of player state zero, along with Player State one and Player State two. 04:55.630 --> 04:59.200 So that's a distinction from the player controller class. 04:59.530 --> 05:06.160 Now if that seems confusing, just think of it as a sort of similarity that the player state has with 05:06.160 --> 05:06.710 the pause. 05:07.780 --> 05:15.310 You see, the server has all three pawns in the game, but each client also has all three pawns in the 05:15.310 --> 05:17.350 game, which makes sense. 05:17.350 --> 05:23.290 If you're playing the game, you have to be able to see your pawn running around, but you also have 05:23.290 --> 05:28.540 to see the pawn controlled by client one and the pawn controlled by client two. 05:28.570 --> 05:34.620 It only makes sense that your machine has copies of all three pawns in the game. 05:34.630 --> 05:35.980 Same with client one. 05:35.980 --> 05:40.930 It needs to see your pawn as well as its own and client two's. 05:41.290 --> 05:45.210 So all the pawns in the game exist on all machines. 05:45.220 --> 05:47.230 The same goes for the player state. 05:47.530 --> 05:54.730 Now the HUD and all associated widgets that get shown on the screen are sort of different than all the 05:54.730 --> 05:55.790 other classes. 05:55.810 --> 06:01.560 Each client has its own HUD class and it only exists on that client. 06:01.570 --> 06:06.450 So if we're talking about a dedicated server, there is no HUD on the server. 06:06.460 --> 06:13.340 If it's a listen server, then the only HUD that exists is the HUD for that local player playing the 06:13.340 --> 06:13.980 game. 06:14.000 --> 06:21.890 Each client only has its own HUD and any associated widgets that get shown to the screen for that player. 06:21.920 --> 06:25.370 Client Zero does not have access to Client One's HUD. 06:25.400 --> 06:28.070 It doesn't exist on Client Zero's machine. 06:28.310 --> 06:32.090 So what does all this mean in relation to replication? 06:32.120 --> 06:35.220 We set our player controller class to be replicated. 06:35.240 --> 06:36.620 What does that mean? 06:36.710 --> 06:41.480 And our player state was set to have a net update frequency of 100. 06:41.510 --> 06:42.770 What does that mean? 06:42.800 --> 06:49.760 Well, net update frequency just means that as changes are made on the server, every single net update, 06:49.760 --> 06:54.650 the server sends data down to the client so they can be informed of that change. 06:54.680 --> 07:01.100 A net update frequency of 100 means that those changes will be updated on clients 100 times a second, 07:01.100 --> 07:06.620 as long as the server can manage that when data is transmitted from the server down to clients. 07:06.650 --> 07:09.820 We call that replication, and here's how it works. 07:09.830 --> 07:13.130 Let's say you have a variable on the pawn class. 07:13.130 --> 07:16.890 Now it could be a float, an integer or any other type. 07:16.910 --> 07:24.860 Now it exists in the pawn class, which means that each version of the pawn has that variable, the 07:24.860 --> 07:29.420 version of the pawn on clients, the version of the pawn on the server. 07:29.450 --> 07:30.960 They all have the variable. 07:30.980 --> 07:38.090 Now, if the variable is designated to be a replicated variable, then if that variable's value changes 07:38.090 --> 07:46.310 on the server, then the next net update that change will be sent down to all clients so that the client 07:46.310 --> 07:50.690 version of that variable can be updated to the new value. 07:50.720 --> 07:55.100 This act of sending that data down to clients is called replication. 07:55.130 --> 08:01.670 Now what happens if we have a replicated variable and it gets changed on one of the clients? 08:01.700 --> 08:06.160 Does that mean that the server will be informed of that change? 08:06.170 --> 08:09.560 In other words, does replication work both ways? 08:09.590 --> 08:12.200 The answer is no. 08:12.350 --> 08:21.080 Replication only works one way from server to client, so if a variable is marked as replicated, it 08:21.080 --> 08:28.310 should not be changed on clients because the server will not know about that change and neither will 08:28.310 --> 08:29.660 any of the other clients. 08:29.690 --> 08:36.650 Only the client who changed that variable will know about it and that variable will now be out of sync 08:36.650 --> 08:39.170 with the server's version of that value. 08:39.170 --> 08:45.170 And remember, the server is the correct version, so the variable on that client will now be considered 08:45.170 --> 08:46.310 incorrect. 08:46.340 --> 08:52.460 Now you might be thinking if replication only works one way, how would a client ever get data up to 08:52.460 --> 08:53.450 the server? 08:53.480 --> 08:56.520 Obviously that has to happen sometimes, right? 08:56.540 --> 09:00.800 I mean, we make input with our keyboard and mouse or controller. 09:00.830 --> 09:04.220 That input has to make its way to the server somehow. 09:04.250 --> 09:12.220 Well, yes, it does in the form of replicated functions which we call RPC or remote procedure calls 09:12.220 --> 09:14.290 and we'll learn about those later. 09:14.290 --> 09:21.970 But the truth is this high level overview of replication is just about all you need to know about multiplayer 09:21.970 --> 09:23.070 for this course. 09:23.080 --> 09:28.720 You can learn all about it if you take my multiplayer shooter course, but there's a reason that that 09:28.720 --> 09:35.380 course is not a prerequisite for this course, and that's because most of the multiplayer stuff is handled 09:35.380 --> 09:36.010 under the hood. 09:36.010 --> 09:37.150 For us in gas. 09:37.150 --> 09:44.290 We will need to know a little bit about multiplayer, but for the most part, gas handles a lot of stuff 09:44.290 --> 09:50.170 for us under the hood and we'll learn about that stuff that gas does for us so that we can appreciate 09:50.170 --> 09:56.440 and let it work for us as we're building our game and all of the gameplay mechanics that we implement 09:56.440 --> 10:00.700 in this course will work in multiplayer as well as single player. 10:01.060 --> 10:06.820 So now that we know a little bit about how the classes work in relation to multiplayer, we'll. 10:06.970 --> 10:14.800 Now move on and add our ability system component and attribute sets to our player state for our player 10:14.800 --> 10:19.210 controlled character and to the character class for our enemies. 10:19.210 --> 10:25.480 And we'll learn how to associate the ability, system component and attribute set with its owner and 10:25.480 --> 10:28.270 we'll learn what that means in the videos to come. 10:28.450 --> 10:29.590 I'll see you soon.