Welcome back.
Now that we know how to have attributes backed by other attributes, we've seen the limitations of the
modifiers and the parameters that we can set for those modifiers.
Now they are quite versatile, but if we want an arbitrarily complex calculation, we have to use other
means.
This is where custom calculations come in.
Let's say we have a modifier, and the attribute that we'd like to effect is max health and we'd like
to use override.
Let's say we'd like this to be in our infinite gameplay effect so that our max health is dependent on
other attributes.
Now let's say that we'd like our max health to be equal to some base value, say 80 plus, a multiplier
multiplied by our vigor attribute.
We know how to do this.
That's no problem.
But then let's say that we have some other value, maybe the player's level, and we'd like to add some
multiple of that to the max health.
So that way if the player gains a level and their level goes up, their max health will go up by ten.
Now, if level were an attribute and the attribute set, this would be no problem.
But that's not necessarily how we want to implement the level.
So vigor, that's an attribute in the attribute set.
We know how to use those in our attribute based modifiers, but what do we do with level?
What if that level variable exists somewhere else, like in the player state?
How do we make an attribute that's derived from both vigor and level?
Well, we could use a custom calculation or in other words, a modifier magnitude calculation.
We refer to these as Max.
This is a class that we can create that determines the calculation that should be used for the modifier.
So we wrap up this calculation into an RMC and set that on the modifier and then we can have any type
of calculation that we wish in the RMC itself.
So in this project I'd like to implement things like this.
I'd like my level to not be an attribute, but rather be a variable on the player state class.
Now level could be an attribute.
You could make it one of the attributes in your attribute set, and that would be perfectly fine.
But I feel like the level is not really appropriate to be an attribute, and not just because level
is not necessarily a float, but is probably going to be an integer.
That's not a problem, but it's more because attributes are numerical values that have these complex
interrelationships with other attributes and other phenomena in the gas system, whereas level is more
like a counter for your progress.
Yes, we will have things trigger in response to the level changing.
Of course we will, but not in the same ways that we'll have things trigger in response to attributes
changing.
And for those reasons I'm going to have the level on the player state.
Besides, it's an opportunity to show another way of doing things and we're going to do it this way.
Now our RMC is going to be able to access some information within it, particularly related to the source
and the target of our gameplay effect.
And I'd like my classes to be general and not closely dependent on very specific classes like our player
state or our character class or things like that.
Rather, I'd like it to be dependent on abstractions like interfaces.
So when we add the RMC to our modifier, it's going to be dependent on an interface instead of specifically
the Aura character class or the aura player state.
For example, I'd like a combat interface that can be shared between all classes that participate in
combat, and then our combat interface can have some kind of function to retrieve the player level.
And that way our RMC will not be dependent on specific classes, but rather this abstract generalization,
the combat interface and then anything that implements the combat interface can implement this getter
function for the player level.
And then it doesn't necessarily have to be a variable that exists on the player state, it might be
on the individual character class for enemies, for example, and all they'd need to do is implement
the interface.
So the implementation details are specific to individual cases, but the RMC can just use this generalization
and this is more flexible code and it's considered more along the lines of best practice and.
Clean code.
So that's how we'll do it.
So that means we have a few next steps to worry about first.
We need to add a level variable to our player state.
That's where I'd like to keep this level amount.
And then we need to create an interface.
I'm going to call it combat interface so it can be shared among all classes that participate in combat.
In our game project.
In this combat interface, we'll have a function to retrieve the level associated with whatever implements
this interface.
And then we can create our Max.
I'd like to make an MK for both Max Health and Max Mana.
That way they can be dependent not only on their backing attributes, but on other variables such as
the level.
So we're going to make these max health and max mana attributes dependent on level and their original
backing attributes for max health.
That's vigor.
And for Max Mana, that's intelligence.
So in the videos to come, we're going to implement these steps before we go on to make our attribute
menu.
Great job.
I'll see you soon.