WEBVTT 00:07.110 --> 00:08.330 Welcome back. 00:08.340 --> 00:14.610 So now that we have some sort of idea what the gameplay ability system is, we need to know the different 00:14.610 --> 00:16.890 parts that make up the system. 00:16.890 --> 00:24.180 So we'll discuss those in this video and lay out a plan for the next steps moving forward that we can 00:24.180 --> 00:26.910 take to start adding gas to our project. 00:27.210 --> 00:32.790 Now, one of the most important parts of gas is the ability system component. 00:33.150 --> 00:41.070 This is a type of component that can be added to an actor and it handles lots of important things in 00:41.070 --> 00:48.630 the gameplay ability system, such as granting abilities, activating those abilities, handling notifications 00:48.630 --> 00:54.630 for when certain abilities are activated or effects are applied, and lots of other things that we'll 00:54.630 --> 00:55.260 learn about. 00:55.260 --> 01:01.200 So the ability system component is something that we must add to our character. 01:01.200 --> 01:04.440 If we'd like that character to participate in gas. 01:04.530 --> 01:13.000 Now, just as important as the ability system component is, the attribute set just about any game involves 01:13.000 --> 01:21.250 a number of attributes that you associate with any given object or character, and these range from 01:21.250 --> 01:27.070 life and mana to just about any other attribute that you can think of in gas. 01:27.070 --> 01:33.880 We store these attributes on the attribute set, which has a number of capabilities that allow us to 01:33.880 --> 01:38.170 associate those attributes with other various parts of the gas system. 01:38.170 --> 01:42.550 Now at the core of the gameplay ability system are the abilities. 01:42.580 --> 01:51.100 Gameplay abilities are classes that we use to encapsulate the functionality of some sort of thing that 01:51.100 --> 01:54.070 a character or object can do in the game. 01:54.190 --> 02:00.490 Things like attacks and casting spells are generally abilities, and the gameplay ability allows us 02:00.490 --> 02:06.940 to keep all the code and functionality kept inside of a specific gameplay ability class. 02:06.970 --> 02:13.240 Now gameplay abilities run asynchronous tasks that we call ability tasks. 02:13.510 --> 02:21.670 These allow us to execute code that is asynchronous, meaning that once we start the task it may perform 02:21.670 --> 02:29.380 its job and finish immediately or its job may span across a period of time and may do different things 02:29.380 --> 02:34.150 depending on what's going on in the game for that specific ability. 02:34.150 --> 02:41.230 So ability tasks are like the workers that perform the work for the gameplay ability itself. 02:41.230 --> 02:44.170 Now we also have gameplay effects. 02:44.200 --> 02:50.530 These are what we use to change the values of attributes and they're capable of a number of different 02:50.530 --> 02:52.420 things related to attributes. 02:52.420 --> 02:59.530 We use gameplay effects to change attributes directly, change them over time, periodically increase 02:59.530 --> 03:06.910 or decrease them, and associate those attribute changes with various calculations that take other parameters 03:06.910 --> 03:08.910 and attributes into account. 03:08.910 --> 03:11.070 We also have gameplay cues. 03:11.100 --> 03:18.120 These are responsible for handling cosmetic effects such as particle systems and sounds and can handle 03:18.120 --> 03:20.220 the replication of those as well. 03:20.400 --> 03:25.470 Now another core part of the ability system are gameplay tags. 03:25.620 --> 03:30.330 Now gameplay tags are not actually unique to the gas system. 03:30.330 --> 03:36.750 They exist outside of gas and can be used in non gameplay ability system projects, but their use is 03:36.750 --> 03:44.880 pervasive all throughout gas and gameplay tags are extremely useful for identifying just about anything 03:44.880 --> 03:52.620 you can think of and their hierarchical nature makes them more versatile than simple variables such 03:52.620 --> 03:55.410 as enums, booleans or strings. 03:55.410 --> 04:00.330 And we'll learn all about their usefulness throughout the course as we use them. 04:01.190 --> 04:03.350 So these are the main parts of gas. 04:03.350 --> 04:07.340 And we need to start with the first two of these. 04:07.340 --> 04:14.450 In order to incorporate gas into our project, we need an ability system component and an attribute 04:14.450 --> 04:15.080 set. 04:15.500 --> 04:19.970 Now the way that we add an ability system component can vary. 04:20.300 --> 04:27.530 We can have a pawn and in the case of our project, our player controlled pawn is an aura character 04:27.560 --> 04:32.810 and you can add the ability system component directly on the pawn class. 04:32.810 --> 04:36.200 You can do the same thing with the attribute set if you like. 04:36.230 --> 04:43.130 Now another option is to take some other class associated with your pawn, such as the player state 04:43.130 --> 04:48.270 and add the ability system component and the attribute set to that class. 04:48.290 --> 04:54.290 Now, there are various reasons to do it one way or another, and the truth is you have some flexibility 04:54.290 --> 04:54.890 here. 04:54.980 --> 05:01.830 But let's discuss a couple of reasons to put the ability system component and attribute set on the pawn 05:01.860 --> 05:03.510 versus the player state. 05:03.510 --> 05:09.660 Specifically, let's say that we've added our ability, system component and attribute set to the pawn 05:09.660 --> 05:10.500 class. 05:10.590 --> 05:18.540 And let's say this is a multiplayer game, at which point our pawn dies and we decide to destroy that 05:18.540 --> 05:21.390 pawn so that we can respawn another one. 05:21.660 --> 05:27.120 Well, because the ability system component and the attribute set exist on that pawn. 05:27.120 --> 05:32.970 When the pawn is destroyed, so are the ability, system component and attribute set. 05:33.000 --> 05:34.440 They go away. 05:34.440 --> 05:41.190 And if you haven't taken measures to save any pertinent data on those classes, say in a save game object 05:41.190 --> 05:45.060 or on a database somewhere, that data is gone. 05:45.060 --> 05:51.900 And when you respawn a new pawn, the ability system component and the attribute set are created fresh, 05:51.900 --> 05:56.460 starting off at their default values and with the default abilities. 05:56.820 --> 06:04.290 Now, let's say instead we have the ability system component and the attribute set on the player state 06:04.290 --> 06:06.870 which is associated with our pawn. 06:06.900 --> 06:13.890 Now if our pawn dies and we destroy it, the ability system component and the attribute set don't get 06:13.890 --> 06:16.980 destroyed with it because they don't exist on that class. 06:16.980 --> 06:25.200 They exist on the player state which persists when you destroy the pawn so we can spawn a new pawn and 06:25.200 --> 06:27.300 associate it with our player state. 06:27.330 --> 06:34.590 And then we still have the same values in our attribute set and the same abilities in our ability system 06:34.590 --> 06:37.380 component because they haven't been destroyed. 06:37.410 --> 06:43.800 Now, this is one reason to set things up this way, but another reason is you just might not want your 06:43.800 --> 06:48.230 ability, system, component and attribute set cluttering up the character. 06:48.240 --> 06:54.030 You may wish to swap out your character for another character and you may not want your ability, system, 06:54.030 --> 06:59.130 component and attribute set to be unique to any given character. 06:59.130 --> 07:03.170 You may want to keep that associated with the player itself. 07:03.170 --> 07:08.930 Now reasons to keep these things on the pawn may be that the pawn might be simple. 07:08.960 --> 07:15.320 Your game might have simple enemies that do have the ability system component and attribute set, but 07:15.320 --> 07:20.330 there's no need for a player state for those enemies because they're simple. 07:20.360 --> 07:26.000 They just have to have attributes and abilities and perform their logic based on AI. 07:26.030 --> 07:32.210 So an ability, system component and attribute set directly on the pawn might be appropriate for that 07:32.210 --> 07:33.230 scenario. 07:33.920 --> 07:35.380 In this game project. 07:35.390 --> 07:37.460 That's the approach we're going to take. 07:37.490 --> 07:45.140 Our enemy characters are going to have their ability, system components and their attribute sets directly 07:45.140 --> 07:47.140 on the character class. 07:47.150 --> 07:52.550 But for our player controlled character, we're going to put our ability system component and attribute 07:52.550 --> 07:54.620 set on the player state. 07:54.650 --> 08:00.740 This gives us the opportunity to see both ways of doing things and the things that you have to take 08:00.740 --> 08:04.070 into account, doing it one way versus the other. 08:04.490 --> 08:11.300 So we need these three classes and these will be associated with our player controller and our character, 08:11.300 --> 08:13.190 which we've already created. 08:13.310 --> 08:19.910 What we have not created yet are the player state, the ability system component and the attribute set. 08:20.090 --> 08:26.060 So we have a number of steps to take to get started adding gas to our project. 08:26.090 --> 08:28.940 First we need a player state class. 08:29.620 --> 08:34.300 And we need to create an ability system component class that we can add to the player state. 08:34.300 --> 08:37.390 And of course we also need the attribute set. 08:37.420 --> 08:43.210 These are the fundamental classes that we're going to need to create to start implementing gas in our 08:43.210 --> 08:46.540 project, and we'll start making those next.