First things first - Creating basis for economy balancing

So, Sky Castle was a manager, which gameplay was based on building, managing and collecting from castle’s rooms. One of the main parts on the briefing was that there should be, at least, 60 rooms (they were inspired by Tap Zoo and other games of the sort) and some of those rooms should be upgradeable.

It sounds like a recipe for a mess, but it is not quite that way. With so many rooms, I had to come up with a idea of organizing best and least desirable rooms and items. I mean, it would be madness to give all those options to a beginner; we always should take most care of our players in the beginning of the game. The approach that seemed most effective here and would also give the player a sense of progression was to limit rooms to a player’s characteristic. In this case, I choose to give player a Castle level since the level concept is widely know and understood now, even between casual gamers, so that the bigger the level, more room options player would have to choose from. By doing this, I could organize rooms in a simple way, associating all rooms to a certain level, but also could calculate in a even simpler way room parameters and how they would evolve.

First, I concentrated myself on the economy part of the issue, thinking on how much rooms would cost and how much would their revenue be. In order to do so, I tested some progression equations and checked out how they would evolve until level 50 [even though, the game was planned to go until level 20 in its launch, it's important to check the development of the amounts a bit further in the case the game is a hit and new levels need to be implemented].

I love Fibonacci and even though I know it’s not very useful for balancing as in its original form, I generally start improving my equations based on a Fibonacci-like one. One of the problems with a pure Fibonacci-based equation here was that amounts rise too quick; value doubles almost every two amount. Generally, when one can hardy afford a determined item with her “income”, this item probably will have a high perceived valuable, however, if soon after the same value is highly affordable, almost small change, its perceived value decreases even more than if the item was always cheap. As so, using such a high increasing  equation would make rooms and items lose its perceived value very quick, and even though we would have 60 different rooms for 20 levels (3 new rooms for level), that it not that much for our playing goal of 2 months.

In this this way, I hand to abandon Fibonacci and end up choosing to use a very slow progression equation, which made values double only after around six rounds. This way, even 5 levels down rooms would not look like a total waste of player’s time since they cost less about 40% and are a but less effective, but not as much as rooms that cost 90% less of the ones player can buy in her actual level. What I ended up was with this value2 =  value1/0.87.

After that, I created 11 categories of items/rooms as a base value to apply to this equation. This categories work in a similar way as items colors in Diablo or WoW; in the same way that a white item for your level costs a fair value for your income, a green one is a bit better and a bit pricier, a purple one is great but quite expensive while a blue one is a amazing item but also ornery. The idea was not to make any room as ornery as blue items in Wow, but offer some price change depending on room properties.  Creating this spreadsheet with all those categories [4 of them applicable to rooms, all other applicable to items and other in-game purchaser] I could easily come across the base-value for any room or item of any level, taking in account only smaller variables as its properties regarding other rooms with similar levels. This is the final base-value spreadsheet:

I think that’s enough for today; next time we will talk about how I calculate the income each room would have based on its cooldown time and also our first system limiter in this game.