Plaga de Ratas

La famosa leyenda de El flautista de Hamelín, recogida por los hermanos Grimm, nos sirve de inspiración para explorar el movimiento de múltiples agentes en un entorno virtual. La historia nos habla de una manada de ratas que iban tras el misterioso flautista, a la par que molestaban a los demás animales y habitantes del pueblo.

Había una vez una pequeña ciudad al norte de Alemania, llamada Hamelín. Su paisaje era placentero y su belleza era exaltada por las riberas de un río ancho y profundo que surcaba por allí, y sus habitantes se enorgullecían de vivir en un lugar tan apacible y pintoresco. Pero un día, la ciudad se vio atacada por una terrible plaga: ¡Hamelín estaba lleno de ratas! Había tantas y tantas que se atrevían a desafiar a los perros, perseguían a los gatos, sus enemigos de toda la vida; se subían a las cunas para morder a los niños allí dormidos y hasta robaban enteros los quesos de las despensas para luego comérselos, sin dejar ni una miguita.

El flautista de Hamelin – Jacob y Wilhelm Grimm

Este planteamiento sirve como excusa para desarrollar un prototipo en el que el jugador controla el movimiento del flautista y todos los demás personajes son controlados mediante agentes inteligentes. Nuestro fiel compañero será un perro, que nos irá siguiendo a todas partes, y también estarán por allí las ratas, merodeando por el pueblo. Tendremos la posibilidad de tocar o  no la flauta, y mientras que lo hacemos, las ratas que nos oigan comenzarán a seguirnos, las cuales desagradan al perro hasta el punto de hacerlo ladrar y salir huyendo cuando hay demasiadas cerca de él.

Este prototipo servirá para probar algoritmos de movimiento que, lejos de ser anticuados, en realidad siguen usándose de forma habitual en la industria, para animar toda clase de criaturas que se mueven tanto en solitario como en “bandada”.

Propuesta

La práctica consiste en desarrollar un prototipo de IA para Videojuegos, dentro de un entorno virtual con obstáculos y con un avatar controlado por el jugador, donde representamos el movimiento dinámico de una manada de ratas, y el del perro. Este último perseguirá al flautista por regla general, con control de llegada. Las ratas de la manada, si el flautista no está tocando su flauta, merodearán por el escenario, y si la está tocando, cada rata que perciba el sonido de la flauta se dirigirán hacia él, en formación con las demás y controlando también la llegada, hasta quedar como “hipnotizadas” a su alrededor.

El punto de partida propuesto para esta práctica, con la documentación e implementación (código y recursos audiovisuales) necesaria, se encuentra en este repositorio de GitHub: IAV-Movimiento.

Las características principales del prototipo son:

A. Hay un mundo virtual con obstáculos (Hamelín) donde se ubican tanto el avatar controlado por el jugador mediante el ratón (incluyendo el tocar la flauta con clic derecho), como el agente que lo acompaña y la bandada de agentes que lo siguen (sólo cuando está tocando). La interfaz permitirá introducir un número N y pulsar un botón para agregar todos esos agentes a la bandada y otro diferente para destruirlos.

B. El avatar (flautista) es acompañado por su perro, una persecución constante con predicción (dinámica) y control de llegada para quedarse a una cierta distancia del avatar. El perro encara según su movimiento.

C. Tu acompañante (perro) huye de las ratas cuando hay más de dos ratas demasiado cerca de él.

D. Cada agente de la bandada (manada de ratas) merodea de manera individual (con un movimiento errático, desordenado), siempre y cuando el flautista no esté tocando la flauta.

E. Cuando el flautista toca la flauta, se produce el desplazamiento en bandada (hipnosis) de las ratas, con movimiento dinámico en formación (seguimiento, cohesión y separación) y control de llegada hasta las proximidades del flautista cuando esté tocando su flauta. En este caso las ratas encaran al flautista.

Condiciones

A la hora de desarrollar el proyecto es obligatorio:

• Atenerse a nuestras recomendaciones generales en la realización de prácticas.
• Documentar claramente los algoritmos, heurísticas o cualquier “truco” utilizado. La documentación deberá ser adecuada (datos correctos, resumen completo del enunciado, descripción del punto de partida con suficiente detalle, investigación de posibles referentes…) e incluir el diseño de la solución mediante diagramas y/o pseudocódigo de Millington (similar a Python), así como el reparto del trabajo y el esfuerzo.
• El ejecutable será práctico y fácil de usar, comprendiendo -con la calidad mínima esperable en el prototipo de un videojuego- las características principales anteriormente descritas, además de los recursos audiovisuales adecuados para representar el entorno y a los distintos agentes.
• Diseñar y programar de la manera más organizada, genérica y elegante posible, separando totalmente la parte visual e interactiva del juego (preferentemente programada en Visual Scripting), del modelo y las técnicas de IA implementadas (preferentemente programadas en C#). Sin olvidar los comentarios. 
• Utilizar únicamente las herramientas de Unity y a lo sumo los plugins de terceros proporcionados por los profesores, sin reutilizar código ajeno a estos.
• Limitarse, en la medida de lo posible, a los recursos del punto de partida proporcionado por el profesor, evitando el uso de recursos audiovisuales pesados, extraños, o que ralenticen la ejecución.
• Personalizar la interfaz con el número de grupo, nombre de los alumnos u otros rasgos inequívocos que subrayen la autoría sobre el resultado.
• Para realizar las pruebas y facilitar las revisiones de los profesores, intentando aprovechar el esfuerzo de desarrollo, conviene crear una interfaz gráfica cómoda para mostrar distintos escenarios de ejemplo, instrucciones de uso, etc. Por ejemplo, habilitando una “consola de trucos” (o teclas rápidas) que permitan ver los datos de los desarrolladores, reiniciar la ejecución, cambiar la cámara, establecer situaciones específicas para hacer pruebas, hacer invencible al avatar, etc. El manejo debe ser ágil e intuitivo para poder realizar rápidamente todas las pruebas con aquellas variaciones que puedan resultar interesantes.
• El prototipo debe ser funcional y su manejo usable, preferiblemente con mando y con teclado, para poder realizar de manera rápida, intuitiva y frecuente todas las pruebas necesarias.

Revisión

Tener el repositorio a disposición de los profesores con todos los entregables, preparados en tiempo y forma por todos los miembros del grupo de manera equitativa, supone un 10% de la nota de la práctica. Los profesores tendrá una lista con los datos de todos los grupos y los enlaces a las organizaciones en GitHub (por ejemplo IAV23-G02, la del grupo 2 del curso Inteligencia Artificial para Videojuegos 2022-2023) donde se encontrarán los repositorios de las prácticas (IAV23-G02-P1, IAV23-G02-P2, etc.).

Los entregables son:

• Documentación del proceso de producción según la estructura habitual, en el README.md. Supone un 10% de la nota.
• Todos los ficheros de código fuente y recursos del proyecto Unity. Se incluirá un enlace a una carpeta compartida con los profesores de Google Drive (llamada por ejemplo IAV23-G02-P1) desde donde descargar todo lo que por peso o problemas de licencia no deba mantenerse alojado en GitHub. Se tendrán en cuenta las buenas prácticas de desarrollo software (commits frecuentes en la rama principal, organización de recursos en el proyecto y de objetos en la escena, escritura sistemática de los comentarios, etc.). Supone un 20% de la nota.
• Fichero con la versión ejecutable para Windows de 64bits (llamado por ejemplo IAV23-G02-P1 1.0.0.zip), publicada como “lanzamiento” en el repositorio. Cada característica del prototipo (A, B, C, D y E) correctamente implementada supone un 10% de la nota. Además se dejará constancia de sus posibilidades mostrando por pantalla aquellas métricas que permitan valorar la eficiencia de la implementación: en este caso, número de ratas y ratio de fotogramas por segundo.
• Enlace a un video oculto en YouTube (llamado por ejemplo IAV23-G03-P1), de menos de 5 minutos de duración, donde quede documentado y comentado por voz y/o subtítulos todo el banco de pruebas realizado. Deberá estructurarse por características (de modo que la sección A1 sea la primera prueba de la característica A, la sección C3 la tercera prueba de la característica C, y así sucesivamente). Supone un 10% de la nota.

Más información

Además de la bibliografía recomendada, se pueden investigar las siguientes referencias. En ningún caso se debe replicar código de terceros sin entenderlo bien y “hacerlo nuestro”, y siempre asegurándonos de que funciona exactamente como se requiere en esta práctica.

• Unity 2018 Artificial Intelligence Cookbook, Second Edition (Repositorio)
  https://github.com/PacktPublishing/Unity-2018-Artificial-Intelligence-Cookbook-Second-Edition 
• Unity Artificial Intelligence Programming, 5th Edition (Repositorio)
  PacktPublishing/Unity-Artificial-Intelligence-Programming-Fifth-Edition: Unity Artificial Intelligence Programming – Fifth Edition, published by Packt (github.com)

Se pueden realizar ampliaciones para ir más allá en el aprendizaje.

• Coloca los obstáculos pseudoaleatoriamente en cada ejecución, utilizando una secuencia de Halton o generando procedimentalmente el terreno mediante el algoritmo de ruido de Perlin. La interfaz permitirá introducir un número de obstáculos y pulsar un botón para generarlos u otro diferente para destruirlos.
• Añade varios flautistas y varios generadores de ratas en el escenario, para que varios jugadores “compitan” a la vez con sus instrumentos por llevarse el mayor número de ratas tras ellos.
• Añade percepción al perro mediante el sentido de la vista al perro, para que se evada de las ratas por verlas y no únicamente por proximidad.
• Haz que el perro y las ratas también eviten obstáculos con suficiente antelación. Puedes incluso desarrollar un gestor sensorial  para centralizar la percepción de todos los agentes.