Page type: Práctica

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

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.

• Code Monkey: Control Units and Give Orders (Unity RTS Tutorial) (2020)
• Opsive, Behavior Designer
  https://opsive.com/assets/behavior-designer/
• Unity, Bolt Visual Scripting
  https://docs.unity3d.com/bolt/1.4/manual/index.html
• Unity, Navegación y Búsqueda de caminos
  https://docs.unity3d.com/es/2021.1/Manual/Navigation.html
• 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.

• 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 novela gótica más popular del periodista y escritor francés Gastón Leroux nos sirve como pretexto para abordar el tema de la Decisión en Inteligencia Artificial para Videojuegos. El personaje que da nombre a la novela es, más que un villano, un antihéroe. Erik es un músico deforme que vive escondido en los subterráneos del Palacio Garnier, la casa de la ópera. Suele encerrarse en una sala secreta para componer su gran obra, y sueña con que sea interpretada por la gran diva del canto Christine Daaé, con la que está obsesionado. Para ello, no dudará en secuestrarla y obligarla a memorizar el libreto si hace falta: tiene hasta la celda preparada. Sin embargo existen dos obstáculos importantes para los planes del monstruo. El primero es el público de la ópera pues, debido a su aspecto, Erik odia ser visto por otras personas (que suelen aterrorizarse al verle) y prefiere permanecer en el anonimato; por eso se desplaza utilizando pasadizos ocultos y pequeñas barcas con las que cruza las zonas inundadas de los sótanos del edificio, siendo capaz de derribar las lámparas del patio de butacas con tal de ahuyentar a los espectadores. El segundo obstáculo que enfrenta Erik es el vizconde Raoul de Chagny, un joven y atractivo pretendiente de Christine que hará todo lo posible por frustrar los propósitos del fantasma.

El escenario de la famosa novela de Leroux El fantasma de la ópera (1910) tiene su origen en una ópera real de París sobre la que el autor había escuchado rumores desde que finalizó la construcción del edificio. Los detalles sobre el Palacio Garnier de París y los rumores que lo rodean están estrechamente vinculados en el relato de Leroux. El lago subterráneo sobre el que escribe en su novela es exacto al que se encuentra bajo esta casa de la ópera, y que aún se utiliza para enseñar a los bomberos de la ciudad a nadar en la oscuridad. El infame accidente de la lámpara que acontece en la historia también resultó ser cierto. En general, es verdad que los misterios que Leroux narra en su novela acerca del Fantasma siguen siendo misterios. Sin embargo, él defendió aquellos rumores como ciertos, incluso en su lecho de muerte.

Sobre el autor y el contexto de El fantasma de la ópera (1910)

Esta vez vamos a desarrollar un prototipo centrado en las decisiones del fantasma, que será el agente inteligente con el comportamiento más complejo de este proyecto. Su objetivo es secuestrar a la cantante, llevarla a una celda secreta que tiene preparada para ella, encerrarla allí, y poder así seguir trabajando confiado en su gloriosa (y a la vez interminable) obra maestra. La diva, por su parte, trabaja sobre el escenario aunque en el descanso entre las escenas, se retira a las bambalinas. El fantasma la aterroriza y es incapaz de ofrecer resistencia alguna si la captura. Su amigo el vizconde, por el contrario, la ayuda a volver a las tablas. Precisamente el avatar que controla el jugador es el vizconde, capaz de moverse por todas partes y poner remedio a todos los males que haya podido causar el fantasma (poniéndole trabas a este también). El vizconde recoloca lámparas caídas (viles atentados del fantasma para expulsar al público), rescata a la cantante de su celda, e incluso se puede ensañar con la guarida del fantasma, golpeando los muebles (¡y el piano!) de la sala de música, haciendo enfurecer terriblemente a esta malvada figura. Si, como jugadores, no intervenimos frente a las tropelías del fantasma, este no tardará en ahuyentar al público, secuestrar a nuestra ‘prima donna’, y seguir impunemente con su febril actividad artística.

Este prototipo servirá para probar los paradigmas de toma de decisiones tanto con máquinas de estado como con árboles de comportamiento, los dos más populares de la actualidad. Además se recurrirá a la búsqueda de caminos mediante mallas de navegación, comportamientos de dirección y hasta gestión sensorial, pero esta vez aprovechando todo lo posible las herramientas que trae integradas Unity.

Propuesta

La práctica consiste en desarrollar un prototipo de IA para Videojuegos, dentro de un entorno virtual que represente la ópera de París, con un agente inteligente (el fantasma) que decide, se mueve y actúa según lo que encuentra en sus diferentes estancias, otros agentes más simples como la cantante y el público, y un avatar, el vizconde -némesis del fantasma-, controlado por el jugador.  

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

En el entorno virtual encontramos las siguientes estancias, describiendo también los elementos más relevantes que podemos encontrar en ellas, y su comportamiento:

• Patio de butacas (P). Es la estancia inicial del público,  dividido en dos bloques (este y oeste). Cada bloque chilla a la mínima que vea al fantasma sobre el escenario, pero permanecerá en su sitio salvo que caiga la lámpara gigante del techo correspondiente (hay lámpara este y oeste), en cuyo caso ese lado del patio de butacas se oscurecerá y los espectadores huirán despavoridos al vestíbulo. No regresarán hasta que no se vuelva a colocar su lámpara. Esta estancia está conectada con el escenario (visibilidad y navegabilidad, como indica la arista negra), con el vestíbulo, y es visible desde los palcos este y oeste, aunque el público no puede alcanzar a ver bien si hay alguien en los palcos, ni aunque estén las dos lámparas encendidas.
• Vestíbulo (V). Es la zona más externa de la ópera, donde van los bloques de público cuando se asustan. Simplemente conecta con el patio de butacas.
• Escenario (E). Es la estancia inicial de la cantante, donde se dedica a su oficio, aunque lo intercala (cada pocos segundos) con un descanso que realiza tras las bambalinas, una estancia contigua. Además también conecta con el patio de butacas y los palcos, y es posible dejarse caer por una trampilla al sótano oeste, aunque no sea posible regresar. El fantasma no pisará ninguna estancia como esta mientras haya público mirando. Eso sí, tanto en esta estancia como en otras puede “capturar” (coger al hombro) a la cantante, incluso compartiendo estancia con el vizconde y llevársela a donde quiera, soltándola por voluntad propia o porque se sienta intimidado por el “choque” con nuestro héroe. Si la cantante acaba en una estancia que no esté conectada con el escenario, se sentirá confusa y merodeará (pasando de estancia a estancia aleatoriamente), dejándose “rescatar” por el vizconde en caso de que lo vea cerca, con la esperanza de que la lleve hasta una estancia que conozca, para poder retomar así su ritmo normal de trabajo.
• Bambalinas (B). Estancia donde suele descansar la cantante y que conecta con el escenario, el sótano oeste y que permite deslizarse por una rampa algo oculta al sótano este, sin posibilidad de regresar.
• Palco oeste (Po). Estancia inicial del vizconde, personaje que controla el jugador y que gusta disfrutar desde aquí de la función. El palco tiene una palanca que se puede usar para dejar caer la lámpara oeste del patio de butacas. Conecta con el escenario, con el sótano oeste y permite ver el patio de butacas, aunque debido a la altura no existe visibilidad en el sentido opuesto. El vizconde puede moverse con libertad, como el fantasma, también sobre las barcas cercanas. Puede usar palancas y chocar contra el fantasma, intimidándole y haciendo que retroceda durante unos pocos segundos (y suelte a la cantante si la llevaba). Puede golpear muebles, como los de la sala de música, haciendo un ruido tremendo que se escuchará en toda la zona subterránea. Puede interactuar con una lámpara caída, para arreglarla automáticamente (colocándola en su sitio), y también con la cantante, cogiéndola en brazos automáticamente y llevándola consigo, o dejándola en el suelo a voluntad (interactuando sin que haya una palanca delante ni otra cosa así).
• Palco este (Po). Estancia similar al palco oeste, con una palanca que se puede usar para dejar caer la lámpara este del patio de butacas. Conecta con el escenario, con el sótano este y permite ver el patio de butacas, aunque sin visibilidad en el otro sentido. 
• Sótano oeste (So). Estancia que conecta con el palco oeste, con las bambalinas y con el sótano norte, aunque para recorrer esta conexión hace falta subirse a una barca. Sólo una persona (tal vez con otra al hombro o en brazos) puede montarse sobre la barca a la vez y sólo si esta se encuentra atracada en la orilla de esa estancia. Por defecto, la barca que se necesita aquí comienza atracada en la otra orilla, en la del sótano norte, y aunque en todas las orillas siempre hay una palanca que permite acercarla, el proceso de “recuperar” la barca es algo lento (mayor coste). Se puede llegar a esta estancia desde el escenario, pero no al revés.
• Sótano este (Se). Estancia que conecta con el palco este, y tanto con el sótano norte como con la sala de música donde compone su obra el fantasma, aunque para recorrer estas dos últimas conexiones hacen falta barcas. Por defecto, la barca que lleva al sótano norte sí está en esta orilla, pero la que lleva a la sala de música está en la orilla contraria. Aunque se puede llegar a esta estancia desde las bambalinas, por una trampilla, desde aquí no se conecta con las bambalinas.
• Celda (C). Estancia donde el fantasma deja a la cantante para completar su secuestro con éxito, usando una palanca que activa unas rejas que la impiden salir (y que por supuesto el vizconde podrá desactivar). Conecta con el sótano norte.
• Sótano norte (Sn). Estancia que conecta con la celda, además de con la sala de música, el sótano este y el sótano oeste a través de sus correspondientes tres barcas.
• Sala de música (M). Estancia inicial del fantasma, donde le gusta pasar tiempo componiendo su ópera. Conecta mediante una barca con el sótano este, y con otra con el sótano norte. El fantasma tiene el objetivo principal de secuestrar a la cantante, para lo que intentará buscarla en las bambalinas, en el escenario o si no logra dar con ella, explorando las demás estancias meticulosamente por si estuviera “perdida” por allí. No puede acceder al escenario si hay público mirando, de modo que, como objetivo secundario, necesita tirar las dos lámparas del techo para vaciar del todo el patio de butacas. Sea como sea, una vez atrapada la cantante, la llevará consigo hasta la celda, intentando usar siempre el camino con menor coste (recordando la última posición de las barcas y del vizconde que conoce, y eligiendo la ruta con menor coste, la que tenga más barcas a su favor y que evite al héroe de esta historia). Cuando llega hasta la celda la soltará allí, activará las rejas e irá hasta la sala de música, permaneciendo allí indefinidamente. Lo único que desconcentra al fantasma cuando está componiendo es escuchar a su musa cantar de nuevo en el escenario, reavivando sus deseos de secuestrarla y encerrarla otra vez en su celda. Por otro lado, si el fantasma llega a percibir el ruido de los golpes del vizconde a su piano, abortará la misión que esté haciendo (soltando a la cantante) y correrá enfurecido hasta allí para dedicar unos segundos a arreglar semejante estropicio. 

Las características principales del prototipo son:

A. Hay un mundo virtual (la casa de la ópera), con un esquema de división de malla de navegación proporcionado por Unity, donde se ubican todos los elementos descritos anteriormente. El vizconde es controlado por el jugador mediante el ratón y un único clic derecho para interactuar con otros elementos. Hay cámaras que siguen a cada uno de los personajes, incluyendo una que nos dé la vista general del entorno.

B. Cada mitad del público huye tras la caída de su lámpara, y regresa en cuanto esta ha sido arreglada. Esto se hace con una navegación y un movimiento triviales, sin apenas decisión.

C. La cantante es un agente inteligente basado en una máquina de estados que pasa del escenario a las bambalinas cuando toca, que puede ser “llevada” por los otros dos personajes hasta otra estancia, que merodea desorientada cuando está en las estancias subterráneas, y que se deja llevar por el vizconde, con la esperanza de reencontrar el escenario y continuar su rutina allí. Tiene navegación, movimiento y percepción sencillos, y decisión mediante máquina de estados

D. El fantasma funciona mediante un árbol de comportamiento complejo, para buscar a la cantante, tirar las lámparas para deshacerse del público, capturar a la chica, llevarla a la celda, activar las rejas para encerrarla, etc.

E. El fantasma también cuenta con un sistema de gestión sensorial para reaccionar a lo que realmente ve (en la propia estancia o en otras que son visibles para él) y oye (el canto de su musa, el grito del público, el ruido de la sala de música…), sin tener que recurrir a información privilegiada sino únicamente recordando lo que ha ido viendo por el mundo.

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 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. 
• 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-P3) 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-P3 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, cantidad de estados en la máquina de estados y de tareas/nodos en el árbol de comportamiento, tareas ejecutadas con éxito y tareas ejecutadas con fracaso, tiempo tardado en completar con éxito cada fase del secuestro fantasmal.
• Enlace a un video oculto en YouTube (llamado por ejemplo IAV23-G03-P3), 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.

• Opsive, Behavior Designer
  https://opsive.com/assets/behavior-designer/
• Unity, Bolt Visual Scripting
  https://docs.unity3d.com/bolt/1.4/manual/index.html
• Unity, Navegación y Búsqueda de caminos
  https://docs.unity3d.com/es/2021.1/Manual/Navigation.html
• 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.

• Crea un escenario con geometría 3D compleja, con portales que unen distintas zonas y saltos insertados en la malla de navegación. Plantea tener un cargador de niveles (construidos modularmente) desde fichero.
• Crea un escenario con mecanismos más complejos, como botones que abren y cierran pasadizos, puertas giratorias, ascensores o rampas controlados por temporizadores, etc. También puedes crear barcas de 2 plazas y hacer que la cantante ocupe su propia plaza y haya que ubicarla debidamente antes de usar la barca.
• Mejora el razonamiento del fantasma sobre el estado y la posición de los distintos elementos (las barcas, la cantante, el vizconde, etc.), de modo que pueda tomar decisiones más inteligentes, considerando los efectos causados por otros personajes.
• Mejora la gestión sensorial, de manera que el fantasma vea y oiga a los personajes no necesariamente compartiendo estancia, razonando también sobre el conocimiento que le aportan esas percepciones, y mostrando realimentación visual para que quede claro lo que conoce el fantasma.
• Plantea incluir varios fantasmas y varias cantantes, funcionando de manera simultánea. Incluso plantea algún nuevo personaje para la historia.

El conocido mito griego del hilo de Ariadna sirve de contexto narrativo para trabajar en el problema de la navegación de entornos virtuales, tan habitual en el mundo de los videojuegos. En la historia tenemos un protagonista, Teseo, en principio heroico, y un villano, el temido Minotauro. Tenemos también el propio entorno donde se encuentran ambos personajes, el laberinto del Minotauro, y por último está el hilo mágico que Ariadna entregó a Teseo. Este hilo tiene la propiedad de burlar el embrujo del laberinto y ayudarnos a salir de él. Aunque en el mito se habla de la victoria de Teseo sobre el Minotauro, aquí vamos a aplicarle la “maldición” que le lanza Ariadna de forma anticipada, para que sea imposible acabar con la dichosa criatura. Lo único que hará el héroe cuando se encuentre próximo al monstruo es combatirlo, lo que en la práctica supondrá ralentizar sus movimientos. 

El segundo canto de El Hilo de Ariadna narra las aventuras de Teseo y su llegada a la isla de Creta, en busca de la cabeza del Minotauro. Ariadna, decidida a salvar al famoso héroe, le entregó un ovillo de hilo para que el laberinto perdiera por completo su secreto, y así Teseo pudiera escapar vivo de la isla. La princesa cretense empezaba a enamorarse perdidamente de él, y este le ofreció todo tipo de promesas que un hombre puede hacerle a una mujer. 
El destino de Teseo estaba escrito, mató al Minotauro y se llevó consigo a Ariadna hasta la isla de Naxos, en la cual se celebró hasta el amanecer la gloria del héroe. A la mañana siguiente, Teseo abandonó a su prometida, mientras ella dormía en la playa. Por eso el canto termina con la maldición que Ariadna realiza sobre su amado…

El mito de El Hilo de Ariadna

En esta ocasión, crearemos un prototipo en el que el jugador controla el movimiento de Teseo por los pasillos del laberinto. La bestia mitológica por su parte será un agente inteligente que se dedica a merodear por allí, siguiendo a Teseo en caso de percibirlo. El hilo de Ariadna funcionará, cuando lo activemos, dibujando una línea blanca el camino de menor coste que lleva a Teseo hasta la baldosa de salida. El hilo, al ser mágico, tiene en cuenta todos los costes, ya que la baldosa donde se encuentra el Minotauro es intransitable, y moverse a las baldosas vecinas al Minotauro (su «zona de influencia») tiene mayor coste que el movimiento a través de una baldosa normal.

Este prototipo aplicará el algoritmo A* como técnica de navegación (búsqueda de caminos con información heurística), muy usada en videojuegos, en combinación con el algoritmo de suavizado de caminos y con los comportamientos de dirección que hagan falta (sean cinemáticos o dinámicos, reutilizados de prácticas anteriores).

Propuesta

La práctica consiste en desarrollar un prototipo de IA para Videojuegos, dentro de un entorno virtual laberíntico, con uno o varios agentes inteligentes que merodean por allí y un avatar, en principio controlado por el jugador. Al activar el hilo de Ariadna, Teseo pasará a ser controlado por la máquina y procederá a salir del laberinto navegando y moviéndose de manera automática, hasta que lo desactivemos. El prototipo será fácilmente usable, y se basará en un entorno de tamaño y complejidad configurable, con habitaciones y pasillos.

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

Las características principales del prototipo son:

A. Hay un mundo virtual (el laberinto del Minotauro) de tamaño y complejidad configurable, con un esquema de división de grafo de baldosas que incluirá una baldosa de entrada, donde se ubica inicialmente el avatar (Teseo) y una baldosa de salida. Debe haber varios caminos alternativos para llegar a la salida, algunos más anchos y la mayoría muy lineales y estrechos (pasillos de una única baldosa de anchura), intentando forzar que sea muy fácil el cruce entre el avatar y el enemigo. El avatar estará controlado manualmente por el jugador, preferiblemente con el clic izquierdo del ratón.

B. En mitad del laberinto están los enemigos (uno o varios minotauros), que realizan un merodeo constante, pasando a perseguir al avatar si lo perciben con la vista o se hayan próximos a él. Debemos mostrar visualmente el área de influencia del minotauro, por ejemplo las baldosas vecinas a la que ocupa este.

C. El camino más corto a la baldosa de salida calculado mediante A* (hilo de Ariadna) se representa pintado con una línea blanca y destacando las baldosas que lo componen con bolitas blancas. Aparece cada vez que se activa la navegación y el movimiento automático del avatar hasta la salida (cosa que ocurre al pulsar el clic derecho del ratón). Desde una opción de la interfaz de usuario será posible elegir la heurística utilizada. Deben tenerse en cuenta cuenta todos los costes, incluido el de la baldosa en la que está el Minotauro y su zona de influencia, cuyas baldosas pueden costar, por ejemplo, 5 veces más que una baldosa normal.

D. Es posible elegir si queremos suavizar o no el camino generado por el algoritmo anterior (activando o desactivando la funcionalidad desde una opción de la interfaz de usuario). Esto reduce las baldosas que forman parte del camino original a la salida, y por tanto también reduce la cantidad de bolitas blancas mostradas.

E. El avatar navega y se mueve automáticamente en dirección a la baldosa de salida mientras está activo el hilo de Ariadna. Este movimiento va haciendo desaparecer la parte del hilo ya recorrido, para que sólo quede la parte del camino que falta por recorrer. Si desactivamos el hilo, el avatar vuelve al movimiento manual habitual, controlado por el jugador.

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 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-P2) 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-P2 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, tamaño del entorno en número de baldosas totales, número de baldosas exploradas, longitud en número de baldosas y coste del camino encontrado, así como el tiempo en milisegundos tardado por el algoritmo en encontrar dicho camino.
• Enlace a un video oculto en YouTube (llamado por ejemplo IAV23-G03-P2), 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.

• Genera procedimentalmente el entorno con verdadera forma de laberinto, utilizando algoritmos específicos para ello. La interfaz de usuario permitirá decidir el número de habitaciones, minotauros o zonas especiales.
• Modifica a los minotauros para que patrullen siguiendo un camino con patrones de vigilancia concretos, o incluso calculando el camino mínimo para llegar a ciertos sitios (por ejemplo para localizar a Teseo, o acercarse a él, al menos). De hecho hasta se podría usar A* para mover al propio Teseo con el simple clic de ratón (aunque eso haría que el hilo de Ariadna -y la práctica entera- deje de tener sentido, jeje…)
• Añade zonas de baldosas con distinto coste al laberinto, como agua, barro, pendientes…
• Permite añadir varias baldosas de salida al laberinto y modifica a Teseo para que, si hay varias salidas, salga por la más cercana, utilizando un algoritmos similar al algoritmo completo de Dijkstra.
• Haz que el hilo cambie de color a amarillo si el minotauro se acerca a él, poniendo en contacto su área de influencia con el camino marcado. En ese caso Ariadna podría “recalcular” el hilo manual (porque se lo pidamos nosotros) o incluso automáticamente. De hecho podría hacerlo sólo de manera parcial, desde donde se ha producido el cambio en adelante.
• Haz que el hilo se «corte» si el minotauro lo cruza, atravesando el camino marcado. Si existe otro camino a la salida que no esté bloqueado, que aparezca un nuevo hilo a esa salida… y si no existe, que se muestre un icono de exclamación con un sonido frustrante, porque el problema no tiene solución ahora mismo.

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.
  

Mixamo es el nombre de una empresa surgida como spin-off de la universidad de Stanford que fue comprada en 2015 por Adobe Systems. Actualmente ofrece una herramienta web que permite descargar personajes 3D con el esqueleto y los aparejos de animación listos, más una librería de animaciones compatibles con estos personajes (por ejemplo se puede seleccionar al personaje Vanguard, una especie de marine espacial, y asignarle la animación Boxing).

La integración de estos recursos en Unreal Engine es uno de los modos más fáciles de tener personajes razonablemente animados para videojuegos (más rápido y sencillo que crearlos con MetaHuman, por ejemplo).

Hasta que un personaje no adquiere personalidad, no puede ser creíble. Sin personalidad, el personaje podrá hacer cosas divertidas o interesantes, pero si la gente no es capaz de identificarse con él, sus acciones parecerán irreales. Y sin personalidad, una historia no puede resultar verdadera para el público.

Walt Disney

Para esta práctica se propone partir de una jugabilidad de disparos y sigilo con vista 3D en primera persona, como lo desarrollado en prácticas anteriores, y mediante el uso de recursos de Starter Content y otros paquetes (ej. a través de Mixamo), conseguir personajes animados y múltiples efectos visuales. Principalmente se trata de que el protagonista y los enemigos manifiesten estéticamente una gran «ferocidad» en el combate y una gran capacidad de destrucción y espectacularidad al ser destruidos (luces, chispas, fuego, sonidos contundentes, etc.).

Los androides no sólo estarán animados de manera diferente según estén quietos, caminen o corran -al detectarnos y perseguirnos-, sino que también podrán golpear o incluso disparar (tanto al jugador como a ciertos obstáculos que necesiten apartar de su camino -puertas, por ejemplo-) y tendrán también animación específica de muerte. Al surgir de los generadores, por ejemplo, habrá mucha luz, sonido y descargas eléctricas. También saltarán chispas cuando sufren daños (e irán funcionando de manera más errática y lenta, al estar estropeados) y finalmente habrá explosiones y -con cierta probabilidad- incendios cuando un androide es destruido, que pueden propagarse y afectar a otros personajes.

Propuesta

La práctica consiste en ampliar y pulir el prototipo ejecutable de un videojuego de disparos 3D para un sólo jugador que habíamos hecho en la práctica anterior. De hecho, el punto de partida es el resultado de la práctica Invasión Androide, pudiendo usar el contenido de paquetes como Starter Content, Infinity Blade: Effects o M5 VFX Vol2. Fire and Flames, y de otras plantillas como Third Person.

Las características principales del prototipo son:

A. Algún androide (el protagonista o alguno de los enemigos) usará una malla esqueletal diferente para ser representado, incluyendo animaciones para estar quieto, caminando o corriendo.

B. Los generadores de androides tendrán algún tipo de animación, aunque sea sencilla y efectuarán un «espectáculo» de luz, efectos y sonido al producir un nuevo enemigo.

C. Algún androide tendrá la capacidad de atacar, ya sea golpeando o disparando algún tipo de proyectil. Estos ataques no serán únicamente contra el jugador sino que con cierta frecuencia veremos efectuarlos furiosamente sobre obstáculos de algún tipo (paredes, puertas, cubos o mobiliario sueltos, etc.).

D. Los androides irán recibiendo un daño gradual hasta su destrucción total, soltando quizá chispas al ser dañados y estropeándose cada vez más a nivel visual y funcional también.

E. Al ser destruido algún androide puede producirse una gran explosión, generándose un incendio de una duración determinada capaz de propagarse a otros elementos del juego y llegar incluso a afectar a otros personajes si entran en contacto durante suficiente tiempo con el fuego, tanto enemigos como al propio jugador.

Condiciones

A la hora de desarrollar el proyecto es obligatorio:

• No utilizar herramientas o plugins de terceros, ni reutilizar código distinto del proporcionado por Unreal Engine o el propio profesor, a través de las sugerencias de este enunciado.
• Limitarse a los recursos de las plantillas y paquetes mencionados. Personalizar el contenido con el número de grupo, nombre de los alumnos u otros rasgos inequívocos que subrayen la autoría sobre el resultado. Evitar en cualquier caso un uso excesivo de recursos audiovisuales que hagan el proyecto pesado o su ejecución lenta. 
• Documentar en el repositorio el proceso de producción, incluyendo los algoritmos y las estructuras de datos más importantes (mediante enlaces a Blueprints), así como el reparto del trabajo y el esfuerzo.
• Programar los diagramas en lenguaje Blueprint de la manera más organizada, genérica y elegante posible. Sin olvidar los comentarios.
• El prototipo debe ser funcional y su manejo usable, preferiblemente con mando y con teclado, e incluso teclas rápidas para reposicionar a nuestro avatar en zonas diferentes o hacerlo invencible, para poder realizar de manera rápida, intuitiva y frecuente todas las pruebas necesarias.

Revisión

Tener el repositorio a disposición del profesor 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. El profesor tendrá una lista con los datos de todos los grupos y los enlaces a las organizaciones en GitHub (por ejemplo DEV22-G02, la del grupo 2 del curso Desarrollo de Videojuegos 2022-2023) donde se encontrarán los repositorios de las prácticas (DEV22-G02-P1, DEV22-G02-P2, DEV22-G02-P3 y DEV22-G02-P4).

Los entregables son:

• Todos los ficheros de código fuente y recursos del proyecto Unreal Engine. Se incluirá un enlace a la carpeta compartida con el profesor de Google Drive (llamada por ejemplo DEV22-G02-P4) desde donde descargar todo lo que por peso o problemas de licencia no deba mantenerse alojado en GitHub vía Git LFS. Supone un 20% de la nota.
• Documentación del proceso de producción según la estructura habitual, en el README.md. Supone un 10% de la nota.
• Fichero con la versión ejecutable para Windows de 64bits (llamado por ejemplo DEV22-G02-P4 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.
• Enlace a un video oculto en YouTube (llamado por ejemplo DEV22-G03-P3), de menos de 5 minutos de duración, donde queden documentadas y comentadas por voz y/o subtítulos las pruebas realizadas. 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.

• Cookson, A., DowlingSoka, R., Crumpler, C.: Unreal Engine 4 Game Development in 24 Hours, Sams Teach Yourself. Sams Publishing (2016).
• MetaHuman de Epic Games.
• Mixamo de Adobe.
• Romero, M., Sewell, B.: Blueprints Visual Scripting for Unreal Engine: The faster way to build games using UE4 Blueprints, 2nd Edition (2019).
• Unreal Engine Documentation.

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

• Mejorar todo lo posible el contenido del juego, como el entorno, y la programación de la jugabilidad.
• Utilizar técnicas de posprocesado para recrear un ambiente futurista y sombrío, contribuyendo a la estética de destrucción furiosa.
• Incluir alguna cinemática inicial y final del juego.
• Localizar el juego en dos idiomas seleccionables desde el menú: español e inglés. Se asume que habrá algunos mensajes de texto para guiar al jugador durante el juego.

Yo, Robot (I, Robot en inglés) es una película de ciencia ficción estadounidense dirigida por Alex Proyas en 2004. Como en otras historias ambientadas en el universo de Isaac Asimov, se especula con el avance tecnológico futuro y con la proliferación de androides (robots con apariencia humana) por todas partes, ayudando a los seres humanos en la realización de toda clase de tareas. El peligro que acecha en estas historias es que estos androides se “descontrolen” y se conviertan en una seria amenaza para la Humanidad.

Control de mando quiere que luchemos como máquinas, que tomemos decisiones frías y calculadas. Pero no somos máquinas. Y si actuamos como ellas, ¿por qué motivo luchamos?

John Connor en Terminator Salvation

Este tipo de historias servirán de base sobre la que diseñar y desarrollar un juego algo más complejo, con una dinámica de combate con elementos de sigilo, y mecánicas más avanzadas que incluye enemigos inteligentes con comportamiento similar al del jugador humano.

Propuesta

La práctica consiste en desarrollar el prototipo ejecutable de un videojuego de disparos 3D para un sólo jugador, con elementos tácticos como guardar cierto sigilo frente a los enemigos, fuertemente inspirado en los robots y la interacción física con el entorno.

El punto de partida es la plantilla First Person que ofrece Unreal Engine, que recrea un mundo 3D con vista en primera persona y la mecánica del disparo; además se podrá usar el contenido del paquete Starter Content y de otras plantillas, como la Third Person.

Las características principales del prototipo son:

A. El mundo virtual consiste en un único nivel que representa un centro de desarrollo tecnológico de androides que sirve como base de operaciones a un ejército de androides “malvados” que se preparan para invadir la Tierra. Está dividido en tres grandes estancias secuenciales a las que se accede atravesando por la fuerza unas persianas metálicas de seguridad. El jugador controla a un androide “bueno”, al servicio de la Humanidad, cuya misión es infiltrarse en esta base, llegar a la última estancia y destruir todos los prototipos de los nuevos y perversos androides gigantes que están diseñando en la última de las estancias.

B. El androide protagonista puede interactuar con distintos mecanismos físicos, como por ejemplo disparar a un cable para hacer caer un objeto pesado y destruir así alguna persiana de seguridad o un androide enemigo.

C. También puede disparar varias veces a los enemigos y a las cabinas generadoras de enemigos (que también hay), hasta destruirlos. Puede coger y usar recargas de munición repartidas a lo largo del juego, existiendo munición normal y granadas, que se lanzan con una tecla diferente y cuando explotan provocan un impacto físico más fuerte y dañino. El androide «bueno» que controlamos recibe daño al contacto con los enemigos, aunque se recupera de esa pérdida de energía con el tiempo.

D. Los androides enemigos patrullan por sus estancias y son capaces de detectarnos, perseguirnos y pegarse a nosotros para hacernos daño por contacto si antes no les destruimos a ellos, ya sea disparándoles o aplastándoles con algún objeto pesado.

E. Tener enemigos que patrullan por el mundo y son capaces de detectarnos, convocar a otros enemigos cercanos e incluso perseguirnos. El juego será fácil de superar si avanzamos con cuidado, evitando que nos detecten y destruyendo los generadores de enemigos (y pocos o ningún enemigo), pero se volverá muy difícil si jugamos sin tener cuidado, simplemente avanzando y disparando a todos los enemigos. Cada vez que completamos el escenario, este se reinicia aunque en un nivel superior (Nivel 1, Nivel 2, Nivel 3… hasta el infinito). En cada nivel los enemigos se generan con mayor frecuencia, corren más rápido y son más resistentes al daño.

Condiciones

A la hora de desarrollar el proyecto es obligatorio:

• No utilizar herramientas o plugins de terceros, ni reutilizar código distinto del proporcionado por Unreal Engine o el propio profesor.
• Limitarse a los recursos de las plantillas y paquetes mencionados. Personalizar el contenido con el número de grupo, nombre de los alumnos u otros rasgos inequívocos que subrayen la autoría sobre el resultado. Evitar en cualquier caso un uso excesivo de recursos audiovisuales que hagan el proyecto pesado o su ejecución lenta. 
• Documentar en el repositorio el proceso de producción, incluyendo los algoritmos y las estructuras de datos más importantes (mediante enlaces a Blueprints), así como el reparto del trabajo y el esfuerzo.
• Programar los diagramas en lenguaje Blueprint de la manera más organizada, genérica y elegante posible. Sin olvidar los comentarios.
• El prototipo debe ser funcional y su manejo usable, preferiblemente con mando y con teclado, e incluso teclas rápidas para reposicionar a nuestro avatar en zonas diferentes o hacerlo invencible, para poder realizar de manera rápida, intuitiva y frecuente todas las pruebas necesarias.

Revisión

Tener el repositorio a disposición del profesor 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. El profesor tendrá una lista con los datos de todos los grupos y los enlaces a las organizaciones en GitHub (por ejemplo DEV22-G02, la del grupo 2 del curso Desarrollo de Videojuegos 2022-2023) donde se encontrarán los repositorios de las prácticas (DEV22-G02-P1, DEV22-G02-P2, DEV22-G02-P3, etc.).

Los entregables son:

• Todos los ficheros de código fuente y recursos del proyecto Unreal Engine. Se incluirá un enlace a la carpeta compartida con el profesor de Google Drive (llamada por ejemplo DEV22-G02-P3) desde donde descargar todo lo que por peso o problemas de licencia no deba mantenerse alojado en GitHub vía Git LFS. Supone un 20% de la nota.
• Documentación del proceso de producción según la estructura habitual, en el README.md. Supone un 10% de la nota.
• Fichero con la versión ejecutable para Windows de 64bits (llamado por ejemplo DEV22-G02-P3 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.
• Enlace a un video oculto en YouTube (llamado por ejemplo DEV22-G03-P3), de menos de 5 minutos de duración, donde queden documentadas y comentadas por voz y/o subtítulos las pruebas realizadas. 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.

• Metal Gear Solid (Konami, 1998)
• Wolfenstein 3D (id Software, 1992)
• Yo, Robot (20th Century Fox, 2004)

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

• Crear un entorno usando recursos del paquete gratuito Modular SciFi Season 1 Starter Bundle.
• Cambiar el arma y la animación de disparo cuando se lanzan granadas.
• Que los enemigos den la voz de alarma a sus compañeros.

Fantasía es la tercera película de animación hecha por los estudios Disney, estrenada en 1940. Se trata de una obra clásica de la animación, basada en ocho piezas musicales. El aprendiz de brujo es una de estas piezas, en la que Mickey Mouse, tras tomar sin permiso el gorro mágico del brujo, hace un conjuro para «programar mágicamente» a una escoba para que lleve cubos de agua desde la fuente, se duerme y pierde el control de la situación.

Lo más difícil de aprender en la vida es qué puente cruzar y qué puente quemar.

David Russell

La dinámica del juego se basa en resolver pequeños puzles dentro de un juego de plataformas: manejamos al aprendiz en las inmediaciones del caserón del brujo y tendremos que usar nuestros poderes para realizar todas las tareas domésticas que nos ha encargado nuestro maestro. La estética será de ambientación medieval fantástica, cuidando la coherencia del escenario, que estará estilizado como en los dibujos animados, y el detalle y funcionamiento de los objetos interactivos.

Este planteamiento de juego sirve como motivación para seguir trabajando en mecánicas de interacción con objetos y con el escenario, así como mostrar una interfaz de usuario más rica y compleja.

Propuesta

La práctica consiste en desarrollar el prototipo ejecutable de un videojuego de plataformas 2D para un sólo jugador esta vez en forma de aventura con pequeños puzles basados en tareas domésticas y cierta inspiración de la película de Fantasía.

El punto de partida es la plantilla Side Scroller que ofrece Unreal Engine, que recrea un mundo 3D con vista lateral en tercera persona, aunque el movimiento del avatar está restringido únicamente a 2 dimensiones; además se podrá usar el contenido del paquete Starter Content y de Stylized Fantasy Provencal (requiere activar en el proyecto el soporte para textura virtual).

Las características principales del prototipo son:

A. Hay un mundo virtual por explorar que consiste en un único nivel donde está el caserón, con sus distintas tareas domésticas, que se habrán de superar con el movimiento lateral, el salto del avatar que controla el jugador y la activación de ciertos hechizos o el uso de ciertas llaves que añadamos a nuestro inventario. Al principio tendremos un menú inicial con las instrucciones del juego.

B. El avatar usará estos hechizos (en forma de libros de conjuros) y dará vida a objetos inanimados, que se moverán o cambiarán de posición (en principio sin necesidad de cambiar la cámara en tercera persona), eliminando así obstáculos del escenario y permitiendo realizar las tareas encomendadas por el brujo. Cada libro obtenido se verá representado en el HUD.

C. La primera tarea consiste en reparar el carro, al que se le ha estropeado una rueda y está tirado en el suelo. Debemos usar la magia para que una rueda nueva llegue hasta el carro y se coloque en su sitio, reparándolo. Tras conseguir cada misión veremos un pequeño texto de felicitación.

D. La segunda tarea consiste en cargar todos los barriles de cereales en el carro (es suficiente con que haya 2 ó 3). Pesan mucho y habrá que hacerlos «levitar» (manejándolos nosotros) hasta su destino, con cuidado de no chocarlos contra nada. Si se dan golpes van cambiando de color hasta destruirse y «reaparecer» en su posición de inicio.

E. La tercera y última tarea consiste en conducir el carro con los barriles hasta el molino, por un camino algo tortuoso (lo manejamos nosotros y de hecho podemos tener una cámara específica que se dedique a seguir al carro en vez de al personaje protagonista), y hacer que este se active y empiece a «trabajar sólo», mágicamente… se conoce que al brujo le encanta hacer repostería con la harina. En el juego no hay enemigos ni posibilidad de morir. Cuando se consiguen todas las tareas, veremos un menú final que nos permite salir o reiniciar el juego.

Condiciones

A la hora de desarrollar el proyecto es obligatorio:

• No utilizar herramientas o plugins de terceros, ni reutilizar código distinto del proporcionado por Unreal Engine o el propio profesor.
• Limitarse a los recursos de la plantilla y los paquetes mencionados. Personalizar el contenido con el número de grupo, nombre de los alumnos u otros rasgos inequívocos que subrayen la autoría sobre el resultado. Evitar en cualquier caso un uso excesivo de recursos audiovisuales que hagan el proyecto pesado o su ejecución lenta. 
• Documentar en el repositorio el proceso de producción, incluyendo los algoritmos y las estructuras de datos más importantes (mediante enlaces a Blueprints), así como el reparto del trabajo y el esfuerzo.
• Programar los diagramas en lenguaje Blueprint de la manera más organizada, genérica y elegante posible. Sin olvidar los comentarios.
• 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 del profesor 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. El profesor tendrá una lista con los datos de todos los grupos y los enlaces a las organizaciones en GitHub (por ejemplo DEV22-G02, la del grupo 2 del curso Desarrollo de Videojuegos 2022-2023) donde se encontrarán los repositorios de las prácticas (DEV22-G02-P1, DEV22-G02-P2, etc.).

Los entregables son:

• Todos los ficheros de código fuente y recursos del proyecto Unreal Engine. Se incluirá un enlace a la carpeta compartida con el profesor de Google Drive (llamada por ejemplo DEV22-G02-P2) desde donde descargar todo lo que por peso o problemas de licencia no deba mantenerse alojado en GitHub vía Git LFS. Supone un 20% de la nota.
• Documentación del proceso de producción según la estructura habitual, en el README.md. Supone un 10% de la nota.
• Fichero con la versión ejecutable para Windows de 64bits (llamado por ejemplo DEV22-G02-P2 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.
• Enlace a un video oculto en YouTube (llamado por ejemplo DEV22-G03-P2), de menos de 5 minutos de duración, donde queden documentadas y comentadas por voz y/o subtítulos las pruebas realizadas. 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.

• Fantasía (Disney, 1940)

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

• Darle vida al entorno con movimiento, cambio de iluminación según pasa el tiempo, etc.
• Incluir efectos de parpadeo, etc. en todos los hechizos que cogemos u objetos que se ven afectados por los conjuros.