Categorías
Informática Universitario Videojuego

Análisis de Mazos de Magic

Obtener datos de juego mediante algún sistema de telemetría es una práctica habitual en la industria de los videojuegos. Especialmente en juegos de estrategia complejos, tener datos con los resultados de muchas partidas es útil para que el equipo de diseño pueda equilibrar el juego, modificando aquellos elementos que facilitan o dificultan en exceso conseguir la victoria a los jugadores.

El popular juego de cartas Magic: The Gathering cuenta con una versión digital llamada Magic: The Gathering Arena que genera una gran cantidad de datos. Muchos de ellos recopilados por la comunidad 17Lands en formato JSON y pueden ser analizados para, por ejemplo, ajustar la eficacia de los distintos arquetipos de mazos de cartas existentes.

El general que gana la batalla hace muchos cálculos en su templo antes de presentar combate; el que pierde, hace pocos.

Sun Tzu (544-470 a.C.)

En juegos de cartas coleccionales, como Magic: The Gathering Arena, los mazos de cartas siguen distintos arquetipos como Agresivo (Aggro), Control, Rango Medio (Midrange) o Combo, y en principio -sin tener en cuenta el estado del metajuego- todos ellos deberían tener las mismas posibilidades de ganar una partida. Hay que tener en cuenta que quien empieza a jugar en el primer turno tiene una cierta ventaja mecánica estructural (se dice que está «on the play» frente al otro jugador que está «on the draw«)… pero incluso esa ventaja debe evitarse que sea excesiva.

Propuesta

La práctica consiste en realizar un análisis del conjunto de datos proporcionado en el punto de partida (y que están en el mismo formato que se utiliza en 17Lands) para identificar si existen dos posibles problemas de los que se estaría quejando la comunidad. El primero es que los mazos de cartas de tipo Mono Red Aggro (del arquetipo Agresivo) parecen estar ganando demasiadas partidas, y el segundo es que aquellos que empiezan a jugar primero tienen demasiada ventaja (es decir, una probabilidad de victoria superior al 55%).

El punto de partida es Deck Base, un repositorio de GitHub que contiene un cuaderno interactivo y un fichero con un conjunto de datos para realizar el análisis de datos telemétricos de los mazos del juego.

Esta práctica tiene un requisito importante y es que sólo está permitido usar bibliotecas estándar de Python, sin usar ningún paquete de terceros.

Las características principales del estudio son:

A. Carga correcta del conjunto de datos desde fichero, según su formato y condiciones.

B. Limpieza básica del conjunto de datos, eliminando los que no se necesitan.

C. Exploración del conjunto de datos, visualizando las victorias en función del tipo de mazo, o si se empieza jugando o no.

D. Análisis estadístico descriptivo del conjunto de datos en limpio, tratando de demostrar también si los datos dan la razón a los miembros de la comunidad que se han quedado de excesivas victorias de Mono Red Aggro y o del jugador que empieza primero.

E. Propuesta final para mejorar los resultados en caso de que se haya probado que existen los desequilibrios mencionados.

Revisión

Tener el repositorio a disposición del profesor, en formato entregable, preparado 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 AAM26-G02, la del grupo 2 del curso Aprendizaje Automático y Minería de Datos 2026-2027) donde se encontrarán los repositorios de las prácticas (por ejemplo AAM26-G02-P0).

Revisión preliminar

En esta primera fase de revisión hay un único entregable:

  • Documentación del repositorio según la estructura recomendada por el profesor y presentada en el README.md. Supone un 10% de la nota.

Revisión final

En esta segunda fase de revisión el entregable es el mismo:

  • Proyecto con todos los ficheros de documentación, recursos, código fuente y resultados de la implementación, generalmente datos en formato CSV, cuadernos interactivos en formato IPYNB, aunque puedan aparecer Unity y C# en algunas prácticas (llamado por ejemplo AAM26_G02_P0). Supone un 20% de la nota. La documentación tiene tantas secciones como características a probar (esto es A, B, C, D y E). Supone un 10% de la nota. Cada característica del estudio (A, B, C, D y E) correctamente implementada supone un 10% de la nota, sumando un total de 50%.

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 o de IA 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.

  • Descarga datos reales de 17Lands, límpialos, fíltralos y trata de repetir el análisis de esta práctica, o uno similar, con ellos.
  • Prueba a repetir el proceso para datos de otros juegos de cartas como Hearthstone.

Esta página está licenciada bajo CC BY-NC-SA 4.0 por Laboratorios Narratech.