In an earlier blog, I briefly mentioned mathematical models and how they’re a great tool for game development. Some folks are already familiar with mathematical models in the context of gaming. For those who aren’t, however, I’d like to take a look at the basics in today’s blog.

The goal of using a mathematical model during game development is to assist game balance efforts by creating a formula to help determine the value of similar components. Those components are most often cards, but they can also be miniatures, dice, tech upgrades, treasures, or any other game component that we wish to present as a *viable* option that is not an *overpowered* option relative to other choices. A good mathematical model behind the game can save a lot of time in the playtest process or even lead to a better balanced final product.

As noted in the asymmetrical game balance blog, not every game has components that need to be balanced against one another. Even for the games that *do*, some games are a better fit for mathematical modeling than others.

For our look at a few building blocks of a mathematical model, let’s assume we’re talking about a card game with lots and lots of different cards that fight against one another (a *very* good type of game for which to use a mathematical model). We’ll assume they have some sort of *Attack* stat, *Health* stat, and *Mana* cost. The most basic place to start our mathematical model is with **ADDITIVE **terms in our formula. We could, for example, say that “Attack + Health = Mana.” It’s not a terrible place to start, and it could even lead to some decent game balance. We don’t typically see games use this as-is, because the in-game math surrounding the Mana resource would become unwieldy for players. Unwieldy math behind the scenes is fine, but not in front of the players.

So let’s add a **SCALING **term to our formula. Let’s move to “(Attack + Health) x (Scaling Factor) = Mana.” A scaling factor of 50% is a decent starting point. It’ll reduce the mana our players need to track, but it also introduces some new questions. We’ll have to figure out how to handle rounding, for one. We also need to consider whether the game in question values Attack and Health comparably. We *might* need to go to “(Attack x Attack Scaling) + (Health x Health Scaling) = Mana.” If the game favors min/max-ing your Attack and Health stats on different cards, we could even start squaring, scaling, adding, and then taking a square root, scaling that, and then… hmm… I seem to be getting ahead of myself.

There’s something else to consider in our cost beyond just mana, though. Playing a card costs mana, but it usually also costs a card. Most card combat games allow just a single free card draw per turn, so let’s put an **OFFSET** into the formula to account for the cost of the card. This brings us to “(Attack + Health – Offset) x (Scaling Factor) = Mana.” Now we’re cooking. For those who are familiar with *Hearthstone*, consider “(Attack + Health – 1) x 50% = Mana.” Glance through a few *Hearthstone* cards, and it sure won’t take long to find one that fits this formula.

On the topic of *Hearthstone*, we know there’s more to a card than just Attack, Health, and Mana, but the tools we used in our foundation of mathematical models will continue to serve us well! Cards with a specific minion type (like Beasts or Dragons) have card synergy that increases their value. Well, let’s just add a “Minion Type Scaling Factor” customized for each Minion type (typically in the 105% to 115% range). Cards that belong to each Class could also have an additional scaling factor by Class (typically 85% to 95%). Then we’ve got abilities. Yikes! Some simply add to Attack or Health, which keeps things simple, but others get quite a bit more complicated. Some are direct damage. Some are conditional increases to Attack or Health or are conditional direct damage. We’ll ultimately need a lot more terms in our formula.

We’ll also need to add *quite* a few more tools to our toolbox before we’ve got a comprehensive mathematical model for *Hearthstone* or for our hypothetical card combat game. This gives an idea of how to start the ball rolling and hopefully gives a slightly better idea of what’s going on behind the scenes. By the time I completed my model for *High Command*, I had dozens of individual terms in my formula, and some of those terms had separate mathematical models generating *just one term.*

I hope you enjoyed scratching the surface of mathematical models for game development. The next time you look at the numbers on a card, I hope you can catch a glimpse of the mountain of numbers behind those numbers and appreciate how that card came to be.