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.

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.

Third Person Camera with Unity


The third person camera

The camera in a game is the eye that the player use to see inside the virtual world created for the game itself. There are tons of different types of camera, but the one we are going to analyze is the third person camera (TPC from now on) which allows to see the main character moving around in the world. In our case it’s a camera that follows the player. Great examples of games that use this type of camera are Super Mario 64, Zelda – The Wind Waker, Metal Gear Solid and Assassin’s Creed.

The purpose of this article is to show how to do a camera system in Unity, with basic intelligence that follows the player and avoids to hit walls by doing auto-adjustments of the distance from the player and the ground as well. The final results are not the best ones and there are certainly other and better ways to do it, and yes, I know there are some improvements that can be done, but the main purpose of this demonstration is to give a simple starting point.


The Unity script is located here. The only things you have to do in order to test the script are:

  • In a new Unity scene add a third person controller. You can use the standard ones
  • Add at least one floor.
  • Add a child GameObject to the controller called “target” for example, and position it where you want the camera to look.
  • Add a child GameObject to the controller called “position” to identify the position of the character: some meshes may have the anchor point positioned differently, so in this way you can decide the correct position of the anchor point. It’s a optional step but it makes things a little easier.
  • Add the script to the camera and put the child objects just created under the camera script parameters in the inspector.

The code is commented and contains also a function to draw lines in the inspector to better see what is going on with the offsets and positions.

Camera position and movements

Without further ado, let’s begin with the fun stuff. The wanted position for the camera is a point that has a distanceUp and a distanceAway from the target identifying a specific point. Obviously if there is a rotation of the character, this point rotate along with it keeping its distances. Now this point is only the wanted position and we want the camera to follow this point with a little of smoothness. Simple, in positioning phase I’ve multiplied Time.deltaTime for a smoothness value.

public void Update()
    //For collision avoidance we need 2 values:
    // the distanceUp of the camera and the wanted position

    Vector3 characterOffset = m_target.position +
    new Vector3(0f, m_distanceUp - m_heightOffset, 0f);

    drawDebugLines (characterOffset);
    m_camPosWanted = m_target.position +
        (m_target.up * (m_distanceUp - m_heightOffset)) -
        (m_target.forward * m_distanceAway);

    collisionAvoidance(characterOffset, ref m_camPosWanted);

    //Positionig and orienting the camera
    transform.position = Vector3.Lerp(transform.position,
    m_camPosWanted, Time.deltaTime * m_smooth);



The collision avoidance

To keep the camera in the correct position and avoid walls that can hide the character or collide, the script makes some tests:

  • Wall avoidance: if there’s a collider near the back of the character or between the camera and the character, the camera takes the position of the collision point (improvable).
  • Ceiling avoidance: if there’s a collider above the character or above the camera, the camera changes its y coordinates to stay under the collider.
//Camera Wall avoidance - raycast from the back of the character and from
//characterOffset to camPosWanted
if(Physics.Linecast(fromObject, toTarget, out m_hitWall) ||
   -m_characterPos.transform.forward, out m_hitWall, 3.0f))
        toTarget = new Vector3(m_hitWall.point.x, toTarget.y, m_hitWall.point.z);

    //Camera Ceil avoidance - raycast from the up of the character and from
    //the up of the camera
    if (Physics.Raycast(transform.position, Vector3.up,out m_hitUp, 1.0f) ||
    Physics.Raycast (m_characterPos.transform.position, Vector3.up, out m_hitUp, 2.0f))
        if (m_hitUp.collider.gameObject.layer != LayerMask.NameToLayer("Player"))
           if (m_camPosWanted.y > m_hitUp.distance)
               m_heightOffset += 0.2f; //adjusting the height


Improvements that can be surely done are:

  • Making a FSM and attaching it to the camera: for example the camera has state like colliding, shaking, bouncing and a following common state.
  • Improving the wall collision not to see parts of the world behind the wall.
  • Adding a colliding sphere to the camera.


Consider also to watching this GDC video on which a creator of the game Journey talks about common mistakes and tips on creating a third person camera.

Source code


I define myself as a creative developer.

From C++ to Python


This post is more theoretic than usual and I will analyze briefly my experience on passing from C++ to Python and what I found interesting to notice when learning another programming language is needed.



After working with C++ for a while, I had to learn Python for the first time and use it with Panda3D engine. Right from the beginning I’ve found myself thinking in C++ style a lot of times while programming in Python, especially for the first couple of weeks. Finally I realized that the first programming language you master (or maybe your favorite one), can affect the way you program and think in other programming languages. Probably this thing is also true for the spoken languages.

When you learn your first programming language, you are learning also all the best practices and the techniques of the language itself. This type of notions aren’t merely syntactical and they belong to “programming theory” or “IT theory” rather than a specific language. But when you starting to master this language you create common mind paths for creating instructions and more complex modules that belong only to the specific language you’ve mastered. Obviously these are my opinions, I’m not an expert in psychology.


Programming mind path

To help passing from the C++ “mind path” to the Python ones to me has been pretty easy after all, but I recalled some struggling at the beginning. Now let’s analyze the two languages to try to facilitate the journey.

First of all, let’s talk about some actual differences from Python and C++:

  • Python is run through an interpreter and is interpreted each time it runs., whilst C++ is pre-compiled
  • In Python, there is no need to declare types explicitly
  • Python uses Garbage Collection whereas C++ does not.
  • C++ supports pointers and low-level memory management.
  • C++ is a statically typed language, while Python is a dynamically typed language.


As you can see in the previous short list Python and C++ are both object oriented languages but they are ruled by different philosophies. Beside these strict differences that are also some intrinsic principles and styles of coding that belong to the specific language and find place in the deepest part of a programmer’s mind, the mind paths. This more “abstract” side of the differences of usage is difficult to manage at the beginning and I think it takes some time to deal with it.


Things to remember

Fortunately the syntactic side of the differences is less deep-rooted and can be managed more easily: there are only some little things that can make you struggle, especially at beginning of the switch. I’ve listed a series of things I found useful to “easily” switch from C++ to Python.

  • Indentation and curly brackets: in Python there are no curly brackets to define a block of code but instead of this it use indentation
  • Loops with float: in Python you can’t easily define a loop with a float increment
  • Data structure declaration: Python has built-in lists and dictionaries and you can declare it simply with “[]” for lists and “{}” for dictionaries
  • There’s no separate char in Python
  • No switch: Python doesn’t have switch statement and you have to implement it with if, elif blocks
  • While-Else: the loops have the else statement which allows to do something when you go out of the switch
  • Use less lines: Python allows you do simple things in less lines than C++. For example: a = 5 if b == 4 else 6
  • Python allows to write if statement in a single line inside an assignment. It’s not mandatory to use this feature but since you have the chance, why shouldn’t you?
  • Function pointers: in Python there are no control on pointers in general, but since the assignment works on reference, you can do similar things. When you have to use something that works like a function pointer, all you have to do is to declare a variable and assign to a function name (without the brackets) and that’s it. Since everything is a class in Python (even functions) and everything is “callable” when you have to call the function pointer, all you have to do is to call the variable.



  • A Byte of Python – Swaroop


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.