domingo, febrero 02, 2020

"The Curse of the Red Forest" ya disponible!

Con "unos arreglos" he conseguido terminar y publicar "The Curse of the Red Forest", un juego en el que estuve trabajando hace años y que tuve que dejar congelado por falta tiempo. Vamos a dar un repaso a su desarrollo.
Comencé a usar Unity haya por 2011, cuando decidí dedicar la semana de vacaciones de primavera, la Golden Week, a realizar un pequeño juego (un clon de Diablo) durante 7 días para aprender como usar el engine.
Después de algún proyecto relativamente pequeño en Unity, me decidí a empezar uno mas grande, un RPG en primera persona con combates por turnos y con bastante historia a lo visual novel (¡ya tenia el engine hecho!). Después de hacer unas pruebas (que convertí en tutoriales para YouTube) me decidí embarcarme en este The Curse of the Red Forest como proyecto personal. Sería un juego para móviles y no demasiado largo a pesar de ser n RPG. Mas o menos hasta 2014 el desarrollo avanzaba bastante bien: el juego tenia toda la base terminada y siete de los ocho niveles estaban acabados o casi. El combate también era totalmente funcional, pero faltaba crear mas skills para protagonistas y enemigos, ademas de la ardua tarea de balancear adecuadamente las subidas de nivel con los enemigos que deberían enfrentar los jugadores. Este trailer muestra bastante bien lo que ya tenia terminado para entonces.


Sin embargo alrededor de 2014 muchas cosas cambian en mi vida y ya no puedo dedicar tanto tiempo a proyectos personales. Así que decido congelar a Red Forest y seguir avanzando con Heroes Trials, un proyecto en equipo dentro de Shinyuden. Después de muchos sufrimientos, retrasos y recortes Heroes Trials al final ve la luz en 2018 y puedo recuperar mis proyectos antiguos.
Pero mucho tiempo ha pasado desde que congele Red Forest... Muchos componentes del juego están anticuados. Incluso una parte importante ya no funciona en la versión de 2019 de Unity. A parte, durante estos casi 5 años de pausa he tenido la oportunidad de participar en varios RPG por turnos en mi trabajo de día, incluso he tenido que realizar el diseño para implementar el sistema de combate por turnos en cierto proyecto. Después de tanto combate por turnos el cuerpo me pedía centrarme en algún tipo de juego con mas acción, al menos en mis proyectos personales.
Cierta día examino el estado del Red Forest y hago una lista de cosas por hacer para poder sacarlo, junto con una estimación del tiempo para completarlas. Después de barajar varias alternativas y dado que el juego era completable de principio a fin con excepción de los combates, saco las tijeras y empiezo a recortar: todo el combate fuera, la progresión, las skills... Red Forest se había convertido en un juego de exploración de laberintos con historia (con solo unos pequeños reajustes para quitar las menciones a los combates que ya no están).
Y ese es el juego que ya esta disponible en la Play Store. Si Red Forest era ya un juego corto en su origen, ahora lo es más. Pero es un juego terminado y lanzado, cosas que dudo que hubiera podido hacer si hubiera seguido con el plan original. 

viernes, abril 22, 2016

Como usar Lua como sistema multi-tarea para cutscenes o IA en Unity


Trabajando en la industria del videojuego, llevo ya unos cuantos años usando sistemas de scripts empotrados en juegos para controlar las cutscenes, la IA y otros elementos varios del juego.

Menos algunas excepciones eran sistemas de script muy sencillos y específicos para ciertas operaciones o para maquinas poco potentes, así que principalmente he estado usando sistemas propios creados a medida de la tareas a realizar (bueno, también cree un interprete de Forth, pero este fue mas como un reto que otra cosa).

Sin embargo el tamaño de los juegos en los que estoy metido, y por tanto la variedad, complejidad y extension de los scripts a utilizar, ha crecido hasta tal punto que ya merecía la penar utilizar un lenguaje empotrado de uso general como Lua.

Usando Lua perdemos eficiencia y la capacidad de personalización de los scripts a medida, pero a cambio ganamos un lenguaje de programación completo, ademas de contar con muchas librerías y soporte de una comunidad.

Y el origen de este articulo viene precisamente de no poder personalizar Lua fácilmente para ejecutar varios scripts a la vez a modo de multi-tarea utilizando los wrappers en C# para Unity.
Tal vez en juegos de aventura como Tokyo Super Night o incluso RPGs por turnos como Curse of the Red Forest es posible tener un solo hilo de ejecución. Pero normalmente quieres tener varios: por ejemplo uno por cada IA activa, otro para cut-scenes, unos cuantos para gestionar triggers, etc..

Vamos a imaginar una situación mas concreta, una cutscene de un JRPG en la que dos personajes se mueven hasta un punto y inician una conversación cuando ambos han llegado. Podríamos escribirlo así:

function my_cutscene()
  move_npc(npc1,{120,120,0})
  move_npc(npc2,{120,100,0})
  say(npc1, "Hola npc2!")
  say(npc2, "Hola npc1!")
end


A primera vista es un código fácil de entender, ¿no? El problema es que no estamos sincronizando el movimiento de los NPCs con el dialogo para que empiece solo cuando ambos hayan llegado al punto de destino.

Simplemente no podemos bloquear la ejecución en move_npc, porque impediría ejecutarse a la siguiente instrucción (y cualquier otro script que haya activo), pero si podemos esperar a que terminen de moverse con un comando nuevo:

move_npc(npc1,{120,120,0})
move_npc(npc2,{120,100,0})
-- El script parara de ejecutarse hasta que todos los personajes se paren.
say(npc1, "Hola npc2!")
say(npc2, "Hola npc1!")
wait_move()

Este tipo de scripts funcionaria si solo tuviéramos este script en ejecución. Y aun así, el wrapper de Lua para Unity que usábamos no soportaba pausar la ejecución de la VM de Lua a mitad de un script para retomarla luego (o al menos yo no encontré como hacerlo), así que este método tampoco funcionaba.

Lo que hacíamos para ejecutar scripts con "pausa" para sincronizar era aprovechar que nuestro engine para juegos de aventura soportaba bloques de codigo Lua entre texto de diálogos, al estilo de los scripts para visual novels:

%{
  move_npc(npc1,{120,120,0})
  move_npc(npc2,{120,100,0})
  wait_to_finish_all_moves()
}%
%{ say(npc1) }% Hola npc2!
%{ say(npc2) }% Hola npc1!

   
En nuestros scripts el código Lua va entre %{ }% y cada bloque se ejecuta entero, pero se pausa para mostrar el texto entre bloques en pantalla (si lo hay) y continua con el siguiente bloque. Esta solución un poco cutre, nos valía para las pocas sincronizaciones que teníamos en juegos de aventura o por turnos. Pero para Adel necesitábamos una sincronizacion mas completa.

En principio deje aparcado como mejorar este sistema de scripts, pero un día, revisitando la página del nuevo juego de uno de los maestros del videojuego, Ron Gilbert, encontré una posible solución. En este articulo, se explicaba como usar las co-rutinas que incluyen algunos lenguajes de programación para simular multi-tarea, al estilo de como lo hacia el mítico SCUMM. Y aquí es cuando descubrí que Lua cuenta con co-rutinas en su funciones principales y, por lo tanto, lo podía utilizar para simular multi-tarea dentro de los scripts. Esto no es para nada nuevo, ya existen scripts para gestionar las tareas con subrutinas. Y investigando un poco, usar co-rutinas para juegos, incluso triple-A, parece ser algo muy común: las saga Uncharted (con su propio lenguaje de script basado en Lisp) o Fable II y III (usando Lua, como es nuestro caso).

Ninguna de los scripts que gestionaban de multi-tarea en Lua con co-rutinas que encontré en la red me convenció, así que decidí crear el mio propio a medida (ques lo que podéis descargar junto a un proyecto de ejemplo de Unity mas abajo).

Pero llegados a este punto, ¿que son exactamente las co-rutinas? Si programáis en Unity seguramente ya las habréis visto usadas en C#. Son métodos o funciones ejecutados paralelamente a otros programas, pero no a la vez y no con cambio automático de tarea. Así una co-rutina debe dejar paso a los demás hilos de ejecución normalmente con el un comando yield y volverá a ejecutarse después de un tiempo establecido o cuando lo despierte otro hilo. Aunque nunca sera tan optimo cono usar los threads del sistema, usar co-rutinas nos libra de muchos de los problemas de programar en paralelo usando threads, al saber exactamente cuando vamos a pasar el control a otro hilo, y ademas nos permite tener muchísimos mas hilos de ejecución (tareas en nuestro caso) de los que permiten los thread del Kernel.

La pequeña librería que hice permite ejecutar varias tareas, pararlas y pausarlas por un tiempo o hasta que se genere una señal o simplemente por un frame (para recordar al mítico DIV, que contaba también con el mismo tipo de multi-tarea hace ya casi 20 años).

Creo que todo queda mas claro aplicándolo al ejemplo del principio:

function my_cutscene()
  -- Iniciamos una tarea para mover a cada personaje
  Task:start("move_mycutscene",move_npc,npc1,{120,120,0})
  Task:start("move_mycutscene",move_npc,npc1,{120,120,0})
  -- Mientras no ternminen, esperamos
  while Task:alive("move_mycutscene") do
    Task:frame()
  end
  -- Mostramos el dialogo
  say(npc1, "Hola npc2!")
  say(npc2, "Hola npc1!")
end

--Aqui iniciamos la cutscene
Task:start("cutscene",my_cutscene)

Y de paso la función say también utiliza el sistema de tareas para esperar a que se muestra un mensaje antes de continuar:

function say(npc_id,text)
  -- La parte en Unity mostrara el mensaje con la cara 

  -- del personaje
  game.say(npc_id,text)
  -- Y esa parte en Unity también envía siempre a la señal "end-dialog" cuando
  -- acaba de mostrar el texto, así que la esperamos

  Task:wait_signal("end-dialog")
end

Y ya tenemos nuestro sistema multi-tarea para cutscenes, IA y lo que necesitemos. Este ejemplo es muy sencillo, pero imaginad que hasta la saga Uncharted ejecutaría un script parecido cada vez que un NPC acompañante se para a esperarte antes de continuar la escalada.

En el link de abajo, tenéis un ejemplo prestado del articulo que me inspiro a crear este sistema, implementado con un intérprete de Lua, mi mini-librería y unos gráficos de opengameart.org.



Descarga

No soy un experto en Lua y es la primera vez que trabajo con este tipo de sub-rutinas, así que cualquier reporte de bugs, posibles mejoras o comentario sobre este ejemplo serán bien recibidas.