Introduction
This is a complementary post to my two previous posts that described the implementation of a Stat System for the Unity game engine:
In those posts I described how I made a generalized stat system with modifiers and provided the github repo, but I didn’t explain the differences between Stats and Resources in video games. Although this system can be used for stats, it is not ideal to use it for resources. In general, it is more difficult to create a generic system for resources, as its implementation will have to be specific to each game’s needs.
Both stats and resources are represented in our code by numbers, but serve different needs. In an RPG game for example, which are games that make heavy use of both stats and resources, the strength of a character is a stat, but its health is a resource. Below I will give a small explanation of stats, as I believe are easier to implement and the reader can also check my implementation in those posts. Then I will give a more detailed description of resources and why making a generalized system for resources would be more difficult, as it is very dependent on each game’s mechanics and even if someone tried to make a system that is generalized enough, each particular game would actually need a very small percentage of its functionality.
Stats
Stats in video games, are data that most of the time is represented by numbers and is used by the game engine to perform checks of things the entity is trying to accomplish.
Stats can be things like strength, speed, jumping height, stealth etc. The character that has these stats, can try doing things in the game world and the game engine will use those to describe if his actions succeeded or failed. The result has not to be binary. For example the strength stat can describe how much weight a character can carry. The character will always be able to carry some items, but the amount of weight a character can carry will depend on his current strength.
The same is true for speed. The character will always be able to move, but how fast will depend on the current value of the speed stat.
The stats can be represented by using two numbers. The base value of the stat and its modified value. Each stat can have modifications that affected it positively or negatively. The stat will always need to have a knowledge of its base value, as every time the modifiers change, the modified or current value will have to be calculated from start.
Because the stats can be represented by two numbers and a method that describes the relationship between those two, a generalized system for stats is easier to make. Resources, though are completely different.
Resources
Resources in video games, are data that can also be represented by numbers, but in contrast with stats, the character has a finite amount. The character uses a resource, until that resource has reached a minimum value. When the resource has reached that minimum value the character cannot use it anymore or something happens. The same is true for the maximum value of the resource. The game has mechanics of how a resource can be gained, until it reaches a maximum value. When the maximum value has been reached the character cannot gain more of this resource, until some of it is spent. Something may also happen when the character reaches the maximum value of the resource.
Resources, are things like health and mana. The character uses health every time he receives some damage, and when his health reaches a minimum amount something happens (he usually dies). Resources are being spent each time something happens and the amount that is lost depends on how hard or important was whatever happened. The health resource for example can represent a maximum number of hits the character can withstand. Depending on the severity of the hit (which is represented usually with a damage stat) the character can die after 10 hits with a dagger, or 5 hits with a longsword etc.
Resources need programmatically three numbers to be implemented. The minimum number, which represents that a resource is depleted, the maximum number and the current number of the available resource the character has. The current number, usually, but not always will be between the maximum and the minimum numbers.
Depending on the game, these three numbers can also have modified values. This can have a resource to be represented by data, that can be anywhere between three and six values. The relationships between those values, is what makes a generalized system very hard to implement. Each game will have different needs, not only on the amount of data that represents each resource, but also on the behaviors that exist describing the relationships between the values of that data. Let’s see some examples, using the health resource as an example.
Only three values for a resource
At its simplest form, a resource will be represented by only three values. The minimum, the maximum and the current value. The relationships that exist between those values are that the minimum value will always be less than the maximum value and the current value, will always be between the minimum and maximum values.
This system, will not have a mechanic for any modifiers on any of those three values. There are mechanics on how health is lost and gained. There will also be mechanics for behaviors of when the current value reaches the minimum or the maximum amount. Usually the minimum amount for a resource will be zero, but this doesn’t always have to be the case. For example, in the old AD&D days, the health value could reach to -10. The moment the character had taken damage that would lower its current health value below zero but above minus ten, the character was considered unconscious and bleeding. Any kind of healing would raise the current health value to exactly zero and the character was considered unconscious but stabilized. If there wasn’t any healing, the character would have his current health lowered by one each round, until it had reached -10. Then the character was considered dead. In this system, the minimum amount of the health resource was -10, with a check that would change the character’s behavior on any value between -10 and 0.
Four values for a resource, a modified current value
A resource can also be represented with four values. The minimum and maximum values as before, the current value and the modified value of the current value. Like this, the current value will be between the minimum and maximum values, but the modified current value, can be between those two or not, depending on the game.
For example, a character with minimum and maximum values 0 and 100 that represent its health, will always have its current value, between those two. What is the range of the modified value, is a game design decision. The modified value, can also be limited between the maximum and the minimum values, but can also be made to be able to get at a greater value than the maximum. For example if the character has a current health value of 90 and receives a modifier from a blessing spell that adds 20 to its current health, the game mechanics could allow for this modified value to be 110 which is above the maximum value.
What happens in those cases, is also a game design decision. The modified current value can stay at that number until it is used somehow, or it can start to get depleted in time, until it reaches the maximum value.
Any use of modifiers to the current value, has to be designed very carefully as this can be the source of many bugs. A modifier can usually be removed, but resources are not like stats. Resources are being spent in the game and any removal of the modifier can make the current value suddenly drop below the minimum or raise above the maximum.
Four values for a resource, a modified maximum value
Another way to implement a resource, is to have the maximum value to have a modified value. In those cases, the current value is still clamped between two values, but this time it is between the minimum value and the modified maximum value. This system might seem easier to implement from the previous, because it has fewer edge cases, but there are also some game design decisions, that have to be made when the maximum value is modified.
The behavior of this system when the maximum value is modified, on how the current value is affected can be also a source of bugs. Consider a character with minimum and maximum value of 0 and 100 in health. Let’s suppose that the current health value is 50. If the maximum value is modified with a +20% additive modifier then it will have a modified value of 120. How we change the current value, is a game design decision. We can also have a +20% modifier on the current value so that it will become 60, or we may add a flat amount that is equal to the amount the maximum health increased, in this case 120-100 = 20, so that the current value will be now 70.
There is also the problem, of our system’s behavior when the modifier is removed. For example, if we decide that the removal of the modifier in the maximum value affects also the current value, then in this example, if the current value has dropped to 10, and we have decided that we add/remove a flat amount, with the removal of the modifier from the maximum value the character will die. If we decide that the current value is unaffected by the modifiers in the maximum value, then if the current value has been raised from 50 to 110 after the modifier is applied, we need a mechanism that will clamp it to 100 when the modifier is removed, or even decide that it can be above the maximum value in those cases, until it drops below that value.
A combination of different cases
The previous three examples, are not the only cases, a decision has to be made that involves any combination of constant and modified values and mechanics for the interactions of those values, especially in edge cases. What happens when the current/modified current value is below the minimum/modified minimum or above the maximum/modified maximum, how the current value is affected when the minimum or the maximum are modified and what happens when a modifier is removed from the minimum/maximum values to the current value(or even worse to the modified current value) are game design questions that have to be implemented for each game specifically. For this reason a generalized system for handling resources, would be much more complicated in its implementation than the stat system and even if a system that is generic enough to be able to cover all those cases was made, only a small percentage of its functionality would be used by each game.
Using the Stat System for Resources
The stat system from the previous posts, is made for stats, not resources. If someone wants to use it for a resource, for example to represent health as a stat, then he could have the minimum/maximum/current health implemented as a stat, but the implementation of the relationships between those values and their modified values will be up to him and specific to the game that he is making.
How the edge cases are handled, what happens when the current health/modified current health gets below/above the minimum/maximum and modified minimum/maximum values, how the modifiers applied to one of those, affect the current value and how any removal of any modifiers affects the current value can range from very simple to a complete headache.
If we add to that, the complexity of the modifiers that are calculated based on the modified value, not the base value (the multiplicative percentage modifiers in the system) and how this modification of the minimum/maximum value will affect the current health, the chance of bugs increases exponentially.
Conclusion
The simplest solution, if someone wants to use the stat system with resources, is to have only the maximum value as a stat and any modification to that value should not affect in any way the current value. After that, he only needs to take care to have the current value between the minimum and modified maximum values at all times, that means checking if the current value is within range, not only when it is being used or replenished but also whenever a modifier is added or removed from the maximum value.
Someone could also implement a resource, by having the same modifiers that are applied to the maximum value also apply to the current value. In this case both the maximum and current values are implemented as stats but at all times have the same modifiers applied. This is a case that using only percentage modifiers is preferable because the removal of any flat modifiers from the maximum value that have also been applied to the modified current value, can decrease the modified value suddenly below the minimum, if the character has spent between the application and the removal of the flat modifiers a big enough amount of that resource.
Thank you for reading, and as always, if you have any questions or comments you can use the comments section, or contact me directly via the contact form or by email. Also if you don’t want to miss any of the new blog posts, you can always subscribe to my newsletter or the RSS feed.