WEBVTT 00:07.730 --> 00:08.270 Okay. 00:08.270 --> 00:09.170 Welcome back. 00:09.170 --> 00:12.070 Now we've created our first gameplay ability. 00:12.080 --> 00:18.440 In fact, we created a C plus plus class and we based a blueprint off of that class. 00:18.440 --> 00:24.350 So the base class is if we click on class settings, we can see its aura gameplay ability. 00:24.530 --> 00:32.360 But going back to class defaults here in our test gameplay ability blueprint, we have a few options 00:32.360 --> 00:39.350 and we're going to go over these options in a sort of rundown in this video so we can kind of get an 00:39.350 --> 00:46.340 idea for the types of things that we should be concerned about on the gameplay ability class and things 00:46.340 --> 00:48.710 that we should be less concerned about. 00:48.890 --> 00:55.940 Now, the first thing we see in the details panel, at least in this version of gas, is the tags. 00:55.940 --> 01:04.310 And in the tags we have a number of different gameplay tags which we can click and drop down and we 01:04.310 --> 01:05.960 can add things here. 01:05.960 --> 01:09.930 Let's say I want to add multiple tags to the ability tags. 01:09.930 --> 01:12.030 I can add them and I can clear them all. 01:12.030 --> 01:15.840 So you can add tags from right here in the details panel. 01:15.840 --> 01:18.900 And each of these has different meanings. 01:18.900 --> 01:26.370 And their tooltips, if we hover over them, come directly from comments in the gameplay ability class 01:26.370 --> 01:31.200 in C plus plus, and they're all pretty self-explanatory and not very cryptic. 01:31.200 --> 01:32.790 Pretty easy to understand. 01:32.790 --> 01:34.560 Let's run through each of them. 01:35.040 --> 01:37.190 So first we have ability tags. 01:37.200 --> 01:40.070 These are the tags that an ability has. 01:40.080 --> 01:45.900 So an ability has the concept of having tags and we can add them right there in the details. 01:45.900 --> 01:49.440 Panel, any tags that we want to add to a given ability. 01:49.470 --> 01:52.560 So why would an ability want to have tags? 01:52.560 --> 01:54.870 Well, let's move on and we'll see why. 01:54.900 --> 01:58.800 The next container we have is cancel abilities with tag. 01:58.800 --> 02:04.890 And the comment says abilities with these tags are canceled when this ability is executed. 02:04.890 --> 02:08.970 So here's an example of why an ability would want to have some tags. 02:08.970 --> 02:16.470 Let's say you give an ability its own tag and then you have another ability that once you execute it 02:16.470 --> 02:20.970 should cancel any other abilities that have a given tag. 02:20.970 --> 02:22.620 So that's pretty useful. 02:22.650 --> 02:29.340 We also have block abilities with Tag and it says abilities with these tags are blocked while this ability 02:29.340 --> 02:33.540 is active so other abilities can have a certain tag. 02:33.540 --> 02:41.140 And while this ability is active, if you try to activate those abilities with the blocked tags, you 02:41.140 --> 02:42.850 won't be able to activate them. 02:43.150 --> 02:49.570 We have activation owned tags and it says tags to apply to activating owner. 02:49.570 --> 02:57.790 While this ability is active, it says these are replicated if replicate activation owned tags is enabled 02:57.790 --> 02:59.440 an ability system globals. 02:59.440 --> 03:05.230 So there's a setting in ability system globals that you can set to replicate these. 03:05.530 --> 03:10.870 So any of the tags in this container will be given to the activating owner. 03:11.550 --> 03:13.830 We have activation required tags. 03:13.830 --> 03:19.800 It says this ability can only be activated if the activating actor slash component has all of these 03:19.800 --> 03:20.530 tags. 03:20.550 --> 03:27.270 Similarly, there are activation blocked tags that says this ability is blocked if the activating actor 03:27.270 --> 03:29.860 slash component has any of these tags. 03:29.880 --> 03:37.110 One example that comes to mind for me is some kind of debuff that can prevent you from activating certain 03:37.110 --> 03:37.970 abilities. 03:37.980 --> 03:42.540 And of course those can be determined by their activation block tags. 03:42.570 --> 03:48.840 We have source required tags and it says this ability can only be activated if the source actor slash 03:48.840 --> 03:51.390 component has all of these tags. 03:51.420 --> 04:00.120 Now source blocked tags are just like activation block tags, except again, instead of the activating 04:00.120 --> 04:02.370 actor, it's the source actor. 04:02.370 --> 04:05.070 And we'll see in time how those can be different. 04:05.220 --> 04:12.430 Target required Tags says this ability can only be activated if the target actor slash component has 04:12.430 --> 04:13.510 all of these tags. 04:13.510 --> 04:20.590 So an ability can have a target and we can require that target to have certain tags if we want this 04:20.590 --> 04:25.000 ability to be activated and we have target block tags. 04:25.000 --> 04:31.960 So if the target has any of these, then the ability can be blocked or prevented from being activated. 04:32.320 --> 04:40.030 So these are pretty self-explanatory and it just provides us with a really easy way to enforce certain 04:40.030 --> 04:44.290 rules pertaining to the activation of a gameplay ability. 04:44.560 --> 04:50.770 Now, under input we have replicate input directly and it says, if true, this ability will always 04:50.770 --> 04:54.760 replicate input press release events to the server. 04:54.910 --> 05:02.050 That means if you press input or say you're receiving input every frame, well that's going to be sent 05:02.050 --> 05:03.030 to the server. 05:03.040 --> 05:05.290 Not really the best idea to use this. 05:05.320 --> 05:09.880 We'll discuss that later when we talk about things that we should not use. 05:10.520 --> 05:17.810 After that, we have advanced with a replication policy and it says how an ability replicates state 05:17.810 --> 05:20.810 slash events to everyone on the network. 05:20.900 --> 05:26.060 It says replication is not required for net execution policy. 05:26.090 --> 05:28.100 We'll talk about this in a minute. 05:28.100 --> 05:33.710 And the instancing policy is how the ability is instanced or maybe not instanced. 05:33.710 --> 05:37.310 And it says that this limits what the ability can do in its implementation. 05:37.310 --> 05:39.620 We'll talk about that as well. 05:39.650 --> 05:41.600 Now we have this setting here. 05:41.600 --> 05:47.660 This Boolean server respects remote ability cancellation, and by default, it's checked. 05:47.690 --> 05:54.710 It says if this is set, the server side version of the ability can be canceled by the client side version. 05:54.710 --> 06:01.070 Basically saying if you cancel this ability on the client, then the server will be informed of it and 06:01.070 --> 06:02.620 the server will cancel it. 06:02.630 --> 06:09.560 It says the client side version can always be canceled by the server as well, but this is sort of allowing 06:09.560 --> 06:12.600 the client to cancel it client side. 06:12.600 --> 06:15.330 So we'll talk about that in a minute as well. 06:15.480 --> 06:22.650 Retrigger instance Ability says if true and trying to activate an already active instance ability, 06:22.680 --> 06:25.090 it says end it and retrigger it. 06:25.110 --> 06:26.940 Pretty self-explanatory. 06:27.180 --> 06:29.190 By default, it's unchecked. 06:29.220 --> 06:31.410 Now we have a net execution policy. 06:31.410 --> 06:34.410 It says, How does an ability execute on the network? 06:34.440 --> 06:37.050 Does a client ask and predict? 06:37.200 --> 06:40.740 Ask and wait or don't ask, Just do it. 06:40.770 --> 06:42.960 We'll talk about this as well. 06:42.960 --> 06:51.480 And then net security policy is related to whether or not a client is allowed to request changes to 06:51.480 --> 06:52.980 the execution of an ability. 06:52.980 --> 06:59.640 And this is set to client or server, meaning there are no security requirements and we're not going 06:59.640 --> 07:01.940 to get too deep into that one. 07:01.950 --> 07:04.920 For most of our abilities, we can leave it as is. 07:04.950 --> 07:07.710 Now, beneath advanced, we have costs. 07:07.890 --> 07:17.310 Gameplay abilities have the concept of a resource requirement or cost that's directly related to your 07:17.310 --> 07:22.020 attributes and costs are implemented in the form of effects. 07:22.020 --> 07:24.780 So we make a cost gameplay effect and set it. 07:24.780 --> 07:31.380 And that cost effect determines what attributes must be used to pay to activate this ability and how 07:31.410 --> 07:39.270 much of that resource is going to be consumed will be implementing costs in most of our abilities throughout 07:39.270 --> 07:40.050 the course. 07:40.670 --> 07:46.960 Ability triggers allow us to execute this ability in response to an event. 07:46.970 --> 07:55.700 So this is an array, and if you add an element to it, you can add a gameplay tag for this ability 07:55.700 --> 08:01.520 to associate with a given event and know that it should activate itself. 08:01.520 --> 08:10.280 If it receives an event that has that tag and a trigger source can be set to gameplay event owned tag 08:10.280 --> 08:12.890 added or owned tag present. 08:12.980 --> 08:18.860 So in other words, this ability can trigger in response to an event or a tag being added. 08:18.860 --> 08:20.870 I'm going to hit that trash can icon. 08:20.870 --> 08:28.550 And then we have cooldowns and just like cost cooldowns are implemented in the form of an effect as 08:28.550 --> 08:29.240 well. 08:29.240 --> 08:34.400 And the effect will determine how long the cooldown period must be. 08:34.430 --> 08:39.350 In other words, how long do you have to wait before you can activate the ability again? 08:39.350 --> 08:46.650 And if you're wondering, well, how long do we wait after the ability was activated or canceled or 08:46.650 --> 08:48.930 ended, when do we start waiting? 08:49.440 --> 08:57.630 And that has to do with committing the ability cooldown, which is something when we decide happens. 08:57.990 --> 09:03.630 So let's talk about a few of these settings in a little bit more detail as we ran through them kind 09:03.630 --> 09:04.530 of quickly. 09:04.920 --> 09:13.020 Let's start with our instancing policy and we'll talk a little bit more later about the replication 09:13.020 --> 09:13.530 policy. 09:13.530 --> 09:17.580 But for now, what is the instancing policy? 09:17.940 --> 09:24.990 Well, we have three options for the instancing policy instanced per actor, instanced per execution 09:24.990 --> 09:27.120 and non instanced. 09:27.240 --> 09:32.100 So gameplay abilities are classes that can be instanced. 09:32.130 --> 09:40.230 And if we choose instanced per actor, then we only instantiate or construct a single instance of this 09:40.230 --> 09:47.850 class when we activate the ability and then this one instance of the ability is reused every time we 09:47.850 --> 09:48.840 activate it. 09:48.840 --> 09:57.720 So abilities have their activation code executed and if it's instanced per actor, then this actor is 09:57.720 --> 10:01.620 persistent, It can store persistent data, it can have variables. 10:01.620 --> 10:08.370 And if you need to reset variables each time you activate the ability, you must do so manually because 10:08.370 --> 10:13.410 the ability is never destroyed, it's reused, it sticks around. 10:13.500 --> 10:22.020 This is a little bit of a performance optimization over the next option, which is instanced per execution 10:22.020 --> 10:24.120 with instance per execution. 10:24.120 --> 10:27.240 We create a new instance with each activation. 10:27.240 --> 10:32.700 So we're getting abilities created and destroyed over and over again. 10:32.700 --> 10:40.680 So it's less performant than instance per actor, and it doesn't store persistent data between activations 10:40.680 --> 10:47.940 because each activation is literally creating a new instance of this class, a new object. 10:47.940 --> 10:51.150 So it's the least performant of the three. 10:51.390 --> 10:53.700 Now we also have non instanced. 10:53.700 --> 10:58.620 In other words, we never actually create an instance of the gameplay ability class. 10:58.650 --> 11:01.560 We're just using the class default object. 11:01.590 --> 11:05.480 No instances are created upon activation. 11:05.490 --> 11:09.120 Now that's going to limit what the ability can do quite a bit. 11:09.150 --> 11:15.900 You can't store state as we're not going to instance an actual object of the ability. 11:15.930 --> 11:20.760 You can't bind to delegates on ability tasks, which is something we'll learn how to do. 11:20.760 --> 11:25.260 So even though it's quite limited, you get the best performance. 11:25.260 --> 11:28.770 We're never actually creating objects of this ability class. 11:28.770 --> 11:30.750 We're just activating it. 11:30.780 --> 11:36.070 Kind of think of this as similar to static function libraries, right? 11:36.090 --> 11:37.560 You gameplay statics. 11:37.590 --> 11:43.290 It's a class that has a bunch of static functions on it, but we never actually instantiate an object 11:43.290 --> 11:44.580 of gameplay statics. 11:44.580 --> 11:46.740 We just call it static functions. 11:46.740 --> 11:50.970 And if it needs anything that exists in the world, we pass that into the functions. 11:51.000 --> 11:57.690 Non instanced gameplay abilities are kind of like that and that they can't really store information, 11:57.690 --> 12:03.360 they can't hold values as we're just activating objects on them. 12:03.360 --> 12:06.480 But of course we get some performance gains with that. 12:07.120 --> 12:09.790 So that covers the instancing policy. 12:09.820 --> 12:17.290 Let's also talk a little bit about net execution policy and what these options give to us. 12:17.440 --> 12:25.570 So we have four options for net execution policy, local only, local predicted server only and server 12:25.570 --> 12:26.680 initiated. 12:26.710 --> 12:28.130 So what do these mean? 12:28.150 --> 12:34.960 Well, with local only when we activate an ability, that activation is only going to run locally on 12:34.960 --> 12:35.620 the client. 12:35.620 --> 12:38.750 The server does not even run the ability. 12:38.770 --> 12:41.490 It doesn't execute any functionality. 12:41.500 --> 12:49.750 So this would be good for something perhaps cosmetic that your local client only needs to see. 12:49.780 --> 12:53.850 Not really anything that has to do with anyone else in the game. 12:53.860 --> 12:58.330 So things that probably aren't going to affect gameplay very much. 12:58.360 --> 13:05.440 Local predicted however, is activated locally on the client and then on the server, so it takes some 13:05.440 --> 13:07.490 time to travel up to the server. 13:07.490 --> 13:10.370 But we're making use of prediction here. 13:10.400 --> 13:17.270 The server is capable of rolling back invalid changes, much like prediction is handled with gameplay 13:17.270 --> 13:17.990 effects. 13:17.990 --> 13:24.980 So this is nice because we can activate an ability and perform things locally on the client without 13:24.980 --> 13:28.010 having to wait for confirmation from the server. 13:28.010 --> 13:32.330 So in high lag situations we won't really feel that lag. 13:32.660 --> 13:37.160 Now server only is, as it sounds, only run on the server. 13:37.160 --> 13:42.530 So this could be something like passive gameplay abilities, something that you want running all the 13:42.530 --> 13:48.080 time that will be constantly doing something or listening for something. 13:48.080 --> 13:52.910 And really those are appropriate to be run only on the server. 13:52.940 --> 13:59.990 Then any important things that the server should only do can be done on the server and then there is 13:59.990 --> 14:01.730 server initiated. 14:01.730 --> 14:06.650 So it runs on the server, but then it replicates down to the owning client. 14:06.650 --> 14:09.460 So not quite as nice as local predicted. 14:09.470 --> 14:17.210 It has to run on the server first and there may not be very many use cases for this, but it's an option. 14:17.210 --> 14:18.500 It's there for us. 14:19.050 --> 14:22.920 So that explains our net execution policy. 14:22.920 --> 14:28.210 And for most of our abilities, local predicted is probably going to be just fine. 14:28.230 --> 14:33.210 So that may beg the question for you why do we have this replication policy? 14:33.330 --> 14:35.460 It's set to do not replicate. 14:35.490 --> 14:36.780 Do we have to turn it on? 14:36.810 --> 14:38.640 Does it have to be set to replicate? 14:38.670 --> 14:39.570 Well, no. 14:39.570 --> 14:44.150 Gameplay abilities are automatically replicated by default. 14:44.160 --> 14:47.410 We don't have to change the replication policy. 14:47.430 --> 14:54.930 There are a few options in here that we either don't need to care about or should not do, and we're 14:54.930 --> 14:56.790 going to talk about those right now. 14:57.390 --> 15:00.000 So let's talk about the things not to use. 15:00.000 --> 15:05.940 And I mentioned that we don't have to do anything to that replication policy. 15:06.150 --> 15:08.400 It's useless, so don't use it. 15:08.430 --> 15:18.120 Refer to a link provided in the resources for this video, which is a discussion shared by Epic Games. 15:18.150 --> 15:25.330 Discuss, ping some questions and answers related to the gameplay ability system and you'll see that 15:25.330 --> 15:28.380 replication policy is not something we have to mess with. 15:28.390 --> 15:30.220 So we're not going to. 15:30.460 --> 15:37.930 Gameplay abilities are already replicated from the server to the owning client and if we're using local 15:37.930 --> 15:40.870 predicted, we can make use of prediction. 15:40.870 --> 15:44.800 We don't have to touch the replication policy for that to work. 15:45.100 --> 15:52.270 Now note gameplay abilities don't run on simulated proxies, so if you need something to happen on the 15:52.270 --> 15:59.260 simulated proxy, you can use gameplay effects and gameplay cues, those support replication and we'll 15:59.260 --> 16:00.370 be using those. 16:00.460 --> 16:05.050 Now we also saw the server respects remote ability cancellation. 16:05.050 --> 16:11.590 We saw that it's checked by default and we discussed how that means that when the local client's ability 16:11.590 --> 16:19.390 ends, the servers will also end, kind of giving the client authority over, canceling the ability. 16:19.750 --> 16:22.630 Now, this is not typically a good idea. 16:22.630 --> 16:25.030 It's the servers version that matters. 16:25.030 --> 16:31.720 If the servers version is canceled, then that's when the client's version should be cancelled as the 16:31.720 --> 16:33.430 server is the authority. 16:33.460 --> 16:38.890 However, the option is there, but I personally never use it. 16:39.350 --> 16:44.450 Now replicate input directly is also an option that's there. 16:44.450 --> 16:49.700 It results in replicating input press and release events up to the server. 16:49.880 --> 16:56.540 Think of this like an RPC that's sent to the server, telling it that you're pressing a button and some 16:56.540 --> 17:00.470 inputs are configured to be processed. 17:00.470 --> 17:06.170 Every frame and RPC sent to the server, every frame are always a bad idea. 17:06.170 --> 17:10.970 But also think about button mashers right spamming buttons and keys. 17:11.000 --> 17:15.280 This can result in a large number of rpcs being sent to the server. 17:15.290 --> 17:18.350 This is a feature that epic discourages. 17:18.350 --> 17:21.920 In fact, they outright discourage it right there in the code. 17:22.010 --> 17:24.290 Look at the ability system component class. 17:24.290 --> 17:31.700 This particular comment says that server set input pressed is direct input state replication. 17:31.700 --> 17:38.690 It says these will be called if be replicate input directly is set to true on the ability and is generally 17:38.690 --> 17:40.830 not a good thing to use. 17:40.860 --> 17:49.110 Instead prefer to use generic replicated events so we can send replicated events under certain circumstances 17:49.110 --> 17:55.310 when we want something to be initiated, client side and done, server side, etcetera. 17:55.320 --> 17:59.340 So right there, right in the comments, it's telling you don't do it. 17:59.340 --> 18:00.690 So we won't. 18:01.020 --> 18:06.930 So we do have a number of things that we don't want to use, but there are lots of things that we do 18:06.930 --> 18:10.440 want to use and we're going to learn about those in the videos to come. 18:11.020 --> 18:15.250 So for those of you who like to take notes, you know who you are. 18:15.280 --> 18:19.990 Add these to your awesome notes and you can refer back to them. 18:19.990 --> 18:23.500 If you forget about some of these rules of thumb in the future. 18:23.710 --> 18:29.470 So for now, we're ready to continue working with our game play abilities. 18:29.500 --> 18:30.550 I'll see you soon.