Review from

A few weeks ago a member from contacted me regarding a possible Zink review. I have to confess that I was a bit skeptical about it at first since I’ve been approached by some so-called reviewers before about what turned to be payed reviews (I’m ok with that but usually isn’t presented as clear as it should).

The review is well structured and it took some time to write for shure, that’s something to notice. It has a demo video too! Although it’s obvious that they spent a while playing the game, for some reason they missed the main feature: the Creation-Sharing of levels which really is the core of Zink. I’ve contacted them about it and they seemed receptive about check the review.

Anyway, since they are so kind to support small studios as ours I feel right to write this post about them. The communication has been easy and direct in my experience. I will let them know about my next release for sure!

You can find the review here

Using Texture Packer


Texture Packer allows to save memory by packaging sprites into a single spritesheet in an optimized way. This is quite important in older mobile devices which use to mount small amounts of RAM.

Curently we are using one spritesheet for the gameboard and another one for the rest of the sprites. We’ve found that, since our gameboard is created at runtime, by using a single spritesheet the amount of Starling draw-calls is reduced drastically improving overall performace nicely.

Furthermore, TP allows to correct typical issues when packaging textures such as “half-pixel” graphical errors by using extrusions and custom paddings. I totally recomend you to try it!

Since they are kind enough to support small developers as ourselves, I’m applying for free license of this great piece of software.

Zink for iOS devices!

We’re happy to finally announce the iOS release! Download Zink for iOS devices!




Zink en català

foto: El Mundo

foto: El Mundo


Catalanes, catalans:

Ens plau comunicar-vos que podeu trobar la traducció catalana de Zink a l’actual versió de les stores.

Agraïments especials a la Natàlia Estruch que ens ha corregit els textos (també en castellà).

available on amazon


Hey Ho, Let’s go!

It is alive! Zink is, finally, out there!

By now, only downloadable in Android devices. We’ll let you know when will be available for iOS devices (we are currently under Apple review).

If you want to become a zinker, don’t hesitate:

available on amazon


Look, this is you! Thanks!!


The right amount of craziness


Some time ago I started dreaming about working on the Zink development. This is fairly common on people doing the same thing for a long time at some intensity. However, some thin line was crossed when I star dreaming COHERENTLY about work. I mean, like coherently boring! Like: “What about changing the order of the buttons of the settings menu” or “we should add more levels to the story mode”.

This phenomenon have been happening sporadically, but I kind of started to worry. That made me step aside for a moment and take a picture of my current professional life.

I really enjoy doing what I do. Even though I have to live with the Damocles sword of the lack of resources hanging over my head, the timelines and the number of working hours, I found out that I don’t need vacation anymore. Don’t misunderstand me, I mean that I don’t need, not that I don’t have or enjoy them. That never happened to me before, all my past jobs eventually drained my energy tank.

Some will say that I don’t really have a job since I can’t live out of making games at the time. Maybe they are right and all this nothing but another kind of dream. Some will say workaholic… I’d like to think that this is more about creation than about ambition.

Anyway, I like to think that some level of obsession in what you do can be like drugs: used wisely, drugs can expand your being and act as creativity triggers but crossing the line will take your life away. This is the line I am considering when I find myself dreaming coherently…

Obviously this is ultimately a subjective experience and may not be lived the same way by other developers or stuff creators. However, I can say that I’m living the greatest professional adventure in my lifetime. A (sabbatical?) time during which I am learning a lot. No only about technology but also about myself and my capabilities. That may be what I strangely enjoy the most: being able to commit mistakes and realizing after the downer that I gave all I had and something more has to be done. Is kind of peaceful, having no one to blame to.

However, as a friend told me, by dreaming small, at least I can accomplish my dreams several times a week!




Cuando tu mayor coste operativo son impuestos…

No preguntéis como, pero Zink se desarrolla con presupuesto sub-crítico en España. Muchos favores, pocos lujos y toneladas de trabajo. El caso es que nuestro coste principal es la seguridad social del los 2 únicos trabajadores/administradores de la empresa. A dia de hoy (y esto suele cambiar muy a lo loco…) los costes de SS suponen unos 630€ en total.

Como aún estamos en desarrollo y no hay producto acabado ni beneficio, estos gastos son un verdadero lastre en el día a día. Sin entrar en legislaciones que no conozco en profundidad, a priori da envidia ver como en otros paises hacen lo obvio y coherente: descargar la carga estatal para cobrarla sobre benefícios. Debe doler soltar la pasta, pero mejor crecer lentamente que morir antes de nacer…

En serio, hacer las cosas bien no es rentable, al menos al principio. Resulta que publicar una app como particular y ver como responde el mercado sin declarar impuestos es el modo al que el estado te está empujando. Huelga decir que eso es ilegal, y bla, bla, bla…

En fin… contento me tienen con sus emprendedores y sus bobadas. No nos ayudéis más!


Handling Hot Updates

Update without store interaction is sweet (Wikipedia)

When facing mobile development for apple store or google play distribution, something tricky to handle are the “minor fixes” updates.

By “minor fixes” I mean for instance, a graphic asset update, an additional supported language or a modification in a UI text.

The classic workflow usually supposes to “collect” this modifications or new content until something deep inside your dark developer soul tells that you that is update time. Obviously some of you may reefer to some bible-like development road map but, come on! someone predicted the misspelling of one word  in the 3rd tutorial? Really? Good for him or her…

Back to the subject, one must know that some updates may cause a certain loss of users. The reasons why this happen are not always obvious and some times are not even rational but we all have to live with it. One of those reasons is that the store forces a full download of the app for each update.

After a bit of wandering around, we decide to develop a “hot update” system. This system permits downloading content directly from our server to the game. Take into account that this workaround is suitable for small files and overwrites since all this extra load will be handled by our servers. Depending on your app,  really cool things can be done with a 100kb download!

I’m not going to get in the insides of our system but it is pretty straight forward:

  1. Receive the available download id list for the client version
  2. Cross check with already downloaded assets
  3. Request for missing downloads (packaged as .zip, every byte counts!)
  4. Unpack the zip and delete from temp.

You really want to spend some time using a zip library (we use this one for AIR). And, of course, keep your data organized so you can serve the minimum amount of content.

I let to you the handling of new assets as well as the version management. It can be a bit tricky but nothing too crazy. Use your file names wisely and create Classes that have version fields.

This approach is also intended to minimize the user leak at the early stages of the game distribution when a lot of bug fixing usually happen… Hope it helps!

The challenge of ordering challenges by difficulty

Have you ever thought about in how levels are ordered in a game? How you get (or don’t) the feeling of an increasing yet “wall-free” challenge?

During Zink development we’ve found that this is a non trivial issue that could make the difference between success or failure of a game.

I am sure that there should be tons of information on the web, however, we weren’t able to find a proper workaround at the time, so we did our own.

The obvious approach

In the aim to state the obvious, the first idea that came to mind was to order levels by “human experience”. In other words, one  of the developers decide how difficult a level is based on own experience. Some correction by external inquiry may be applied too.

This approach has two main problems:

  • The error introduced by the human, since the difficulty of a mind challenge isn’t perceived equally by different subjects
  • The amount of time required to do so, since each challenge requires a personal study and some testing correction.

In the Zink world another problem appears, since the content is dynamic and self-maintained by the community without developer intervention. Hence, becomes impossible to chase the community creations on order to evaluate them at “mass-creation-speed”.

The observer approach

The best estimator for the difficulty will be always the one obtained by observing real user behaviors. This approach assumes you have a way to store the challenges outcomes in order to analyze the data.

The server will collect, as an example, how many times a level is completed vs how many tries took to do so. This ratio is relative to the level so every try made by every user counts. Let’s call this ratio “O-difficulty” as in Observed Difficulty.

Once again, this approach takes a lot of time or resources (assuming you can pay someone to get the data faster). Some time to get the data and some to analyze it. In Zink, the dynamic nature of the content supposes the additional handicap of being able to test new levels so this isn’t suitable for us either.

The statistical analysis approach

Don’t worry that’s it, I’m not going to bother with more scenarios…
Let’s take the data obtained with the “observer approach” at a certain stationary instant and focus in the tested level set. Let’s focus, specifically, in the “static” or countable properties of this set of levels.

As an example, take this Zink level.

A Zink Level In our game, the game board contains elements such as walls, color drops, targets, keys, doors and traps. The game board as well as this elements can be treated as “difficulty variables” as in “a level with N traps is easier than a level with M traps”.

Our mission is to extract as many as this static “difficulty variables” as we can. Don’t be afraid to get non linear!  Maybe wall density is better estimator than number of walls…

Collect all the data and arrange it someway (at first we used Excel)


Then the magic… Get Minitab or any other software that let you to perform a regression analysis (learn about regression here).

The statistical process is not trivial at all, you should read about it to learn how to handle the results but, in a few words, a simple regression analysis will provide an equation that estimates an output value (difficulty) as a lineal combination of variables (game properties). Something like this:

difficulty = - 15,5 + 1,57 par + 0,40 size + 22,4 numTargets + 2.1 wallDensity + ...

This is a powerful tool that will let us evaluate a level’s difficulty by entering its elements, and just after creation! And this is something a computer can do really fast.

Obviously, the more observations you get, the more accurate the estimation would be. However, the beauty of this method relies on that you can get an estimate from a few testers and iterate from there when you’ll have more users.









¿Como se juega a Zink?

Unas pocas normas para empezar. Nuevos elementos de puzzle por descubrir.

Zink está actualmente en fase beta. Si quieres formar parte de la comunidad Zink, puedes pedir una invitación AQUÍ.