itch.io

Nice tune!

Thanks!

Muy buen score! 👏

I see! For that I’d need to publish the PICO-8 cart. I’m afraid I’m wary to do that, since the few carts I published got pirated and assets re-sold :(

Hi! I don’t know what’s RG351 and how it works, so I’m not sure how can I help. Can it run web apps?

Thanks for the kind comment!

Hola! Este lo hice en javascript con el framework Phaser

Thanks for playing the game! Two things come to my head:

• Just in case, have you tried holding the jump button? The longer you hold, the higher you jump.
• Some people on slower machines or browsers get stuck because you jump a bit less high when the framerate is low :( Since this was an entry for a game jam, I didn't have the time to code a proper fix for this bug. I'm really sorry if this is the case. I'd suggest trying with a different browser, such as Firefox Quantum, or a different computer  and see if it helps.

Buenas, un log de desarrollo no es más que un registro de qué se ha hecho / cuándo se ha hecho. En las jams se suele pedir para comprobar que la gente no ha hecho trampa (p.ej. presentando un juego desarrollado anteriormente). Es una manera de "justificar" de algún modo el progreso.

En su forma más básica, un log puede ser simplemente un TXT de este estilo:

• Jueves 12:00 - Decidido el diseño y mecánica principal del juego
• Jueves 14:00 - Implementado un prototipo de la mecánica principal con gráficos placeholder
• Jueves 17:30 - Creados assets del personaje principal para: idle, walking
• Etc.

Otra manera más o menos automática de hacer el log es usando un control de versiones, como Git. Por cada commit que se haga, si ponéis un mensaje con sentido que explique qué ha cambiado, luego se os queda algo tal que así. Además, con un control de versiones realmente se tiene un registro de qué se ha añadido/quitado cada vez, con lo cual no hace falta ser súper detallado.

Hola, ¿ponemos en este hilo recursos, tutoriales, etc. para hacer videojuegos? :) Aquí van mis recomendaciones:

Game jams, prototipado rápido, etc.

• How to succeed at making one game a month es un artículo de un tío que se hizo un juego al mes durante un año, y explica su proceso. Creo que este tipo de desarrollo es muy adaptable a una game jam y es más o menos lo que yo intento seguir: tener algo jugable rápido e ir iterando sobre ello, en vez de estar esperando hasta el final para tener algo que se pueda jugar.
• Adriel Wallick hizo un juego a la semana… durante un año! En su web podéis pegarles un ojo, pero la parte que es más interesante son los mini-postmortems o comentarios de cada juego. Se puede aprender mucho en ellos (sobre todo en temas de scope y ser capaces de "recortar" el juego para que dé tiempo a hacerlo).

En mi blog tengo varios artículos sobre cómo afronto las jams, qué herramientas uso, y post-mortems. Algunos son:

• Surviving Ludum Dare
• Engines, tools and apps for Ludum Dare
• Ludum Dare #38 post-mortem (este es el post-mortem de la última jam que hice)

Herramientas

• Para gestionar el tiempo recomiendo alguna técnica de time boxing. Yo utilizo la técnica Pomodoro, con una app en el ordenador que me hace de temporizador. Hay mil apps de estas gratis para móvil y ordenador. Lo bueno de esta técnica es que os obliga a programar descansos y mini-descansos (realmente marcan la diferencia!)
• Para gestionar tareas, yo me suelo apuntar en un TXT o alguna app de notas (o en papel!) la lista de features del juego, y assets necesarios (gráficos, música, etc.). Tener las cosas apuntadas nos da muchísimo control porque si vemos que la lista es muy larga, sabemos que estaremos en problemas… por adelantado! Así que tenemos la oportunidad de recortar cosas del juego para que sí nos dé tiempo. Si sois varios en el equipo, podéis hacer esta lista en algún sitio de documentos compartidos, como Google Docs.
• Para gráficos pixel art, yo estoy enamoradísima de Pyxel Edit. Un clásico es Graphics Gale, que es gratis (aunque sólo está para Windows).

Según me vaya acordando de más cosas, iré actualizando el post. Espero que pueda servir de ayuda :)