Maths is the fundamental language of games: Strip away the audio, the visuals and the story and you’re left with only numbers. This is true of every game, big or small.

Maths is the fundamental language of games: Strip away the audio, the visuals and the story and you’re left with only numbers. This is true of every game, big or small. The numerical exchanges in Yahtzee or poker may be well surfaced, but the maths at play in a game like Fortnite is far less obvious.

Yet Fornite’s designers consider thousands of different values: how many players should be in a match? How big should the map be? How quickly should the storm move in? How frequently should each weapon rarity drop? How do we set clip size, reload time and rate of fire for each weapon? How much damage should a bullet cause? How many life points should a player have?

Mathematics are the wheels and cogs that make any game work: behind the scenes, numbers are changing every second. In fact, it’s helpful to think of your game as a machine in which players exchange resources in pursuit of a win. For example, Hearthstone has you exchange mana and cards to reduce your opponent’s life, whereas in Half-Life you exchange ammo to down enemies in order preserve your own HP.

It’s our job as game designers to make exchanging resources evoke an emotion in our players. Taking a knight with a pawn in Chess is exciting, but being low on ammo and health in Resident Evil evokes anxiety. Fortunately, we have a wealth of research to help us: from Gestalt psychology’s definition of the pattern-seeking mind to the behavioural economics study of emotional decision making.

If you are the ideal game designer then you’ll have a PhD in mathematics (as well as psychology), but for all practical purposes all you need are curiosity and an understanding of where to start. This in-depth article will give you those jumping off points by explaining some essential concepts to add to your designer’s toolbox. Initially it will cover Curves and Probability, before we move on to look at Economics and Match Making.

Throughout, our focus will be on the nuts and bolts of balance rather than academic complexity. As such, this article is far from a complete reference on the meeting of maths and game design, but if you learn and practise the tools in both parts, I guarantee that you’ll become a more insightful and confident game designer. So, let’s get started!

Curves

*What?** Curves are the various shaped lines that represent the relationship between**two values when plotted on a graph. For example, the speed of a car accelerating**from a stop over time is represented by a logarithmic curve.**Why? **In any game studio you’ll see whiteboards covered in curves. That’s**because curves are a quick and clear way to describe the relationship**between values that can be easily understood and applied.*

Curves are the slang term game designers use to describe a line two values make when plotted on a graph. You can also think about curves as mathematical functions: algebraic formulas that relate two (or more) varying quantities.

That description might seem a bit bewildering, but let’s look at the simplest possible curve (which really isn’t curved at all): linear. When saying two values have a linear relationship it means that one increases proportionally to the other creating a straight line when plotted (see below).

We can also think of a linear curve as a mathematical function:

Where *m* is the the steepness of the graph and *c* is where the curve will intercept the *y* axis.

If we said to a programmer “levels grow linearly with XP”, she already knows that each level requires the same amount of XP plus how to create the relationship in code. This makes talking in curves a super helpful way to get your ideas across.

However, linear curves generally suck: they rarely appear in nature, they’re predictable and games that use them can feel grindy. So let’s instead look at two much more exciting and useful curves: Exponential and Logarithmic.

The Exponential Curve

You’ll find exponential relationships everywhere in nature: from the acceleration of a falling object to the population increase of plants and animals. An exponential curve is characterised by a constantly increasing rate of growth.

The mathematical function for an exponential curve is:

Where *b *is the base and defines how quickly the curve grows.

Exponential relationships are as frequent in games as they are in nature because they feel kick-ass rewarding: a player’s expectation is constantly exceeded by this feeling of rapid acceleration. Have you ever lost hours to an incremental game? If so, you’ve been suckered in by this little curve making you feel like your resources are growing quicker and quicker over time. That’s hard to step away from.

However, there are clear downsides to the use of exponentials. Uncapped exponential costs or gains in games are hard to comprehend, as numbers get so big they lose all sense of relativity. Designers often combat this by resetting players (prestige mechanics) or switching to a more reasonable linear progression at some point.

The Logarithmic Curve

Like exponential relationships, logarithms appear frequently in nature. For example, logarithmic spirals are found in the shell of the deep sea dweller the nautilus. This isn’t surprising, as a logarithmic curve can be considered the inverse of an exponential one.

The mathematical function for a logarithmic curve is:

Where *b* is the base and acts much in the same way as the base of the exponential curve.

Logarithmic relationships appear in games where there is a rapid growth followed by diminishing returns. One example is slow car catchup in a racing game: your speed boost has a logarithmic relationship to your distance from first place. In other words, as you’re far away from the race leader you have a speed advantage that moves you up the ranks. But as you close in to first your advantage rapidly diminishes. This kind of relationship results in much more exciting races where first place is always in contention – if you’ve ever played Mario Kart, you’ll likely recall how addictive this can be.

The strength logarithmic relationships have over exponential ones is also the relationship’s weakness: the diminishing returns of a logarithmic progression can be discouraging. Something that was once highly rewarding is now less so. For example, as you overtake other cars, your slow car advantage drops.

Very often we see logarithmic relationships in between XP and player level in RPGs: the first few levels are quick to gain but progressively they become more grindy. Assuming a flat XP gain then a logarithmic XP vs level relationship is the inverse of a level vs XP required, which is in fact exponential. Below is an example:

**Player LevelXP Required**14253647596117148189241033*Table 1: Player Level vs XP Required*

**Player XPPlayer Level**1041526374951161471882493310*Table 2: Player XP vs Player Level*

Often when we see an exponential or a logarithmic relationship in a game, we can expect their inverse to be found in some other relationship: When XP required per level is exponential then we know our level growth will be logarithmic.

Other Curves

*Other Uses of Curves**Curves can be used for more than just planning progression or explaining concepts in design.**They’re also used to interpret player behaviour. Looking at analytics software, you’ll have access**to hundreds of graphs about how players have been using your game. Recognising the shapes**of the curves will allow you to quickly understand the underlying relationships they represent.**This will give you a powerful mental model of how your game is played and whether it correlates**with your intentions when designing it.*

Exponential and logarithmic aren’t the only curves you’ll find in games. You can also expect to see:

**Step**: This curve has repeated jumps in values which gives the appearance of a set of steps when plotted.**Sawtooth**: A repeating pattern of linear increases followed by instant decreases that looks like teeth on a saw blade.**Square**: A repeating pattern represents a tick tock between two values that creates the look of an archers’ parapet.**Parabola**: A symmetrical curve that can be thought of as a large dip. When rotated 180^{o}the curve represents the path of a thrown projectile (or a jumping platform sprite).**Bell**: Often found representing distributions of values, a bell curve looks like side view of a bell or rise and drop of a roller coaster track.**Sinusoidal**: Sine curves appear frequently in nature from the tops of pond ripples to sound waves. A sine looks like a perfect wiggly line and can be used to “ease in” and “ease out” between two values repeatedly.**Sigmoid**: Sigmoid looks like an exponential curve moving into a logarithmic one, creating an S shape.

You may find when designing that you want to use different parts of curves to get your desired result. You can do this with a piecewise function that lets you define different functions for specific intervals. A piecewise function would allow you, for example, to build a curve that starts exponential but becomes linear before values get too high.

You can also set about modifying functions to achieve different curve varieties. For example, you can modify a sine function with modulus (*y = |sinx|*), so that *y* is an absolute value (i.e. always positive), thus creating a curve that looks like the path of a ping pong ball skipping over a table.

Additionally, you can experiment with the product or sum of different functions to see what results you get. The sum of a linear function and a sine function (*y = x + 2sinx*) might be a good model for difficulty progression.

Be it how XP relates to levels or how your character should jump, curves are everywhere inside your games. So thinking in curves lets you build up a powerful mental model that not only will help you design and balance, but also give you what you need to communicate your ideas.

# Probability

**What Is It**? Probability is the mathematical definition of how likely something is to happen. For example, how often a dice will land on a six.

**Why Is It Important?** Most games are non-deterministic, meaning that there are random events that impact the course of play. These random events add excitement, but if they happen too frequently (or too infrequently) they will ruin a player’s experience.

Games are full of random elements, from weapon drops to dice rolls. But just because they’re random doesn’t mean that we can’t or shouldn’t quantify them. In fact, good game balance relies not just on the chance of an event but the value of it and all of its permutations. Very rare but highly valuable events can put a game out of whack as quickly as an event that’s too common.

Let’s start by looking at the simplest example of a probability: a coin flip. On a given flip, what is the probability (or chance) a coin will land head up? As there are two outcomes (heads and tails) which are both as likely, we can say the chance is 50%, or 0.5 or 1/2. All of which say the same thing: we expect heads to land on half of all coin tosses and so tails to land on the other half.

What now if someone makes you a wager: you toss a £1 coin, and if it comes up heads they keep your coin, if it comes up tails they give you another £1 coin. Is that a fair bet? In half the tosses we expect to lose a pound and in the other half we gain a pound. The below table shows how we can calculate an average winning by multiplying the chance with the benefit to give us a contribution (the value we can expect from that outcome). When summed, our contributions give us our average expected winnings.

**OutcomeChanceWinningsAverage Winnings Contribution**Heads0.5-£1-£0.50Tails0.5£1£0.5Average Winnings 0*Table 3: Winnings table for coin toss wagering.*

We can see that this bet is fair because nobody comes out ahead on average. However, this doesn’t mean that every toss we make will result in £0 winnings, but over many tosses we’d expect to see *regression to the mean*. Regression to the mean is the phenomena where the more often the same random event happens the more likely that the outcome will match the average.

We can plot the same coin toss wager as a *probability tree* over three tosses:

A probability tree maps the *probability space* — that’s to say all potential outcomes of a series of linked random events. Over our three coin tosses, we can see there are eight outcomes and each is as likely as the other to occur, so we can say any given outcome has a 1/8 (or 0.125 or 12.5% chance) of occurring. Another way we can calculate the ultimate outcomes’ chances is with the product of each event’s probability:

Or:

We can see that for the three tosses we never reach our calculated average outcome of £0, because there’s no way to give and take £1 three times to reach £0. Instead, we see a range of outcomes with winnings from -£3 to £3, but not all winnings are as likely happen.

We can link all of the coin toss outcomes by their winnings into *events*. Events are sets of outcomes that have their own probability — in our example, we can say that -£3 is an event comprised of one outcome and so 1/8 (0.125) probability, whereas the £1 event has two outcomes and a probability of 2/8 (0.25).

As our coin toss probability space grows with more tosses the number of winnings events increases, but the extreme outcomes become less and less probable. For example, it’s possible for us to flip the coin twenty times, land only heads and end up with -£20 but it is highly unlikely. We can calculate the probability of a -£20 run as:

Let’s now look at a common game scenario: You would like to give players 500 gold every day. You could simple add 500 gold to their balance, but wouldn’t it be more exciting if they opened a chest that had a random amount inside? Let’s look at how you might balance that using a *loot table*:

**RewardChanceGoldAverage Gold Contribution**Common0.710070Uncommon0.215030Rare0.0752,000150Epic0.02510,000250Average gold per day 500*Table 4: A loot table calculating average gold winnings based on a random reward*

A loot table is a list of rewards from which only one is chosen based on a “roll” (a random number generated in code) which is checked against the probability. Our above loot table makes use of the same average winnings contribution from our coin toss example which can be summed to give us an average gold reward per day.

This process is the basis of balancing most random events in games. All we need is the chance and the outcome of each event to create an average outcome. From this, we can balance our values such that events happen frequently enough (and no more) and are rewarding enough (and no more) to be exciting without breaking anything. We can easily scale up the method to build loot tables with thousands of items or balance complex combat procs (programmed random occurrences) for multiple classes.

However, as your game gets bigger and lots of random events have an impact on multiple systems, then you’ll become less certain about a player’s path. In this case, there’s another tool we can use: *Monte Carlo simulations*. Monte Carlo simulations can be made in a spreadsheet using scripting or with modified game code; either way, the basic premise is always the same: simulate the game being played, including random events, multiple times and analyse the outcomes by looking at averages and ranges.

Monte Carlo simulations, although a lot of work to make, are super helpful when your game gets complex and playthroughs take a lot of time. Running some kind of script that simulates a playthrough lets you quickly modify values and see their impact within minutes. These simulations can also let you catch edge cases, like a player getting a super rare drop early and racing through the game.

Keep in mind when working with chance in your games that humans are not naturally good at thinking in probability, so don’t worry if you struggled to follow some of this section on your first read. This probability irrationality leads to all kinds of interesting behaviours, such as superstition and belief in luck, but most importantly, the right rewards and probability ratios can lead to very strong compulsions to play. This makes mastery probability a super powerful game design tool.

*Try this:** For our gold reward example (see Table 4) we could say that the outcome is rather “spikey”. Spikey random events are ones where the outcomes have high variance and so create a value graph with lots of spikes.**Build a spreadsheet and rebalance the loot table so that the reward variance is reduced from 100x (100 gold to 10,000 gold) to 10x keeping the average gold per day the same.**Which loot table do you think players would prefer and why?*

# A Recap – What We’ve Learned so Far

Up to this point we’ve added two very useful tools to our game design belt: Curves and Probability. Within the Curves section we looked at how mathematical formulas can give a relationship to two values that when plotted on a graph give specific shapes; While during the Probability section we looked at how chance and outcome can allow us to think about average outcomes which are helpful for balancing.

These two topics make up a large portion of the low level design you will encounter in your career making games. Below, meanwhile, we’re going to expand your toolkit with two more concepts: Economics and Match Making. Economics will equip you with some ways to think about the flow and interaction of currencies and items in your games, while matchmaking will give easy ways to bring the right players together.

# Economics

**What Is It?** Economics is a large field of study covering how and why the production,

consumption and transfer of items occur. For example, the UK’s economy is defined

by the complex flow of money between corporations, households and the government.**Why Is It Important?** As games become more complex with currencies being created,

used and transferred they are effectively becoming their own economies.

Understanding a few economic theories help you to understand and curate game resources better.

Over the last decade economic theories have be increasingly applied to the complex value exchanges within games, becoming an invaluable tool for designers. Back in 2012 Valve, seeing the value of economic theory, hired Yanis Varoufakis as Economist-in-Residence. Varoufakis later went on to become Greece’s finance minister, attempting to save the country from bankruptcy.

Economics is the use of maths to understand the production, exchange and consumption of a good, and is as effective a tool for Greece’s national debt as Team Fortress 2’s hats. So let’s start by looking at the simplest expression of economics in games: The creation and destruction of in-game resources.

## Taps, Sinks and Pinch

A game’s economy is the flow of resources between its systems and players. When talking game economies there are two helpful concepts: *Taps* and *sinks*. A tap is point of creation of a resource: In League of Legends, for example, the player receives gold at a rate dependent on the map and any items they are carrying, making the map and items gold taps. Meanwhile a sink is a place where the resource is destroyed: League of Legends players spends their gold in the shop, so the shop the game’s singular gold sink.

The analogy of tap and sink is an interesting one because it allows us to build a mental picture of a resources flow; If the tap is generating the resource quicker than the sink can remove it then an excess builds. Any resource that is in excess becomes effectively worthless to the player and they stop interacting with the tap. If you’ve ever used an infinite health hack in a game you’ll know boring a game becomes once health is abundant.

However, the inverse can also be true: When there is too little resource coming from a tap then there is little motivation for a player to interactive with it. The correct balance between a tap and a sink is known as a *pinch point*.

In economics a pinch point is the level of supply of a commodity at which demand is maximised due to consumers becoming concerned about the supply. In games we can think about this as the point where the supply shows the utility of a resource but is scarce enough to have players continue to seek it.

*Try this**: Find the sinks and taps in a game you like and build a spreadsheet**to model them. At what rate do each of the sinks and taps work at?**Is the pinch point effective? How could it be improved?*

A great example of this is any game with a rocket launcher: Rocket launchers are nearly always the most destructive, powerful and fun weapons to use, but in finding the pinch point on ammo designers show the utility of rockets while stopping short of satiating your appetite for destruction. This ammo pinching keeps players motivated to play as they seek those allusive rockets.

However, it’s possible that a pinch point in a game isn’t static. Instead it may move as all the taps and sinks grow in size.

## Inflation

In economics inflation is described as the increase in cost of goods and services, often driven by an increase in resources, such as cash, within the system. Inflation in games can occur throughout a playthrough, via the introduction of new content or as a result of emerging economic efficiencies coupled with player-to-player trading (such as gold farming).

There are some big benefits to intentional inflation within a game: As players progress they feel rewarded by increased taps. Incremental games make great use of intentional inflation by building sinks that increase the taps exponentially (see part 1 for more details), constantly rewarding the player.

But incremental game makers also increase the sinks so as to balance the expanding flow of resources: This stepping of increased taps and sinks manages to have the player feel their demand is being met while the goalposts shift proportionally, ultimately creating a moving pinch point.

Let’s look at a hypothetical gold mining incremental game where the player buys and equips items that increases the rate at which they can mine gold (see table 1 below).

**ItemGold Generation (Gold Per Second)Buy CostEffort (Seconds Mining to Upgrade to Item)**Hands2––Spoon3200100Pickaxe5300100Shovel10500100Jackhammer301,000100Digger1503,000100T*able 5: The cost and gold generation rate of equipment*

By inflating taps and sinks proportionally you’re able to effectively manage inflation to require the same level of effort, which in our example is 100 seconds of play. However, you can also modify the rates of tap and sink growth to create a different effort growth. In table 2 the tap and sink grow non-linearly creating an increasing rate of effort, which is more common.

**ItemGold Generation (Gold Per Second)Buy CostEffort (Seconds Mining to Upgrade to Item)**Hands2––Spoon3200100Pickaxe5400133Shovel101,000200Jackhammer302,800280Digger1509,200307*Table 6: An exponential effort growth*

Yet it’s rare that any game has one resource, one sink and one tap: The majority of games feature multiple resources that can be converted between each other, creating complex economies that are interesting for players to manage and challenging for designers to build. How then can we begin to design such an economy?

## Anchor Values & Conversion

*The exchange of gems to time in Clash of Clans is based on a piecewise function (see part 1),**where longer timers are per second cheaper than shorter equivalents. See Wolfgang**Graebner’s Gamasutra article Clash of Clans Time Monetization Formulas Demystified**for a great explanation.*

An *anchor value* is some resource from which you can build other resources through one or more conversions.

For example, in *Clash of Clans* players starts with mines and pumps that generate gold and elixir second by second, so the initial exchange is realworld time for resources. This gold and elixir is exchanged for construction or troop training which also requires time. Therefor gold, elixir, troops and buildings in *Clash of Clans *are the product of time. Elixir, gold, buildings and troops are the foundation of the entire game’s economy and so time is *Clash of Clans’* anchor value.

But what does an anchor value allow us to do? Anchors are the yardstick of balancing and with them we can model, build and refine a game’s economy. For Supercell’s designers working on *Clash of Clans*’ they were able to plan how quickly players would get through content and, as in-app purchasable gems allow timer skips, know how much money they could expect from top end players. In other words, anchors are the base on which we build our economies.

If as a designer you get your anchor values wrong the impact can be devastating, resulting in under or overpowered mechanic. In effect, any mechanic that is overpowered (or OP) is one in which the exchange is far more effective than comparative offers. OP mechanics can shrink the diversity of strategy making good games repetitive and dull, but are come as a natural part of find the fuzzy edges of exchanges.

*Try this**: Find a game you like with an historical OP mechanic. What exchange of value is making**this mechanic OP? How would you fix it? If you can’t find something, then check out some speed**running to see how players exploit mechanics.*

While good game designers plan out their anchor values and comparative exchange rates, great game designers build exchanges subtly complex enough that the best exchange is so subjective it keeps players enthralled for many years, just as *Clash of Clans* has. So avoid linear exchanges and think about how values can vary with time, turns or other mechanics to make systems that create deep and varied strategies. Even if you occasionally build something OP.

# Matchmaking

**What Is It?** Matchmaking is the process of finding any given player a fair opponent,

where fair means all players have an as close as possible chance of winning a match.

Some algorithm, often with one or more tracking variables, are used to place

various opponents together in to a match.**Why Is It Important**? Playing a game where you frequently lose to better players

really sucks. So finding good matches between players is essential to good

balance in PvP.

In 1975 psychologist Mihaly Csikszentmihalyi described a pleasurable mental state, reached when a given task is not too difficult and not too easy, known as flow. Everyone who plays games know this feeling and every designer knows how hard it is to achieve this goldilocks balance. Therefor, getting players matched to other players who offer the right challenge is essential.

But how do we achieve fair matchmaking? It’s an old question in game design, but luckily there are two main answers:

**Tournament**: A set of various matching algorithms, from simple to complex, for self-contained events.**Historic Results**: Players are matched to other players based on their historic performance.

Each of these approaches have their advantages and drawbacks, as well as several different possible implementations within them. Let’s look at what those are.

## Tournament

Tournaments are the oldest and easiest matchmaking system going. They’re great for self-contained events, especially if you want to find a winner. The simplest tournament structure is a *round robin* event where everyone plays everyone else at least once. Some form of points based on the outcomes will create a final standing. League soccer works this way, but with the addition of various leagues that teams can be promoted and relegated to.

The major drawback of the round robin is that it dictates the number of matches to be played. Alternatively the *Swiss-system*, used in many trading card tournaments and some sports, matches players based on their current tournament score while avoiding repeat matches.

Players are randomly paired for their first match, then are paired in the second and beyond based on their previous results. So winners of the first round will be paired in the second round, and so on. While rather elegant, the Swiss-system doesn’t handle draws particularly well, resulting in players being paired up or down. Additionally it can be difficult for players to follow and due to the short number of rounds can effectively work as a *knockout tournament*.

Knockout tournaments have players randomly assigned in pairs with only the winner progressing to the next round. The final winner is placed first, while the loser is assigned second place and those who were eliminated in the semi-finals are matched to decide third place.

This structure is super simple to understand and the brutal elimination leads to an everything-on-the-line level of tension. However, as initial pairing is random the best two players may meet in the first round while other less skillful players get an easy path to the final. Additionally, being eliminated puts players out on the sidelines, bored and dejected.

However, the major problem for tournaments is that they are based on a tiny snapshot of time, not factoring historic information of the player, such as the player’s historic skill.

## Historic Results

Probably the most popular way of matchmaking in modern games is the *Elo rating system*. Elo is a simple piece of maths originally intended to rank chess players with a rating value which could be used to predict the outcomes of match.

The beauty of the system is that at the end of the match the winning player takes a number of rating points from the loser based on the rating delta of each. So a lower rated player beating a higher rated one will gain more rating points than if the higher player wins. Ultimately this creates a self correcting system where only the best players rise to the top.

Today variations on of the system are used across lots of competitive sports and games including *Counter Strike: Global Offensive* and *Team Fortress 2*. However, while simple, the maths behind Elo isn’t widely understood.

## How Elo Works

Let’s use a worked example of two players, A and B who are matched, to explore Elo. In Elo players must start with a number of rating points, which could be any number including zero. Here we’ll use 1,000. So player A, who is new, has 1,000 points but player B is ranked higher with 1,100. We can calculate each player’s chance of winning with the following formulas:

Where *E* is the probability of winning and *R* is the player’s rating points. From this we can calculate player A’s chances of winning.

0.36 is the expected result, which is to say she’ll win 36 of 100 matches against player B. Another way to think of this is 36% chance of winning. The two play and player A is victorious, so gains some of player B’s points according to the following formula:

R

Where *K* is the K-factor and sets the maximum possible adjustment per game and *S* is the score (-1 for a loss, 1 for a win and 0.5 for a draw). Let’s set a K-factor of 32.

Meanwhile, player B loses the same number of points leaving them at a rating of 1,080. The players then go on their way to play some more games via a matching algorithm, of which there are two common approaches:

**Pool**: Players are placed in a pool while an algorithm seeks the lowest rating delta (difference between highest and lowest value) in matches. This is best for group games.**Live**: Once a player readies up, the game seeks all other ready players and if there is one within a specified rating rage (for example ±10%) then a match is made. Else they wait until another player matches them. This is best for one versus one games.

Alongside player Elo ratings these algorithms give you a complete skill-based matchmaking system. However, before you rush off to implement one it’s worth understanding the problems of the Elo system.

## The Problems of Elo

Elo has some well documented issue:

**Confusing Maths**: Although the maths is relatively simple, having your average player pull out a calculator and work the equations is unlikely. This can lead to mistrust.**Ranking Down**: When Elo rankings are uncovered to players, in leaderboards for example, a loss feel doubly punishing as the player ranks down, creating a disincentive for play. In extreme cases a top player’s best defence of position is to not play.**First Rankings**: All starting players are considered of equal skill when in reality there will be huge disparities. To overcome this issue some games force new players into a series of sorting matches that use a high K-factor for rapid adjustment.**Group Games**: Although a team ranking point average can be created to allow for group matchmaking, when it comes to adding and removing ranking points the Elo system has no specific way of doing so other than evenly. So players who don’t pull their weight are rewarded in the same way as those who do.

All of these problems lead designers to modify Elo in various ways: Some add tournament-like structures, others factor non-skill values such as troop count, while many seek to fix the math flaws with further calculations. You will need to look at the pros and cons of different matchmaking approaches and frankenstein your own to fit your needs.

*Try this**: What different matchmaking approaches can you find in games you play?**How do they work? If matchmaking is undocumented, attempt to reverse engineer**the system with some informed assumptions.*

The importance of a good matchmaking system can’t be overstated; The difference is players flipping from frustration to boredom and players finding the perfect challenge in every match to keep them coming back to your game. While you will never get matchmaking perfect, you can get very close and that’s a challenge well worth pursuing!

# Recap

Across these two parts we have investigated some huge mathematical concepts from curves and probability in the last issue through economics and matchmaking in this issue. Having read both parts you are now equipped with tools that will allow you to better understand a game’s inner workings.

The more games you design and apply these concepts the more your mathematical toolbox will grow: There’s much more depth to each of the subjects we’ve discussed and even more to the thousands we didn’t. For example, we didn’t touch on the broad areas of behavioural economics or game theory. Nor did we discuss the best use of spreadsheets or how to go about creating algorithms to generate enemy character behavior.

*Try this**: Put together your skills from these two articles by designing a**board game that features the following: The random chance of a dice,**an exponential curve, three resources that can each be exchanged**through some mechanic and a way of matchmaking players. Then**play it, observe the problems and iterate the design! Keep going until**you’re happy.*

If you want to learn more about these topics then your local library will have many books. But if, like me, you’re more of a visual learner then YouTube is another great resource. You can also talk with other game designer and analysts about their approaches. Or if your in school why not ask your maths teacher if one of assignments can be on game design?

Wherever you get your knowledge from, keep growing it. I’ve been designing games for over a decade and in the process of writing these two parts I’ve realised both how much I know and how much there still is to learn.

So I hope you’ve enjoyed read as much as I’ve enjoyed writing. If use any of these techniques in your game, make sure your get in contact and let me know at ** will@departmentofplay.net**. I’d love to see your work!

*This piece first published in **Wireframe magazine** as a two-parter.*