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.

GGJ 2018 Post Mortem


Game jams are events in which the participants have to create a game in a certain amount of time. In the Global Game Jam (GGJ) this span of time is 48 hours and few weeks ago (the last weekend of January) there was the annual GGJ.  Once again I decided to participate to it in Milan location, even if I live in Trento and even if Trento was a jam location for the first time this year. I learned too late that I could have gone in Trento for the jam and I’ve already bought train tickets, so…too bad, see you next year. After the jam is done, I tend to write a “post mortem” of the experience so, here it is. If you haven’t red the previous ones, go check them out HERE.

In terms of number of participants, the Milan location was at the third place in the world, and like I always do, I’d like to thanks the organizers (Pier Luca Lanzi and Daniele Loiacono) for all the patience and the competency on handling such a big number of people.


The jam experience

Like last year, I went to the location in the afternoon. Sadly, my train had forty minutes of delay 🙁 so I arrived pretty late. During the trip, Emanuele (a guy from the team of 2016 GGJ team) contacted me, proposing me to form a team together. I said it was a great idea, but since my train was delayed, I told him to form a team without me and I would have joined the team once I got there. Next year I think I will go on the venue in the late morning, because in case there will be train delays I will still be able to arrive in a decent time, and have all the time to join or form a team.

During the jam I felt like I had the grasping of everything because I thought that was my third time, I have became a pro just for that reason, but I have to admit that I was totally wrong. I faced the jam with a wrong mood, without focusing on the fun part of creating a game and interacting with people that have my same passion. I faced like it was a normal task I have to face every day in my daily work. Next year I will try my best to find the right mood, great lesson learned though.


What went right

The theme: I really liked the theme of this year which was “transmission”. It can be interpreted in a lot of ways, really. It was very enjoying to cover all the aspects of a transmission in a game,especially in the initial brainstorming session. We ended up using the transmission theme as an alien transmission of a signal that the player has to understand and respond in the correct way.

Good team skills: My teammates this year were very talented and experienced. All of them had already done a game jam or they develop and collaborate in the creation of video games in general. So great level of preparation, the roles were very defined and the skill coverage was great with one game designer and programmer (Andrea), two programmers (me and Luca), three visual artists (Irene, Curzio and Emanuele).

What went wrong

Development coordination: Even if the team was skilled, the overall coordination (of the development side) seems to lack in synergy. From my side, I realized that I’m becoming used in writing code that no one reads, so the final result was not the most readable code for other members. I hope this will not become a bad habit. In addition, some of the guys had a little framework to facilitate things, but we ended up not using it as the main framework, and it was used only by them, creating maybe some confusion.

Lack of concentration: I don’t know why, but this year I had a lot of troubles concentrating during the development process, and I hadn’t the grasping of the big picture all the time. Maybe this lack was due to the size of the team, but right now I can’t tell exactly why.


Tips for the future

My personal tips for future jams are:

  • Grasp the big picture.
  • Don’t focus on complexity but focus on depth (game design tip).
  • Try to have, right from the start, a vision of what are the game goals.
  • Think more about inclusion.


Final result

The final result of all our efforts is Space Diplomacy (lots of infos here). We are considering to resolve some bugs and maybe publish it on Google Play and/or Amazon Appstore.


If you are interested on game development and game design I have a series of posts in which I show my progress of the development of a mobile game Steady Drop. HERE!

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.

6 tips for better game design


In this post I would like to give you some basic game design concepts to create better games and videogames. This are some of the notes and lesson I’ve learned watching talks and, more importantly, creating my own games. Coming from a programming background I tend to not give the proper importance to game design, so I’ve decided to give it the right importance and to try training myself to use game design concepts more easily, studying and going on depth in more and more aspects.


01 – Expand your background

The first advice I can give you is to expand your background, I mean your general knowledge. Since game design involves a creative process, the more things you know, have seen, have touched, have experienced, the more you can pop out ideas. Starting doing new experiences is a good way to start. You can start watching more films you haven’t watched yet, read more books, visit some art expositions, etc…Game design is creative but is also ruled by some essential rules and best practices, so to understand it more you can play different videogames and try to learn from them, for example how the thing works on the same genre of games, how the controls works, progression and so on…


02 – Try to give more, not just gameplay

Once you have a good mechanic and your game is fun to play, try to give more than that by creating a world to put the player in, work on immersion and flow and give the player the right space to breath. The player has to acquire the will to play your game, once again to feel new sensations every time he plays. Giving more than a clear and guided goal but a more complex and variegated set of goals or purpose, can help to create the feel of an infinite play.


03 – Remember all types of players

When designing a game, keep in mind to visualize all possible scenario about the type of operation you allow and what the players can do with it. On this matter it is useful to remember yourself all the type of players. There are a lot of different types of players and some famous game designers categorized them in different ways, but the way I like the most is “The four types of players” (explained HERE). Try to design a progression that is suitable not for only one genre of player.


04 – Tune carefully your challenges

The progression of the players is one of the most important things that are not visible but are there, and the player can feel it very well. I mean the progression can be felt but not directly seen. Its sensation property makes the progression a crucial thing, and for this reason you have to carefully design the player progression, with the right challenges at the right time, and the gathered skills have to keep the mind flow of the player active. And remember this: easy to learn, difficult to master.


05 – Social Games

When designing a social game, think at all the tools you give to become social. Probably all of them are communication tools. Every communication tool lets the player use the tool in different ways. If you give too much space, you probably have to face problems of misuse of the tool. In the first place, you have to find the right tool for communication that can avoid misuses and secondly, think a proper way to both punish the misuse and reward the right use, in a fair way.


06 – Decide: game or market

A game can be a pure expression of art and technical skills or can be a mere selling product that has to satisfy the market in some specific ways. For me both sides are a little risky to make and they have both pros and cons, but I think that the truth is in the middle, as they say. A good game designer should find a good compromise between art and selling purposes.


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.

GGJ 2017 Post Mortem


Once again I’m going to describe and share my experience at the Global Game Jam in Milan, that was the world’s fourth site in terms of participants in this edition, even if in Italy there was almost 10 sites around the country. I have to renew my thanks to the organization crew of the event that did a really good job for both organization and security matters.

This was my second participation (last postmortem here) and this time I felt to be more prepared than the first time. Logistically I already knew the venue and how the event is structured, so my organization for the event was all ok and smooth. On the site I’ve found a lot of good friends and passionate people  about videogames, willing to share their games and thought about game development, some of them were also very skilled and professional people. Like said, I’m going to analyze my experience on this GGJ, instead of focusing on the game we made.


The jam experience

This year I decided to go on the venue in the afternoon. The morning conferences are very interesting but since I had to travel for 3 hours from Trento to Milan, I decided to skip the morning session and rest a little more. Once arrived and registered, I started to walk around and look at some of the games from the guys of the Politecnico. Like the first time, the team building was very random: while walking around, after refusing some interesting offers using Unreal Engine (I don’t use Unreal and I think it’s not a good choice to learn how to use it on a jam), I found a game designer who was searching for a team. Ok, we were in the same situation and we started to search for an artist, and the search was literally 2 seconds long. Then the artist found some sound designers. At that point we needed another programmer and we found one programmer and another one with a game designer badge who joined our team. Our team was good to go and we went to the theme revelation conference (like always, one of the best moment of the jam) and then jumped into the development for the following 48 hours. I have to admit that the spirit and the mood of your jam can drastically change along with the components of your team 🙂


What went right

Self wisdom: that was my second GGJ and my third game jam, so I faced all the phases of the development with some extra wisdom, avoiding the common mistakes and the mistakes I’ve done in the past jams, and the fact that I was the only member of my team who already done a game jam, was pretty vital.

Right Idea, very fast: we found some decent ideas for the game pretty fast, with a well-ordered brainstorming. We had the right inputs from the others members, using different phases of brainstorming, and with the right time for each phase we didn’t loose much time or find stucked.

Good rest: This time I decided to schedule the rest during the jam in a proper way. I worked every day to 2am and rest until 7am. Five hours are a good compromise to me, and I didn’t felt exhausted at all.


What went wrong

Bad task assignment: As the only one who have already participated to a jam, I had the “privilege” to coordinate and assign tasks to the other two programmers. I started with the first things that came to my mind and assigned them, but on second thought I should have thought to the big picture and assigned tasks for a certain aspect instead of some braided tasks that have almost compromised the project.

Engine issues: In the middle of the jam we encountered a little problem with Unity (the causes are still unknown). There are some project files corrupted that they forced us to waste a lot of time in redoing some tasks. Fortunately they weren’t dramatic, and we solved pretty fast.


Tips for the future

My personal tips for future jams are:

  • (again) give more meaningful choices to the player.
  • Think more to different game genres that are suitable for a jam
  • Explore more games from the previous jams to get the feel of them


Final result

The final result of all the efforts is Make Babushka Proud (lots of infos here). We are currently working on it to resolve some bugs and maybe publish the game for Android in the Play Store. I leave the time lapse of the “making of” and link for downloading the game on

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.

LD36 Post Mortem


With a little delay, I will write a short post-mortem for my first Ludum Dare I’ve ever done.

Preparing for the jam

I live in Italy and August is a “ghost month” since everyone are in vacation… After some unfortunate team searching I decided to partecipate to the compo (which lasts 48 hours) also because the jam was 72 hour long and I had to work until Monday night which was not possible for me. The main rule of the compo is that all the work has to be done by one person, so I jumped in the compo by myself.

Since I was doing all the work, I started to set up my workstation at home and my software environment for coding with Unity, making 2D assets with Gimp, making sound effects with Sfxr and making music with LMMS. Ok ready, all set. Let’s start! The theme? Ancient technology.


What went right

It was my first time on doing all the work (programming, art, music & sfx) and I’m pretty happy on how I faced this challenge, but not completely on the final results. The workflow I used was very smooth and I scheduled all the task with meaning. I’ve the opportunity once again to test my skills and expose all the things I’m good at, and also the things I need to work on. After all the experience was very challenging in a good way and I’ve learned new concepts that I can reuse in my future projects.


What went wrong

First of all the time, but not the remaining time. I mean the time zone: in this jam everyone starts at the same time regardless of your time zone, and since I live in Europe I started my jam at 3am. So the lack of sleep influenced the rest of the jam for sure.

Secondly the theme was a hard one for me, so I struggled in the beginning for finding an idea, and I end up with using a poor game-logic idea. At some point during the event I thought to quit the jam and rest, I felt really stressed and I wasn’t sure if I was able to continue, but fortunately after a little nap I carried on.

I was recording my screen to do a time lapse (like I did for the last GGJ) but sadly after some hours of work since I thought to quit I stopped the recording and I hadn’t turned on again, so no time-lapse video this time.


Tips for the future:

  • Concentrate more on the theme.
  • Try to come up with a game logic that has the theme involved, not just mentioned.
  • Spend more time on choosing the graphic style.
  • Sleep more during the event.


Final Result

This time the results of all the efforts was Titus Discovery (ld36 entry). I think I won’t work on new features or bugs, we will see.



I define myself as a creative developer.