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:

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.

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!

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!