WEBVTT 00:06.930 --> 00:07.990 Welcome. 00:08.010 --> 00:12.180 We've now come to the part of the course where we talk about gameplay abilities. 00:12.210 --> 00:15.320 Now these are at the heart of the gameplay ability system. 00:15.330 --> 00:20.550 Gameplay abilities are actions or skills that an actor can perform in the game. 00:20.550 --> 00:27.690 It's a class derived from you gameplay ability and it defines what an ability does and the conditions 00:27.690 --> 00:29.400 under which it can be used. 00:29.550 --> 00:36.330 So rather than implementing an action with a simple function, a gas gameplay ability is an instance 00:36.360 --> 00:38.970 object running asynchronously. 00:39.150 --> 00:45.810 This means that it can be activated at some point in time and run multi-stage tasks that may or may 00:45.810 --> 00:48.240 not span across periods of time. 00:48.480 --> 00:55.260 These can potentially branch off into different tasks, apply their own gameplay effects, and once 00:55.260 --> 00:59.790 we learn about gameplay queues, we'll see that they can kick off those as well. 00:59.910 --> 01:01.620 And these can be conditional. 01:01.620 --> 01:08.230 They may be based on player or environmental interaction, gameplay abilities have built in replication 01:08.230 --> 01:11.080 and prediction support, much like gameplay effects. 01:11.110 --> 01:18.160 Gameplay abilities also have the built in concept of cost and cooldown where attribute resources must 01:18.160 --> 01:22.420 be present in a sufficient amount to pay for an ability activation. 01:22.420 --> 01:28.540 In this course, we'll implement this cost mechanic using mana as the resource, but it could literally 01:28.540 --> 01:35.290 be anything and cooldown periods prevent an ability from being activated again until the cooldown period 01:35.290 --> 01:36.340 is over. 01:37.240 --> 01:44.110 Gameplay abilities use ability tasks although they don't have to ability tasks are derived from the 01:44.110 --> 01:51.610 class you ability task which is a more specialized form of the more general gameplay task class. 01:52.210 --> 01:57.040 These perform asynchronous work during a gameplay abilities execution. 01:57.070 --> 02:01.150 They can affect execution flow by broadcasting delegates. 02:01.180 --> 02:07.300 These tasks can be used in C plus plus, but they can also appear in blueprint in the form of a specialized 02:07.300 --> 02:11.920 blueprint node that can have multiple output execution pins. 02:12.040 --> 02:18.760 These are executed as a result of delegate broadcasts made in response to occurrences determined by 02:18.760 --> 02:19.720 the developer. 02:19.870 --> 02:22.230 Basically, something happens in the game. 02:22.240 --> 02:26.260 Your ability task will broadcast a delegate and in blueprint. 02:26.290 --> 02:32.980 This means that that particular output execution pin on the task node will be executed. 02:33.190 --> 02:39.610 This allows us to easily map out an abilities control flow in blueprint and we can still enjoy the benefit 02:39.640 --> 02:46.090 of optimal performance of C plus plus as the work being done by the task is often done on the C plus 02:46.090 --> 02:48.490 plus side, although it doesn't have to be. 02:48.700 --> 02:54.410 But because we can make these ability tasks and make them do the bulk of their work in C plus plus, 02:54.440 --> 03:01.040 we gain the flexibility of being able to design the mechanics of a gameplay ability in the abilities 03:01.040 --> 03:08.120 blueprint and allow designers who don't have access to the C plus plus domain to have more control over 03:08.120 --> 03:11.090 the ability without sacrificing on performance. 03:11.270 --> 03:16.760 To use a gameplay ability, the ability system component must be granted the ability. 03:16.820 --> 03:23.780 When this happens, a gameplay ability spec is created and the spec defines the details pertaining to 03:23.810 --> 03:29.840 that particular ability, including the gameplay ability, class itself, the abilities level and any 03:29.840 --> 03:32.930 dynamic information that can be changed at runtime. 03:33.110 --> 03:39.050 Abilities are typically granted on the server, but when this happens the ability spec replicates down 03:39.050 --> 03:43.610 to the owning client so they can activate it from their gameplay abilities. 03:43.610 --> 03:45.870 Have the concept of activation. 03:45.890 --> 03:52.700 Once activated abilities are said to be active until they are either ended or canceled. 03:52.850 --> 03:57.500 Abilities can end themselves as well as be canceled externally. 03:57.770 --> 04:05.690 So in summary, gameplay abilities are classes that define a given skill or spell or any type of ability 04:05.690 --> 04:08.150 that can be performed by an actor. 04:08.480 --> 04:15.020 Abilities must be granted to an ability system component to be used, and we do this on the server, 04:15.020 --> 04:20.780 at which point an ability spec is granted and replicated down to the owning client. 04:21.270 --> 04:24.090 To use an ability, it must be activated. 04:24.150 --> 04:28.350 It's then considered to be active until it's ended or cancelled. 04:28.380 --> 04:32.130 Abilities have the built in concepts of cost and cooldown. 04:32.610 --> 04:38.890 Abilities can be run asynchronously and multiple abilities can be active at one time. 04:38.910 --> 04:46.140 An abilities can run ability tasks which are asynchronous actions that encapsulate behaviors into individual 04:46.140 --> 04:50.670 classes, each of which can perform their own particular job. 04:51.280 --> 04:53.640 So abilities are quite useful. 04:53.650 --> 05:00.880 And now that we're able to start using them, we'll be able to give our character some really cool capabilities 05:00.880 --> 05:03.400 and make this game a lot more interesting. 05:03.400 --> 05:07.180 And we'll start making our first ability in the videos to come. 05:07.330 --> 05:08.560 I'll see you soon.