WEBVTT 00:06.850 --> 00:07.930 Welcome back. 00:07.960 --> 00:14.860 Now that we know how to have attributes backed by other attributes, we've seen the limitations of the 00:14.860 --> 00:19.150 modifiers and the parameters that we can set for those modifiers. 00:19.180 --> 00:25.840 Now they are quite versatile, but if we want an arbitrarily complex calculation, we have to use other 00:25.840 --> 00:26.680 means. 00:26.800 --> 00:29.530 This is where custom calculations come in. 00:29.770 --> 00:36.400 Let's say we have a modifier, and the attribute that we'd like to effect is max health and we'd like 00:36.400 --> 00:37.510 to use override. 00:37.510 --> 00:43.840 Let's say we'd like this to be in our infinite gameplay effect so that our max health is dependent on 00:43.840 --> 00:45.160 other attributes. 00:45.640 --> 00:54.130 Now let's say that we'd like our max health to be equal to some base value, say 80 plus, a multiplier 00:54.130 --> 00:56.470 multiplied by our vigor attribute. 00:56.500 --> 00:57.760 We know how to do this. 00:57.760 --> 00:59.260 That's no problem. 00:59.380 --> 01:05.740 But then let's say that we have some other value, maybe the player's level, and we'd like to add some 01:05.740 --> 01:08.780 multiple of that to the max health. 01:08.780 --> 01:15.770 So that way if the player gains a level and their level goes up, their max health will go up by ten. 01:15.800 --> 01:21.140 Now, if level were an attribute and the attribute set, this would be no problem. 01:21.140 --> 01:25.670 But that's not necessarily how we want to implement the level. 01:25.910 --> 01:29.930 So vigor, that's an attribute in the attribute set. 01:29.960 --> 01:36.050 We know how to use those in our attribute based modifiers, but what do we do with level? 01:36.050 --> 01:40.730 What if that level variable exists somewhere else, like in the player state? 01:40.760 --> 01:46.160 How do we make an attribute that's derived from both vigor and level? 01:46.400 --> 01:53.840 Well, we could use a custom calculation or in other words, a modifier magnitude calculation. 01:53.840 --> 01:56.540 We refer to these as Max. 01:56.570 --> 02:04.700 This is a class that we can create that determines the calculation that should be used for the modifier. 02:04.790 --> 02:12.440 So we wrap up this calculation into an RMC and set that on the modifier and then we can have any type 02:12.440 --> 02:16.420 of calculation that we wish in the RMC itself. 02:16.430 --> 02:20.240 So in this project I'd like to implement things like this. 02:20.420 --> 02:27.260 I'd like my level to not be an attribute, but rather be a variable on the player state class. 02:27.290 --> 02:29.300 Now level could be an attribute. 02:29.300 --> 02:34.340 You could make it one of the attributes in your attribute set, and that would be perfectly fine. 02:34.340 --> 02:41.000 But I feel like the level is not really appropriate to be an attribute, and not just because level 02:41.000 --> 02:45.740 is not necessarily a float, but is probably going to be an integer. 02:45.770 --> 02:53.900 That's not a problem, but it's more because attributes are numerical values that have these complex 02:53.900 --> 03:00.590 interrelationships with other attributes and other phenomena in the gas system, whereas level is more 03:00.590 --> 03:02.720 like a counter for your progress. 03:02.750 --> 03:07.460 Yes, we will have things trigger in response to the level changing. 03:07.490 --> 03:13.040 Of course we will, but not in the same ways that we'll have things trigger in response to attributes 03:13.040 --> 03:13.670 changing. 03:13.670 --> 03:18.050 And for those reasons I'm going to have the level on the player state. 03:18.050 --> 03:23.660 Besides, it's an opportunity to show another way of doing things and we're going to do it this way. 03:23.660 --> 03:32.720 Now our RMC is going to be able to access some information within it, particularly related to the source 03:32.720 --> 03:35.330 and the target of our gameplay effect. 03:35.330 --> 03:44.390 And I'd like my classes to be general and not closely dependent on very specific classes like our player 03:44.390 --> 03:47.810 state or our character class or things like that. 03:47.930 --> 03:53.450 Rather, I'd like it to be dependent on abstractions like interfaces. 03:53.450 --> 04:03.110 So when we add the RMC to our modifier, it's going to be dependent on an interface instead of specifically 04:03.110 --> 04:07.310 the Aura character class or the aura player state. 04:07.310 --> 04:14.270 For example, I'd like a combat interface that can be shared between all classes that participate in 04:14.270 --> 04:20.690 combat, and then our combat interface can have some kind of function to retrieve the player level. 04:20.690 --> 04:28.820 And that way our RMC will not be dependent on specific classes, but rather this abstract generalization, 04:28.850 --> 04:35.270 the combat interface and then anything that implements the combat interface can implement this getter 04:35.270 --> 04:37.130 function for the player level. 04:37.130 --> 04:43.460 And then it doesn't necessarily have to be a variable that exists on the player state, it might be 04:43.460 --> 04:49.670 on the individual character class for enemies, for example, and all they'd need to do is implement 04:49.670 --> 04:50.540 the interface. 04:50.540 --> 04:59.810 So the implementation details are specific to individual cases, but the RMC can just use this generalization 04:59.810 --> 05:06.320 and this is more flexible code and it's considered more along the lines of best practice and. 05:06.440 --> 05:07.470 Clean code. 05:07.490 --> 05:09.260 So that's how we'll do it. 05:09.470 --> 05:14.840 So that means we have a few next steps to worry about first. 05:14.870 --> 05:18.140 We need to add a level variable to our player state. 05:18.140 --> 05:21.440 That's where I'd like to keep this level amount. 05:21.860 --> 05:24.170 And then we need to create an interface. 05:24.170 --> 05:30.380 I'm going to call it combat interface so it can be shared among all classes that participate in combat. 05:30.380 --> 05:31.870 In our game project. 05:31.880 --> 05:38.210 In this combat interface, we'll have a function to retrieve the level associated with whatever implements 05:38.210 --> 05:39.230 this interface. 05:39.560 --> 05:42.020 And then we can create our Max. 05:42.050 --> 05:45.800 I'd like to make an MK for both Max Health and Max Mana. 05:45.830 --> 05:51.500 That way they can be dependent not only on their backing attributes, but on other variables such as 05:51.500 --> 05:52.190 the level. 05:52.190 --> 05:59.360 So we're going to make these max health and max mana attributes dependent on level and their original 05:59.360 --> 06:01.040 backing attributes for max health. 06:01.040 --> 06:01.850 That's vigor. 06:01.850 --> 06:04.650 And for Max Mana, that's intelligence. 06:04.670 --> 06:11.520 So in the videos to come, we're going to implement these steps before we go on to make our attribute 06:11.520 --> 06:12.330 menu. 06:12.360 --> 06:13.330 Great job. 06:13.350 --> 06:14.550 I'll see you soon.