De Unity existen varias licencias de uso, incluyendo algunas gratuitas para estudiantes y aficionados.
También se lanzan nuevas versiones continuamente, que aunque suelen ser compatibles con proyectos anteriores en lo principal, es habitual que surjan problemas de migración. Por ello hay que decidir muy bien cual utilizar y ver cuales son sus requisitos hardware y software.
La empresa cuenta con una plataformas llamada Unity Learn donde puedes encontrar los materiales ideales para comenzar a utilizar este entorno e ir conocimiento y practicando con sus diferentes herramientas.
Más información
Para complementar es recomendable consultar otros documentos.
Unity es un entorno de desarrollo de videojuegos multiplataforma creado por Unity Technologies. Permite trabajar en Windows, Mac OS y Linux, y generar juegos para todo tipo de plataformas incluyendo WebGL.
La empresa fue fundada en 2004 por David Helgason (CEO), Nicholas Francis (CCO) y Joachim Ante (CTO) en Copenhague, Dinamarca. Desde un primer momento se orientó como herramienta para desarrolladores independientes, consiguiendo 1 millón de usuarios en 2008.
Más información
Para complementar es recomendable consultar otros documentos.
Estos son algunos ejercicios que pueden realizarse para practicar lo aprendido en el tema de Cuestiones avanzadas, sobre gestión de la ejecución, interfaz del mundo y herramientas de autoría.
La Figura 1 muestra cómo el gestor de ejecución de un motor de IA organiza la realización de una serie de comportamientos inteligentes, utilizando programaciones para distribuir dichos comportamientos a lo largo de todos los fotogramas del juego. Determina cuáles deben ser las nuevas fases y frecuencias de cada comportamiento de manera que no haya colisiones entre ellos y que cada uno se ejecute con la misma asiduidad.
En la Figura 2 que se muestra a continuación, ¿cuál sería la mejor fase a utilizar si queremos añadir un nuevo comportamiento que se ejecutará con frecuencia de 2 fotogramas? ¿Por qué podría considerarse injusto incluir el fotograma 10 en tus cálculos?
Escribe el pseudocódigo de una estación de sondeo como solución para el Interfaz del mundo entre el motor de IA y el entorno virtual donde operan los agentes.
Escribe el pseudocódigo de un gestor de eventos como solución para el Interfaz del mundo entre el motor de IA y el entorno virtual donde operan los agentes.
La Figura 3 muestra la representación visual de un fichero de registro (log) como el que podría generarse con puntos de guardado de un nivel que es visitado durante una sesión de juego. ¿Qué problemas podrían ocurrir si este fichero de registro fuese usado para generar automáticamente un grafo de puntos de ruta? ¿Qué información adicional podríamos guardar en el fichero de registro para resolver el problema?
Figura 1: Programaciones de comportamientos A, B y C.
Figura 2: Programaciones de comportamientos en general.
Figura 3: Registro de puntos de guardado de partida en un nivel durante una sesión de juego.
Las herramientas de autoría son una pieza fundamental en la infraestructura de un motor de IA para Videojuegos, ya que con ellas trabaja todo el equipo de diseñadores (técnicos) de lógica del juego para especificar comportamientos, estados, comunicaciones, etc.
Para centralizar la percepción de los agentes y otras cuestiones, es buena idea implementar una interfaz del mundo entre el entorno virtual y el motor de IA, con todos sus comportamientos algorítmicos.
Como parte de una buena infraestructura de un motor de IA para Videojuegos, conviene implementar algún sistema que permita gestionar la ejecución de la manera más eficaz posible.
Estos son algunos ejercicios que pueden realizarse para practicar lo aprendido en el tema de Evaluación y Coordinación, sobre puntos de ruta tácticos, análisis de terreno, acción coordinada, etc.
La Figura 1 muestra un mapa con algunos puntos de ruta tácticos sin etiquetar. Etiqueta los puntos que pueden proporcionar cobertura, puntos donde el personaje quedará expuesto al enemigo, puntos que podrían ser útiles para organizar emboscadas, etc.
Supón que definimos la propiedad táctica compuesta de ser “buen punto para francotiradores” como una combinación tanto del nivel de cobertura como del de visibilidad que tiene un punto de ruta, en principio propiedades tácticas primitivas e independientes. Asume que en lugar de darnos valores concretos para estos niveles nos proporcionan probabilidades, de este modo: Cobertura = 90% Visibilidad = 70% Indica la probabilidad que tiene dicho punto de ser un “buen punto para francotiradores”.
La Figura 2 muestra un mapa con algunos puntos de cobertura. Añade información extra en los dos puntos de cobertura A y B sobre las direcciones (norte, sur, este y oeste) en las que el personaje necesitado de cobertura estará cubierto con respecto a los dos enemigos. Después, compara los resultados obtenidos con los que se obtendrían mediante la realización de un paso de post-procesado (cálculos extra) que utilice pruebas de línea de visión apropiadas (proyección de rayos) entre los puntos de cobertura y los dos enemigos.
Observa el mapa de influencia de la Figura 3 que contiene unidades militares del ejército blanco y del negro. Utiliza la siguiente fórmula de caída lineal de la influencia para calcular la influencia de ambos ejércitos en todas las baldosas del mismo: Id = Io / (1 + d)2 siendo Id la influencia a distancia d e Io la influencia a distancia 0. Utiliza la distancia Manhattan y asume un radio máximo de influencia de 2 baldosas para todas las unidades militares.
Utiliza el mapa de influencia de la Figura 3 para indicar qué baldosas domina el ejército blanco (B) y qué baldosas domina el ejército negro (N). Identifica alguna baldosa en la frontera del ejército negro por la que sería conveniente iniciar un ataque.
Describe las acciones coordinadas entre personajes que se requieren para que una escuadra militar avance con precaución por un pasillo hasta una bifurcación y gire a la izquierda, según la táctica militar expresada en la Figura 4.
Describe en qué fases se divide la generación de lenguaje natural compleja y realista.
Figura 1: Puntos de ruta tácticos.Figura 2: Puntos de cobertura.Figura 3: Mapa de influenciaFigura 4: Acción coordinada.
Unity ofrece un sistema de navegación integrado que permite organizar las escenas según un esquema de división de malla de navegación, y tener agentes que sepan moverse por dicha malla con soltura.
La malla de navegación se divide en áreas de navegación, cada una de las cuales puede tener un cierto factor de coste (para ser multiplicado por la distancia recorrida) y un tipo (Walkable, Not Walkable, Jump o uno personalizado), para por ejemplo impedir -usando una máscara- que ciertos agentes naveguen usando las áreas de ciertos tipos.
Cada agente además, mientras está activo, puede sobreescribir el coste de algunas áreas de navegación mediante programación (método SetAreaCost)… lo cual es útil para establecer diferencias entre la manera más «conveniente» de navegar de cada agente.
Más información
Para complementar es recomendable consultar otros documentos.
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 controladores 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 lanzaruna nueva y sorprendente variante del escenariodesarrollada 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.
La comunicación en lenguaje natural siempre ha sido uno de los sueños de la IA, y en videojuegos, aunque no haya cosechado grandes éxitos, tenemos ejemplos de uso de estas tecnología.
