The math of it all

Different mechanics have different mathematical properties. For example: Rolling two six-sided dice to get a number from two to 12 yields a different distribution of results than rolling a 12-sided die and re-rolling results of one. You probably already know this, but that's just the tip of an iceberg of hidden math in game design.

Consider a tile-based maze game where the object is to get from the start to the finish (I know that your game is different, but I'm trying to make the example at least a little relevant). You're trying to figure out how long the game will take to play. You know that a player's average movement result is 5 spaces, and that roughly every other turn will result in an encounter at a random point in the player's movement. You also know that about 33% of encounters will end the player's movement prematurely. You want to know what the player's actual average movement per turn will be so you can figure out how far the exit should be from the starting point. Once you have that distance, you can design your tiles to ensure that they permit average travel distances that conform to what you need.

You can either design and re-design prototypes and play test them until you hit upon the right answer, or you can do some math beforehand and help yourself out. Before reading further, take a moment and guess how far a player's actual average movement will be.

Okay. Let's do the math: Half the time, you move five spaces. The other half the time, you have an encounter. Let's figure out how far you move on a turn with an encounter. Two-thirds of the time, you do just fine and get to move your full five spaces. One-third of the time, you stop at a random point in your movement. That means that you'll stop in the middle of your movement (on average), and that's three spaces. Averaging two fives and one three together gives 4.33. That's how far you move on an encounter turn. Now average a normal turn and an encounter turn. Averaging five and 4.33 gives 4.66. This means that a player moves an average of 4.66 spaces per turn, or 14 spaces every three turns. If you want a play to take an average of 10 turns, you'll want the exit to be about 46 spaces from the start. We learned something else, too: It looks like the encounters don't really slow players down as much as we might have expected them to.

Sounds complex? Perhaps, but imagine doing all of that with no math. Imagine figuring that out with physical prototyping and trial and error. That's a lot of work. Math can be very helpful and save you a lot of effort. The effort you save is effort you can use to make your game better or make other games.

(I acknowledge that there's a lot of implied math in the example, like a random encounter during movement averaging out to be the middle of your movement, but this wasn't intended to be a math lesson. My goal is to point out that many games have a lot of math hidden in them, so knowing how to model that math can save you a lot of labor.)

I agree that in the end, there is no substitute for playtesting, however math can be a good first sweep (the way grade point average or standardized tests are often a first sweep). If you have some way of approximately quantifying everything, it gives you a good starting point (from which you can figure out if the supposed “extraneous” factors really can be ignored). Although, as I said, it’s more and less useful, depending upon your game. Wargames seem especially prone to requiring math; games like Settlers of Catan, maybe not so much.

Along with plain mathematics, computer simulations can also be a good tactic.

(The next two paragraphs are a bit technical, but are another tactic I use to save time, if you’re interested)

My favorite computer simulation is something called a genetic algorithm (or though I’ll admit, what I use isn’t usually a true genetic algorithm). For those who don’t know what that it, basically it is a computer simulation based on the principals of natural selection. You come up with a problem, and fine some way to quantify the answer to the problem. You then come up with a large number of randomly generated solutions. You assign each solution a “fitness,” which is basically a way to measure how good the solution is. You then take only a certain proportion of the solutions (only the best ones), and delete the rest. From the remaining solutions, you keep a few exact duplicates, and you “mutate” some of them randomly (or, under some algorithms, you “breed” the solutions, and create a new set of solutions that are hybrids of the previous set), in order to keep up some amount of variation. You then repeat the process for the new generation of solutions. Do this 1000 times, and you often have a pretty good answer.

For a more concrete example, I’m working on a wargame right now. Each player, when developing a character, can choose from a number of different stat increases, and I wanted to develop them in such a way that all were roughly equivalent (so there is no single best thing to choose). So, I came up with a test set of possible advancements each character could have (such as +1 Attack, or +3 Dodge and +2 Armor, or...). At the beginning, each of 1000 or so characters were randomly assigned an advancement. Each generation, each character would fight against another random character within the population. The winner of the battle would contribute 2 “offspring” to the next generation, and the loser would be killed and contribute nothing. Occasionally some characters would be randomly switched to a different advancement (maybe 2% of the time). Characters would fight for 1000 generations (or something like that, I can’t honestly remember the numbers), and at the end of it, I looked at what the distribution of different advancements were. If, for example, +3 Dodge and +2 Armor was unfairly powerful, often it would represent 70-90% of the population (and thus, I would need to tone it down for the next simulation). If it was too weak, it might only represent 1-3% of the final population, in which case I would need to tone it up in the future. I knew I was finished when no advancement ever had more than ~20% of the total population at the end of a simulation (although, afterwards I ran a slightly simpler test to make sure this was reasonably accurate).

That said, when it came down to playtesting, I discovered that +3 Aim/+2 Dodge was more powerful than my computer said it would be, because my simulation had only considered melee combat. In the playtest, archers were using Aim it as well, and often badly injuring characters before they even got to melee. Similarly, I have yet to figure out how spells that ignore Armor will have an impact on that stat’s power (though so far, it hasn’t made a real game-shaking impact).

That might have been overly technical, if so I’m sorry, although I think it was one of the most useful things I learned during my short time as a computer science major, so I thought I would share it. (If I did a bad job explaining it, and you’d like to know more, PM me and I’ll try again)

Simon

That was a really interesting read. Of course, I also love math. :)

Like I said in other thread, I am currently reading some books about math in probabilities. I am understanding half of it but I could always make a reference sheet that could explain some stuff. Still, it probably already exist somewhere on the internet.

As for computer generation, is there software that allow you to do these generations without actually programming the whole thing yourself.

For my starcraft lite variant, I tried using a ponderation for each stats to compare the strenght of units with each other. It's really hard to do and it's really hard to determine the ponderation. There is also diffierent scaling: linear, exponential, etc. So my evaluations where pretty approximations. Probably computer generations would allow to create a better ponderation.

In overall, if an hour of math can make me save much more time as prototype building and play testing, then I don't mind using it.

One of my habits is that I have a lot of symetry in my games. This is somewhat a way to make a game balanced intuitively without needing to do calculations and testing.

I'm investigating how to create 'fractal' maps that can be explored by the players. I mean, generated during play. The maps must be logical, as if they've been built by intelligent creatures. So there must be no paths to 'nothing', no loops, ...

That's why I'm trying to use fractals. Fractals usually have a tree structure. I'm a math teacher and I've been working with fractals a bit, so I hope I find an elegant solution. I'm working with seeds right now (a seed is a number used to generate random sequences).

Just an example on how math can be used in game design.

Thanks for sharing this resource! Years ago, I wrote a maze game that used an unnecessarily complex algorithm (I didn't have a clue, really). The depth-first search is elegant. I'll finally be able to add mazes to my board game maker software.

Cheers,

Mitch

It's my own program. I use it to create mockup boards that you can print.
I've found that it's a lot of fun to use for the GDS challenges :)

Cheers,

Mitch