WEBVTT 00:06.930 --> 00:09.690 Welcome in multiplayer games. 00:09.690 --> 00:14.760 The server should have authority over any significant changes to the game state. 00:15.600 --> 00:22.830 If clients can change important factors, then this leaves a vulnerability that cheaters can exploit. 00:23.100 --> 00:30.390 However, if clients must wait for confirmation from the server that their requested changes are valid, 00:30.420 --> 00:35.970 then a noticeable delay would exist between the client performing an action. 00:36.620 --> 00:39.740 And seeing the results to mitigate this problem. 00:39.740 --> 00:42.350 Games make use of prediction. 00:42.560 --> 00:46.370 Prediction is when the client goes ahead and makes a change. 00:46.370 --> 00:53.690 Moving the character, opening a door, shooting a weapon and informs the server of that change. 00:53.780 --> 00:58.670 When the server gets the information, it makes sure that it's a valid change. 00:58.970 --> 01:06.080 The character hasn't moved into a wall or traveled across the map in a split second or opened a door 01:06.110 --> 01:10.010 that it can't reach or shot a weapon that it doesn't own. 01:10.010 --> 01:10.970 ET cetera. 01:11.180 --> 01:16.130 And if the change is not valid, the server undoes those changes. 01:16.650 --> 01:18.690 To have a playable experience. 01:18.700 --> 01:22.680 Fast paced multiplayer games have to make use of prediction. 01:23.070 --> 01:29.880 The goal of the gameplay ability system is to have gameplay logic and a gameplay ability and prediction 01:29.880 --> 01:32.820 for that ability that just works. 01:32.850 --> 01:40.650 What the developers didn't want was to have abilities filled with branches, like if authority do x, 01:40.980 --> 01:43.530 else do predicted version of x. 01:43.560 --> 01:47.700 Rather they wanted prediction that was more or less automatic. 01:47.820 --> 01:52.000 Now it's important to note that not everything needs to be predicted. 01:52.020 --> 01:59.040 Footstep sounds, for example, don't need to be predicted, but significant things like health changes, 01:59.040 --> 02:00.960 Mana doing damage. 02:00.960 --> 02:07.650 Things like this need to be predicted as the server should have some say in whether or not those changes 02:07.650 --> 02:08.460 are valid. 02:09.430 --> 02:10.560 Out of the box. 02:10.570 --> 02:19.090 Gas automatically predicts ability activation triggered events gameplay effect application including 02:19.090 --> 02:26.440 attribute modification but not execution calculations which we haven't made yet, but we'll get to those. 02:26.470 --> 02:33.490 Gameplay tag modification as well as gameplay cue events whether they're from some predicted gameplay 02:33.490 --> 02:38.950 ability or on their own and we'll get to gameplay cues soon enough. 02:39.130 --> 02:46.750 Also predicted are montages as well as movement, thanks to the new character movement system in Unreal 02:46.750 --> 02:54.790 Engine, but gas does not predict gameplay effect, removal or gameplay effect periodic effects. 02:55.120 --> 02:58.840 These are some technical challenges that have not been overcome. 02:59.200 --> 03:04.930 Prediction in gas is centered around the concept of a prediction key. 03:04.960 --> 03:13.250 Prediction keys are based on prediction key A prediction key is simply a unique ID, and these are stored 03:13.250 --> 03:15.800 in a central location on the client. 03:16.370 --> 03:23.150 When the client performs a predictive action, it will send a prediction key up to the server and associate 03:23.150 --> 03:27.980 its client side predictive actions and side effects with that key. 03:28.010 --> 03:33.200 The server will receive that key and either accept it or reject it. 03:33.230 --> 03:41.000 It will then associate any server side created side effects with that key and will respond to the client 03:41.000 --> 03:45.770 informing it that the key has either been accepted or rejected. 03:45.770 --> 03:51.470 An F prediction key sent from client to server will always make it to the server. 03:51.560 --> 03:57.950 Now, in the past we've made the statement that replication only happens from server to client, but 03:57.950 --> 04:00.740 that was referring to replicated variables. 04:00.740 --> 04:07.100 In other words, variables marked with replicated or replicated using in their uproperty macro. 04:07.160 --> 04:13.250 For these, yes, replication only happens from server to client, but here we're talking about sending 04:13.250 --> 04:19.950 a prediction key up to the server and for this we often use the term replication for convenience. 04:19.950 --> 04:26.370 So we say that that key is being replicated to the server and you'll see this trend a lot in gas. 04:26.520 --> 04:32.430 And when a server sends the prediction key back, it will only go back to the client that sent it to 04:32.430 --> 04:34.230 the server in the first place. 04:34.320 --> 04:42.330 This replication down to clients is done in the prediction key net serialize function and all other 04:42.330 --> 04:50.070 clients will simply receive an invalid key or a key with an ID of zero when that prediction key replicates. 04:51.010 --> 04:58.180 We say that a gameplay ability in gas is a first class predictive action, meaning that whenever a client 04:58.180 --> 05:05.230 predictively activates an ability, it explicitly tells the server and the server explicitly responds 05:05.320 --> 05:08.710 whenever a client predictively activates an ability. 05:08.740 --> 05:13.450 There now exists a window in which predictive actions can occur. 05:13.600 --> 05:20.800 We refer to this window as a prediction window, and while this window is open, the client can perform 05:20.800 --> 05:26.830 important actions that can change the game state such as use up attribute resources. 05:26.860 --> 05:27.850 ET cetera. 05:27.850 --> 05:30.580 Without asking the server for permission. 05:31.240 --> 05:37.390 The ability system component has functions for communicating the activation of abilities between clients 05:37.390 --> 05:38.350 and server. 05:38.530 --> 05:42.970 We've already seen and used one of them tri activate ability. 05:43.120 --> 05:46.900 Here's what happens when we call this function first. 05:46.930 --> 05:53.020 The client calls tri activate ability and this results in the generation of a new prediction key. 05:53.110 --> 06:00.520 Remember in our ability task target data under mouse when we call the function get activation prediction 06:00.520 --> 06:01.030 key. 06:01.060 --> 06:06.520 This is the key that that function retrieves that activation prediction key. 06:06.550 --> 06:15.820 Now once tri activate ability is called, then a server RPC is called and that rpc is server tri activate 06:15.820 --> 06:16.660 ability. 06:16.690 --> 06:23.380 After calling this server RPC, the client continues on without waiting for any server confirmation 06:23.380 --> 06:29.620 and goes ahead and calls activate ability with the generated prediction key which is now stamped onto 06:29.620 --> 06:33.500 that abilities activation and its activation info. 06:33.680 --> 06:40.280 While the client is busy doing things and generating side effects, all the side effects have this generated 06:40.280 --> 06:42.710 prediction key associated with them. 06:42.830 --> 06:49.040 Now we mentioned that the client calls a server RPC server tri activate ability. 06:49.040 --> 06:53.810 Once the server receives this and this RPC is executed on the server. 06:54.020 --> 06:58.430 The server then decides if this ability activation is valid. 06:58.460 --> 07:05.360 Now, once the server makes this determination, it now knows whether or not this client activated ability 07:05.360 --> 07:07.880 is a failure or a success. 07:07.880 --> 07:11.240 And then it calls one of two client rpcs. 07:11.270 --> 07:17.450 If the ability activation was a failure, the server calls client activate ability failed. 07:17.480 --> 07:23.030 If it was a success, the server calls client activate ability succeeded. 07:23.180 --> 07:29.780 The client receives the server's response and if it receives failure, it kills the ability and then 07:29.780 --> 07:34.910 proceeds to undo all the side effects associated with the generated prediction key. 07:34.940 --> 07:39.980 If it was a success, then those side effects are valid and don't need to be undone. 07:40.400 --> 07:47.510 Now the ability system component has a member variable called replicated prediction key, and this is 07:47.510 --> 07:49.630 set to the generated prediction key. 07:49.640 --> 07:52.430 And as soon as it's set, it replicates. 07:52.550 --> 07:59.180 Once it catches up to the client, the client can then respond accordingly, such as undoing side effects 07:59.180 --> 08:00.170 and so on. 08:00.170 --> 08:03.320 And this prediction key has its own rep notify. 08:03.350 --> 08:05.810 It's called on rep Prediction key. 08:06.460 --> 08:09.630 Now, we've been talking an awful lot about side effects. 08:09.640 --> 08:11.950 So what are some examples of those? 08:12.040 --> 08:15.110 Well, gameplay effects are side effects. 08:15.130 --> 08:21.070 These are not first class predictive actions like abilities are because they're not explicitly asked 08:21.070 --> 08:27.100 about gameplay effects are only applied on clients if there is a valid prediction key for the ability 08:27.100 --> 08:28.120 applying them. 08:28.120 --> 08:34.630 If the gameplay effect is predicted, then any of the following that the gameplay effect does are also 08:34.630 --> 08:35.500 predicted. 08:36.040 --> 08:41.740 Attribute modifications, gameplay tag modifications and gameplay cues. 08:41.920 --> 08:48.640 When the active gameplay effect is created, it stores this prediction key on the server. 08:48.670 --> 08:55.780 The active gameplay effect gets the same key and this active gameplay effect is replicated now on the 08:55.780 --> 08:56.650 client side. 08:56.650 --> 09:03.130 When it receives that replication, it can then check the key to see if it already has an active gameplay 09:03.130 --> 09:05.110 effect with that same key. 09:05.140 --> 09:12.590 Now if they match then we already know that any logic executed upon effect application has already been 09:12.590 --> 09:15.980 done locally and doesn't need to be run again. 09:16.010 --> 09:22.550 This helps to avoid duplicate on apply type effects that you can often run into when implementing your 09:22.550 --> 09:23.810 own prediction. 09:24.080 --> 09:30.650 This does mean, however, that the local container that stores all active gameplay effects will now 09:30.650 --> 09:34.190 have two of the same effect, at least temporarily. 09:34.700 --> 09:41.360 The ability system components replicated prediction key variable will be currently replicating down 09:41.360 --> 09:42.110 to the client. 09:42.110 --> 09:48.590 While all this is happening and when it finally arrives, any predicted effects can be removed. 09:48.590 --> 09:54.320 And of course we have on rep prediction key to do anything that needs to happen once that prediction 09:54.320 --> 09:55.820 key arrives. 09:56.680 --> 10:03.940 At this point, I feel we have a good enough understanding of prediction in gas and why we need prediction 10:03.940 --> 10:04.780 keys. 10:04.870 --> 10:11.260 How deep you decide to dig into the gas code is up to you, but it's important to have at least a high 10:11.260 --> 10:15.700 level understanding of what gas is doing behind the scenes for us. 10:15.910 --> 10:22.330 For more information, please refer to gameplay prediction dot h where the comments therein explain 10:22.330 --> 10:27.880 much of what we've gone over in this video and you can learn more about how prediction is handled there, 10:27.880 --> 10:34.390 including prediction for gameplay attributes as well as some of the more advanced level challenges that 10:34.390 --> 10:37.630 were faced when implementing the prediction system in gas. 10:38.440 --> 10:43.540 So now that we have some understanding of gas prediction, we can now better understand the code we've 10:43.540 --> 10:50.860 created in our custom gameplay task target data under mouse and we can now continue implementing interesting 10:50.860 --> 10:51.670 things. 10:52.060 --> 10:53.260 I'll see you soon.