Balancing a Game for Pre-Alpha Testing

I am, by no stretch of the imagination, not a mathematician. My brain doesn’t quite work with O(), derivations, integrations, Omega, or natural logs (or any kind of logs, really). But when designing a game, unless you have a number monkey on your team, you have to sit down and hammer out equations, checks, and balances to ensure one player can’t overrun everyone else through mathematical exploits.

Since I am not a mathematician, I generally lack the patience to research proper theory about statistical analysis of randomness in games. I find reading proofs boring and I subconsciously ignore any and all math equations. This isn’t helpful when trying to figure out the best cost-to-player ratio of in-game assets, or how many dice is appropriate for the start of a game. I have to rely on the games I’ve played and a cursory glance at how the mechanics for these issues were designed (from a player’s perspective) for those titles.

That being said, I am by no means a slouch when it comes to understanding mathematics. I needed quite a lot of it for my graduate work in computer science. I’ve found that some basic knowledge in statistics and algebra will go a long way to a pre-alpha or prototype version of a game.

I’m going to use Die Civilization (DieCiv) as my example game since I’m working on it as we speak. The original game required a LOT of custom dice—ten with different colored faces. Each die was somewhat unique in that I used frequency analysis on the cards for a game called Innovation (by Carl Chudyk). I went through each age the cards represented and figured out the frequency of each color icon as it appeared in that age. With that frequency analysis, I was able to determine how many faces on each of the ten dice were of any particular color. Each die represented an age in Innovation, so I had a way to collect resource cubes with dice.

It was pretty exciting! The problem came when players began to interact. It was done through combat, posturing of red and green cubes, actions that happened during, before, and after combat, and a whole slew of other complications. The resource market was meant to be both functional and thematic in that you built a pyramid of the resources and had to spend resources to get more. The game became slow and sluggish. Not fast and sleek like Roll Through the Ages.

So I went back to the drawing board. I’d done a lot of footwork and guesswork with the previous incarnation (I believe v1.1a), but the game didn’t feel right. I wanted a push-your-luck game. I wanted a game that allowed you to do things with the dice, not with a bajillion cubes.

Enter DieCiv version 2.0a. There will be a lot of dice in the initial game (approximately 58) that represent concepts such as production and manpower to agriculture and combat units. The majority of the game’s mechanics rests on two different concepts: success/failure and point accumulation.

The problem with balance is introducing technologies which will cost research and production points to claim. Also, the type of research needed, how much the technology costs, and the benefits the technologies provide. In addition, each type of research die provides a benefit if the success doesn’t happen.

That is a lot of probability, luck, and math. We have to look at luck mitigation techniques in case someone just has a bad time with the dice. We have to look at limiters in case someone is having a wonderful time with the dice. And we have to weigh in the probability of the draw of cards from the technologies, wonders, and achievements.

This is not a light game. During the first playtest, the pre-alpha (of which there will be many), the game lasted for over one-and-a-half hours. The interesting thing about the experience is that even though we were tweaking and talking about what was going on as we played, it felt like twenty to thirty minutes. We had fun, never got bored, and played strategically. The rules as written (RAW) made us think about nearly every move. I wish all playtests were like that.

In any case, to balance the game for the playtest, we used Innovation’s cards as the technologies (because that’s what they are). We found that the lack of certain icons on these cards was keeping us from even looking at the majority of the components for DieCiv. We also discovered that purchase prices for the technologies were rather…low. Victory points were…OK (twice the technology level for the first one to complete the tech’s acquisition, the tech level otherwise). And the cards were definitely large enough for the size cubes we were using.

I need to look into balancing seven dice across eight cards (eight per tech level) so that there’s a chance that players will see most, if not all, of the dice in the game. There are ways to acquire all the dice which are a part of the catch-up/luck mitigation mechanic. So their abilities can be used once acquired.

To that end, I have decided there are three total requirements to purchase a technology:
1) A research success for each color shown on the card,
2) Production points of a certain amount, modified by tech level,
3) and at least one production point produced by a die that matches the card’s color.

Now it’s a matter of choosing the colors of the cards, the colors of the icons, the cost of the cards, and whether or not I have variable numbers of required research icons on them. Additionally, do I want to add a tech tree to ensure players progress through certain technology chains? Well, that’s a question to answer another day. For now, I’m just going to make my closing remarks.

When you’re working on a game for the first time make sure you play a lot of pre-alpha and alpha playtests before you move into the beta state. Refine your rules as you go along and observe any outliers which may cause the game to break down.

In terms of balance, it’s important to know approximately what you’re looking for in the components. Nothing has to be laid out in a plan or set in stone! You’re trying to get a feel for how the game plays, how long it takes, and what you need to keep your eye on. Balance can be as simple as using another game’s components and expanding from there. It can be more complicated by studying up on the mathematics behind all of your mechanics.

Me? I carry a notebook and pen with me when I’m designing to jot down ideas whenever they show up. I sketch out layouts and how things may look down the road. I draw a lot of diagrams trying to figure out placement, how many things of something I need, averages of dice rolls, and point systems.

This may have been a ramble, but I hope you walk away with a little insight into what I’m doing and maybe some of it can help you…

Updated: November 13, 2014 — 6:38 am