viernes, mayo 08, 2020

Lisp y Naughty Dog

Lisp es uno de los lenguajes de programación mas antiguos (el segundo de alto nivel, solo posterior a Fortran) y hoy en día, en diferentes dialectos o inspirando otros lenguajes, aun sigue bastante vivo. Sin embargo, a pesar de que una buena implementación es lo bastante compacta para ser un lenguaje de script para juegos, a poca  gente se le ocurriría usarlo como lenguaje principal en el mundo de los videojuegos. Si exceptuamos a Naughty Dog, claro.

Por que como Andy Gavin cuenta, empezaron usando su propia versión de Lisp en el cutre clon de Mortal Kombat llamado Way of the Warrior para implementar las maquinas de estado. La cosa continuo en su siguiente saga, Crash Bandicoot, creando una versión de Lisp llamada GOOL (Game Oriented Object Lisp), que usaron para scriptar el gameplay de los objetos del juego.

El código de GOOL esta basado en los estados de los objectos, que implementaban su jugabilidad con diferentes bloques de código. Permitía ejecutar trozos de código estilo corutina: el código marcado como ":code" se ejecuta hasta que encuentra una variante del comando "frame", que pasa el control al siguiente bloque. Por ejemplo, aquí repite una animación hasta que colisiona con algo
:code (defgcode (:label play animation)
  ; play the animation until this object is colliding with
  ; another, then change states
   (until (status colliding)
    (play frame group animation))
    (goto collided)))

Dentro de los estados también permitía código ejecutado cada frame, marcándolo con ":trans". Por ejemplo, aquí rota un objecto 10 grados cada frame hasta 180.
:trans (defgcode (:label turn 180)
  ; set the y rotation 10 degrees closer to 180 degrees
   (setf roty (degseek roty (deg 180) (deg 10))))
GOOL también contaba con un sistema de eventos tan sencillo de usar como este ejemplo para colisiones en la cabeza
(send event hit on the head (find the nearest object))
Vamos que si podías sobrevivir a usar LISP tenias a tu disposición un lenguaje de script muy potente para la época y la plataforma.

Y todo llego a un nivel mas con GOAL (Game Oriented Assembly Lisp) que se usó en la saga de Jak & Daxter. En este caso nada mas y nada menos que el 98% del código del juego estaba escrito en esta variante de Lisp. Esto les llevo a unos cuantos quebraderos de cabeza a la hora de encontrar programadores, ya que en el mundo de los videojuegos es relativamente fácil encontrar expertos en C++, pero es muy difícil reclutar a expertos en Lisp. No hay mucha información mas sobre GOAL, a parte de que esta implementado con Allegro CL y que, como su nombre indica, se compila directamente en assembler para la PS2.

Y vaya, parece que ND estaba muy augusto con su engine hasta que la unión con Sony les obligo a programar en C++, para que pudieran compartir código con otros equipos dentro de la compañía japonesa. Eso si, aunque ya no sea su lenguaje principal, se sigue usando como lenguaje de script, como demuestra esta presentación sobre Uncharted 2 en la que se ve que aun siguen usando una nueva versión de Lisp para scriptar partes del juego.

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.