Categorías
Juegos Universitario

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

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.