Dev Update #14 – Concept Graphics and Aspect Ratios

Have your base (classes) covered!

In spite of what I wrote in my previous blog post, I realized I need to create one more department before I can finally tackle the Build Menu: The Management department. Like the Design department, this one works differently from the production floors. This makes a difference from the coding point of view – as I want a base class to take care of all floors, and then handle only specialized stuff in derived classes. And like I said, I want all my bases covered.

Here is the mockup graphic for the Management floor:
Management

The idea was that a Management floor can employ up to four development directors. Each director would allow for one game to be in production. This way the player can work on multiple games at the same time. But I made a pretty noobish mistake when creating the above mockup – I hadn’t given any thought to the aspect ratio of my floors.

Aspect Ratio, anyone?

When creating the actual game graphics for this floor based on this mockup, I ran into some trouble. I hadn’t really thought about aspect ratios and screen width when I created those images. That was a big mistake, as it turns out. The mockup screens were too wide. There was simply no room left on the right side of the screen for the two big purple buttons, not unless I scaled the height down.  But then everything else in the floor would become tiny. To counteract, I would have to scale up the characters. But then I didn’t have enough room above the head of the managers to put the actual game icons. My characters were simply too big.

So I redesigned that department completely. Here’s the result (middle floor):

BlogPost15

Instead of placing the icons above the characters’ heads, they were placed next to them, sorta like a PowerPoint screen in the background. It actually gives it a nice manager look and feel. And as a bonus, this will free up some screen space at the top of each floor where I have been wanting to put a floor number. In another change, the Release and Trash buttons on the right are done away with. Instead, scripts can be released or trashed by clicking on them and opening up their details dialog.

I definitely learned my lesson and will create future mockups in a sensible aspect ratio.

Now, this time for real – next up is going to be the build menu.

Dev Update #13 – Code and Design Departments

It should have come as no surprise to me that spending my free time working on a game directly clashes with writing blog posts in that same free time. And one of these things simply comes more natural to me than the other. So it’s been five months… Time for an update.

I really want to start working on the build menu, but before I can do that, I need a few floors that I can actually build. So I created basic prefabs for the Code and Design departments.

Here are the results.
BlogPost12The Code department layout (top) represents the basic layout for all the basic production floors. 3D Art, Animation, Sound etc… they all will share the same basic setup with three queue slots. The Design department (bottom) works differently and needed a special setup. So it made sense to create these first and cover all my bases.

In my original game design document, the workers would all sit with their backs towards the player. This was mainly due to my poor drawing skills. But for the actual game I found this to be too boring. So instead, I turned them all around, so that they would be facing the camera.

The floors all use the same background graphic for the floor, which is actually grayscale. The graphic is tinted in realtime with the color of the floor.

Please keep in mind that the floors are not really finished yet. The coder for example doesn’t even yet have a computer in front of her. But it’s good enough to work with. Now I can start creating the menu that let’s me build floors into my game studio tower.

Dev Update #12 – Game Name Generator

I like to get all unpleasant work out of the way first – but I allowed myself a little fun task this week: A Game Name Generator!

blog_gamenamesFor my game Game Tower I need a bit of code that randomly generates game names for the virtual games the player creates.

This was probably the most fun task of all the work so far!

Pattern Matching

I went for a simple pattern matching system. The generator picks a pattern at random from a long list and then replaces the placeholder wildcards with random words from others lists.
Here are a few examples of such patterns:

<name> and the <noun>
<noun> Tycoon

The generator would take such a pattern and replace the wildcards with words from a list of pre-approved words. The wildcard determines which words match – there a nouns, verbs, names and plural forms of nouns. When all wildcards are replaced it spits out the finished game name, for example:

Jesse and the Unicorn
Waldo and the Zombie
My Mom and the Warlock
Zombie Tycoon

It’s soo much fun!

I added the name generator to my debug menu (see Dev Update #9) so I can test it out and generate new game names when I feel like it. It works great and I find myself adding new words or patterns to my database every few days, because it is simply that much fun.

GameNameGenerator

Good ideas come … while in bed.

All patterns and words are kept inside my trusted Google Spreadsheet. I have a macro that can convert them into a string list quickly, so I can get it into my code fast. I can access the spreadsheet from anywhere – and this has already paid off.

Like all coders (I assume) I have a lot of good ideas in bed. When I have a fun idea for a new pattern or a noun to add to the list. I can just reach for my phone and punch it in.

More updates and screenshots from the game in progress coming up soon!

Dev Update #11 – Tip of the Day instead of a Tutorial

I would like to see if it’s possible to make Game Tower a game that can be played without a needing tutorial.

It’s not that I would shy away from implementing one. But when I pick up a game, I would like to start actually playing it right away. So this is an experiment I will try. There’s two plans of attack I have for this: Giving the player more features only over time and a Tip Of The Day.

Tip of the Day

I like loading screen-tips in games, because I can easily ignore them when I don’t want them. A tutorial forces me to click at a sequence of buttons in a specific order and is much more restrictive. That is fine for other games, but feels like overkill for such a simple game like Game Tower.

BlogPost11More coder art for your enjoyment! Ok, I know that this is bad, even by my standards. But my plan is to get the entire game done and working. Then I can see to it that the graphics are replaced by someone with actual talent.

So I created this quick’n’dirty Splash Screen and a Tip of the Day database. A random tip is displayed every time the game is started. The game will load the player’s tower in the background while the screen is displayed. There is a minimum display time of 4 seconds, to give the user a chance to read it even if the loading is done faster.

Easy to Learn, Difficult to Master

Probably everybody has heard of Bushnell’s law, that good games are easy to learn and difficult to master. The actual quote is a bit longer and also mentions rewarding the player (here is an interesting blog post about it). But I’ll stick with the short-hand version for now.

Applying that to my no-tutorial experiment, it should be possible to make the game easy enough in the beginning that there is no need for a tutorial before the player can start actually playing. I will have to do some more trial-and-error testing, but my current plan is to provide the player with three basic floors instead of an empty tower at game start. That way he can immediately jump in and start producing games, rather than worrying about building the correct floors, hiring people etc. Essentially I want the player to learn the core gameplay first – and then get into the finer details as he levels up.

The level-up design should come in really supportive here as well. Since the player unlocks more departments and larger game designs by leveling up, the complexity of the game already starts out small and grows larger over time.

If at first you don’t succeed…

…make sure you don’t blindly ignore if something is just not working.

Making Game Tower playable without a tutorial is something I want to try. But I won’t stick to it like it’s set in stone. If in the end I discover that the absence of a tutorial makes the game to confusing, I will mark the experiment as failed and provide a tutorial. After all, the game is meant to be played.

P.S.: I am also playing around with different names. That’s why that screenshot reads “Game Studio Manager” instead of “Game Tower”.

Dev Update #10 – A Resolution Independent Tower

As promised I will post some updates about what has happened with Game Tower in the last weeks.

Creating the actual tower with all it’s floors was a little more difficult than the creating the overlaying UI and the menu screens. The main problem here was the various resolutions that needed to be supported. It’s a mobile game and with the multitude of phones and screens out there, it needs to be basically resolution independent. Buttons and other nine-sliced UI elements can stretch or be anchored and adjust themselves to different resolutions fairly easily. But the individual floors inside the game area are a different matter.

The floors should adjust to the screen size, but without squishing or stretching the graphics. Because of the different screens, the width of the tower is unknown. The tower doesn’t have a fixed height either, since I can add more floors to it as I play. This made it slightly difficult to set everything up.
BlogPost10I want each floor to use the entire width of the screen. Of course the graphics shouldn’t be squished or stretched, so depending on the width each floor then adjust it’s height to match the original aspect ratio that I designed it for. This would mean that the floor graphics look the same on all devices, but the amount of floors that are visible on screen at the same time depends on the aspect ratio of the screen of the phone it is being played on. Thinner or longer phones would show more floors than wider or shorter ones.

The new Unity GUI system is still fairly new to me, so it took me a little longer to figure this one out. But it finally worked. My code now calculates each floor’s position from it’s height, and the height is calculated from the width. Technically the game can handle it if the screen is re-sized in the middle of the game. Even though that would be impossible on a real phone, it’s just something I feel good about. The floors and their content keep their aspect ratios and adjust with the screen resolution, and I can even already scroll through the tower by dragging up and down.

There are more updates coming, next up is a startup screen with gameplay tips!

Lots of progress, but not a lot of updates

I realize I haven’t posted since the new year started and hang my head in shame for that. I have been working on Game Tower quite a bit and have a lot of progress to show for it – but somehow I never found the time to post any updates.

Now with the GDC out of the way, things should slow down a little. In the next weeks I will start sorting through everything and post a few updates about what happened with the game since Christmas.

Dev Update #8 – Let the implementation begin!

With Thanksgiving finally out of the way, I have enough peace of mind for another blog post, even if it is just a short one.

Finally I found the time to start the actual implementation of Game Tower! It felt really good to finally create a new project and folder structure in Perforce (Yes, Perforce. I prefer it over Git.)

It will be fun implementing the functionality as I have written it down in the design document. Since the major design work is done, I should be able to focus mainly on the technical side of everything.

Unity Logo

For the implementation of Game Tower I chose the Unity engine. I don’t know it as well as I do CryENGINE yet, but I have worked with it before on two other games (Boob Rescue was made with it as well).

I think Unity is perfect for this game, because I can easily get the game to run on both iOS and Android (and Windows Phone – as per special request from a friend). And it is so ridiculously fast to do anything in this engine that I find myself moaning every time I have to do anything in any other engine now.

Since Unity has just released their new GUI system, I want to use that for Game Tower. I have previously used NGUI, and the base of the new system was written by the same guy, so I expect good things.

 Enough for today, I will post more soon.

Dev Update #7 – How to Balance a Game – Part 2

While Part 1 of this article explained the basic methods of game balancing, I now want to apply this to an actual game. By the way, if you are interested, I shared the spreadsheet from part 1 on Google Docs. You can find it here.

It’s time to run a first balancing pass over my game design for Game Tower. This will be fun! I feel much more comfortable creating formulas, tables and spreadsheets than creating art. Numbers are my friends. A woman with glasses has her hand on her hips and says: "I'd like me some 3.14159"

In the last week I created a ton of spreadsheets and graphs to tell me if my numbers are reasonable. I will pick two of these and present them in (some) detail here.

Does leveling up punish the player?
As a player levels up in Game Tower, more complex games can be produced. A higher level game takes longer to make, but will also pay more. But will it be enough?

My main concern was that it wouldn’t pay off for the player to create higher level games. If the longer work time didn’t pay a lot more, players would want to stay at a low level as long as possible. Leveling up would feel more like a punishment than a reward. What a perfect opportunity for some pre-implementation balancing! So I created a table that listed the time it takes to complete a game production and the money the game would make in relation to this time.

I work with undefined units instead of actual numbers. This means 1 Work Time unit will give me 1 Money unit – without specifying how many minutes or dollars that actually is. In the final game one time unit might be 15 minutes, and 1 money unit $7. For the math to work out, it doesn’t matter! Once the balancing is right, the resulting functions will work with any numbers I throw in. 🙂

I already knew what to expect, but to check my theory (and to be able to present it here), I started out with a simple linear relationship: 1 time unit would pay 1 money unit. At first my spreadsheet looked like this:

The graph shows that the payoff is perfectly linear to the work time. If the work takes twice as long, the payoff will be twice as much.

The graph confirmed what I already knew, a longer production time wouldn’t pay off (the blue and the red are overlapping perfectly). I needed a non-linear relationship between the work time and the money payoff.

So I added a third column to my table, which would contain a growth factor for the money payoff. In simple words – the more time a game required, the more each individual time unit would pay. I found a curve that would make a longer game production not only pay more, but a lot more than a lot of smaller games. This way it will always be beneficial for the player to level up to be able to produce more complex games for a bigger payoff. Here is the table:

A graph showing the non-linear relationship between work time and payoff. The payoff increases exponentially with the time spent working. If the work takes twice as long, the payoff is more than just double.

The new graph shows how the red line (money payoff) is increasingly moving away (up) from the blue line. The result of this balancing is a simple formula which I can implement inside the game’s code to calculate how much money a game will make, based on how long it took to create it.

By the way, this problem can not be solved by simply increasing the amount of money that a time unit will pay. Any linear relationship between money and time would yield the same result. If 1 time unit paid 5 money units, it still would not make higher level games more profitable.

Why? Here is the explanation:

Linear:
In a linear relationship between time and money, each hour of work will yield exactly the same payoff. If I get $1 per hour, it doesn’t matter if I produce ten 1-hour games, or one 10-hour game. The payoff at the end would be exactly the same: $10. Increasing that factor does not change that truth. It doesn’t matter if one hour pays me $1 or $5 or $10. It will never make a difference, the payoff will be the same for both scenarios.

Non-Linear:
In a non-linear relationship the amount of money an hour of work will pay is not fixed, but defined by a formula. The more work a game requires, the more each individual hour will pay.
Example: A game that takes 1 hour to complete, will pay $1 for each hour. But a game that will take 10 hours to complete, each hour will pay $2. Which means, if I make ten 1-hour games, I end up with $10, but if I make one 10-hour game, I end up with $20! In both cases, I have worked 10 hours, but the higher level game pays twice as much!

Result:
This is the formula for my work time payoff:

Formula: Money = WorkTime * (1 + WorkTime/100)


Instead of one formula, you can use multiple
One size doesn’t fit all, and that is true in balancing as well. If a balancing formula is great for part of the problem, but not for all of it, it might still be usable.

I ran into this when balancing the prices for building new floors. I wanted the cost of a department to increase with each floor, but wasn’t sure by how much. I started out with simply increasing the price by 50% each time the floor was built.

Following this formula the first Code department might cost $10, the second one $15 and the third $23 and so on. I get a small increase early but a steep increase in prices later in the game, which will entice players to build different departments instead of building the same one over and over. I put this into a spreadsheet and let the table figure out the build costs for building the same floor 50 times to verify my idea:

The graph shows the building cost increase exponentially. It doesn't rise much at all at first, and then rises super fast and super high.

For the first 25 floors, the prices looked OK. But after that the departments became much too expensive (as you can see, they literally went off the chart 🙂 ). But there is no reason I have to stick to this formula for all floors. Once the numbers get too large, I can switch to a different formula:

The graph shows the building cost increase with more moderation. It doesn't rise much at first, and then rises linearly and constantly.

The red line represents the discarded previous formula

The graph looks a lot better now, with the right half of it increasing steadily and linearly. The graph still goes off the chart – but in a much shallower incline. And while my table calculates the cost for 50 floors, I actually consider everything above 25 as late-game. If I get to build more than 25 floors of the same type in my tower, my tower is easily over a 100 floors tall in total.

In this case I went with the 1.5 exponential increase for the first 25 departments, and then after that switched to a linear function, to keep the increase in price reasonable.  I also went through the table and manually edited the prices for the first 25 build levels, using the calculated prices as a guideline, but rounding them to a pretty number. $5023 would be rounded to $5000 and so on.

My game is now reading those numbers from a hardcoded table for the first 25 build levels, and will switch to a linear increase function after that. The function that implements this is only a few lines long, since it only has to look up how many floors of this type exist, and then decide which pricing model to use.

The hidden Spreadsheet
I am cheating a little bit by ending the blog post here. There is a third spreadsheet that I haven’t mentioned yet and am not going to. This sheet takes the data from the two tables I discussed above and combines them. It can give me information about how long it would take a player to earn enough money to build the tower to a certain height.

This spreadsheet is my reality check. While the numbers are only an estimation (every player will build different floors and the order in which they are built is important, too), it can give me a sense of whether my values make sense or not. I will have to play the game to see if the mathematical model actually holds up.

I chose not to discuss that final spreadsheet here, because it would blow up the post even more – and there really isn’t any more to gain from it. It is more of the same: A table, numbers and graphs. Massage the numbers until the graphs look pretty. 🙂

Now the implementation begins!
Stay tuned for some first look screenshots!

Breasts? No thank you!

Maybe I should have just made a game about candy pieces. It would have been a lot easier. Calling my shiny, colorful puzzle game ‘Boob Rescue’ certainly made things a lot harder than they needed to be.

Screenshot of the game boob rescue. A puzzle game with crystals.

I think it’s great when developers create post mortems about their released games and I have always wanted to do the same. At the beginning of October I released my pink puzzle game on the Google Play Store. Boob Rescue hasn’t been on the market long enough to really gather relevant data in terms of download numbers or revenue, but I will post those at a later time. Today I want to write about the development of the game, which deserves its own post.

What I learned during the development of Boob Rescue in the past few months is that making a game about breasts is anything but easy.

Breast Cancer has to do with breasts, but it isn’t sexy.
Although these days the display of female breasts seems to be socially accepted for purposes of advertisement or promotion of goods and services, making a video game focusing on the female breast is still a challenge. Boob Rescue has nothing to do with sex, pornography or anything else the game’s title might suggest. It is a game about breast cancer with the goal to raise breast cancer awareness. That is a good cause and should not create any problems, right? Well…

A pink ribbon, the international symbol for the fight against breast cancer.

The idea for Boob Rescue was born in ‘Pinktober’, the breast cancer awareness month where everybody is happily and cheerily celebrating the fight against the disease. Pink t-shirts and fund raisers are omnipresent each year during October, and this year, I wanted to join the cause. Making a cute little mobile game dealing with breast cancer to raise funds for breast cancer research with in-app purchases was my attempt to support the fight.

I felt that I would be the right girl for the job: I am female, an experienced software engineer, and I have a personal connection to the subject matter. My mother battled hard with breast cancer and almost lost the fight. She had to undergo a very aggressive form of chemotherapy and lost one of her breasts. Somewhere in the back of my head lingers the constant fear that one day I might get hit by the disease as well, just because I might have inherited some of the wrong genes.

What better way than to combat that fear than to make a game that lets players ‘puzzle against breast cancer’!?

Not much ‘boob’ left
Well, let me tell you, now that the game has been released, there is not much ‘boob’ left in Boob Rescue. The first thing that died were the physicalized 3D breasts which could be touched and scanned in order to detect dangerous lumps. This was really the coolest feature of the game and has now been replaced by a simple 2D scratch-off style puzzle.

It is sad because the underlying tech prototype had worked really well and made great use of the multi-touch ability of modern tablets. It had a custom animation system with realistic surface deformation, using both blend shapes and joint animations. I even dare to say that this would have been one of the most realistic physicalized breasts you would have gotten on a tablet.

A screenshot from the game Boob Rescue. It shows an cartoon X-Ray of a woman with two tumor cells in her body.

However therein also lies the problem, since Apple or Google will not approve anything for release in their stores which even remotely features ‘bouncing’ breasts, no matter how far away the content is from any sexual reference.

It’s not that I can’t see where they are coming from. Even though the gameplay focused on detecting lumps and learning about breast cancer prevention, it isn’t hard to imagine that in the hands of teenage boys those wobbling 3D breasts might be used in ways not quite intended by the designer. 🙂

Breasts are fine in ads, but not the other way around
Even after removing the most loved feature of the game and replacing it with a more ‘safe’ 2D alternative, things didn’t go smoothly from there.

Since the game was free I wanted to bring in a bit of extra money by placing ad banners in the game. After signing up with one of the biggest ad networks out there it only took a couple of days to get the game banned from their network due to its ‘inappropriate’ content. Again the name ‘Boob Rescue’ was hurting the game, since something that is called Boob Rescue must clearly have some pornographic/sexual content, right?

My emails asking what exactly was inappropriate about the game never got any replies. It needed several attempts, a rework of the game’s logo and artwork to finally get signed up with an ad network without getting kicked out again.

Marketing
Next up was marketing. Everybody familiar with the mobile space knows that without marketing it is very hard to get noticed among all the hundreds of games released every month. One of the greatest things about Boob Rescue is that a share of every in-app purchase will be donated to breast cancer research. The more players spend in the game, the more funds for breast cancer research will be raised.

My plan was to get involved with the most popular breast cancer charities and try to get their help to promote the game on their social media accounts and in return it would (hopefully) generate lots of extra funds for them. I was even offering to guarantee a certain amount of donations, and pay for it myself, should the game fall flat. Everybody wins, right? Again, things proved to be a bit more difficult.

I have not yet found anyone who wants to partner with me and promote the game. I was turned down due to ‘contractual’ reasons or told that this isn’t really a fit. Do games and breast cancer not mix well? I don’t know if people found the two years my company has been in existence as too short to bear credibility, or if they found the whole idea of making a game about breast cancer too dubious. At this point I decided to just release the game without any support and see where things are going. I figure I can just donate the money anyway, without an official partnership.

A screenshot from the game Boob Rescue. A female surgeon getting ready to destroy the tumor.

Boob Rescue has since been released for phones and tablets, just in time for this year’s Pinktober. The game is out on the Google Play Store now and has not yet been banned, so I guess it will stay there for good.

I also submitted the game to Apple’s AppStore but there has been no approval yet. At the time of writing, it has been in review for three weeks, more than twice as long as the average review time. In my mind I am speculating wildly about what’s causing the holdup. I hope whoever is reviewing it doesn’t just look at the title and then rejects the for ‘sexual content’ without ever opening the app.

I never expected Boob Rescue to make millions. I just didn’t expect it to be this complicated.

Dev Update #6 – How to Balance a Game – Part 1

This is part 1 of my take on game balancing. This post will deal with the what and how of game balancing. In part 2 I will give an real life example, and run through some numbers, formulas and tables for my current game project.

Girl in front of her computer is devastated, because her favourite character class in the game she plays has been nerfed again.

Balancing means adjusting all numbers and values in your game so that they work together well. Here is an example showing what this means and why it is so important:

The Overpowered Warrior
Think of a warrior, a type of game character that commonly has very high values in defense. In a fight with a monster he can take a lot of hits without dying. But on the downside the warrior can only do very little damage, compared to a wizard for example. Essentially, a warrior needs his high defenses to stay alive longer – because he needs longer to kill an enemy. This is in essence how a basic warrior class is balanced.

Without this trade-off between damage and defense the character would become unbalanced. If a warrior had high defenses and high damage output, he’d be overpowered and players wouldn’t play any other class anymore. If he had low defenses in addition to his low damage, they would play any class but the warrior. You want to avoid either scenario.

Balancing on Paper vs. Balancing by Playing
Finding the right numbers for armor, damage, item prices and monster difficulty is not as straight-forward as one would initially think. Most games have more than two values that influence each other. This is what makes Game Balancing a topic all on its own.A scale with not two, but four plates hanging at a perfect balance.

Balancing is important for basically any game genre, from shooters to tycoon games. Does building get too expensive later in the game? Will the upgraded weapons make too much damage and make fights too easy? Does it pay off more for the player if he didn’t level up and kept the monster levels down?

There are two ways these questions can be answered: By playing the game – or by looking at spreadsheets.

Balancing by Playing
Balancing can be done simply by playing the game and adjusting the numbers until it feels right. But there are some downsides to using that as the only approach to balancing.

First of all make sure you are not under the illusion that balancing will somehow work itself out automatically as you go along. Simply playing a game every now and then won’t cut it. You will need to play the game a lot. A whole lot. And then again every single time you adjusted your numbers. You will need to schedule time for this into your development plan. And this is where the first problems arise.

The game needs to be playable first
Since you need to be able to play the game to do this type of balancing, all of the important game features need to implemented first. This means you have to be pretty far in development before you can even begin to start adjusting your numbers.

But the downside of waiting with the balancing until the end of the implementation is that it has a high risk of being skipped or not given enough attention. Time becomes a hot commodity near the end of production, when all efforts are spend on polishing, bug fixing and ramping up marketing. So it a good idea to start a early as possible with balancing.

You need to notice a problem before you can fix it
If a game is balanced only by playing it, you rely on perception to notice unbalanced sections of your game. In other words – you need to notice a problem before you can fix it. But almost every game can be played in several ways, with different strategies. A player with a different play style than your own might find your game terribly unbalanced, even when the numbers work great for yourself.

A blindfolded woman - Justicia - holding up scales. The blindfold is a symbol of equal justice for everybody.

Great for Justice – But not for Game Balancing

If you are the only one playing your game for balancing, you run the risk of adjusting the game to your personal play style, while being blind to issues others might encounter. So you need to seek strength in numbers. To balance by playing, you need beta testing more than ever to get your game in the hands of as many players as possible and hope for valuable feedback.
And even then it is easy to miss things.

The Late Game is hard to reach
Not every game has a late game, so this paragraph only applies to those that do. Late game is called late for a reason. It should take some serious play time to get there. And since it takes so long to get to the late game, you will not reach it by accident. During development games are usually only played for a few minutes at a time, to test out a feature or fix a bug.  You don’t play for hours on end to get to the final level to fix a bug in the boss fight. You will directly jump there using some kind of debug or cheat feature.

This is fine for development, but to truly balance your game, you will need to reach the boss battle through regular play. And then, when you realize the boss is horribly overpowered and you quickly lower the prices for better weapons and armor – you will need to start all the way from the beginning again – and play your game through with the new numbers. In short, the amount of time you need can quickly get out of hand. You run a serious risk of an unbalanced late game if you rely on this method of balancing alone.

Balancing on Paper
The other method of balancing a game is to use mathematics. I call it paper balancing – though of course instead of paper I am using spreadsheet software like Excel and Google Docs.

Using this method you work with your numbers directly and put them into tables and graphs to see whether they all work out. This can give you a tremendous amount of information about your game that you would never find out otherwise.

Various graphs, overlayed over one another, symbolizing that there is a LOT of data to evaluate to achieve balancing.

One of the strengths of paper balancing is that it is very easy to see the results and consequences of any changes your make to your values. In case you are easily scared off by math, you will be happy to hear that it requires very little actual math skills.
To demonstrate how paper balancing works I will give an example.

Paper Balancing – a simple example game
In this example I am developing a simplified hack’n’slash game. The player needs to kill monsters to  earn XP to level up. Now let’s do the basic balancing.

The first step is to find some starting numbers. I decided the player needs 100 XP to get the first level up, and each monster will give 5 XP. That means the player has to kill 20 monsters to get the first level, which sounds fair. But these starting numbers are not all that important, the real balancing starts now.

To make each level a bit more difficult, the XP needed to get to the next level should constantly go up. I am choosing that each level will require 35% more XP than the last.

Now I need to make the higher level monsters worth more XP – otherwise the players will just keep killing the low level monsters. Again I pick a random number and decide that each monster will give 10% more XP per level. This number has to be lower than the 35% more XP needed for leveling up. If it grew at the same rate, players would need to kill exactly the same amount of monsters to level up each time.

A goblin stands next to a sign post that lists his statistics. It reads: "Goblin. Level 1. Reward 5 XP, Time to Kill: 2 minutes"

Now that I have these two numbers, I can put them in a table and see if they work out. The spreadsheet immediately tells me that I need 135 XP to get to the second level. Since each monster on that level gives me 6 XP, I need to kill 25 monsters to level up. That’s 5 monsters more than I needed for the first level. Everything sounds pretty good so far, right?

But then I notice the rather large numbers near the bottom of my table. To get from level 29 to level 30, the player needs 446,011 XP. At this level, each monster will give 72 XP. My spreadsheet automatically calculates that this translates to 6,186 monsters that I need to kill. It also calculates how long this would take. The result is horrible.

If I killed a monster every two minutes while playing, and I would play for 8 uninterrupted hours a day, without stopping for food or going to the bathroom – it would still take me 26 days of playing without a break to get that level up. A more realistic player who can play maybe 8 hours a week would need to spend 4-5 months to get just this one level up. I have nothing against a little grinding, but that is just not acceptable.

And this is where the paper balancing really shines. Let me tweak the number of how much more XP is required for each level. I am tuning it down from 35% to 25%. Immediately the numbers adjust. Now I only need to kill 717 monsters to get from level 29 to level 30. This would mean 24 hours of game time, or 3 days of 8 hour power-gaming sessions.

Those numbers sound a lot more sensible now! And I found this out within 5 minutes of working with a spreadsheet. Can you imagine how long it would have taken me to balance this only by playing the game?
Isn’t math cool? 🙂

[To those actually double checking these numbers with a calculator right now: All numbers are rounded up. Since you cannot earn 3.5 XP, you will get 4 XP instead and so on.]

I shared the spreadsheet with this sample data on Google Docs, so you can take a look at how a balancing table can look like. You can also copy the document and play with the number to see what happens.
Here is the link: Balancing Table Example on Google Docs

The complexity goes up!
Just in case you are not yet convinced of the power of paper balancing, let me drive the point home some more. See, a real game is a little more complex than the example above.

In my hack’n’slash game, the player gets more XP when killing a higher level monster. But what is to stop low-level players from killing higher level monsters? Clearly, they need to be harder to kill. So their health needs to go up with each level.

But if their health goes up, it would take longer to kill them. To counter this, higher level characters need better weapons to do more damage in the same amount of time. So I need to make higher level weapons with higher damage.

Then, to stop low level players from buying high level weapons I need to make them more expensive. But to enable higher level players to buy those weapons, I also need to make higher level monsters drop more gold.

Question 1: At what rate do you need to increase the rate of gold drop for each monster level, so that a player can afford a new weapon each level before he has gained enough XP from the same monsters to level up?

Question 2: Do you really want to balance this by playing? Or does paper balancing sound pretty nifty right around now?

Not a perfect system
While they sound boring, spreadsheets will show you problems in your game that you would never see otherwise. It is not a perfect system, but it is definitely a more objective system than just playing and fixing the issues that happen to bother you. It is also a great tool to balance parts of your game that are hard to get to through playing, especially the late game.

But not all parts of a game can be balanced on paper. Action elements that require reflexes and timing – such as quick time events for example – are better balanced by trial and error during play. The same is true if you are making Flappy Bird. 🙂

Graphs and tables also can not tell you every strategy and exploit that your players will undoubtedly find when playing your game. This is why many online games need to readjust their balancing so often, as massive hordes of players develop new play styles and combos.

Best of Both Worlds
Summing up, balancing a game purely by playing it is a poor choice.
This isn’t necessarily true for all types of games, but enough to let it count as a general rule of thumb. 
This is not to say that you shouldn’t play your game. You should. A lot. It might be off-topic, but I cannot stress this point enough: Play your own game.

But as usual, the best approach is to use both methods of balancing. Have your spreadsheets and formulas ready, and then actually put those numbers to the test by playing the game, tweaking and adjusting as you go along. And if you run short on time near the end of development, you can rest assured that your spreadsheets have your late game covered.