Tuesday, November 25, 2014

Mobile Income Report #5 - October 2014 (monthly income report from Android, iOS, Tizen, ... games)

previous parts
Mobile Income Report #4 - September 2014
Mobile Income Report #3 - August 2014
Mobile Income Report #2 - July 2014
Mobile Income Report #1 - June 2014
Apps page - Portfolio (what are my assets?)

If you do not want to miss any of my Income Reports you can follow me on Twitter. Just click the button above.

Under Apps page you can see my portfolio. It is list of the games that are then reported in Income Reports. The portfolio is regularly updated with new information (releases for new platforms, new updates, ...)

What I did in October

October report is very short. I continued to work on my projects, but there was not any big or noticeable event.

Report

This month I decided to remove bada stats from the report. The reason is that bada is dead OS and also downloads are negligible now. If there will be any download it will be merged with Android stats, but I doubt.

So, let's get to the figures. Here are stats for paid apps:

Last month was strongly affected with Shards being "Free App of the Day" as Amazon. In October the effect of this faded. The decrease is from $375 to$146,9.

The ratios changed a lot from last month. In September the Shards share was 93%. Now, Deadly Abyss 2 has almost half of the profit and for Android it was more profitable than Shards. probably this is some echo of "Free App of the Day" for Deadly Abyss 2 which was in the very end of September..

For ads supported apps I decided to remove Tapjoy. I had only very low traffic there and the performance was not satisfying for me. The Chartboost, the usual leader of my ad incomes, decreased from $75,2 to$60 - it was one of the weakest months in this year. Total ads income decreased from $168,7 in September to$128,2.

The shares are almost the same as in September as the decrease was not only for Chartboost, but also for other sources:

So, total income for SBC team in October = $146,9 +$128,2 = $275,1 (- 49,4% compared to September report). It is still far away from my mid term target$750 / month.

Next?

In October I worked on some new games and also continued my work on big Unity project I am involved in. In November report I will report impact of some app promotion events for Fruit Dating.

Friday, October 24, 2014

Procedural Generation of Puzzle Game Levels

This article was originally published at Gamedev.net. The discussion there, below article, brings some improvements to solver part of generator.

1. Introduction

If you ever wanted to create a puzzle game you probably found that implementation and coding of game rules is relatively easy, while creating the levels is a hard and long-lasting job. Even worse, maybe you spent a lot of time on creating some levels, with intent to incorporate specific challenges into it, but when you asked your friend to try it, she solved it in a totally different way or with shortcuts you never imagined before.

How great would it be if you found a way to employ your computer, saved lot of time and solved issues similar to the above mentioned... Here is where the procedural generation comes to the rescue!

It is necessary to say that while there is only one correct way how, for example, to sum vectors and every programmer wanting to do it has to follow the same rules, when it comes to procedural generation you are absolutely free. No way is right or bad. The result is what counts.

2. Fruit Dating – its rules and features

In past days we released our Fruit Dating game for iOS devices (it is also available for Android and even for unreleased Tizen). The game is a puzzle game with simple rules. Your target is to match pairs of fruit of the same color simply by swiping with your finger. The finger motion matches the tilting of the board in any given direction. So, while trying to fulfill your goal, various obstacles like stones, cars or other fruit, get in the way. Simply, all movable objects move in the same direction at once. To illustrate, in the pictures below you can see first level that needs 3 moves to match a pair.

Over time new features are introduced:

 One-ways are placed on the border of the tile and limits directions in which you can move. Anteaters can look in any direction, but its direction is fixed and unchanging during the level. When fruit is in the direction of the anteater and no obstacles are in the way, the anteater will shoot its tongue and drag the fruit to it. Mud can be passed through with stones, cars or barrels but not by fruit. When the fruit falls into mud it gets dirty and there is no date! Sleeping hedgehog is sitting on a tile and wakes up when hit by something. If hit by a barrel, stone or car he falls asleep again as these items are not edible. But when he is hit by fruit he eats it.

You probably noticed that the game is tile-based which simplifies things as each level can be represented with a small grid. Maximum size is 8x8 tiles but as there is always solid board, the “usable” area is 6x6 tiles. It may seem to be too small but it proved that some very complex puzzles can be generated for it.

With the basic rules (as the additional features were added later) I started to build my generator. My first thought was that someone in the world surely already solved a similar problem, so I started to search the internet for procedural generation of levels for puzzle game. It showed that this topic is not widely covered. I found only a few articles useful for me. Most of them were about generating / solving Sokoban levels - for example:
It was also interesting, that most of them were written by academic people (professors of Sokoban! :-)) From the papers I learned two things: first, when generating something randomly it is good if it has some symmetry in it as people will perceive it more positively. Second, the algorithm is up to you, but none is ideal.

3. Solver

As it was obvious that every generated level will have to be tested (whether it is possible to solve it and how easy or hard it is) I first wanted to code a solver. As at that time I was only considering basic rules and not features added later I came up with these ideas for the solver:
1. from initial position you can start in any direction (up, left, right, down),
2. from next position you can continue in any direction again,
3. in any position check for fruit match, remove matched fruits from board and continue with b) until some fruits remain on board.
As you can see, it is a simple brute force approach. So, the number of possible board situations was: 4, 4*4 = 4^2, 4*4*4 = 4^3, … 4^n. In the 10th move it was more than a million board situations and in the 25th move it was 1125899906842624 board situations. Okay, you could limit maximum moves to some number, let's say 10 and not be interested in more difficult levels, but there is hidden another danger. Some of the puzzles can be designed or generated in such a way that if a player does some bad moves in the beginning, she cannot finish the level. Or, in some levels you can get into a loop of board situations. If the algorithm branched early into such a way the level would be marked as not solvable, even if there were other branches with a simpler solution. Also if this algorithm found a solution there would not be any guarantee that it is the shortest solution – you would have to finish all branches to find the shortest solution. Beside this there are very often board situations in which one move in particular direction does not change anything. See third picture in “Fruit Dating – its rules and features” - there is no change if moved left.

So, the rules changed:
1. from current position try to move in any direction,
2. if there is a change in the board situation, check if the situation is new or you already were in such a situation,
3. if a new situation, store it along with solution depth (number of moves to get into this situation)
4. if previously was in this situation and solution depth was equal or lower, terminate this branch. Else, remove old situation (as you just got into it with less moves) and continue.
There are also other rules, like checking matches and thus terminating the whole process when a solution is found and later new rules when features were added, but this is the core of the solver. It quickly cuts whole branches without a solution. Beside solution depth, it also references to parent situations stored in each board situation, so it is easy to print the final solution in the end. Let's show it on the first level of the game:

From the initial position a move into all four directions is possible. These are labeled 1-1, 1-2, 1-3, 1-4. The algorithm always tries to move right, up, left, down in this order. As it employs a stack to store situations to examine further, the first situation to continue is the last one pushed onto the stack (1-4 in this case). Again, first is a move to the right (2-1) and as this is a new situation it is put onto the stack. Next is a move up which results in situation 2-2. We already were in this situation and it was in the first round. So, we apply rule d) and terminate this branch – nothing is put onto the stack. Next, a move to left is tried. It results in a new situation (2-3) and this is put onto the stack. Last move is down, but there is no change between 1-4 and 2-4 so we put nothing onto the stack (rule b) … no new situation = do nothing). Now, the stack top situation is 2-3. From it we move right and get into situation 3-1, which is equal to situation 2-1. But in 2-1 we were in the second round so we terminate this branch. Next we move up and fruits are on adjacent tiles, matched and as it was the only pair the game ends.

The algorithm works, however it may not find the shortest way. It is simply the first solution found. To overcome this I first start with limiting the maximum moves to 30. If a solution is not found I say that the level has no solution. If a solution is found in, let's say, 15 moves I run the solver again with maximum moves depth 14 (15 – 1). If no solution is found then 15 was the shortest way. If solution is found in, let's say, 13 moves I run the solver again with 12 (13 – 1) maximum allowed depth. I repeat while some solution is still returned. The last returned solution is the shortest solution.

See discussion on Gamedev.net below article. As Makers_F pointed the correct way would be to use Uniform Cost search. The algorithm described is fortunately only one step from it. When exploring new board situations, prefer those with lowest cost, where cost is number of moves to get into the situation. In other words, described algorithm in point c. is storing it into LIFO stack. Replace it with priority queue. The rule d. then changes from "if previously was in this situation and solution depth was equal or lower, terminate this branch." to "if previously was in this situation, terminate this branch.". After these changes the algorithm will find the shortest solution in first iteration.

4. Generator

Now that the solver works, we can move to the generator and validate every generated puzzle with it.

The generation phase can be split into two parts:
• generating walls
• generating on-board objects

Some random parameters are generated that say whether wall will be paint by one tile a time or two tiles a time. If two tiles a time then random symmetry is generated. It says where the second tile will be placed – if it will be flipped horizontally, vertically or rotated by 90 degrees or combination of these. First grid in the picture below is when one tile a time is painted. The rest are for two tiles a time with different random symmetries:

The number of walls is random as well as their length and direction. Each wall starts from a random point on the border. Every wall is drawn in one or more iterations. After the first iteration, a random number between 0 and wall length – 1 is chosen. If equal to zero, the iteration loop is terminated. If greater than zero, then this number becomes the length of the next part of this wall. A random point on the current wall part is chosen, direction is set randomly to be orthogonal to the current wall part and the next part of the wall is drawn. The result may look like this (the numbers label the iterations):

From picture it can be seen that every next part of the wall is shorter, so you can be sure it will be terminated at some point.

So far all walls started from the border, so every single tile was always connected to the border. It looked boring so I added another step where inner walls are generated. Inner walls are not connected to any existing tile. It starts by selecting a random tile and checking if it is free as well as its 3x3 tiles surrounding. If yes a wall WILL be placed into the grid and the next tile is chosen based on random direction (this direction is randomly chosen before first tile was tested). Loop terminates when condition for 3x3 free surrounding is not true. Notice the stress on word “will” above. If you placed the wall into the grid immediately and proceeded to next tile, the 3x3 surrounding would never be free as you just placed a wall there. So I store all wall tiles into some temporary array and place them into the grid at once when the loop is terminated.

During wall generation some of the walls may overlap others and it is very probable that some small spaces will be created or even that the initial area will be divided into several disconnected areas. This is something we do not want. And this is why in the next step I check which continuous area is largest and fill all others with walls.

In this check I iterate through the whole board grid and if the tile is free I recursively fill whole continuous area with area ID (free tiles are tiles without wall and with no area ID yet). After that I iterate through the whole board again and count tiles for each area ID. Finally I iterate the board one last time filling all tiles with area ID with walls except for the area ID with the highest count.

The whole process of generating walls can be seen in this animation. There is wall generation, inner wall generation and in the last frame a hole in lower right corner is filled during area consolidation:

When walls are generated we can generate objects. We need at least one pair of fruit and zero or more obstacles (represented by stones, cars, barrels in the game).

It would be nice if fruit was placed most of the times into corners, in the end of corridors or so. Placing it in the middle of an open area can be also interesting sometimes but the first is more preferable. To achieve this we will add weights to every free tile from the point of its attractiveness for placing fruit there.

For the end of corridors, surrounded with tiles from 3 sides I selected weight 6 + Random(3). For tiles in horizontal or vertical corridors I selected weight 2. For corners I selected 3 + Random(3) and for free areas 1.

From weights it is obvious that the most preferable placement is in the end of a corridor, followed with placement in corners, corridors and free areas. The random numbers in weights can also influence this and change weights between corridor ends and corners. The weights are generated only once for each generated level.

Obstacles (stones, cars, barrels) are placed in a similar way, only the difference is these weights are separate from weights for fruits and also some random obstacles density, which says how many obstacles will be in level, is chosen.

By the way, with the weights you can do other tricks. Features added later were sleeping hedgehog or anteater (see features description in the beginning). Placing them into the middle of a corridor made no sense so they have a weight for corridors = 0.

In animation bellow you can see populating level with fruits and obstacles:

The final generated level is in the static picture below. It takes 6 moves to solve it (right, up, left, down, right, up). Great, after 1-2 minutes of clicking on the Generate button we have a level that looks interesting, and the solution is possible in 6 steps (no one will play levels with solution in 30 steps!), while it is also not a breeze to find it. But … it still could be little bit better. It is this point where our manual entries took place to make the levels nicer.

5. Editor

The generation ended in the previous part. Our editor supports drag and drop, so it is easy to rearrange the objects to achieve a higher level of symmetry like this:

It is important to re-test the level with the solver after adjustments. Sometimes a small change may lead to an unsolvable level. In this case the adjustments increased the number of solution steps from six to seven.

With this manual step the approach to procedurally generated levels forks. If you need or want manual adjustment then procedural generation only works for you as a really big time saver. If this step is not necessary or you think that generated levels are OK then the generator can be part of the final game and players have the possibility to generate future levels by themselves.

6. Final result

Generating levels procedurally saved us enormous amounts of time. Although the generator also generates rubbish – levels too easy to complete or levels too hard to complete, levels full of obstacles or ugly looking levels - it still saved us an enormous amount of time. It also allowed us to make selections and throw a lot of levels away. If we made it by hand it would take months. This is how levels generated in this article look like in the final game:

Thursday, October 9, 2014

Mobile Income Report #4 - September 2014 (monthly income report from Android, iOS, Tizen, bada, ... games)

previous parts
Mobile Income Report #3 - August 2014
Mobile Income Report #2 - July 2014
Mobile Income Report #1 - June 2014
Apps page - Portfolio (what are my assets?)

If you do not want to miss any of my Income Reports you can follow me on Twitter. Just click the button above.

Under Apps page you can see my portfolio. It is list of the games that are then reported in Income Reports. The portfolio is regularly updated with new information (releases for new platforms, new updates, ...)

What I did in September

• On 27th September we finally released our Fruit Dating game on iOS. Game has one universal binary for iPhone / iPad and it is available here at iTunes. Unfortunately, there was bug in iOS8 version (related to screen orientation) so we had to update it immediately. The update is just in approval process. The game is puzzle game with nice graphics by Tomáš Kopecký and music by Matúš Široký

For generating puzzles I coded special procedural generator which helped us very much - really big time savings. Generated puzzles were then manually adjusted to look more attractive. Below is one screenshot from editor and final game. As the procedural generation of puzzles is very interesting topic I will publish article on it in next days.

• believe it or not, beside FAD for Shards we were featured in one more FAD event in the same month! Our earlier game Deadly Abyss 2 was promoted on 30th September at Amazon. The game got average rating 2,7 stars with more than 60000 downloads. The rating is not good. Lot of user were complaining about controls. But, unfortunately, most of them obviously did not see the tutorial. For me it means: in any other game where tutorial is necessary I must force the player to go through it. Other part of users did not like gameplay and lack of information on upgrades. These are right - the gameplay is very unbalanced. Even if you play for first time you can survive for long time. Also the explanation on upgrades in ... none. You can guess from icons, but for the next time we must add clear description.
• I still continue to learn Unity and work on "game from jungle". I was not in team from the very beginning, so lot of work was done before I joined. The intent is to make the game available for mobile devices as well as home PCs. Unfortunately, there were no performance tests before, so while the game currently runs well on PC, it is terrible slow on tablet. I am converting all of the built levels into new model that works with texture atlases instead of individual textures, replaces 3D models with 2D sprites, replaces 3D physics with 2D as well as some inflexible custom animation system with standard Unity one. As I want to do as much of the conversion automatic as possible, I wrote some scripts that do this for me. Here is screenshot of one converted level. See the nice big STOP sign, which is automatically put into places where something went wrong during conversion:

For building texture atlases I am using my SBC Tool, which we used so far for all our games. It is great tool and I have big plans with it. Currently the code inside is old and terribly written, so every adjustment is pain. But I plan to rewrite it from scratch, add some extra functions and offer it for some reasonable fee. I hope it will help me on my indie way. Good point is that I am really using the tool hard, so the functions in it have real value. Here is example of texture atlas from Fruit Dating created by the tool - you can see how nicely it is organized:

Report

And now to figures. September was highly affected by "Free App of the Day" event in the beginning. Stats for paid apps are these:

You can see jump in Shards downloads for Android and iOS. Compared to August earning ($39,7) there is increase to$375. It is great, but from detailed day-by-day data it is clear that October will be poor again. To make reports clear I shifted downloads during FAD events (125000 for Shards and 64000 for Deadly Abyss 2) into table with free downloads.

The most profitable game was Shards again raising its share from 86% in August to 93%. No wonder - thanks to FAD. Fruit Dating is still very low. Let's see whether it will change in October with iOS version released.

For the ads supported versions the September was better than August. The earnings raised from $121,7 to$168,7 (by 38,6%)

In absolute figures Chartboost is still most profitable, but it is loosing its relative position (from 57% to 45%). It is given by increase in earnings from Amazon ads (from $17,7 to$38,0). My Chartboost eCPM is around $2,5. If Amazon keeps its eCPM higher I may consider to redirect some traffic there. So, total income for SBC team in September =$375,0 + $168,7 =$543,7 (+ 336,9% compared to August report).

While Shards performed well in September I am still below my mid term target ($750). So, current portfolio will not probably pay my bills. It is time to move further. The Unity game I am working on is big project, it will not be finished soon, so I have to start some smaller projects beside to keep my indie life. Monday, September 15, 2014 Mobile Income Report #3 - August 2014 (monthly income report from Android, iOS, Tizen, bada, ... games) previous parts Mobile Income Report #2 - July 2014 Mobile Income Report #1 - June 2014 Apps page - Portfolio (what are my assets?) If you do not want to miss any of my Income Reports you can follow me on Twitter. Just click the button above. Under Apps page you can see my portfolio. It is list of the games that are then reported in Income Reports. The portfolio is regularly updated with new information (releases for new platforms, new updates, ...) What I did in August • we released free version of Deadly Abyss 2 at Amazon. The main reason was to touch$6 CPM for newly published apps that includes Amazon interstitial ads,
• I finished some contracted work on game named "McDiary From tomorrow...".  The client came with  game that has mobile part and web part. I was responsible for mobile part, which is simple game in which you are catching falling diamonds into cart. There are 7 colors of them (like in the rainbow). You have to catch only one of each color and you also have to avoid falling stalactites. If you are successful, you can send your resolution to do something to web page. If you connect to web you can read resolutions of other people. The game uses box2D for physics and is available for Android and iOS. As there are menus and registration forms and so on, I had to learn it for Android as well as for iOS. It finally kicked me to dive deeper into both systems. Here are at least some screenshots. The graphics was done by Tomáš Kopecký (flyboj) from www.littlecolor.com - see his work for example here.

• in second half of the August we were preparing for "Free App of the Day" event at Amazon. Yes! We were chosen with our game Shards. And on 3rd September our game was featured. So, next time, in September report, I will refer in big detail on how was it all about.
• there was really serious bug in iOS version of Shards. All iOS 6 devices were crashing. It was reported by one guy from Canada. Thankfully he is also developer, so he understands that coding is complex area and was very helpful. The bug came from fact that with the game I was targeting iOS 6 and above. But some linked libraries were targeting iOS 7 and higher. I previously compiled box2D as static library with iOS 7 target (not intentionally, just did not mentioned). Box2D is not using any iOS specific features so why it crashed? There is some optimization in compiler for iOS 7 that replaces consequent calls to sin and cos with only one call to function that is not present in older versions. So all iOS 6 devices crashed because of calling non-existing function. If you see in crash report this, you have the same problem:
Dyld Error Message:
Referenced from: /var/mobile/Applications/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/Shards.app/Shards
Expected in: /usr/lib/libSystem.B.dylib
Dyld Version: 212.3.2

• still learning Unity ... and working as a part of bigger team on Unity game. Group of guys formerly working on Mafia II game (yes THAT Mafia II!) were looking for programmer for their Unity game.  Matúš Široký, the music composer who composed music for our Fruit Dating asked me whether I would like to join their team. It is really big challenge for me: Unity ... is new for me. C# ... is new for me and I am only amateur in the team, while all others are big professionals. So I feel little pressure in my head... really, just little ... ok, medium... and only sometimes big :-) While I am new in Unity I already set some pipeline for sprites based on my previous experience. With few key presses I can now create big sprite atlases and import them easily into Unity - with custom pivot points, ... - and immediately create prefabs from them. Here is at least one screenshot from the game (the graphics is by Rostislav Vajbar and you can see his portfolio here):

Report

Here are figures for paid apps for August:

Compared to July the number of downloads is almost the same (from 26 to 27) as well as earnings (from $40,7 to$39,7). While iOS are 14 (as in July), the number of bada downloads decreased by half (from 14 in July). No wonder as this OS system is dead.

The most profitable was Shards again. It increased its share from 80% in July to 86% in August. The game has good user reviews and during August we were in contact with Amazon team responsible for Free App of the Day event. Shards was featured within this event on 3rd September and next month I will report the financial impact of it. I am little bit sad seeing Fruit Dating is performing so bad. I like that game as it is original puzzle with nice graphics and music (and some really challenging puzzles). But it seems, that bet on proven concept (Shards - brickbreaker) is better than some original thoughts...

For the ads supported versions the August was bad month. As bad as July. There is only slight increase from $118,6 to$121,7. The income stayed on the same level. I can look at it from positive side: there was no further decrease :-)

Most of the earnings came from Chartboost again. This network has priority in our ads manager. Newly you can also see small amount for Deadly Abyss 2 Amazon ads. These are interstitials and Amazon guarantees $6 CPM for August and September (if you meet some conditions). We have only very low traffic there. But if the CPM remained at this level we would consider to prefer Amazon over Chartboost. Finally, this month there is one more source of income for me. Despite income from apps, which is income for all our team (and only around 1/2 half is mine), this one is all mine.It is$1048 from contracted work on McDiary game.

It is currently far from my mid-term target which is $750. Next? From 1st August there is 2 moth period with guaranteed$6 CPM at Amazon for apps newly implementing their interstitials. I implemented these ads into free version of Deadly Abyss 2, but I do not expect any big traffic.
I am still studying C#, Objective-C and Unity.
There are still some opportunities how to utilize current games - for example convert Fruit Dating for iOS, HTML5, ...
It is almost time to think about new game!