‘Fastest Growing’ mobile device? That Means Nothing!

I just read an article on Flurry about Phablets being the fastest growing device type. Phablet usage grew a seemingly impressive 148% in one year. (You can read the article here)

But is it really that impressive? Should we all now rush to create apps specifically for phablets?

blog_fastestgrowingI like phablets. I am NOT comparing them to cockroaches in this comic.

Fastest Growing means nothing

Growth is measured in percentage, relative to your current size. Which means, the smaller you are, the easier it is for you to have incredibly large growth numbers.

Imagine a bored farmer starting a company to make cellphones. In the first year he makes one for himself. Then he sells one to his mother and one to his neighbor in his second year. Thus he has grown his sales by 100%. Sounds impressive, right?
(Explanation: He sold one in the first, and two in the second year.)

On the other side: If Apple, which has sold roughly 170 million iPhones in 2014 (Source here), now sold 171 million iPhones in the next year – a whopping 1 million more devices! – it would only make iPhone sales grow by 0.006%. Simply because the number was already that high.

Clearly, the farmer has the faster growing product.
But, does that mean anything? Or at least, does it mean anything good? Is a total of three devices something to celebrate?

Which company would you rather invest your money in?
What cellphone operating system would you spend your time and money developing exclusive content for?

(Of course I wish the best of luck to the farmer in his endeavors!)

Small growth can be more impressive

Growth alone doesn’t mean much. But that changes when you provide surrounding data, ideally in the form of some absolute numbers.

If you grow your company size by 10% and had 1000 employees before – congratulations! You just created 100 new jobs!.
If you increase the amount of money you give to charity each year by 100%, and you gave $3 before… not much to celebrate here.

I am getting tired of reading ‘fastest growing’ everywhere as if it was somehow impressive all by itself. If anything, big growth usually means that whatever is growing so fast is currently really quite small.

It’s the small growth numbers that are often way more interesting. Something that is already big and still manages to grow 5%-10%? Now that is actually impressive.

And if something claims to be the fastest growing industry/company/religion/tech/whatever, but then doesn’t provide any real hard numbers, things start smelling fishy.

Here is a comic by XKCD that pretty much hits it on the spot:

Back to Phablets

Don’t get me wrong – I like Flurry’s insights articles a lot. And the core of the information is perfectly fine and interesting. More and more Phablets are being bought and used. They are probably here to stay and will become a permanent and relevant part of the mobile device market.

Unfortunately the article doesn’t list any absolute numbers on how many phablets are out there, how often a day they are being used and so on. It just states that their usage is growing faster than that of iPhones in the same period. Which means nothing. Even without knowing the exact numbers I can tell that there must be a multiple times the amount of iPhones out there than phablets. That makes it hard to judge how important phablets really already are.

From a developer standpoint it probably doesn’t matter much. Phablets are in between phones and tablets in screen size, so they’ll run all apps from these two markets just fine. No need to target phablets specifically.
There’s already apps for that.

Summing it all up, I’m really just ranting.
My point: Beware when something claims to be the ‘fastest growing’ in its field.


I mentioned Apple and iPhones in this article. This was purely for making a point. Neither do I promote buying Apple products, nor do I discourage from it.

Fun fact:
Did you know that Apple actually trademarked the phrase “There’s an app for that”?

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!