Floating Point Combat Systems

Recently I discussed Integer based combat systems that you can read about here.

In that article I touched on floating point combat systems in order to accent the unique characteristics of integer based systems. I began that article by stating that floating point systems are often the norm for games and there’s a good reason for that. Floating point systems are easy to design content for and don’t require as much iteration on the specific values of the game’s systems. There are a lot of features and design patterns that are much easier to use with float based systems than in integer based systems and I’ll be discussing the main ones throughout this article.

Floating Point Based Systems

For the purposes of this article a floating point system is any system that tracks health or damage with decimal places, but also includes integer based systems that start the player with triple digit health since they are effectively using decimal division by using large numbers. There are a lot of benefits to the floating point systems like having more freedom when tuning damage values, negative/positive effects, and you can often use percentages without needing to worry about whether the percentage rounds up or down.

Damage values immediately have a lot more range due to being able to divide values in whatever way the designer wants. Starting with 100.0 health gives you a lot of options immediately. You can do 2.5 damage per second for 20 seconds which increases tension for whatever situation the player is in. Applying this same logic to an integer base system has issues immediately. First of all the minimum percent you can do to a player with 10 health is 10%. So that would translate to 1 damage per 4 seconds for 20 seconds. This immediately has less tension as it seems predictable and manageable for the player because they can easily tell the rhythm of the damage as well as the amount of damage they’re taking. This player with 10 health is far more worried about the resulting health amount they have left than they are with moment to moment health loss. The player in the floating point system is never sure the exact amount they take per tick of damage and the longer duration means their judgement on this will determine how they react. Do they hide? Do they attack aggressively to minimize exposure to enemies? It’s much more tense and much harder to figure out the “right” way to react to each situation.

Percentages are a useful tool for designers and using them makes it easier for players to understand a floating point system without removing the complexity that it offers. As discussed in the previous article in this series, players often make estimates based on perceived percentages. This is great when planning your system’s values this way because it makes it easy to make the player feel the pressure you want them to without directly exposing the numeric value they’re taking, which is almost unavoidable in an integer based system. This also means that changes and balancing don’t often have massive impacts on other systems. If playtesting shows consistent friction in a certain area, then you can simply reduce the damage by percentage until the right pacing is achieved. A good rule of thumb for these situations is to just reduce or add 50% to the problem value and find the best value through testing those two extremes.

Each of these things are huge benefits to floating point systems for creating fun systems and content for the game that can be tweaked easily and with a lot of granularity. However, there are a few drawbacks with these benefits. The player won’t be able to really understand the systems of the game. The player must estimate incremental changes to damage and health over time rather than predicting what is the best ahead of time and being able to act with confidence.

Scaling Systems

Scaling systems in this case don’t mean all systems with progression. I’m specifically referring to any system that significantly increases values to make early gameplay elements like enemies or equipment irrelevant in the later part of the game.

One common characteristic of floating point systems is this system scaling, meaning the values of the game all rise in lockstep over time. This means the player’s values increase, the enemies values increase, and the values of the resources the player can use also increase making older elements of the games from enemies to equipment more and more irrelevant. This gives the player a tangible feeling of progression and they can easily tell when they’re up against enemies they’ve surpassed. This can be a ton of fun for players and in a lot of cases can inspire players to keep coming back to feel that progress, but the drawback of this is creating a need for a lot of new content, new systems, and complexity as older content becomes increasingly irrelevant and boring for players.

Floating point systems tend to fall into this design pattern naturally and it becomes a huge part of games that take advantage of it. Besides this kind of progression system needing a lot more content and balancing work, it also puts a great deal of stress on the elements of the game that were not fully fleshed out and supported. This bottlenecks players into the specific optimal play patterns that are easy to spot and use and quickly makes more niche and potentially interesting play patterns irrelevant quickly. When there is a linear progression happening to the player, any imbalances become necessary to exploit or make systems get left behind both for developers and players.

This is an issue that is less likely to happen in flat scaling that is more common with integer based combat systems because each change in equipment or value is comparatively much larger than is possible in a scaling, float based combat system. The issue of balancing suboptimal systems remains, but it is a much easier to manage problem when there are fewer, more significant upgrades to balance rather than a smooth transition of progress with respect to time.

Game Examples

It’s difficult to discuss scaling systems without one of the most publicized game to implement a scaling combat system, The Elder Scrolls IV: Oblivion. The reason this game is so noteworthy is in the implementation. The skills of the game that controlled player aptitude would increase based on the actions the player took in game. The increasing of these skills contributes to leveling up which gives the player an opportunity to increase their base stats for moderate bonuses. The problem with this system is that all of the math in the game scales relative to the player’s level value, not to the stats they choose or their stat values. This means that if the player levels up speechcraft or acrobatics early and puts all of their level up stats into movement and social based attributes then the game would fill the world with enemies that would be far stronger in nearly every way compared to the player. This results in a game that can easily leave the player behind to the point that combat is punished if the player tries to engage and can even become impossible if the player isn’t optimizing their player constantly.

The game also added a key feature to this, the difficulty slider. This allowed the player at any time to adjust the difficulty of the game by seemingly scaling the damage of all enemies directly. This means that rather than the systems of the game keeping the game balanced for the player, it is the player that needs to dynamically balance their experience and attempt to make it as fun as they want it to be. As mentioned, the use of percentile scaling is a benefit of floating point systems, but this game and how it disincentivizes experienced players from ever leveling up is a great example of the pitfalls associated with systems like these because they can be scaled so easily.

Dead Cells is a recent 2D roguelike that has the player starting from the beginning each time they start a run of the game. This means all the player’s stat values are reset and the player must venture forth and explore to find ways to level up their stats until they die and need to restart. This game makes aggressive use of all benefits of the floating point combat systems. Plenty of mechanics occur over time, have percentile changes, or have challenges that can be overcome by how you increase your stats. This progression and “out-leveling” of opponents is paired with a progression system that is removed from specific playthroughs of the player but instead unlocks better bonuses and more options for future runs.

Many games with these kinds of combat systems leverage the player’s desire of progress as a way of preparing them for the strategy available when they have all the tools of the game at their disposal. Dead Cells is a great example of a floating point combat system that keeps all of the positives but avoids many of the pitfalls that progression and player perception can bring. Using the structure of your game to increase accessibility rather than decrease it should be the goal of all gameplay systems regardless of the mathematical conceits that go into its development.

Guiding Rules

I’ve put together a series of rules that boil down the issues and virtues I’ve mentioned into easy to apply axioms. Each one of these is possible to ignore for your game, but it is always a good idea to examine them and be sure you’re making your choices for your systems rather than the system dictating how you need to react to it.

The Rule of Obsolescence means that you should plan to have the player constantly progressing. The rate that you chose to have this happen at is integral to how much a player engages with your game if they are specifically there for this element. This means that you need to prepare as many tiers of content as you have categories of difficulty, areas, enemies, or whatever metric you measure your player’s obstacles in your game. There are games that expect the player to outgrow their current equipment frequently like World of Warcraft and those that only have a few very distinct jumps in equipment and difficulty like with The Outer Worlds.

The Rule of Degenerate Play refers to players often taking the path of least resistance. These issues are amplified in games that encourage community whether by being a multiplayer game or by having hard to understand systems. A simple rule of thumb is that the more complex and difficult your systems are the more you are encouraging players to subvert that complexity and difficulty. By virtue of your game scaling with play, it means players may find the most efficient enemy to kill 1000 times over the course of a week to make the part of the game they’re stuck on easier for them. This is obviously not what we want, but it is a natural and almost inevitable part of complex systems meant to challenge players.

The Rule of Focus dictates that the player splitting focus is often punished. If a player is constantly switching what elements of the system they progress with it can lead to a bad play experience if there are no points in the game’s pacing that let them course correct. A great example of this comes with the Dark Souls series where they increase the amount of souls (the currency of the game) that you collect significantly at points in the game. This allows players to easily solve some of their shortcomings they’ve noticed because the other elements of the games (items prices, weapon and armor upgrades, and leveling up) have not had their costs increased proportional to these large spikes in currency for the player. Addressing this rule as a core part of your system can actually encourage players to try new things and learn what they most enjoy, which gives the player more agency and satisfaction with their choices.

The Rule of Milestones is the phenomenon that players can’t notice incremental growth particularly well. People in general tend to need milestones in order to really feel progress or achievements even if they’ve been slowly progressing the entire time. This applies to all elements of your game that scale. If a weapon goes from 100 damage to 120 damage then they aren’t likely to notice this as well as if a weapon does from 100 to 150 because they understand that ratio change is far more significant. This means it’s best to balance your game around these incremental changes.

Another consequence of this to be aware of is that small amounts of damage, healing, slows, or any other minor effects are often ignored by the player. This can be leveraged as a part of difficulty that rewards observant players, but it can also be considered frustrating to players if it isn’t properly messaged or expected by the player. Another way to tackle these hard to track value changes in your system is to instead refer to them as “types” rather than values. If you have an armor progression that goes from 3 to 5 to 10 then it isn’t likely the player will understand how those numbers affect their success, but types like light, medium and heavy armor very clearly message these mechanical differences. For something like health it can also be useful to segment health bars into chunks so players can more easily track damage, progress, and the difficulty of a given area.

Summary

The complexity of floating point systems is a double edged sword that can be much easier to make content for, balance, and layer systems on top of, but it also can lose many players in that complexity. This puts the focus on the gameplay and the player skill and much less on the systems themselves which is great for players looking for that experience but can be alienating to many others that aren’t as naturally talented or experienced in games like yours.

Overall