Steady Drop – Log #13 – Releasing


In this post I will talk about on how I started to acking everything up for releasing the game on the Play Store.

Reward system and AdMob

Since the beginning of the project I’ve always thought that Steady Drop would have been a free game but that there will have been some kind of reward system based on ads. The model I’ve always wanted is like Three game that gives tries if you watch video ads. The more you watch them, the more tries you have. So, to implement something similar to this model, I started watching different types of ad system. I initially came across to UnityAds, because I thought that would have been simple to integrate (since I’m using Unity), but I wanted something more standard and not too related to the engine I’m using. So I chose AdMob, that has become the Google standard for all kinds of ads on mobile platforms. It’s very easy to integrate, even in Unity, and there are a lot of official guides and useful resources on how to use it. I will integrate UnityAds maybe later, but for now I will stay with AdMob.

The integration was very easy, also because I was already ready to have a tries-system that makes you play only if you have tries left; the only thing missing was the way to recharge them with the ads. I’m also thinking on having different type of reward the integrates with the player experience, but for that I will have to implement more game mechanics, like speed boosts, recharge gravity stop time, invulnerability and so on.


Internal tests with Google Play Console

The time for the release on the Play Store it’s finally coming but I wanted another test with real users. So, while I was exploring the Google Play Console, needed to submit your app on the Play Store, I saw that the tool can handle different versions of your app, and in particular internal test version, visible only by a selected group of users. The system allows you to create different groups of testers and they can test the last app uploaded as the internal test version. This system is very easy to use, but maybe it lacks a bit on a standard way to have feedback report from testers. They had to call me or reach me in some way to give me feedback or to report some issues.

This phase was also useful because, in order to upload the installation file (apk) correctly, it has to be signed, so I had to learn how to sign it in the Unity editor, a very easy process, by the way. Once this internal test phase is considered done, I will create the Play Store entry as a Production version, with all the screenshots and descriptions. Then I will have to do some marketing.


Graphics Improvements

I will show you just a quick overview on how the game visually changed over time, since the first prototype. I’ve added some little details that are also functional to the gameplay, like the triangle grid that moves in parallax, so the falling movement is more evident.


In the next post I will talk about on actually releasing the game on the Play Store. Stay tuned 🙂

I define myself as a creative developer.

Steady Drop – Log #12 – Music & SFX


In this post I will briefly describe my process to create sounds effects and music for Steady Drop. Nothing about development or code this time, sorry 🙂


The recording setup

Problem 1: how do I record sounds?

I started recording some sounds with my smartphone with an external mic plugged in. To achieve the best result I could with my “great and professional” gear, I used a folded blanket placed over the bed like a little camping tent, to make small recording room with no reverb, no echoes and limiting outer noises. Problem solved!


Problem 2: what do I record?

I literally looked around in my apartment and grubbed some random objects I thought could potentially produce some noise, like old CDs, some packaging boxes and some kitchen tools. With these I will produce sounds manipulating or letting them falling on a surface while I have the recorder on. Problem solved!


Problem 3: how do I mix?

To clean and mix the recordings of the sounds I chose Audacity which is a very popular software used for audio recording and editing. In this case I will use it only for the editing part, removing the background noise and isolating the individual sounds.


The sounds

I started with some weird high pitched sounds and some low-deep “blocky” sounds. I don’t have a list of sounds I have to produce in the game but I want to create like a little sound library that I might reuse in the future. If I need a very specific sound for Steady Drop I can record it later. For this first phase, I want to adopt a broad focus on sounds to narrow it step by step and to choose and produce very specific ones. However I will try and add sounds only if the gameplay needs it without putting sound effects for everything.


The Music

Meanwhile I started creating some music track with SoundTrap which is a very interesting site that provide a DAW, but you don’t have to install anything on your PC, it’s all onlineThey have different paid plans but you can choose to use the free plan with the only restriction on the number of projects, number of instruments and number of loops. So for now I’ll stay with an unpaid plan. For Steady Drop I want short music tracks (at least three) possibly suited for looping. The genre I want, I call it “dreamy electronic”, which is electronic music with a lot of echoes and delays in the pads, slow paced, clean and minimal percussions. I will try my best to achieve something like that, without going crazy, I hope.


Stay tuned for future posts of the series, and if you are interested on other post series don’t forget to visit the blog main page 🙂


I define myself as a creative developer.

Steady Drop – Log #11 – Statistics


Collecting game data for simple statistics

After the previous iteration I’ve done on graphic and UI improvements in the game I started to think about collecting some data from the game that comes from the player actions, in order to have a sort of statistics screen that the player can check from time to time to see his progress, and furthermore in this way the game can collect useful data to base some kind of achievements system in the future. For example there will be an achievement for falling through 100 game units (or meter if you want) or for playing 500 rounds. For the achievements system, I’m planning to integrate some native stuff for Android and iOS (Play Game Services for Android and Game Center for iOS), starting with Android, obviously.


Implementation of the statistic system

For the implementation, I chose to create a single class that handles all the requests to store and get the data collected. The data we want to collect are mostly integer numbers handled in different manners. For example, if I want to memorize the high score, I have to tell this entity that the data tagged as “high_score” has to be saved as MAX of the previous, and on every game over I have to memorize the current score. In this way, every time I memorize a new value, the entity keep the max between the previous and the current values. In a similar way, I can memorize a counter (like to count the rounds played). What I have to do is to memorize a value 1 every  game over.

This entity relies on the DataMgr to load and save the data. The DataMgr itself is an interface to read and write values from the physical memory of the device you run your Unity application. Here some snippets I took from the StatisticMgr.

//Load and save data from the device
public void loadLocalData() {
    foreach(KeyValuePair<string, StatData> entry in dataBank) {
        string readData = DataMgr.readData(entry.Key);
        if(readData != null)

public void saveLocalData() {
    foreach(KeyValuePair<string, StatData> entry in dataBank) {
        DataMgr.writeData<double>(entry.Key, entry.Value.value);

//For store a new value in game
public void storeNewValue<T>(T _value) where T: IConvertible {
    Double dValue = Convert.ToDouble(_value); //numbers stored as double
    switch (mType) {
    case(StatDataType.PLAIN): //saved without logic
        value = dValue;
    case(StatDataType.SUM): //saved as increment
        value += dValue;
    case(StatDataType.MAX): //saved as max (if the current max is lower
        value = Math.Max(value, dValue);


Where is the sound?

I’m still planning to make sound and music for the game but the sound iteration will take some more time. I could pay somebody to make music and sound for me, or take it from some Creative Commons site, but since I have a little knowledge of music theory in general and in the past I was into recording, DAWs, MIDI and stuff, I want to try to harness my past passions to make something out of it, before asking for external help. What I have in mind, though, is to record some real sounds and manipulate and combine it to create the sounds I need.

Stay tuned for future posts of the series, and if you are interested on other post series don’t forget to visit the blog main page 🙂


I define myself as a creative developer.

Steady Drop – Log #10 – Visuals

Deadline changes

I had the milestone to complete the next development iteration of Steady Drop at the end of march 2017, but for the lack of time and for the efforts put in other projects (like the game I made for the Global Game Jam 2017) I’m forced to postpone this milestone and to go a little bit further with the deadlines. The project is still growing, it’s just I had little drawbacks, that’s it. I’m still adding improvements here and there, most graphical ones, and I have some “big” features I want to add before the next deadline. Like I said, I fixed most of the bugs I received from the alpha-testing phase and I’m still integrating some improvements based on the feedback I had. Goos news after all!

Visual improvements

I reviewed the color palette of the entire game, so I changed every color a little bit to make it more glued together (I used a palette generator) and to give more sense to the overall experience. But I completely changed the enemy colors: they was very similar to the avatar of the player but now, as you can see, they have their own color, and it’s more clear to the player that’s this shapes are not something related to the avatar he’s guiding down.

Another two visual improvement I’ve added are the trail behind the falling avatar and a particles generator on the bottom of the screen, they both give more sense of movement.And last but not least I’ve added a dynamic gradient un the background. So here you can see the differences between how it looked like and how it looks like now.


Next steps

One of the things I want to do next is to add some visual feedbacks when you lose health (or zero-gravity time) and to make some enemies a little bit more alive with some scale animations. I’m also planning to rewrite part of the UI system and replace the UI of the main menu, because I made the current placement just for the prototype, which has limited menu choices.
Next I will have to modify the tutorial (again) because I don’t like the current one, and to work on some game balance parameters like the score multiplier…a lot of magic numbers 🙂 After that, I will start to research how to integrate and produce sounds and music. It will be fun!

Just a reminder, if you want to play the alpha, just download and install this file. Steady-Drop-Alpha

I define myself as a creative developer.

Steady Drop – Log #9 – Alpha Ready

Alpha released


I released the alpha of Steady Drop! It was a silent release (sadly I’m not a marketing guy :-P), which I’ve done only for people I know and for members of some Facebook groups I’m in, but It was the right time for a first slot of tests.

Right after releasing the alpha version, I started to receive a lots of useful feedbacks by the “alpha testers”. I gave them the possibility to leave a feedback in a traceable way (with a Google Form) or in a more direct and fast way. One of the last changes I’ve done right before the release was to add a button to leave a feedback on a form I made just for them. With this form I tried to gather all the informations I needed in order to progress the development in the right direction and make Steady Drop more playable and easy to use.

After all, seeing my game from another person’s perspective is the best way to find out some flaws which are invisible to me and just view the experience from another angle I didn’t considered before. Seeing what another person sees while playing your game is invaluable, and the more you have the possibility to let this happens, the more your game can improve. The only (little) drawback is that it’s required to filter in some way and extract the right signal from a feedback.

Thanks to all of the feedbacks, I listed a number of fixes, improvements and just some things I wanted to try, that I added to the task list I want to develop for the next step, which is a release of a beta version. I will also try to remove the sense of prototype while playing the game…it will be a hard one.

Right now I’m not putting so much effort on new features or bugfix, because I have other little projects I want to finish and publish (like this one). Right after finishing these little projects I will spend more time on this project and I will bring the development forward. If you want to try the alpha version of Steady Drop contact me 🙂

I define myself as a creative developer.

Steady Drop – Log #8 – Tutorial

The value of the tutorial

It’s been awhile since the last devlog and from there I’ve been struggling so much in the project to create a proper tutorial.

At some point in the development (probably too late) I started thinking a way to explain to the player the main mechanics and  what are the goals of the game. There are a lot of ways of doing that (I’ve done my homework) and I thought that a short tutorial, at the first try, before starting the game, could be a good way to proceed.

I wanted a tutorial to explain the input basics and the main mechanics to the player, so in this section all the points and the game logics (talked here) and the spawn logic (talked here) have to work in a different way.


I started to work on this with a specific approach where the entire tutorial is a level slot (here I talk what I mean for slot) but this wasn’t really suitable for what I had in mind, so after almost forcing myself to try and develop a tutorial system that works in that way, I realize that it ain’t gonna work, so I deleted everything and started the tutorial system from scratch. After some time and some struggling, I finally have a tutorial system that “kinda” works. It’s still pretty rough but It does its job so I can refine it after the launch of the game alpha.


The biggest advice I want to leave is to consider designing the game and the code with a tutorial in mind, if you want one. The fact I didn’t think at all to the tutorial at the beginning of the development made me waste a lot of time to refactoring my code and redesign the levels. So, keep the rules simple and keep a simple way to explain it to the player right from the beginning of the development.


I think the alpha version of the game will be available in early january 2017. Stay tuned 🙂

I define myself as a creative developer.

Steady Drop – Log #7 – Project Structure


In this post I will talk about how I put everything together and a little bit of code management.

Code versioning

Let’s begin with some things to remember: use a versioning system…and again, use a versioning system. I can’t stress this enough. Really, for every project you’re working on, use a versioning system like Git, SVN or Mercurial. It really helps keeping the project managed and it’s necessary for collaboration with other people. If you don’t know what is a repository you can start here.

My habit is to use repositories especially for work and since I saw more benefit using it I decided to use them on my side projects. For Steady Drop I used Git on BitBucket with only one branch (for now) it really helped me also giving more value of what I developed and I will develop.


Project structure

In the beginning the files are not well organized and the project was a little mess. At the time the code was really messed up and disorganized, since I started from a prototype. After some refactoring sessions, the code was more readable and clear but I still had one problem: the organization of the files (both scripts and assets).

I started to re-organize the project (with some Unity guidelines) doing a lot of folders to separate logically the assets and the scripts, but I wanted more for the scripts. So, I started to separate the scripts and to do a lot of folders. I was not sure if this approach could work out but then I started to separate the “core” scripts and the game specific scripts, finally giving a more meaningful project structure.


Reuse core modules

All that core scripts are inside a specific package so in the future I can take this package and use it in another project. But what is the best way to do it without going crazy on maintaining a “fork-like” package? Recently at work I started to use the git submodules which basically are repository that can be inserted in an existing repository (like an inception of repositories 😀 ), and I thought that I can create a module with all the core stuff and reuse it in different projects. This change will be the next “project-side” improvement and since I have already experience with multiple submodules in one project so, it will be a piece of cake to set things up for only one module.


Alpha is coming

The alpha of the game is going to be released in the next couple of months. The best way for me to release it is to give it to a restricted set of people, (like friends and relatives) and gather feedbacks from them. Then I will iterate once again to make things better and put some others features in the game to create (some day) a beta version.



I define myself as a creative developer.

Steady Drop – Log #6 – 2D Art


This post on Steady Drop development is about the art process and choices I’ve made.

Minimal style

During the pre-production phase I wrote down all the possible styles I could develop for Steady Drop, and like I said in one of the first posts, I was thinking to give to my game a cartoonish-like style, similar to Cut The Rope, just to mention a famous example. I finally chose a minimal style in order to emphasize the gameplay and reduce the distractions and also because it is easy to maintain.

Since the style I wanted was really simple and minimalistic, I started to create the assets on my own. I’m not an artist, but this type of style is something I’m able to work with. I wanted the main focus to be game logic and gameplay so I eliminated the unneeded and went back to the roots: the shapes and the colors. I think that sometimes all we need to recognize an object is its shape and its color, so every element in Steady Drop has its particular (geometric) shape and its inner color. I regret a bit this choice but it makes possible to speed up the assets production and allows me to concentrate more on the development.


The need of using a vectorial format

Having a minimalistic and geometric style for all the graphic assets led me to think using a vectorial format. The pros of using a vectorial instead of a lossy format are quite important on both technical and design side:

  • Smaller file size.
  • Changing resolution without loosing details.
  • The sharpness of the shapes are always very neat.


Obviously this pros are applied for my project, you don’t always need a vectorial format. I grabbed my favourite vectorial editor and I created some ideas of objects and actors of the game. And after some concepts and a lot of inspiration sessions, I came up with the (almost) final version (posted here). The problem at this stage was: I could possibly take advantage of a vectorial format in Unity?


Using the SVG importer

To solve this issue, I tried to find a way to use natively a vectorial format in Unity but unfortunately Unity (version 5.4) does not support vectorial formats, at least I haven’t found a native support. So, I started looking on the assets store and I found this (SVG Importer). Basically this tool imports a SVG file and convert it in meshes (I think one for any visible closed path), keeping the quality of the shapes at any resolution, I thinks even retina displays. The integration was very easy with no code required and the results are very good and I’m happy with it. I’ve only one little issue on replacing a svg texture at runtime but I solved it with a little workaround.


The next post will be on putting everything together and on code management. Stay tuned 🙂

I define myself as a creative developer.

Steady Drop – Log #5 – Game Input


Gyroscope handling

I want to talk a little bit about the first things I developed when I got the idea for Steady Drop. Just from the beginning I had this idea to use the gyroscope data from a mobile device and to do something with it. I started developing a first prototype which uses the gyroscope quaternion given by the “attitude” property and elaborating it to get the gravity direction using euler angles. The class doing all this stuff was (and is) called GyroTilt and for some time the name of the game/project was GyroTilt until I came up with Steady Drop. For a prototype it worked fine, and I started developing the game on top of this logic. At the time I wasn’t testing everything so often on a real device and for a reason or another I finished up screwing part of the logic and all the rotations were broken.

Recently I’ve changed the method to compute the gravity direction by simply getting the gravity directly from the the gyroscope class. This property returns a vector (with magnitude one) with the direction of the gravity in world space. I can take this vector and go on and use it with the rest of the logic which wants only the gravity direction and ignores how it is computed. Unexpectedly this gravity vector is much more stable that the attitude and I think it is not more CPU expensive that the other.

One issue I will have to resolve will probably be the device compatibility, since I’m developing this game for Android, there are hundreds of different devices with different mounted sensors. I haven’t tested my game on different devices yet, so I’m thinking to give the game build to some friends and people who can test it out, a sort of “closed alpha”.


Gravity direction, now what?

Ok, now that I have the gravity direction I use it for adding the increasing force (like I said in devlog #4) with its logic ruled by user inputs, and for rotating the object. To rotate the object correctly, I tried in the first place to use the RigidBody rotation caused by the force I add, which is nice but I could not find the right level of responsiveness I want. So I decided to freeze the rotation on the RigidBody component and to apply the rotation manually to the Transform. In this way the rotations are very responsive and the fact that I’m not using the rotation from the RigidBody is not a problem, since the physic system is all custom and ruled from my scripts.


Future uses

Since now the gravity direction seems stable I’m thinking to use the gravity for different purposes that can add gameplay variationsRight now the only object that react to gravity is the avatar of the player, what about some special enemy that reacts to gravity? I’m not sure to use the pendulum that I have right now, but I’m thinking a new type of walls maybe, that reacts to gravity. Maybe the gravity can affect some physics parameters of an object or an obstacle. I will decide what to do about this matter in the future, surely after the beta release.
Stay tuned for future posts 🙂

I define myself as a creative developer.

Steady Drop – Log #4 – Game Logic


Like I said in the last post, this one is about game logic.

I think games can be a pretty good simulation of the real world, and so far they do a really good job in this, even if most of the times there are only approximation of physics rules. Again, they CAN be a simulation but they do not HAVE to. So, in my case, I choose not to follow the stricts physics rules of gravity but I defined my own one.


Gravity logic

What I have at this point is only the gravity direction ruled by the device orientation. The amount of gravity force is determined by a simple algorithm: starting from a base multiplier, I add a certain value to this multiplier every N crossed unit and then I multiply the gravity vector for this multiplier.  In this way the speed increases in a sort of exponential way.

When the player stops the gravity, current force and speed are saved and they are applied once the player release the stop.


Point Logic

Let’s start with explaining the basic idea. I wanted a scoring system based on the distance that increases the points every N crossed game unit. The amount of increase depends on different factors. It depends on the gravity multiplier explained above and on a point multiplier that is progressively lerped to zero when the player stops the gravity and lerped to a maximum value when the player doesn’t stop the gravity. In this way a long stop equals to a smaller point increase, especially for high gravity multipliers. If you stop at the beginning there’s no big deal because the gravity multiplier is still low.

To do a recap:

  • Increase points every N crossed game unit .
  • The increase depends on the gravity multiplier and the elapsed time .
  • The gravity causes speed, which implies that the points are added more often.


Obviously, user-side the only things to be told are to keep falling as smoothly as possible and try to avoid to stopping too often. It seems a complex system but it’s not and it adds a certain level of unpredictability for the player.

The health is the maximum gravity stop time

The game world:

  • leaves room to the player to do basically whatever he wants
  • it’s “analogic”: the actions are not sampled or fixed


I need a system to connect all the aspects (gravity, health, score) together. I started to think about something that can affect the gravity, the points and the gameplay as well, and I think to bring in the time, too. We can stop the gravity with all the effects on point multiplier discussed earlier. But for how long we can stop it? Well…for a time related to the remaining health of the player! When stopping the gravity, a bar shows the player that the time is decreasing. When the available time is zero the time it starts to load but the player can stop the gravity again only when the time reaches the maximum value (the remaining health). I came up with this idea pretty far in the development but it is something that connects everything and I developed it.

This kind of relationship between stop time and health holds up everything giving importance to every aspects of the gameplay.

For visualization I choose two overlaid bars. When the time is increasing or decreasing the player sees the above bar that scales down or up revealing the bottom bar that represents health. In the image you can see the bar that represents health (green) and the stop time bar (lime-yellow) when the time is decreasing.

Schermata 2016-07-10 alle 14.03.30


This covers pretty much everything on game logics and since this time was a lot talking, I decided to give something visual as well. These are the current versions of the game actors. I think they will be the final ones, more or less. You can see the color palette I decided to use too.




I define myself as a creative developer.