Categorías
Informática Universitario Videojuego

Furia y Fuego

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.
Categorías
Universitario Videojuego

La Fortaleza

El videojuego de disparos en primera persona (en inglés, First-Person Shooter o FPS) es un subgénero de acción que obtuvo gran popularidad con la revolución multimedia de los años 90, en parte gracias a los avances en gráficos 3D y al desarrollo del modo multijugador competitivo en línea. Wolfenstein 3D (1992) suele mencionarse como un arquetipo del género y Doom (1993) como uno de sus ejemplos más populares e influyentes.

Aunque hoy día casi todos los entornos de desarrollo cuentan con plantillas para desarrollar videojuegos FPS, su jugabilidad (aunque clásica) sigue resultando apasionante para muchos jugadores y a menudo es el contenido (y todos los detalles del pulido) lo que diferencia una apetecible obra del género de otro “clon” mediocre y aburrido.

Se debe ponderar y deliberar antes de hacer un movimiento. Conquistará quien haya aprendido el arte de la desviación. Tal es el arte de las maniobras.

Sun Tzu

En esta práctica tomamos como punto de partida FPS Microgame, un microjuego que proporciona las mecánicas fundamentales de los FPS. Además nos vamos a centrar exclusivamente en el diseño de contenido (principalmente una fortaleza enemiga, estructurada en niveles) hasta dar forma a un videojuego completo con una duración muy limitada, eso sí. La manera de “dosificar” el contenido a lo largo de una sesión de juego, distribuyéndolo por el mundo ficticio, será clave para valorar si se ha conseguido la mejor experiencia de juego posible, exprimiendo al máximo el material de partida.

Propuesta

La práctica consiste en desarrollar un pequeño videojuego FPS completo con la cantidad y calidad mínima de contenido como para ofrecer una experiencia de juego interesante y razonablemente «cerrada» en la que se trate de satisfacer al jugador sin cansarlo ni volvernos excesivamente repetitivos.

El punto de partida será este proyecto de Unity 2021 que proporciona el profesor, consistente en la plantilla FPS Microgame más una serie de recursos extra para tener más contenido disponible, algunos gratuitos y otros de pago, principalmente del FPS Microgame Creator Bundle.

El producto resultante deberá contar con estas características:

A. Se deberá mantener la jugabilidad original de la plantilla (mecánica, dinámica e incluso los rasgos principales de la estética: estar en una fortaleza enemiga), evitando programar cualquier comportamiento adicional en C# y sin crear ni añadir al proyecto ningún contenido adicional a lo incluido expresamente en el punto de partida. Obviamente tampoco hay que usar todo el contenido que se proporciona. 

B. Aunque no sea necesaria una narrativa complicada, se debe establecer un bucle básico del juego a base de proponer objetivos clásicos tipo “alcanzar cierto punto del nivel”, “coger cierto objeto” o “eliminar a ciertos enemigos”, dándole cierto trasfondo y desarrollo narrativo.

C. Se deberá “dosificar” de manera inteligente el contenido, mostrándolo gradualmente a lo largo del juego en al menos 3 localizaciones diferentes (escenarios con nuevas identidades visuales y sonoras, armas parametrizadas de otra manera, enemigos cuya dificultad aumenta progresivamente y que a la vez dan mejores recompensas, detalles cosméticos, etc.).

D. Se esconderá un «huevo de Pascua» a modo de guiño humorístico en alguna parte del juego, con el objetivo de que sea encontrado por aquellos compañeros y profesores que se esfuercen un poco en buscarlo.

E. Aunque no haya límites explícitos a la duración del juego, es importante medir las fuerzas del equipo, planificar la producción para aprovechar el tiempo y sobre todo distribuir el contenido de forma óptima para explotar la jugabilidad todo lo posible sin llegar a abusar de la repetición de niveles, objetivos, enemigos, etc. 

Condiciones

Condiciones a la hora de desarrollar esta práctica:

  • Comienza por explorar todo lo que contiene el proyecto proporcionado por el profesor y todas las posibilidades que tiene este FPS Microgame. En el sitio web de Unity (y dentro del propio proyecto) hay varios tutoriales que permiten formarte en cómo añadir contenido sin necesidad de programar nada, siendo válido utilizar herramientas avanzadas de este entorno de desarrollo como son ProGrids y ProBuilder. Al final de este enunciado hay referencias donde poder profundizar en estas cuestiones.
  • El documento de diseño estará escrito en español, y no debería ocupar más de 5 páginas, unas 1500 palabras. Debe quedar claro el título del juego, los datos de sus autores (nombres completos, número de grupo…), los esquemas visuales del mundo de juego, con sus distintos niveles, qué referentes se tienen, lista de mecánicas, descripción básica de la dinámica, qué contenido se ha optado por usar, y cómo se distribuye el contenido para sacan más provecho de la jugabilidad base que tenemos.
  • El producto resultante de este proceso de diseño será un pequeño FPS, en forma de juego ejecutable, con el contenido y la duración adecuadas para disfrutar de su jugabilidad plenamente y sin llegar a aburrirse.
  • Se tendrán en cuenta otras recomendaciones ya aparecidas en prácticas anteriores.

Revisión

Tener la carpeta compartida 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 carpetas de Google Drive (por ejemplo DV22-G02, la del grupo 2 del curso Diseño de Videojuegos 2022-2023) donde se encontrarán las subcarpetas de las prácticas (DV22-G02-P1, DV22-G02-P2, DV22-G02-P3 y DV22-G02-P4).

Los entregables son:

  • Los ficheros de código fuente y recursos, proyecto en Unity.
  • Documento de diseño según el modelo MDA (llamado por ejemplo DV22-G02-P4). En este documento no se oculta información al lector ni se describe el juego de manera informal o «marketiniana», pues se trata de documentación técnica. Debe recoger todo lo dicho anteriormente. Supone un 30% de la nota.
  • El fichero EXE para Windows 64 como prototipo ejecutable. Cada característica del juego (A, B, C, D y E) correctamente implementada supone un 10% de la nota.
  • Enlace a un video oculto en YouTube (llamado por ejemplo DV22-G02-P4), de menos de 5 minutos de duración, donde queden documentadas y comentadas por voz y/o subtítulos las pruebas realizadas. Conviene dividirlo en tantas partes como características se quieren probar (A, B, C, D y E). 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 deben replicar ideas de terceros sin entenderlas bien y «hacerlas nuestras», y siempre asegurándonos de que funcionan exactamente como se requiere para esta práctica.

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

  • Desarrollar algún tipo de arma nueva o enemigo final distinto.
  • Añadir alguna forma de consultar el mapa de los niveles.
Categorías
Informática Universitario Videojuego

Invasión Androide

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.

Ejemplo de mapa esquemático del Centro de Desarrollo Tecnológico de Androides.

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.
Categorías
Universitario Videojuego

Explorador Desaparecido

La exploración urbana (abreviada en inglés como urbex) es una actividad consistente en recorrer estructuras creadas por el ser humano, a menudo abandonadas (caserones, hospitales, fábricas, centros comerciales…) o poco transitadas, como azoteas de edificios o galerías subterráneas. Habitualmente el explorador urbano, aunque trabaje sólo o sin apenas compañía, documenta y comparte sus experiencias con mucha más gente, grabando y haciendo fotografías desde su punto de vista subjetivo.

Entre las posibles motivaciones para realizar esta actividad está el evadirse de la rutina, disfrutar de la soledad y las sensaciones que transmite el entorno, excitarse con los desafíos y riesgos que se presentan, o ser el primero en conocer o retratar para otros un determinado lugar. Es interesante considerar las similitudes y diferencias entre la exploración de entornos artificiales en el mundo real y en el virtual (el de la literatura, el cine, los ordenadores…), especialmente el de los videojuegos que también pueden presentar entornos con ese atractivo e incluso se prestan a que dichas «exploraciones» sean expuestas ante grandes audiencias a través del streaming de gameplay.

No todo lo que brilla es oro, ni todos los que andan vagando están perdidos.

J. R. R. Tolkien

En esta práctica trabajaremos la dimensión estética de los videojuegos y para no caer en la tentación de plantear una mecánica o dinámica complicada, vamos a trabajar con una herramienta muy simple pensada para crear experiencias de narración interactiva, aventuras reducidas a su mínima expresión. Típicamente solemos recurrir a herramientas de creación de Ficción Interactiva (como Inform), Novelas Visuales (como Ren’Py) o Aventuras Gráficas (como Adventure Creator). Un buen equilibrio entre texto, imagen e interacción (siempre desde un minimalismo pixelado) lo encontramos en Flicksy, un entorno para desarrollar pequeñas aventuras “point and click”, aplicaciones hipertextuales de capacidad multimedia muy reducida.

Flicksy 2, la versión a utilizar, consta de un editor 2D muy fácil y rápido de usar, pues no requiere instalación (se ejecuta directamente desde la web) y casi tampoco instrucciones de uso. Pone el foco en la narrativa (como Twine) pero tiene un modelo de interacción algo más rico, ya que muestra sprites en pantalla sobre los que podemos hacer clic. Esos sprites podrán ser objetos que añades a tu inventario, personajes (inmóviles) con los que poder hablar, etc.

El juego partirá de un gancho narrativo detectivesco, una historia que deberá contarse despertando la curiosidad y generando cierta tensión e inquietud en el jugador. Se nos hablará de un joven investigador, aficionado a la exploración urbana, que a finales de los años 80 está empezando a ser conocido en su comunidad universitaria por compartir crónicas e imágenes de sus «misiones solitarias» a través de una BBS (una especie de «tablón de anuncios» digital de la era pre-Internet), hasta que un buen día desaparece por completo. Lo misterioso del caso es que el mismo día de su desaparición, aparece publicado un último documento que de manera impactante termina con el explorador pidiendo ayuda a sus lectores por encontrarse atrapado entre las ruinas de un viejo laboratorio informático abandonado. ¿Cómo es posible?

Propuesta

La práctica consiste en desarrollar una aventura hipertextual con gráficos, que -tratando de manera seria y documentada el tema de la exploración urbana- narre una historia emocionante según el anterior planteamiento, a la vez que nos invita a reflexionar sobre esta idea de la relación entre exploración en mundos ficcionales y exploración en entornos artificiales reales. Flicksy fuerza a que el estilo audiovisual será bastante retro (imágenes fijas en 2D a baja resolución y con una paleta de colores muy escasa) aunque podrán usarse fotografías, convenientemente «reducidas» en calidad. Como punto de partida técnico se tomará la demo de Flicksy y una lista reducida de contenido: escenarios como una casa o un laboratorio abandonado, objetos como cámara de video, cuerdas o notas de papel, y sin apenas personajes no jugadores.

Las características principales del juego a crear son:

A. Presenta un entorno a base de imágenes en el que podemos interactuar de manera performativa (se basa en lo que “hace” el jugador, por ejemplo encarnado a un protagonista y viendo el mundo desde su punto de vista), explorándolo e interactuando con algunos objetos.

B. Ofrece mecánicas simples e intuitivas, y una dinámica que requiere cierta interpretación ergódica (resolver el misterio requiere poner esfuerzo por parte del jugador) al leer los textos o ver los detalles de las imágenes.

C. Transmite esas emociones de curiosidad e incluso miedo -o tensión al menos- en determinados momentos, asociadas a la exploración urbana. Se usarán los medios adecuados para provocar esas emociones.

D. Presentar una historia detectivesca bien estructurada y redactada, sea con narrador o mediante textos de los personajes, partiendo del gancho propuesto, desvelando poco a poco el misterio y ofreciendo un final razonablemente satisfactorio.

E. Comunicar al jugador lo que reflejéis en vuestro documento de diseño como idea central y profunda sobre la relación entre explorar ciudades abandonadas y explorar mundos de ficción y videojuegos.

Condiciones

Condiciones a la hora de desarrollar esta práctica:

  • Comenzad por investigar a fondo el tema a tratar y el género de los juegos hipertextuales. Aunque es perfectamente posible obtener inspiración jugando a cualquier videojuego o realizando cualquier actividad, ¡en ningún caso se os está animando a practicar la exploración urbana ni a asumir sus riesgos! Un recorrido legal y seguro por el campus y sus edificios os puede servir para obtener material fotográfico suficiente ;).
  • Haced una lluvia de ideas y una posterior discusión en torno al tema del juego. Documentad cuál es la idea principal a transmitir y cómo se van a contar, provocando emociones en el jugador para asimilarla mejor. Aunque en el juego se haga de una forma velada o menos explícita, el profesor al terminar de probar el juego -sin haber visto nada antes- tiene que ser capaz de recibir esa ideas y sentir las emociones propuestas.
  • Es importante conocer de primera mano estas creaciones para tener claro cuáles son los límites de la herramienta e identificar la mecánica y dinámica que es viable sin añadir ni programar extensiones de ningún tipo.
  • A continuación será necesario formarse en el uso de Flicksy, en la definición de mapas y escenas, ubicación de objetos, etc. Para ello la propia herramienta incorpora instrucciones y un tutorial.
  • El documento de diseño estará escrito en español y no debería ocupar más de 5 páginas, unas 1500 palabras junto con esquemas de todas las escenas y quizá un anexo con los textos si son demasiados. Debe quedar claro el título de la aventura, los datos de sus autores (nombres completos, número de grupo…), qué referentes se están manejando, así como una lista de las mecánicas utilizadas (nombre y una única frase descriptiva) y una descripción breve de la dinámica del juego.
  • El producto resultante de este proceso de diseño será un juego creado con Flicksy, y seguirá por tanto el formato HTML de juego exportado.
  • Se tendrán en cuenta otras recomendaciones ya aparecidas en prácticas anteriores.

Revisión

Tener la carpeta compartida 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 carpetas de Google Drive (por ejemplo DV22-G02, la del grupo 2 del curso Diseño de Videojuegos 2022-2023) donde se encontrarán las subcarpetas de las prácticas (DV22-G02-P1, DV22-G02-P2, DV22-G02-P3, etc.).

Los entregables son:

  • Los ficheros no tanto de código fuente sino del prototipo del videojuego, en formato HTML jugable exportado (por ejemplo DV22-G02-P3.html). Dejad la implementación para el final, grabad a menudo y mantener varias copias de seguridad porque Flicksy producen pérdidas de datos a menudo.
  • Documento de diseño según el modelo MDA (llamado por ejemplo DV22-G02-P3). En este documento no se oculta información al lector ni se describe el juego de manera informal o «marketiniana», pues se trata de documentación técnica. Debe recoger todo lo dicho anteriormente. Supone un 30% de la nota.
  • El fichero HTML sirve como prototipo ejecutable. Cada característica del juego (A, B, C, D y E) correctamente implementada supone un 10% de la nota.
  • Enlace a un video oculto en YouTube (llamado por ejemplo DV22-G02-P3), de menos de 5 minutos de duración, donde queden documentadas y comentadas por voz y/o subtítulos las pruebas realizadas. Conviene dividirlo en tantas partes como características se quieren probar (A, B, C, D y E). 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 deben replicar ideas de terceros sin entenderlas bien y «hacerlas nuestras», y siempre asegurándonos de que funcionan exactamente como se requiere para esta práctica.

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

  • Incorporar una narrativa ramificada con varios finales posibles.
  • Incluir pequeñas animaciones (siempre basadas en aparición y desaparición de sprites) y minijuegos.
  • Incluir puzles que requieran ingenio del jugador.
Categorías
Universitario Videojuego

Plataformas de Chocolate

Super Mario Bros. es el nombre de la archiconocida saga de videojuegos de plataformas de Nintendo, creada por Shigeru Miyamoto, y que tiene como punto de partida el clásico de las máquinas recreativas Mario Bros., lanzado por primera vez en 1983. Posiblemente es el referente en el que todos pensamos al hablar del subgénero de acción de las plataformas.

Existen numerosas herramientas, oficiales y extraoficiales, que permiten crear nuevos mundos y niveles para los distintos videojuegos de la franquicia, aprovechando e incluso ampliando las mecánicas de juego y el contenido presente en los títulos originales. Seguramente las más destacables por su usabilidad y potencia son aquellas creadas por la propia Nintendo y comercializadas como parte esencial de su franquicia Super Mario Maker para Wii U, Nintendo 3DS y también Super Mario Maker 2 o Game Builder Garage para Nintendo Switch.

La fe no es sacar conclusiones precipitadas. Es llegar a la conclusión de saltar.

W. T. Purkiser

Para trabajar todos con una misma herramienta gratuita, en esta práctica vamos a poner el foco sobre Super Mario Bros. X2, también llamado SMBX2 (o SMBX 2.0). Se trata de un proyecto colaborativo y de código abierto, que expande una herramienta anterior (SMBX 1.3.0.2) completando su funcionalidad y su contenido notablemente. Actualmente incluye tanto el motor de videojuegos de plataformas como el editor de mundos y niveles más potente que hay en PC para recrear los juegos de la saga Super Mario Bros. y otros títulos similares.

Lo que se pretende con esta práctica es aprender a diseñar dinámicas que resulten efectivas e interesantes dentro de este muy trabajado género, y al mismo tiempo entrar en contacto con herramientas concretas y específicas de diseño de contenido.

Propuesta

La práctica consiste en desarrollar un nuevo nivel plataformero, fresco y divertido, siguiendo el estilo visual y el contenido habitual del aclamado plataformas Super Mario World (SMW), videojuego publicado para la videoconsola Super Nintendo (SNES) en 1990. Concretamente se tomarán como punto de partida conceptual los niveles del sexto mundo del juego, Chocolate Island., cuya información detallada está disponible en wikis como esta (se usan muelles, koopas aladas, bloques detonadores, etc.). Como punto de partida de la implementación pueden tomarse los niveles de The Princess Cliche incluidos en SMBX2 (y resumidos en este video).

Las características principales del juego a crear son:

A. El nivel estará dividido en 5 secciones principales, más al menos 1 sección secreta (opcional para el jugador). Para diseñar con precisión la distribución de los bloques y personajes en cada sección, conviene usar hojas de papel cuadriculado (al final de esta página se pueden usar las hojas originales que usó Nintendo en sus inicios), aunque también hay herramientas informáticas para diseñar niveles formados por baldosas, como Tiled.

B. Sólo se utilizarán los mecanismos y contenidos ya incluidos en la última distribución disponible de SMBX2, concretamente los bloques, fondos y personajes del conjunto de baldosas (tileset) SMW.

C. La dinámica de juego al comienzo será simple y predecible, sin llegar a ser un tutorial exhaustivo, pero con clara finalidad introductoria. Muy rara vez se podrá morir en este tramo.

D. Después irá creciendo en cuanto a complejidad y ligeramente en cuanto a dificultad, desarrollando las mecánicas principales al estilo de Super Mario World, aunque sin suponer un reto excesivo para el jugador en ningún momento. Antes del final existirá al menos una sección con un pequeño puzle intrigante para el jugador, que requiera «pensamiento lateral».

E. Deberá poder ser completado en menos de 5 minutos, aunque un jugador inexperto tarde más. Existirá una ruta óptima que permite superar el juego a quien lo conoce bien con cierta fluidez satisfactoria.

Condiciones

A la hora de desarrollar esta práctica es obligatorio:

  • Comenzad por investigar a fondo este tipo de juegos. Aunque es perfectamente posible obtener inspiración jugando a los títulos originales de Nintendo o probando niveles creados por la comunidad de Super Mario Maker (por ejemplo), es también recomendable centrarse primero en analizar detenidamente los niveles creados con SMBX2. Es importante conocer de primera mano estas creaciones para tener claro cuáles son los límites de la herramienta e identificar las mecánicas y los contenidos con los que contamos, ya que no se pueden añadir ni programar más.
  • A continuación será necesario formarse en el uso de SMBX2, en la definición de niveles y secciones, ubicación de bloques, fondos, personajes, etc. Para ello disponéis de recursos como el manual oficial o los videotutoriales mencionados en el último apartado de este enunciado.
  • El documento de diseño estará escrito en español y no debería ocupar más de 5 páginas, unas 1500 palabras junto con esquemas de todas las secciones del nivel y alguna otra imagen. Debe quedar claro el título de la nueva aventura, los datos de sus autores (nombres completos, número de grupo…), qué referentes se están manejando, así como una lista de todas las mecánicas utilizadas (sólo mencionar nombre y una única frase descriptiva, sin detallar nada más), y una explicación más detallada de los conceptos dinámicos del juego utilizados en las distintas secciones del nivel.
  • El producto resultante de este proceso de diseño será un nivel creado con SMBX2, y seguirá por tanto el formato LVLX con el que trabaja tanto el motor como el editor de esta herramienta.
  • Se tendrán en cuenta otras recomendaciones ya aparecidas en práctivas anteriores.

Revisión

Tener la carpeta compartida 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 carpetas de Google Drive (por ejemplo DV22-G02, la del grupo 2 del curso Diseño de Videojuegos 2022-2023) donde se encontrarán las subcarpetas de las prácticas (DV22-G02-P1, DV22-G02-P2, etc.).

Los entregables son:

  • Los ficheros de código fuente y recursos del prototipo del videojuego, en formato LVLX (por ejemplo DV22-G02-P2.LVLX).
  • Documento de diseño según el modelo MDA (llamado por ejemplo DV22-G02-P2). En este documento no se oculta información al lector ni se describe el juego de manera informal o «marketiniana», pues se trata de documentación técnica. Debe recoger la lista de mecánicas utilizadas, la estructura de juego con un diagrama completo de todas las secciones del nivel, los objetivos y conflictos, las recompensas y castigos, consideraciones sobre el equilibrio y la dificultad, y el diseño de puzles. Supone un 30% de la nota.
  • El propio LVLX sirve también como prototipo ejecutable. Cada característica del juego (A, B, C, D y E) correctamente implementada supone un 10% de la nota.
  • Enlace a un video oculto en YouTube (llamado por ejemplo DV22-G03-P2), de menos de 5 minutos de duración, donde queden documentadas y comentadas por voz y/o subtítulos las pruebas realizadas. Conviene dividirlo en tantas partes como características se quieren probar (A, B, C, D y E). 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 deben replicar ideas de terceros sin entenderlas bien y «hacerlas nuestras», y siempre asegurándonos de que funcionan exactamente como se requiere para esta práctica.

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

  • Probar el lenguaje de scripting y programar algún comportamiento ad hoc.
  • Diseñar el nivel pensando en la posibilidad de jugar varios jugadores a la vez y mantener el nivel de reto, e incluso hacer que el puzle funcione a dos jugadores.
Categorías
Informática Universitario Videojuego

Aprendiz de Brujo

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.

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.

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.
Categorías
Universitario Videojuego

Duelo de Naipes

La baraja española más antigua data del año 1390, y fue localizada en Sevilla. Hace más de 600 años estas cartas ya utilizaban la simbología actual, con los «palos» de Oros, Copas, Espadas y Bastos.

El escritor y esotérico francés Antoine Court de Gébelin asoció cada uno de estos símbolos a los principales pilares de la sociedad medieval. De modo que el Oro representaba el dinero y el comercio, la Copa representaba a la Iglesia, la Espada hacía referencia a la nobleza y el ejército, y por último el Basto representaría a la mayor parte de la población en aquel entonces, el campesinado.

El destino mezcla las cartas, y nosotros las jugamos.

Arthur Schopenhauer

Se conocen una enorme cantidad de juegos que se desarrollan usando únicamente este material: la clásica baraja española de cuarenta naipes, cartas numeradas -para cada uno de los cuatro «palos»- del 1 al 7, más las tres figuras de la Sota, el Caballo y el Rey.

Precisamente este material será el que tomaremos como base para realizar un ejercicio de diseño de mecánicas de un juego de cartas, extrapolable no sólo a videojuegos basados en cartas como Hearthstone o Magic: The Gathering Arena, sino a muchos otros títulos de estrategia.

Propuesta

La práctica consiste en diseñar y redactar el reglamento de un juego de cartas para dos jugadores con una dinámica que les enfrente como lo harían sendos generales de ejércitos medievales que combaten a muerte en el campo de batalla. La estética estará muy apegada a las ilustraciones habituales de los naipes: el Rey representa una personalidad importante, el Caballo, una especie de guerrero, la Sota, un fiel siervo… y los números pueden representar efectivos militares o distintos niveles de poder. Y los «palos» pueden entenderse de manera similar a como lo hizo Court de Gébelin.

El punto de partida lo conforman este documento de diseño de Flappy Pong, a modo de Práctica 0, y este sitio web con reglamentos de juegos de naipes (aunque se pueden tomar como referentes juegos de cartas de otro tipo, como UNO, Munchkin, Ciudadelas, etc.). Una estructura típica de estos reglamentos suele ser: Componentes, Objetivo, Preparación, Desarrollo y Final. Para el simulador se puede tomar este ejemplo con las Siete y media como base (aunque en la Web se pueden encontrar hasta versiones completas de Texas hold ‘em hechas en Excel). El primer documento ejemplifica cómo en sólo dos páginas se puede documentar de forma bastante completa la jugabilidad y el contenido de un juego sencillo, y el sitio web contiene reglamentos de una estructura y extensión similar a la que se pide en esta práctica.

Las características principales del juego a crear son:

A. Hay un conjunto de espacios discretos y bien definidos donde pueden estar las cartas (por ejemplo la mano o el mazo de un jugador, varias zonas diferentes de la mesa, etc.). También hay turnos consistentes en una serie de pasos ordenados dentro del juego en los que se pueden realizar determinadas acciones con las cartas (por ejemplo bajar una carta de la mano a la mesa, robar una nueva carta al terminar tu turno, etc.).

B. Cada uno de los jugadores empieza el juego con su propio mazo completo de 40 cartas. El reglamento explica cómo se «mueven» las cartas de un espacio a otro en el juego y qué ocurre si no quedan cartas en el mazo o en la mano de un jugador.

C. El reglamento también explica cómo «interactúan» las cartas entre sí, simulando el combate entre dos ejércitos rivales. No hay grandes tablas con información para consultar en el reglamento, que ocupa un máximo de 3 páginas, ni hace falta escribir nada en ningún papel; aunque sí se permite usar fichas -de un único tipo- como contadores para algunas funciones del juego.

D. Si bien el diseño de una dinámica interesante y equilibrada queda fuera del alcance de esta práctica, los jugadores, dentro de la aleatoriedad que puede suponer el orden en que aparecen las cartas, toman decisiones y estas -si son inteligentes- permiten inclinar la balanza de la victoria hacia su bando. Siendo conscientes de las cartas que hay en juego, las que podrán estarlo y las que ya no están, los jugadores pueden escoger entre varias estrategias para acumular poder y llegar a derrotar al contrario. El reglamento declara de forma inequívoca quien es el ganador, y esto ocurre de manera normal en un tiempo bastante reducido (10-15 minutos máximo).

E. Aunque todos los cálculos se pueden hacer «de cabeza» sin mucho esfuerzo, existe un «simulador» para los más vagos, que permite calcular automáticamente los resultados de algunas situaciones que pueden darse en el juego (por ejemplo, los combates). Este simulador consiste en una hoja de cálculo de Google en la que podemos introducir las cartas que están en juego (codificadas como números: 11, el As de Oros; 24, el cuatro de Copas; 38, la Sota de Espadas; 40, el Rey de Bastos… ¿ves el patrón?) y obtener un resultado.

Condiciones

A la hora de desarrollar esta práctica es obligatorio:

  • No plagiar sistemas de juego de cartas ya existentes. Es posible estudiarlos y tenerlos como referencia (citándolos debidamente), pero la mecánica propuesta deben ser en buena medida original.
  • No asumir la existencia de ningún otro material que no sean los dos mazos de 40 cartas y las fichas de contador. Evitar complejidades innecesarias.
  • Documentar el diseño en la carpeta compartida con el profesor, siempre editando el mismo fichero para que quede patente en el historial de versiones que se ha repartido el trabajo y el esfuerzo equitativamente entre todos los miembros del grupo.
  • Utilizar la terminología en español que vemos en clase, comentando y aclarando toda aquella decisión de diseño que no sea trivial.
  • El juego debe ser funcional y cómodo, con leer el reglamento en voz alta dos personas ya pueden empezar a jugar y podrán concluir partidas de manera rápida, intuitiva y frecuente para hacer así todas las pruebas necesarias.

Revisión

Tener la carpeta compartida 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 carpetas de Google Drive (por ejemplo DV22-G02, la del grupo 2 del curso Diseño de Videojuegos 2022-2023) donde se encontrarán las subcarpetas de las prácticas (DV22-G02-P1, DV22-G02-P2, etc.).

Los entregables son:

  • En esta práctica no hay ficheros de código fuente ni recursos del proyecto, porque no estamos haciendo el prototipo de un videojuego.
  • Documento de diseño según el modelo MDA (llamado por ejemplo DV22-G02-P1). En este documento no se oculta información al lector ni se describe el juego de manera informal o «marketiniana», pues se trata de documentación técnica de un proyecto. Supone un 30% de la nota.
  • Reglamento del juego, sin tecnicismos y escrito pensando exclusivamente en el jugador (llamado por ejemplo DV22-G02-P1 Reglamento). Cada característica del juego (A, B, C, D y E) correctamente implementada supone un 10% de la nota.
  • Enlace a un video oculto en YouTube (llamado por ejemplo DV22-G03-P1), de menos de 5 minutos de duración, donde queden documentadas y comentadas por voz y/o subtítulos las pruebas realizadas. Conviene dividirlo en tantas partes como características se quieren probar (A, B, C, D y E). 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 deben replicar ideas de terceros sin entenderlas bien y «hacerlas nuestras», y siempre asegurándonos de que funcionan exactamente como se requiere para esta práctica.

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

  • Completar el simulador para que sea posible representar una partida completa dentro de la hoja de cálculo de Google.
  • Añadir reglas para configurar mazos iniciales, que no estarían formados por las 40 cartas habituales sino por un subconjunto más estratégico.
Categorías
Informática Universitario Videojuego

Asalto al Castillo

Fūun! Takeshi Jō (que en japonés significa ¡Diversión! El Castillo de Takeshi) era un concurso de televisión japonés de los años 80 en el que su presentador, Takeshi Kitano, sometía a los participantes a humorísticas pruebas de destreza física en las que estos solían sufrir ridículas caídas y golpes. El objetivo era tomar por la fuerza el castillo de Takeshi, superando las pruebas, para conseguir un millón de yenes.

Si no construyes castillos en el aire, no construirás nada en el suelo.

Víctor Hugo

La dinámica del juego es relativamente simple: avanzar corriendo y saltando sin caerse ni recibir demasiados golpes hasta llegar al final, recogiendo el cuantioso premio. Y la estética era bastante alocada y absurda, con disfraces y escenografía de todo tipo.

Este planteamiento de juego sirve como excusa para desarrollar algunas mecánicas sencillas que se encuentran en muchos videojuegos, principalmente del género de plataformas como es el caso de Fall Guys.

Propuesta

La práctica consiste en desarrollar el prototipo ejecutable de un videojuego de plataformas 2D para un sólo jugador con mecánicas inspiradas en algunas pruebas de El Castillo de Takeshi.

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. Para la documentación se puede tomar como ejemplo la de este repositorio, a modo de Práctica 0.

Las características principales del prototipo son:

A. Hay un mundo virtual por explorar que consiste en un único nivel donde está el castillo con sus pruebas, que sólo se pueden superar con el movimiento lateral y el salto del avatar que controla el jugador.

B. El avatar debe interactuar con ciertos objetos para activar mecanismos que eliminan los obstáculos del escenario, para hacer factible la victoria. Concretamente hay pócimas mágicas que aumentan la fuerza del avatar y le permiten empujar obstáculos muy grandes.

C. La primera parte del juego consiste en cruzar el foso del castillo dando saltos sobre troncos que resultan resbaladizos y pueden hundirse bajo nuestros pies.

D. La segunda parte consiste en escalar la muralla del castillo aprovechando salientes y empujando obstáculos, con ayuda de los mecanismos y las pócimas mágicas antes mencionadas.

E. La tercera y última parte consiste en atravesar las estancias interiores hasta el corazón del castillo, con puertas falsas y algunas trampas. No hay “enemigos” como tales, sólo objetos con movimiento que resultan molestos e incluso peligrosos para el jugador. De todas formas si el avatar cae o recibe daño, el castigo no debe ser excesivo ni suponer la muerte o el reinicio del juego; es suficiente con tener que repetir el último tramo jugado. Finalmente al coger el gran lingote dorado en el interior del castillo, la partida termina.

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 el paquete Starter Content. 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-P1) 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-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.
  • Enlace a un video oculto en YouTube (llamado por ejemplo DEV22-G03-P1), 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.

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

  • Crear un cronómetro de manera que el jugador pierde si no consigue llegar a la meta a tiempo.
  • Desarrollar un total de 5 pruebas, escogiendo algunas algo más complejas de entre las pruebas que ofrece el juego Fall Guys.
  • Esconder al menos un «huevo de Pascua», pasadizo o zona secreta en el juego.