25 julio, 2006

De números y juegos

Tras una épica batalla entre dos imperios de la era napoleónica en Imperial Glory, se generaba un pequeño fichero. En él se podía leer, entre otras cosas, que la tropa con id 17 había logrado matar a su enemigo con id 33 gracias a un disparo en el minuto 4:55, cuando tenía 14 unidades de fusileros. El disparo había tenido bonificaciones por la formación de línea, proximidad y ángulo de tiro. La penalización gracias a la formación del enemigo no impidió que sus 4 unidades murieran.

Toda esta información, y mucha más, se almacenaba en una base de datos, donde se acumulaban resultados de decenas de partidas. Mediante consultas, la base de datos podía proveer estadísticas, como cúanto daño había sido causado en distancia (mediante disparos), frente a daño de melée o de artillería, o el daño causado frente al daño recibido por las tropas de caballería en general. Se podía consultar por partida o haciendo medias de varias partidas.

El objetivo de este sistema era conseguir un entendimiento mejor de los "números" del juego, principalmente para poder balancearlo correctamente. No era la única ayuda que existía. Mediante una orden especial, el juego grababa un fichero .csv que se podía abrir con Excel, y que contenía el resultado de una simulación de enfrentar las tropas todas contra todas, probando todas las combinaciones posibles de 1vs1 y 2vs1. La tabla permitía no sólo ajustar la potencia de tropas similares, sino observar el efecto "piedra-papel-tijera" que se suele usar para evitar estrategias dominantes.

Aunque la tabla de enfrentamientos fue razonablemente útil, el uso principal de la base de datos de partidas fue encontrar bugs en los algoritmos de simulación de combate. No es algo desechable, desde luego, pero dista mucho de lo que un sistema de estas características parece prometer.

Cuando hicimos esa herramienta, tuvimos que elegir entre hacerla sofisticada y fácil de usar, o ahorrar algo de trabajo (que dedicaríamos a otras tareas). Optamos por la segunda. Todo el sistema, incluyendo la instrumentación del código, la generación del archivo por partida, la instalación de la base de datos MySQL y la implementación de una sencilla aplicación en MFC para acceder algo más cómodamente a la información costó menos de 2 semanas/hombre. La recogida de información era bastante completa, pero las herramientas de análisis eran primitivas, y requerían un buen nivel de conocimiento del lenguaje SQL para hacer consultas sofisticadas. Difícilmente podían los diseñadores acceder a estadísticas sin un programador presente.

No estoy seguro de si la falta de un interfaz más amigable fue lo que hizo que nuestro sistema básico de "data mining" no alcanzara todo su potencial. Por un lado, es posible encontrar información muy valiosa gracias a análisis de este tipo. Es posible detectar anomalías, como puntos de una misión donde los jugadores mueren con bastante frecuencia, armas que apenas son usadas o que no son todo lo efectivas que deberían, desequilibrios por el uso generalizado de unas pocas tácticas en detrimento de otras, etc. Pero por otro lado, los juegos de hoy son complejos. Quizás son tan complejos que tratar de extraer conclusiones aplicables mediante simples técnicas de análisis numérico o teoría de juegos resulta casi imposible. De ahí que el balanceo se siga haciendo principalmente mediante instinto, ensayo-error y muchas horas de jugar y observar a otros.

La experiencia de Imperial Glory me demostró que las herramientas automatizadas pueden servir para analizar y equilibrar elementos de bajo nivel, como enfrentamientos directos entre tropas uno contra uno. Sin embargo, el fracaso de nuestro intento de obtener información sobre "dinámicas", sobre los números del juego cuando varios elementos interactúan entre sí, puede ser indicativo de que existe un límite de lo que se puede categorizar matemáticamente, aunque no es de momento prueba definitiva. Yo sigo pensando que hay algo interesante en explorar ese camino, aunque no está claro cuánto trabajo hace falta para obtener fruto.


Mostrar/ocultar resto...

4 Comments:

At 25/7/06 15:25, Blogger Saül said...

Tener una herramienta de este tipo es realmente útil para un proyecto del estilo "Imperial Glory" (o "Fallen Lords") pero, como apuntas, eso tan solo te permite analizar elementos de bajo nivel. Pero eso ya es muchísimo!! Para Fallen Lords no tubimos ninguna herramienta de este estilo y el balanceo de todos los elementos de bajo nivel también nos lo tubimos que comer yo y los testers enterito con la "vieja técnica". Tube que retocar constantemente las "tablas de valores" a medida que los testers las iban recibiendo y detectaban posibles "trampitas" provenientes de un error de balanceo. La verdad es que fué un buen "pollo" y tener una herramienta como la vuestra, por mucho que sea difícil de manejar (mySQL) lo hubiera agradecido mucho.

De todas formas creo que esta herramienta no te ahorra el tener que "pasar" por "la vieja técnica del prueba-y-error", más aún si el juego tiene una fuerte vertiente multijugador en la que usuarios de diferentes perfiles crearán sus propias estrategia y utilizarán tus unidades para funciones que ni se te habían pasado por la cabeza. De aquí que todos los parches que se publican para juegos de este estilo (dawn of war, battle for middle earth, etc.) estén normalmente relacionados con re-balanceos que han descubierto, por lo general, a través de las partidas en red (una muy buena forma de testear este tipo de cosas).

 
At 26/7/06 14:57, Anonymous Jare said...

Pra sacar conclusiones sobre el estado del juego y los posibles problemas, no hay nada como tener a gente externa al equipo jugando al juego en las horas de comida. Las herramientas de captura de datos son muy utiles, pero no pueden suplir el factor humano, solamente complementarlo. Cuando Makineto (jefe de gráficos de Commandos 3 y CSF) nos vino a decir que las torres de asedio de Praetorians resultaban muy útiles en multiplayer para usar como tanques, fue un momento muy revelador. Al dia siguiente las habiamos quitado del multiplayer, claro. :)

 
At 26/7/06 22:32, Blogger sgarces said...

Ayer estuve leyendo un par de artículos en el Massively Multiplayer Game Development que hablaban de esto. De hecho, dan el nombre que no recordaba cuando escribí el post: Game Metrics.

Aunque los artículos defienden el uso de sistemas de recogida de estadisticas y hasta (gasp!) matrices de payoff de teoría de juegos, yo estoy de acuerdo con lo que decís. Es necesario el "toque humano" al balancear el juego. Pero bueno, supongo que en el equilibrio está la sabiduría, ni 100% matemático, ni 100% a brazo.

 
At 27/7/06 01:38, Anonymous Jare said...

Emergent Technologies ha incluido un módulo de recogida de estadísticas y datos en su motor Gamebryo (o a lo mejor es un producto separado). Y si, la palabra que usan es Metrics. Por supuesto, sugieren todo tipo de usos: desde equilibrado de dificultad, hasta detección de "cagadas" en el desarrollo del contenido: si ves que de repente las estadisticas de frames por segundo de un nivel en las máquinas de los testers baja notablemente, es probable que alguien haya metido algun gráfico o elemento lógico mal construido.

Los online masivos necesitan de todo este tipode métricas y análisis para detectar problemas con mecánicas de juego ("exploits") y con jugadores haciendo trampas. No quiero pensar el tipo y tamaño de la información contenida en los "logs" de estadísticas de los servidores de World of Warcraft. :)

 

Publicar un comentario en la entrada

Links to this post:

Crear un enlace

<< Home