Reconstruyendo Hayaku en Unity, una herramienta a la vez

Hola! En el primer post conté por qué estamos pasando Hayaku! de Construct a Unity. Esta vez, como prometí, quiero mostrar un poco de todo lo que hay por detrás de ese trabajito.

PRIMERO los atraigo mostrándoles cómo se ve y se siente el juego y los mechas y eso, y DESPUÉS, cuando ya los tengo, largo todo mi speech utra técnico sobre herramientas e importadores MUAJAJAJAJA

Esta historia tiene dos partes. Una es todo lo que Unity nos deja hacer con el juego. La otra es todo lo que estamos construyendo adentro de Unity para que sea mas fácil hacer el juego.

Por qué Unity

Construct se merece mucho cariño. Hayaku existe porque construct le dio a Ezequiel (que es un tremendo artista con muy pocos conocimientos de programación) una forma de hacer un juego él solo. Después el juego creció, el equipo creció, y necesitábamos un engine que encaje mejor con el proyecto.

Martin y yo tenemos mucha experiencia con Unity, y C# es un lenguaje muchísimo mejor para trabajar en un juego de este tamaño. Podemos ordenar el código, entender la relacion entre los scripts, cambiar un sistema sin tener que hacer arqueología en una event sheet de hace cinco años. O sea seguimos haciendo arqueología, obvio. Pero ahora tenemos mejores herramientas.

Hayaku también funciona mejor en Unity y ahora cuando algo no funciona bien tenemos mejores formas de entender por qué no funciona bien. En unity se puede medir el rendimiento (que herramienta del bien el profiler), encontrar qué es lo que realmente está consumiendo tiempo y trabajar sobre eso en vez de culpar al sistema que tenga más cara de sospechoso ese día.

Y después está cómo se ve. El Universal Render Pipeline (URP) de Unity nos abre muchísimo lugar para hacer las estupideces visuales que nos encantan. Podemos escribir shaders y renderer features propios. Le podemos meter efectos mucho más dramáticos pero respetando los píxeles de Hayaku. Hasta podemos hacer que el juego entero parezca que está en un tele de tubo o en una Game Boy, porque evidentemente una sola dirección de arte no nos alcanzaba.

El mismo juego, mintiendo de tres formas distintas sobre la pantalla en la que está corriendo.

Igual la mejor parte me parece que es el editor de Unity. Hacer ventanas del editor es magia. Cuando tenés que hacer trabajo repetitivo se vuelve lento o molesto, y ahí hacemos una ventana o un botón que esté hecho específicamente para cómo funciona Hayaku. Y así terminamos con un montón de herramientas: para importar niveles, para editar el mapa, para escribir diálogos, para trabajar en las quests, para probar cinemáticas, para entender cómo se conectan los niveles, para poner enemigos, props… La lista es interminable.

Unity nos abrió el camino para hacer un Hayaku más ambicioso y también formas de mejorar cómo lo hacemos. La verdad que es realmente muy copado que un equipo del tamaño del nuestro pueda laburar en un juego de este calibre.

El port igual sigue siendo una cantidad totalmente irracional de trabajo. Una de nuestras herramientas nació de un trabajito que había que hacer pero me estaba desesperando.

Por favor no me hagas poner todos esos tiles de nuevo

Casi todos los niveles de Hayaku! están hechos con tiles que son como pedacitos de una imagen que acomodás en una grilla (Imaginatelos como azulejos: los vas poniendo y armando un dibujo). Los ponés y tenés las paredes y los pisos de una habitación. Seguís, agregás más habitaciones, y ahí tenés un nivel.

Todo eso se puede copiar a mano. Se puede, sí, y lo sé porque para ese momento ya había armado (¡porteado, en realidad!) un par de habitaciones así. Un par (exactamente DOS) fue suficiente para no querer copiar el tiling a mano nunca más en mi vida.

Poner tiles cuando estás diseñando un lugar es hasta divertido Probás el salto, movés una plataforma porque no termina de funcionar, probás de nuevo… Copiar una habitación que ya existe es un embole inmenso. Las decisiones de diseño ya están ahí, en el otro engine. Vos solamente tenés que poner todo de nuevo en el mismo lugar otra vez. Te quema la cabeza, lleva un montón de tiempo y es recontra tedioso.

Así que hice una máquina que se ocupe de esa parte.

La idea era leer los datos del nivel guardados en Construct, encontrar qué tile iba en cada posición y colocar los correspondientes en Unity. Todas esas decisiones que Ezequiel ya había tomado estaban adentro de los archivos del proyecto. Yo necesitaba que el importador las entendiera.

Sonaba fácil. Yo pensé que iba a ser fácil.

SPOILERS, supongo: no lo fue.

Construct tiene su propia forma de guardar qué tile va en qué lugar dentro de un archivo JSON. Los datos se ve más o menos así: 23x0,4x85,15x0,14x85,62x0.... Muy útil si ya sabés qué significan todos esos números raros. Imaginate… no sé. ¿Unos ~650 mil de esos números? Más o menos.

Yo NO sabía qué significaban esos números.

Había que descifrar el (rarísimo) idioma robot y hacer bastante matemática para traducir cada posición. Porque, resulta que Construct y Unity no se ponen de acuerdo sobre para qué lado es arriba. Ni siquiera sobre qué es cero. Hay muchísima investigación y prueba y error ahí metido… y cuando digo MUCHA prueba y error, es MUCHA. Iba cambiando cómo el importador leía los datos (traía… no sé, traía ALGO. Nada que tenga sentido, pero algo), cambiando los cálculos y probando otra vez. Y otra. Y una más. Y después otra. Y así una y otra vez.

Para ese momento ya teníamos movimiento y saltos andando, un par de enemigos y esas habitaciones que había armado a mano. Y en el intento número mil quinientos treinta y siete, importé un nivel entero y de repente SE VEÍA (casi) BIEN.

Ufff. Qué sensación esa. Fue como ganarle a un jefe que me tenía trabado hace como 1 mes.

Esa primera vez solo trajo las paredes y los pisos. O, para más precisión, había importado todo y TODO ERA PARED. Pero se podía reconocer el nivel, y no me había pasado todo ese tiempo copiándolo tile por tile. O sea… SÍ me había pasado todo ese tiempo haciendo que esto funcione. Pero esta cosa que inventé nos estaba por

AHORRAR.

TANTO.

TIEMPO.

FUNCIONÓ. Más o menos.

Yo estaba muy pero recontramuy contento con ese más o menos.

Ya pasaron muchos meses, y ahora la herramienta hace muchísimo más. Podemos elegir un nivel y las capas de tiles que queremos traer, incluidas las decorativas. Una vista previa transparente muestra dónde van a quedar, así podemos revisar la posición antes de importar.

El importador de ahora: revisamos dónde van a quedar los tiles y los traemos.

Llegar desde ese primer éxito hasta una habitación que se vea y se comporte como Hayaku llevó muchísimo más trabajo. Después vinieron los fondos y las decoraciones. La cámara también necesitó lo suyo, incluido un sistema de parallax propio que mantiene el pixel art bien lindo y nítido mientras que le da profundidad al escenario. Hicimos que funcione parecido al que Ezequiel ya conocía en Construct porque, y sí, cambiar de engine ya era suficiente quilombo para un solo artista.

Construct a la izquierda, Unity a la derecha. Entre estas dos imágenes hubo bastante trabajo a mano.

La mayor parte del port hubo que hacerla a mano igual. El importador nos saca de encima una parte que simplemente es muy aburrida. Con eso ya alcanza para que sea una de mis cosas favoritas de las que hice para el juego.

Esto lo va a corregir Ezequiel

Las cinemáticas tienen su propia herramienta: como un lenguaje de scripting que escribimos en archivos de texto.

Pensalas como guiones de teatro.

Un script puede decirle a un personaje que camine hasta un lugar y espere. Puede mover la cámara, reproducir una animación o arrancar una conversación. Nosotros escribimos las acciones y sus tiempos, y el juego las ejecuta. Un guioncito que simplemente es super específico sobre cuánto debería tardar alguien en caminar.

Mi primera pasada es, más que nada, hacer que la escena funcione. Que los personajes hagan lo que tienen que hacer, cuando tienen que hacerlo. Después Ezequiel los corrige.

Un personaje puede llegar exactamente al lugar correcto en el momento correcto y aun así verse raro. Una pausa corta puede hacer que una reacción funcione, o hacer que parezca que todos se olvidaron de por qué están parados ahí. Una y otra vez hay que mirar de nuevo la escena y cambiarla.

Como la cinemática está en formato de texto, podemos editarla y volver a ponerle play en el editor de Unity sin reiniciar el juego cada vez. Eso elimina una cantidad enorme de espera entre querer probar algo y ver si funciona.

Un pedazo del script, y Hayaki y el tenebris siguiendo sus instrucciones. Los tiempos precisos los ve Ezequiel.

También hay un motivo bastante más sencillo para usar archivos de texto: prefiero trabajar con el teclado. El mouse es muchísimo más lento para estas cosas. Cosas de programador. No me hagan agarrar el mouse solo para cambiar un número, porfa.

El mapa se toma algunas libertades

La herramienta del mapa resuelve otro problema. Arranca tomando las habitaciones reales de los niveles y genera un mapa a partir de eso.

Después lo ajustamos a mano, porque el código del juego tiene como una idea bastante particular de qué es lo que es una habitación. En general una habitación es un rectángulo que le dice a la cámara hasta donde puede llegar y por dónde puede moverse.

Vos, la idea es que disfrutes de algo un poquito más interesante que un montón de rectángulos de cámara.

Un pasillo que termina en una caída, en el juego se puede sentir como un solo lugar que tiene forma de L, aunque la cámara necesite áreas separadas para manejarlo. El mapa tiene que ayudarte a reconocer el lugar por el que vas moviéndote. Mostrarte cómo dividimos el escenario para que funcione la cámara no sería demasiado útil.

Así que el editor del mapa nos deja agrupar esos espacios y cambiarles el contorno. Las habitaciones originalmente salen del juego real, pero después podemos ajustar las proporciones y conexiones hasta que el nivel entero se entienda.

Las habitaciones son reales. Sus proporciones son... digamos que 'negociables'.

Todavía nos queda mucho camino por delante, pero ahora estamos avanzando más rápido que nunca y ya podemos empezar a pensar en próximamente divisar la recta final, muy a lo lejos.

Si te gustó mirar un poco el “detrás de Hayaku” escribinos. La verdad que no estoy seguro de que haya público para esto (¿Posts largos? ¿En 2026? ¿¿¿Y encima me pongo técnico???) Tenemos muchas más herramientas que hicimos, y cada una viene con otra historia sobre un problema que estábamos cansados de resolver a mano. Si la gente quiere leer esas historias, yo feliz de seguir escribiéndolas.

Y sí, esto era inevitable… WISHLIST PLZ

Si Hayaku te suena a que es un juego para vos, agregalo a tu lista de deseados en Steam. Nos ayuda, y te enterás cuando esté disponible. Win-win.

¿Ya lo agregaste? Contale de hayaku a un amigo… o a varios. Podés pasarles este post, o el trailer o alguno de los GIFs del mecha si te parece que los va a convencer más. No me ofendo. No soy boludo. Hasta arranqué este post con un GIF.

Hay más del juego en el Twitter de Ezequiel, y el Discord está abierto si querés meterte a charlar mientras hacemos el juego.

Muchas gracias por leer. ¡Dale like y comentá si querés más de la parte técnica!