Post-mortem: Ludum Dare 40 (Español)

Para quienes no lo conozcan: Ludum Dare es una competencia de desarrollo rápido de videojuegos que se realiza tres veces al año. Tiene dos modalidades: la Compo y el Jam. Yo participé en la Compo, que es la más dura: es una competencia estrictamente individual, en la cual los participantes deben crear un videojuego desde cero en menos de 48 horas, incluyendo concepto, código, gráficos, música y efectos de sonido, y al finalizar la competencia están obligados a publicar el código fuente de su proyecto. La otra modalidad, el Jam, dura 72 horas, permite que se trabaje en equipos, permite el uso de código, gráficos y audio de terceros y no requiere la publicación del código fuente. Ambas modalidades permiten que se empiece a trabajar sobre cualquier base de código de la que se disponga (que, en el caso de la Compo, tendrá que publicarse al final), y el uso de cierto tipo concreto de recursos de terceros (como fuentes tipográficas), lo cual es de especial ayuda en la Compo.

Mi entrada a la competencia se llama Yottaman. Es un juego de acción rápida que gira alrededor de Yottaman, un superhéroe que se hace tan poderoso que él mismo se vuelve un peligro para el mundo. Lo desarrollé en aproximadamente 32 horas, ya que el resto del tiempo de la competencia (¡16 horas!) se fue en dormir, comer y un par de salidas de la casa. En este post-mortem narro cómo fue mi experiencia creando el juego, qué cosas salieron bien y qué cosas pudieron ser mejor.

Ideas iniciales, diseño del juego y alcance

El tema de la competencia fue "The more you have, the worst it is", que se traduce como "Entre más tengas, peor es", y los juegos presentados deberían tratar de ejecutar ese tema de alguna forma. Fue el tema ganador tras una serie de votaciones abiertas que se hicieron los días anteriores a la competencia.

Inicialmente, no me gustó mucho el tema (mi opinión cambió más adelante). Creo que había otros más interesantes y que se prestaban para cosas más creativas. Creo que este tema daba pie a hacer muchas cosas obvias ("entre más daño tengas, peor es", o "entre más enemigos haya, peor es"). Espero que mi aproximación haya sido lo suficientemente creativa.

Lo primero que hice fue una lluvia de ideas para tratar de determinar qué hacer, listando cosas que hicieran todo peor entre más hubiera. Primero pensé en lo obvio (daño, miedo, cosas malas en general) y luego en ideas mejores (admiradores, hijos, dinero mal aplicado, supervivientes en un búnker nuclear...).

La primera idea que caló fue hacer un juego sobre un padre o madre con hijos: los hijos tienen distintas necesidades según su edad (pañales, comida, ir al parque, colegio, ir al cine, ir a fiestas, universidad, ser sacados de la comisaría...) y requieren de cada vez más dinero. Por desgracia, los días siempre duran lo mismo, de modo que el padre debe comprimir cada vez más actividades en sus días, incluyendo trabajar y dormir. La misión sería tratar de obtener un nivel de "realización" que no dependería del dinero sino de la cantidad de hijos graduados de la universidad, lo cual implicaría que más hijos son potencialmente más puntaje, pero al mismo tiempo una dificultad mucho mayor. Pensé (y sigo pensando) que puede hacerse un interesante, cómico y frenético juego de manejo de recursos alrededor de este tema. El problema es que sentí que el tamaño del juego podía descontrolarse para sólo 48 horas de tiempo.

Yottaman surgió después, de la idea de los "admiradores". Pensé primero en un superhéroe tratando de hacer su trabajo, pero con muchos admiradores que llegaban a mirarlo y aplaudirle, estorbando y exponiéndose al peligro en el proceso. Sin embargo, la idea pronto mutó y se enfocó en el héroe en sí mismo: el héroe es tan poderoso que empieza a hacer daño al entorno sin querer, volviéndose él mismo un peligro social. Aunque la idea me gustaba un poco menos que la de los hijos, me pareció que era más fácil de realizar en el margen de tiempo del concurso.

Según mi idea original, Yottaman podía resumirse en lo siguiente:

• El héroe puede lanzar lásers por los ojos y golpear con puños.
• El héroe no es afectado por las balas enemigas.
• El héroe empieza el juego con un poder adecuado para eliminar a sus enemigos.
• El héroe sube de nivel de poder esporádicamente. En los niveles superiores de poder, las habilidades se salen de control cada vez más: los láseres ahora causan incendios o estallan como bombas atómicas, los puñetazos revientan edificios o parten el planeta entero en dos y las balas que tocan al héroe rebotan con tanta intensidad que se vuelven armas nucleares.

Inicialmente, me imaginé el juego con civiles (que correrían despavoridos exponiéndose al peligro), enemigos (en el suelo y voladores) y varios tipos de ataque del héroe (láser y puñetazos). A medida que desarrollaba, sin embargo, el tiempo se empezó a volver asfixiante, y noté que era cada vez más difícil dar tanta variedad de mecánicas, ya que cada una implicaba no solamente código y arte extra, sino también diseño de la mecánica en sí, ya que de otro modo el juego podía quedar desequilibrado, muy difícil o con mecánicas sin mucho sentido.

El comportamiento de los civiles llegó a estar prácticamente programado, pero al final descarté la idea porque sentía que el juego se podía poner difícil de jugar con ellos. El segundo ataque del héroe primero pasó de ser un puño (que finalmente no vi que encajara con las demás mecánicas) a un tackleo, y finalmente se removió por razones de tiempo. El escenario iba a ser dinámico (por ejemplo, un edificio o un auto podían representar que había sido destruido con un gráfico diferente), pero eso se simplificó con incendios que se generaban en los puntos donde el láser o las balas rebotadas tocaban el escenario.

En general, la lección más importante para una competencia de tiempo limitado como esta, definitivamente, es que el alcance del juego se debe limitar lo más posible antes y durante su desarrollo, priorizando lo esencial y ampliando si al final queda tiempo.

Gráficos

Lo primero que hice fue elegir una paleta de colores para el juego usando Paletton, que poco después reemplacé por una que hice yo mismo a partir de algunos colores concretos.

Mi primera aproximación fue intentar hacer un personaje con pixel art sin basarme en nada, pero el resultado iba tan mal que lo descarte. Tras buscar inspiración, encontré un estilo que me pareció gracioso y agradable, y basé a mi personaje principal en él:

La Z es por "Zettaman". Para nombrar al personaje, busqué cuál era el prefijo más grande del sistema métrico. Los dos mayores son "Yotta", que significa 10^24 (esto es, un uno seguido de veinticuatro ceros), y "Zetta", que significa 10^21. Como referencia, "Kilo" es 10^3, "Mega" es 10^6 y "Giga" es 10^9. El nombre "Zetta" me gusta mucho más que "Yotta", y lo elegí primero. El problema es que la Z del personaje quedaba al revés al girarlo horizontalmente (o sea, cuando miraba hacia la izquierda). Podía corregirlo, claro, pero era más trabajo, de modo que tomé la ruta más corta y me quedé con la Y. El beneficio adicional es que el nombre del héroe usa el mayor prefijo de todos en vez del segundo mayor.

Durante el resto del desarrollo, los personajes tuvieron pocos cambios. El más importante fue al momento de animar. Inicialmente, intenté animar a los personajes directamente con sprites:

No iba mal, pero estaba costándome hacer bien las extremidades en distintas posiciones, por lo que decidí pasar a animar con skeletal animation:

Nótese que escalé los sprites que conforman al personaje, de modo que se pierde el efecto "pixelado" al rotar. Normalmente soy muy quisquilloso con eso, pero esta vez no me pareció que se viera mal, y tampoco tenía mucho tiempo para correcciones. En retrospectiva, pude haberlo escalado menos, para no perder del todo el efecto pixelado. Además, por inexperiencia con mis herramientas (en particular, Spriter), creí necesario pasar el pixel art a una imagen vectorial en Inkscape para poder escalarlo bien; después descubrí que no era necesario. Se suponía que también podría pulir el arte al ser vectorial (para no hacerlo tan pixel art), pero eso tampoco lo alcancé a hacer.

Lo último que implementé fueron los sistemas de partículas y los escenarios. En mi afán, hice dos edificios y solamente usé uno, me olvidé de cambiar el color del cielo (quedó el que Unity trae por defecto) y no respeté mi paleta de colores en varios elementos gráficos. Tonterías fáciles de solucionar, pero que pueden generar un impacto grande en como se ve el juego.

Lección aprendida en gráficos: se debe tener un buen flujo de trabajo con los gráficos, conocer bien las herramientas antes de la competencia y respetar la paleta de colores a rajatabla (es fácil: si es posible, dejar solamente los colores de la paleta en la herramienta). Si se tienen "plantillas" con estilos de personajes y elementos que puedan seguirse para hacer nuevas creaciones, mucho mejor.

Audio

Ah, el audio, mi azote. Aunque cotidianamente soy más incompetente en la parte gráfica que de audio (no sé dibujar, y me es muy fácil tocar música a oído), me cuesta mucho más hacer audio que considero decente que gráficos que considero decentes.

Mi proceso inicial de composición musical tuvo varias etapas:

• Tararear algunas melodías mientras hacía otras tareas.
• Empezar a implementar las melodías en una herramienta.
• Darme cuenta de que en realidad mi "composición" era simplemente que estaba tarareando una melodía que hace mucho no oía ni recordaba.

Fue horrible: creía que tenía una idea fantástica, y en realidad era mi memoria jugándome bromas pesadas.

La tarde del sábado, se me ocurrió algo mientras conducía hacia la casa. Grabé la idea en el celular y esa noche la trabajé en Rytmik Ultimate. En el camino, noté que, de nuevo, la idea estaba influenciada por temas que conocía, pero esta vez menos, y no me costó mucho modificar mi melodía para diferenciarla al máximo. Jugué un rato con los instrumentos, le puse un bajo que al principio me costó pero creo que quedó razonablemente decente, y ya está: el tema de Yottaman quedó listo. Puede oírse en el video que puse más abajo, o siguiendo este enlace.

Quedé contento con el resultado. A medida que pasaban las horas, se me ocurrían mejoras para hacerle, pero no hubo tiempo para eso. Seguramente un músico le encontrará problemas por miles, pero creo que no está mal, y cumple muy bien su objetivo de ambientar un juego cómico sobre un superhéroe torpe y autodestructivo.

Los efectos de sonido no me costaron mucho gracias a herramientas como jfxr, que generan efectos de sonido aleatoriamente y permiten mutarlos y refinarlos.

Después de las 48 horas: notando lo invisible, probando otros juegos

Una vez finalizadas las 48 horas, Ludum Dare pide a sus participantes que prueben y califiquen los juegos de los demás. De ese modo, todos obtienen calificaciones para sus juegos. El sistema motiva a la gente a calificar lo más posible al priorizar en el listado de su página principal los juegos de la gente que más ha calificado. De ese modo, quien califica mucho también será calificado mucho.

Yottaman ha recibido buenas críticas en general, pero también comentarios que me revelaron algunas falencias importantes en la claridad del juego: algunas personas pierden y no entienden la razón. Ello es grave, ya que una persona que no entienda las condiciones de derrota del juego puede pensar que no está completo, o que no tiene sentido, o incluso que está mal diseñado, cuando en realidad lo que hace falta es una buena explicación. Además, ello causa que la dificultad del juego, que de por sí es elevada, se perciba más alta de lo que debería.

En este sentido, una lección que volví a aprender es que es bueno que una persona pruebe el juego antes de lanzarlo. El desarrollador simplemente no ve las falencias mientras desarrolla, porque se acostumbra al juego demasiado. Otra lección es que el juego debe hacerse fácil y corto, ya que las personas que están calificando muchas veces lo hacen con prisa o poca paciencia. Estoy seguro de que una persona que le dé un tiempo al juego y/o lea las instrucciones en la página lo entenderá perfectamente, pero ambas cosas son mucho pedir para el público de Ludum Dare: otros desarrolladores que probablemente están probando decenas de juegos más para dar visibilidad a sus propios trabajos.

En cuando a los juegos de los demás, he encontrado cosas muy variadas e interesantes, que me hicieron cambiar mi opinión respecto al tema de la competencia ("Entre más tengas, peor es"). Como esperaba, muchos juegos trataron de adaptarse al tema de manera obvia (más enemigos es peor, más elementos para organizar es peor, más velocidad es peor), pero otros trabajaron con elementos creativos. Independientemente del tema, a muchos juegos se les nota el trabajo gráfico o de audio, y hay mecánicas muy interesantes que se exploraron. Obviamente, a los juegos que más se les nota el pulimento es a los juegos de Jam, hechos por equipos, con assets externos y con más tiempo.

Conclusiones

Hice un video de 3 minutos ilustrando el proceso de creación del juego. La música de fondo es el tema de Yottaman:

En general, el Ludum Dare fue una experiencia divertida. Hay cosas que la competencia podría mejorar en sus reglas y en el control que se ejerce sobre la gente trantado de hacer trampa (que serían temas para otro texto), pero como desafío personal es muy positivo. Mis conclusiones personales, algunas de las cuales ya mencioné, son:

• El alcance debe limitarse al máximo. Si en el camino hay cosas que puedan removerse o dejarse opcionales, mejor.
• El juego debe finalizarse completo primero, y luego mejorarse si queda tiempo. Priorizar es fundamental.
• Las herramientas a usar deben conocerse bien, y debe tenerse un flujo de trabajo bien definido. Tener plantillas que puedan usarse como guía al momento de crear nuevo contenido es de mucha ayuda.
• La paleta de colores debe respetarse para que los gráficos del juego queden consistentes e interesantes. Preferiblemente, se debe definir al comienzo, para no tener que adaptar los gráficos más adelante.
• El juego debe hacerse fácil. Que una persona promedio pueda pasarlo en 5-10 minutos. Debe priorizarse la claridad del juego (cómo se juega, cómo se gana, cómo se pierde) sobre el humor, la estética o el deseo de que el jugador lea entre líneas.
• En lo posible, una persona externa debería probar el juego antes de lanzarse. Esto implica que el juego debería estar jugable (así sea sin pulir) varias horas antes de la hora de corte de la competencia, con el fin de hacer correcciones o aclaraciones donde se requiera.

Es todo. Espero poder participar nuevamente en un Ludum Dare más adelante. Me gustaría participar en el próximo, que será dentro de aproximadamente 4 meses, pero ya veremos.

Para jugar Yottaman, clic aquí