Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

Sergi Lazaro

A member registered Jan 14, 2014 · View creator page →

Creator of

Recent community posts

I wasn’t planning on it, but I don’t have any reason not to either. I’ll keep it in mind for the future.

Are there any specific reasons that would make you prefer Steam? Having everything all in the same place, automatic updates, etc?

Glad you like it!

No, it doesn’t interact at all with the fonts installed in your system, only the fonts you open or create.

As for it being free, I actually plan on making it a paid app with a very permissive trial (no restricted features at all, just one screen asking you to purchase when you open it). So not free, but you would be able to use it without paying. It’s explained on the website but I should also mention it on the page :)

Thank you!

I label it as pre-release because I want other people to test it a bit just in case, and to see if anybody would use it at all, but it’s ready for a released 1.0 version as-is.

If you’ve tried to use it a little bit and have any feedback at all, I’m all ears! :)

(2 edits)

You can create your own pixel fonts and export them to TTF. Check the project page and/or the external website for the list of features.

It’s fully functional but not “officially released”, since I’d like to get some feedback from other people first. Please try it and share any problems or important missing features that you find! :)

I loved this game! Gave you some feedback and ideas for fixing delay problems on the Ludum Dare site. I'll also copy it here just in case.


Amazing little gem of a game. I’m a drummer so I love rhythm games. I played the linux version.
I had a problem with delay, I tried mouse and keyboard separately, ended up using keyboard but the delay seemed to be the same. Trying very low latency on different platforms, using Unity, would have been impossible, so I don’t blame you, it’s a hard problem. In my case the clicks “hit” when I released the spacebar. By this I mean, the game registered the key down, but the delay made it feel like it was the key up that made the hit register.
Having played rhythm games before, and being a drummer, I adapted quickly to the delay, so after a couple of rounds of the same rhythm I just got the groove and could finish the rhythm without issues.
As a programmer, the way I’d solve it is by having some kind of calibration step beforehand. I just happen to have thought about this for a while because I was thinking of developing some software that would have these same issues with delay. My idea was to have like a “sync” step where a metronome is beating, and you’re supposed to hit the key at the same time as the metornome. You don’t get any audio feedback from your hits, but the game tells you that it’s registering them (so that you know that they’re not lost), with like a progress bar or something. But you don’t hear a sound when you hit, because that could throw you off. The first few beats are ignored (they probably aren’t very accurate), and then you save a list of the delays between each beat timestamp and when the user key events are registered. If everything goes well, and you average them out (also removing some outliers), that gives you the offset that you should apply to the game detection. If you repeat this process with different metronome BPMs, I think you’d get very reliable delay correction without the user having to input random numeric values via trial and error.
That’s what I always had in mind which could work while being pretty user friendly. With good user experience tweaks the calibration step could be a mix of tutorial and calibration, making it seamless for the user.
In any case, I loved the game, the way the music builds up as you nail the rhythm is very satisfying. I wish it was longer, but it’s a jam game!


Los pick-ups añaden una bola más para lanzar, se acumulan permanentemente. Quería añadir un efecto en el que se viera como baja una bola y se añade al resto, pero no me dio tiempo.

El resto de comentarios estoy de acuerdo también. He añadido un post-mortem sobre eso y otras cosas. :)


El objetivo para mí de esta jam era empezar y terminar un juego lo más sencillo posible para poder encontrar y arreglar problemas en el mini-engine en el que estoy trabajando en paralelo. Por eso no me importa del todo el hecho de que el game design no está retocado o perfeccionado (hay problemas obvios), porque he estado el 90% del tiempo trabajando en engine y 10% el juego en si. No pude hacer casi testing. Pero me importaba más la implementación que el juego en si.


Como ha comentado @erades-dev y ya había visto al jugar al juego en calma una vez entregado, el ángulo de disparo es un problema. Cuando puedes disparar casi en paralelo, la cantidad de rebotes por turno es enorme y reduce mucho la dificultad.

Otro problema es el aumento de dificultad a la que se suben niveles. Ahora mismo la dificultad aumenta de forma lineal, y combinado con el problema del ángulo de disparo, el juego no tiene reto para llegar a 99, simplemente es tiempo, es básicamente imposible perder.


No hay sonido ni música. Tenía implementado el "back-end" para ello pero no tuve tiempo para añadir nada. Pero claramente le añadiría un extra al juego.


Estoy bastante satisfecho en la parte estética. Todo son cuadrados de color liso (excepto la fuente), y con el post-efecto pixel me gusta bastante como ha quedado todo. El screenshake ocurre siempre a cada golpe, pero es sub-pixel, por eso solo se ve cuando hay bastantes golpes seguidos (y entonces temporalmente suma a 1px o más). De esta forma solo se ve cuando hay mucha acción a la vez, en vez de constantemente que sería molesto. Quería añadir algo de partículas también pero no me funcionó a tiempo.


Con el tema y queriendo hacer algo super simple, no estuve nada de tiempo pensando en qué juego hacer. Al empezar a implementar, tuve que arreglar las físicas en el motor, lo cual fue quizás un 30-40% del tiempo. Luego tuve que desarrollar de cero el render a textura, escalado, post-procesado, etc. para el efecto pixel, otro 20%. También desarrollé de cero el sistema de partículas (al final sin usar porque había problemas), y animaciones/transiciones, otro 10% del tiempo aprox.

O sea que al final solo estuve un 20-30% del tiempo en el juego en sí. Pero ese era el objetivo, tener la excusa y oportunidad de descubrir y arreglar y mejorar el motor, para poderlo seguir usando en otros juegos 2D.