itch.io

NICE!

I got to 1562 on my second try!

I was being careful on my first try, but I found that the strategy that made more sense was to just spam blocks as fast as possible and only worry about rotation and precise placement as you run out of obvious places.

If you mean the fonts you create, then sure! It’s just an editing program, in the same way you’d use something like Photoshop. The program doesn’t do any creative work, so you’re the creator of the font.

So in the same way that image editing works, if you create something from scratch, it’s your own creation so you can do anything you want with it, while if you take something already made and modify it, then it becomes more complex.

In any case, the fact that you’re using this tool in particular doesn’t matter, it works the same way as with other creative products.

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! :)

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.

https://sergilazaro.itch.io/pixelforge

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!

Gracias!

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. :)

POST-MORTEM

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.

GAME DESIGN

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.

AUDIO

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.

VISUAL

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.

TIEMPO DE DESARROLLO

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.