Categorías
Informática Universitario Videojuego

Batalla en el Desierto

El trasfondo de esta práctica será el universo de ciencia ficción que Frank Herbert inauguró en su exitosa novela Dune, publicada en 1965. La épica batalla final de los Fremen contra las fuerzas del Emperador y el Barón Harkonnen en el planeta desértico Arrakis servirá para poner a prueba las técnicas de IA para Videojuegos sobre Evaluación y Coordinación que hemos estudiado. Diez mil años en el futuro, en nuestra misma galaxia, encontramos este planeta, también llamado Dune, que es el hábitat natural de los Gusanos de Arena, unas criaturas gigantes que surcan sus arenas. Sólo en este rincón del universo es posible extraer la especia conocida como melange, una droga que alarga la vida e incluso despierta poderes psíquicos en las personas que se ven afectadas por ella. Uno de los personajes principales de la historia es Paul Atreides, miembro de una estirpe nobiliaria caída en desgracia, que poco a poco se revelará como el Kwisatz Haderach, una especie de “mesías” que liderará la revolución del pueblo nativo de Arrakis, los Fremen, contra aquellos que explotan comercialmente los recursos de su planeta y son sus enemigos político-religiosos: el Imperio y sus socios de las Grandes Casas feudales que existen en la galaxia, como la liderada por el sádico Barón Vladimir Harkonnen.

«Se habla de que han fortificado los poblados del graben hasta tal punto que no conseguiréis nada contra ellos. Dicen que sólo necesitan sentarse tranquilamente tras sus defensas y dejar que vosotros os agotéis en fútiles ataques.
—En otras palabras —dijo Paul—, se han inmovilizado.
—Mientras que vosotros podéis ir a donde os plazca —dijo Gurney.
—Es una táctica que he aprendido de ti —dijo Paul—. Han perdido la iniciativa, y esto quiere decir que han perdido la guerra.
Gurney sonrió con una sonrisa de complicidad.
—Nuestro enemigo se encuentra exactamente donde yo quiero que esté —dijo Paul. Miró a Gurney—. Bien, Gurney, ¿quieres enrolarte conmigo para el final de esta campaña?
—¿Enrolarme? —Gurney le miró sorprendido—. Mi Señor, nunca he dejado tu servicio. […]«

Fragmento de Dune (1965), de Frank Herbert

El prototipo se va a construir en torno a un pequeño juego de estrategia en tiempo real en el que pueden enfrentarse varios ejércitos, concretamente el bando Fremen contra las fuerzas Harkonnen. El controlador de cada ejército puede dar órdenes a las distintas unidades que posee para extraer recursos, moverse y atacar a sus enemigos. También puede usar sus instalaciones para crear nuevas unidades, si ha obtenido los recursos necesarios para ello. Este juego ya trae resuelta la percepción, el movimiento, la navegación y hasta las decisiones básicas de los agentes inteligentes que hay detrás de las distintas unidades, en forma de árboles de comportamiento. Por lo tanto, habrá que desarrollar un sistema en el que, sobre los agentes inteligentes, añadimos un controlador basado en IA. Este controlador podrá jugar de forma autónoma tomando decisiones según la situación táctica del escenario de batalla que se encuentre a cada momento, intentando acabar con las unidades de su rival antes de verse destruido por ellas.

Este prototipo servirá para probar el modelo de IA multicapa (controlador por arriba, y unidades por debajo), coordinando los distintos agentes gracias a realizar una evaluación o análisis del terreno en el controlador mediante una implementación en Unity de la técnica conocida como mapa de influencia.

Propuesta

La práctica consiste en desarrollar un prototipo de IA para Videojuegos, en forma de controlador automático de uno de los dos bandos enfrentados en el escenario de batalla del juego de estrategia en tiempo real proporcionado por el profesor. Este controlador deberá usar, al menos, un mapa de influencia (elaborado con los datos de ambos bandos) para tomar mejores decisiones sobre qué órdenes dar a sus unidades e instalaciones en cada momento. Se pueden programar tantas clases como sean necesarias, aunque dicho código debe reunirse bajo una misma carpeta y espacio de nombres, y en todo momento hay que adaptarse a las interfaces y el funcionamiento de la infraestructura proporcionada por el profesor, sin modificar dicho “código base” ni acceder a él para “hacer trampas” (esto es, sin modificar la situación de uno u otro bando de maneras que no sean las permitidas y contempladas en la documentación de la API proporcionada).    

Captura del juego de estrategia en tiempo real utilizado como punto de partida. Las unidades extractoras, exploradoras y destructoras del pueblo Fremen son amarillas, mientras que las de la Casa Harkonnen son azules. Las instalaciones base y de procesamiento también llevan un estandarte del color correspondiente. Las torretas y poblados de los graben son verdes.

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-Coordinacion.

Hay un escenario por defecto ya preparado para su navegación, utilizando mallas de navegación junto a la percepción y el movimiento dinámico de Unity. Aunque debe conservarse ese escenario por defecto para realizar allí pruebas de funcionamiento, el controlador debe estar totalmente desacoplado de cualquier escenario concreto y ser capaz de funcionar sobre otros escenarios sustancialmente modificados, siempre que cumplan una serie de condiciones razonables:

  • Aunque pueda haber pendientes, la navegación es posible para todas las unidades entre cualquier par de puntos del escenario, no hay zonas inconexas. 
  • No hay recursos (campos de melange) superpuestos ni en distribuciones rebuscadas. Para que la batalla sea justa se debe buscar cierta simetría en dicha distribución.
  • Aunque haya poblados graben que no puedes atravesar, es posible destruirlos si reciben 10 puntos de daño. Las torretas graben además atacarán a cualquier unidad que se les acerque. Soportan 20 puntos de daño y causan 1 cada medio segundo (2 DPS).
  • Podrá haber obstáculos sobre los que no se pueda navegar (típicamente dunas), estáticos e indestructibles, a diferencia de las instalaciones, unidades, poblados y torretas, que no puedes atravesar pero sí pueden destruirse. 
  • Hay suficiente espacio inicial entre todas las instalaciones, torretas y poblados, e incluso entre las unidades que comienzan situadas en el escenario desde el principio y que, naturalmente, también deberían suponer un reparto equitativo de fuerzas.

En cuanto a las instalaciones y unidades de que disponen todos los controladores del juego, y al tipo de comportamientos que tienen, se ofrecen detalles a continuación:

  • La instalación base es un edificio que hace las veces de barracón del ejército. Se le puede solicitar la creación de una nueva unidad de alguno de los tres tipos posibles: extractora, exploradora o destructora. Los requisitos para que dicha creación sea posible es que la instalación cuente con dinero (solaris) suficiente para ello y que no se supere el límite máximo de ese tipo de unidades. Puede recibir 100 puntos de daño antes de destruirse. Si se pierden las instalaciones base, se pierde la partida.
  • La instalación de procesamiento es otro edificio que hace las veces de refinería del ejército. Se encarga de la conversión de la especia extraída en solaris, pero en realidad no se le puede solicitar hacer nada. Puede recibir 50 puntos de daño antes de destruirse.
  • La unidad extractora es la responsable de extraer la especia melange de los campos donde esta se encuentra. Se le puede solicitar que se mueva a cierta posición, de modo que cuando se topa con estos campos, se pone a extraer. Tras realizar su trabajo, la unidad extractora irá a devolver su carga a la instalación de procesamiento, haciéndonos ganar los solaris correspondientes a los recursos extraídos. Salvo nueva orden, esta unidad repite el proceso indefinidamente e irá una y otra vez a ese mismo campo de especia a trabajar. En cada viaje se obtienen recursos por valor de 1.000 solaris. Puede recibir 10 puntos de daño antes de destruirse. Su fabricación cuesta 10.000 solaris y como máximo un controlador puede llegar a tener 5.
  • La unidad exploradora es ágil para moverse por el escenario y también sabe combatir. Se le puede solicitar moverse a cierta posición y, o bien permanecerá allí inmóvil si la zona es tranquila, o atacará la instalación o unidad enemiga que encuentre cerca, así como la torreta o poblado graben que se interponga en su camino, hasta que dicho objetivo sea destruido. Tiene tendencia a perseguir a su objetivo si esta es una unidad enemiga que huye, y a contestar a su agresor, si en algún momento es atacado por una torreta o alguna otra unidad. Causa 1 punto de daño cada medio segundo (2 DPS) y puede recibir 5 puntos de daño antes de destruirse. Cuesta 15.000 solaris y como máximo se pueden tener 30.
  • La unidad destructora es similar a la exploradora, más poderosa y resistente, pero también más lenta. Funciona de manera similar, aunque no persigue objetivos ni contesta a agresores, tendiendo más a centrarse únicamente en su objetivo a abatir. pero causa muchísimo más daño a los enemigos. Ataca causando 10 puntos de daño cada 2 segundos (5 DPS). Puede recibir 20 puntos de daño antes de destruirse. Cuesta 30.000 solaris y al mismo tiempo sólo se pueden tener 10.

El controlador automático representa al mando táctico supremo, una especie de “capitán general” de todo el ejército. Lo que tiene que hacer la IA que implementa dicho controlador es dar órdenes a las unidades de su propio ejército, al igual que a su propia instalación base. Esto lo puede hacer en todos los fotogramas o cada cierto periodo de tiempo (ej. utilizando corrutinas), pero teniendo en cuenta que las unidades necesitan tiempo para completar sus acciones y que las órdenes muy seguidas, si son contradictorias, pueden resultar contraproducentes y producir bloqueos. 

Para poder dar órdenes contando con información táctica es necesario sondear el entorno, el estado del escenario y de las distintas instalaciones y unidades que allí operan, tanto propias como ajenas. La única técnica que debe ser usada obligatoriamente es la de la creación de un mapa de influencia, con un esquema de división de baldosas, por ejemplo, que permita conocer las zonas más o menos seguras, más o menos apropiadas para realizar según qué acciones. Para facilitar la depuración y la corrección, este mapa de influencia debe dibujarse de alguna manera sobre el escenario, reservando la teclas F, G y H para poder mostrar u ocultar la influencia de los Fremen, Graben o Harkonnen, respectivamente.

Las características principales del prototipo son:

A. En una primera ejecución, sin necesidad de tocar nada, vemos una batalla completa e idealmente emocionante en la que el controlador automático se enfrenta a sí mismo en el escenario por defecto del juego de estrategia en tiempo real proporcionado por el profesor.

B. A continuación se puede lanzar una nueva y sorprendente variante del escenario desarrollada por vuestro grupo donde probar el controlador automático, permitiendo enfrentar al controlador de IA contra un jugador humano, además de contra sí mismo (con los mismos o diferentes parámetros); siempre en batallas 1 contra 1.

C. Se puede visualizar a voluntad el mapa de influencia utilizado, y ver en tiempo real cómo se van actualizando las influencias según cambia la situación táctica del juego.

D. Se demuestra cierta robustez en el funcionamiento del controlador, que trata de evitar la inactividad o los bloqueos de sus unidades, así como cierta capacidad de reacción a la hora de defenderse del enemigo y cierta proactividad a la hora de atacarlo para tratar de ganar la partida.

E. Se demuestra mediante pruebas diseñadas a tal efecto un nivel de competencia razonable en el juego, aprovechando el tiempo y los recursos disponibles, venciendo sin problemas a controladores incompetentes, sean humanos o no. También queda patente la capacidad de adaptación tanto a diversas situaciones iniciales (empezar con o sin muchas unidades, con o sin mucho dinero, etc.) como a cambios bruscos en la situación táctica de la batalla (pérdida de las unidades, carencia total de solaris, etc.)

Condiciones

A la hora de desarrollar el proyecto es obligatorio:

  • Atenerse a nuestras recomendaciones generales en la realización de prácticas. En este caso en el código se debe separar todo lo relativo al controlador y al mapa de influencia en una subcarpeta RTSGXX dentro de la carpeta Scripts.
  • 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 visualmente), del modelo y las técnicas de IA implementadas (preferentemente programadas en C# o con herramientas de autoría específicas). Sin olvidar los comentarios en los encabezados y a lo largo de todos los métodos.  En este caso, restringirse a la programación del controlador automático y del mapa de influencia, sin modificar sustancialmente el código ya proporcionado por el profesor.
  • 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 en el contenido del juego 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-P4) 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 en todas las clases y métodos, etc.). Supone un 20% de la nota.
  • Fichero con la versión ejecutable para Windows de 64bits (llamado por ejemplo IAV23-G02-P4 1.0.0.zip), publicada como «lanzamiento» en el repositorio. Aunque lo importante es agrupar todo el código del controlador y del mapa de influencia en la carpeta RTSGXX con el espacio de nombres es.ucm.fdi.iav.rts.gXX) para poderlo copiar sobre otro proyecto. 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, unidades activas de cada bando, unidades eliminadas, instalaciones activas, instalaciones eliminadas, proporción de influencia de cada bando a lo largo de la batalla e incluso duración temporal de la misma.
  • Enlace a un video oculto en YouTube (llamado por ejemplo IAV23-G03-P4), 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.

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

  • Mejora aspectos del escenario, añadiendo sonidos o efectos visuales para mejorar su estética, manteniendo la estructura del código sin cambios. 
  • Mejora aspectos de la interfaz y el control para el jugador humano, arrancando con un menú que permita configurar los contrincantes y las condiciones de la batalla a ejecutar.
  • Mejora aspectos del movimiento y la navegación de las distintas unidades, aunque en ningún caso valdrá asumir que esas son las condiciones normales para las pruebas.
  • Añade gusanos de arena, que se mueven lentamente por el nivel y tienen tendencia de ir hacia las instalaciones, causando daños al colisionar con otras entidades. 
  • Mejora el controlador para jugadores humanos, de manera que recibas feedback visual y sea posible precisar la posición a la que mandar moverse a las unidades seleccionadas.
  • Localiza puntos de ruta tácticos para que las unidades naveguen mejor por el escenario.
  • Realiza un análisis táctico de otro tipo distinto al de la creación de mapas de influencia.
  • Coordina la acción de varias unidades de tu ejército, realizando jugadas predefinidas.
  • Extiende la inteligencia del controlador para poder combatir en batallas N contra N.

    Evaluación y coordinación