WEBVTT 00:07.190 --> 00:08.240 Welcome. 00:08.600 --> 00:14.930 Now, we've just put a lot of effort into adding an ability system component and an attribute set. 00:14.960 --> 00:21.680 We were careful to initialize our ability system component with an owner, actor and an avatar actor. 00:21.680 --> 00:25.370 So our ability system component knows who its owner is. 00:25.490 --> 00:27.380 What about the attribute set? 00:27.410 --> 00:34.640 Well, when we construct the attribute set alongside the ability system component inside the owner actor's 00:34.640 --> 00:40.250 constructor, as we've done, it's automatically registered with the ability system component. 00:40.280 --> 00:45.920 The ability system component has access to it and any other attribute sets that are registered with 00:45.920 --> 00:46.430 it. 00:46.520 --> 00:49.580 We can have multiple attribute sets if we wish. 00:49.610 --> 00:55.730 Say you want to distribute your attributes among several different attribute sets based on category. 00:55.940 --> 01:01.370 Well, you can do this if you like, but it's important to know that each of these must be separate 01:01.370 --> 01:02.190 classes. 01:02.210 --> 01:06.290 You can't have more than one attribute set of the same class type. 01:06.320 --> 01:11.580 Otherwise, you get ambiguity attempting to retrieve it from the ability system component. 01:11.610 --> 01:17.730 On the other hand, it's perfectly acceptable to contain all of your attributes on the same attribute 01:17.730 --> 01:18.420 set. 01:18.450 --> 01:24.030 This can make things simpler, especially if the attribute set needs to know about the values of the 01:24.030 --> 01:26.730 other attributes when making calculations. 01:26.760 --> 01:33.600 Attributes take up negligible memory so you can even share a single attribute set among all classes 01:33.600 --> 01:40.200 in your project if you wish, and simply use the attributes that you need in any given class in this 01:40.200 --> 01:41.220 game project. 01:41.250 --> 01:46.680 Our attribute set will contain attributes that are used by all characters in the game, so we'll have 01:46.680 --> 01:48.270 just a single attribute set. 01:48.270 --> 01:51.990 But keep in mind for future reference that you can have multiple. 01:52.020 --> 01:54.480 So what are attributes exactly? 01:54.510 --> 02:01.230 Attributes are numerical quantities associated with a given entity in the game such as a character. 02:01.380 --> 02:03.630 All attributes are floats. 02:03.660 --> 02:08.070 They exist within a structure called gameplay attribute data. 02:08.370 --> 02:14.550 Attributes are stored on the attribute set, and the attribute set keeps them under close supervision. 02:14.580 --> 02:20.310 We can know when an attribute changes and respond to it with any functionality that we like. 02:20.550 --> 02:27.750 Now attribute values can be set directly in code, but the preferred way to change them is by applying 02:27.750 --> 02:29.070 gameplay effects. 02:29.220 --> 02:34.710 When we get to gameplay effects in this course, we'll soon learn that gameplay effects can change attribute 02:34.710 --> 02:37.110 values in a number of different ways. 02:37.350 --> 02:43.620 Aside from the built in capabilities of gameplay effects, another reason to use them is because gameplay 02:43.620 --> 02:47.460 effects allow us to predict changes to attributes. 02:47.820 --> 02:53.760 Prediction means that the client doesn't need to wait for the server's permission to change a value. 02:53.790 --> 02:59.750 The value can change immediately client side and the server is informed of the change. 02:59.760 --> 03:03.840 The server can then roll back any changes that it deems invalid. 03:03.930 --> 03:09.420 This is a huge benefit because prediction can take a lot of extra work to program yourself. 03:09.720 --> 03:13.800 Prediction is something that makes for a smoother experience in multiplayer. 03:13.800 --> 03:18.780 It's one of those things that you don't notice when it's there, but you do notice when it's not. 03:18.870 --> 03:23.760 Here's how a client side change would occur without prediction on the client. 03:23.760 --> 03:29.550 Let's say you have an attribute that needs to change since the server should be in charge of important 03:29.550 --> 03:30.930 gameplay changes. 03:31.050 --> 03:33.720 Otherwise clients would be able to cheat. 03:33.900 --> 03:41.130 A request is sent to the server telling it that the attributes value needs to change so the server receives 03:41.130 --> 03:47.520 the request decides whether that request is valid based on any number of criteria set by the developers, 03:47.520 --> 03:54.090 and if that change is deemed valid, the server then sends the confirmation back down to the client 03:54.120 --> 03:56.970 who can now change the attributes value. 03:57.000 --> 04:03.450 Since data takes time to travel across the network, this results in a noticeable delay from the time 04:03.450 --> 04:09.060 the client needed to change the value to the time it received permission from the server to actually 04:09.060 --> 04:09.990 change it. 04:10.020 --> 04:16.770 It's not unusual for lag times to reach 100 milliseconds or more, so performing an action in the game 04:16.770 --> 04:22.890 and having a noticeable delay before you can see and hear the effects of that action makes for a very 04:22.890 --> 04:24.780 bad gameplay experience. 04:25.080 --> 04:28.230 Let's see how this type of thing works with prediction. 04:28.500 --> 04:35.700 With prediction in gas, a gameplay effect modifies an attribute client side and that change is perceived 04:35.700 --> 04:37.290 on the client instantly. 04:37.320 --> 04:38.820 No lag times. 04:38.820 --> 04:45.270 Then that change is sent up to the server who still has the responsibility of validating that change. 04:45.540 --> 04:49.010 If the server decides it's a valid change, then cool. 04:49.020 --> 04:51.510 It can inform the other clients of the change. 04:51.510 --> 04:58.020 However, if the server decides that the change is not valid, let's say a client hacks the game and 04:58.020 --> 05:04.320 tries to do an ungodly amount of damage, for example, then the server can reject that change and roll 05:04.320 --> 05:06.870 back the changes, setting the client's value. 05:06.910 --> 05:08.290 Back to the correct one. 05:08.590 --> 05:14.920 So the server still has authority, but our client doesn't have to have a delay. 05:15.130 --> 05:22.210 Prediction is complicated and having it as a built in feature throughout gas is a huge benefit that 05:22.210 --> 05:28.390 lets us focus on creating gameplay mechanics and not worry about implementing lag compensation. 05:28.780 --> 05:35.920 So an attribute is an object of type gameplay attribute data and is stored on the attribute set. 05:36.280 --> 05:41.500 Attributes actually consist of two values a base value and a current value. 05:41.650 --> 05:45.220 The base value is the permanent value of an attribute. 05:45.250 --> 05:52.330 The current value is the base value plus any temporary modifications caused by gameplay effects. 05:52.660 --> 05:59.200 Think about this in terms of buffs and debuffs, you may have an effect that adds or subtracts a value 05:59.200 --> 06:05.560 for a certain period of time, and once that time is up, that modification is undone and the attribute 06:05.590 --> 06:07.730 goes back to its base value. 06:07.820 --> 06:13.780 Now, you may be tempted to conclude that the base value is the max value for the attribute. 06:13.790 --> 06:19.670 For example, when calculating the percentage for a health bar, do you divide the current value by 06:19.670 --> 06:20.690 the base value? 06:20.720 --> 06:21.620 Well, no. 06:21.620 --> 06:25.010 This is a common mistake and it's not the way to go about it. 06:25.160 --> 06:29.810 The max value for an attribute is separate from the attribute itself. 06:30.050 --> 06:37.100 If the max value can change, which is pretty common, the max value should be its own separate attribute. 06:37.220 --> 06:43.820 This way we can have gameplay effects applied to the attribute itself or apply to the max attribute 06:43.820 --> 06:49.730 separately, and the percentage for your health bar, for example, can simply be the fraction of health 06:49.730 --> 06:51.260 divided by max health. 06:51.440 --> 06:54.110 So now that we know what attributes are. 06:54.140 --> 06:58.940 It's time to add some to our attributes set and we'll do that next.