Pokes y cargadores (II)

20 marzo, 2014

En una entrada anterior vimos que existen mecanismos para modificar el comportamiento de un juego, si modificamos su lógica. Concretamente, los ejemplos fueron actuar sobre el juego una vez cargado en memoria o sobre los datos de las partidas guardadas. A medida que los juegos y los sistemas operativos se hacen más y más complejos, este proceso se complica. En los antiguos ordenadores de 8 bits, modificar un pedacito de memoria a nuestro antojo era trivial, el propio sistema ya te daba la instrucción «POKE«. Tener que rebuscar solo por 64 Kb, con la instrucción «PEEK«, también ayudaba lo suyo. Pero hoy en día no es tan fácil, ya que los videojuegos son programas de gran complejidad.

Sin embargo, dicha complejidad a veces juega a nuestro favor. A menudo, los videojuegos ya no se generan a base de crear todo el motor del juego de manera ad hoc, sino que se basan en un motor genérico, personalizado con ficheros de configuración o scripts, que son los que realmente definen el comportamiento de ciertos aspectos. Por otro lado, los videojuegos de hoy son programas muy complejos que deben ser fáciles de depurar y a menudo necesitan un nivel de ajuste de las reglas a base de prueba y error. Por todo ello, y para no tener que recompilar TOOODOOO el programa cada vez que se requiere una actualización, no es infrecuente que los ficheros que definen la propia lógica de las reglas se encuentren fuera del propio código binario ejectuable, y en un formato más o menos legible y fácil de depurar… tanto para los desarrolladores como para el resto del mundo.

Un ejemplo interesante lo tenemos en la saga Puzzle Quest. Un juego en el que no es difícil que te entren ganas de «ajustar un poco las reglas» a causa de la frecuencia con la que el ordenador tiene excesiva «suerte» a la hora de que aparezcan nuevas piezas en la pantalla. Quizá es mi sesgo personal, pero pone de los nervios. El caso es que una gran parte de las reglas se encuentra en ficheros en formato XML y scripts LUA, totalmente legibles. Gracias a la expresividad de ambos lenguajes, resulta relativamente simple deducir el significado de cada valor y qué hay que cambiar.

Para modificar una habilidad a nuestro gusto, solo hay que seguir los siguientes pasos: Primero, se debe abrir el fichero «Assets.zip», en la propia carpeta del juego. Aquí están todos los ficheros de configuración, contenidos. Una vez abierto, hay que buscar el código asociado a la habilidad que se desea modificar. Para ello, entramos en la carpeta del idioma que usamos y abrimos «StandardSpellsText.xml», que lista todas las habilidades del juego en formato XML. Encontrado el nombre de la que deseamos retocar (por ejemplo «Fire Bolt»), el atributo XML «tag» nos da el código (en este caso «SFBO»).

La definición de las habilidades está en la carpeta «Assets/Spells» del propio «Assets.zip». Para cada código hay un fichero .xml y otro .lua (para nuestro ejemplo, SFBO.xml y SFBO.lua). El fichero .xml especifica el coste de la habilidad mientras que el fichero .lua especifica su efecto en scripting, mediante la función «CastSpell». Si modificamos su contenido, mejor cambiar también la función «ShouldAICastSpell» (que calcula cuando un oponente que tenga dicha habilidad la usará) para evitar que los enemigos no nos hagan tomar nuestra propia medicina.

¡Qué gran invento el scripting y XML!

Otro ejemplo que me he encontrado muy recientemente es el caso del Might & Magic X – Legacy, otro vivo ejemplo de que la «vieja escuela» de RPGs sigue vivita y coleando, y que se basa en Unity, un motor muy popular para la creación de videojuegos. Aquí, las reglas que definen las capacidades de los personajes o los puntos de experiencia para llegar a cada nivel se definen en un… fichero de texto CSV! Así, tal cual, perfectamente comentado y todo, para no tener que pasar por el trabajo de pensar cómo llevar a cabo ingeniería inversa. Así pues, si no estamos de acuerdo con las habilidades iniciales de las diferentes clases de personaje, las podemos cambiar.

Yo quiero un cruzado con una espada de doble puño. La reglas penalizan dicho opción, ya que los cruzados óptimos se basan en espada y escudo. Para demostrar nuestro desacuerdo con los diseñadores del juego, vamos a cambiar esto. Buscamos el fichero «CharacterClassStaticData.csv» en la jerarquía de carpetas del juego, donde se definen todas las clases, y echamos un vistazo. Cada entrada indica claramente la definición de las diferentes clases de personaje (12 en total). Ya en los comentarios de las primeras líneas de texto nos indica el formato de cada entrada, con lo que es sencillo encontrar las listas de habilidades, sus características iniciales o puntos de vida/magia. Las habilidades se clasifican en experto, maestro o gran maestro de acuerdo a 3 listas de valores entre dobles comillas (si hay un único valor, no son necesarias).

Might & Magic. Todo se puede resolver editando un fichero de texto

Donde hay que pensar un poco es con como asociar los distintos valores numéricos a las propias habilidades. Pero con un poco de trabajo deductivo comparando los niveles de las habilidades del resto de clases, ya conocidos, o simplemente a base de prueba y error, vemos que la habilidad de armas a dos manos tiene asignado el código 8. Para no abusar y mantener la base que cada clase solo tiene 4 habilidades al máximo nivel potencial, haremos un trueque de habilidades entre listas existentes. Pondremos armas a dos manos como habilidad de gran maestro, bajaremos disciplina arcana (código 6) a maestro y eliminaremos escudo (código 9), que ya no nos sirve para nada. Por lo tanto, intercambiamos valores y ya lo tenemos. Y así crearíamos una clase a nuestro gusto modificando los propios ficheros del juego. Nuevamente, eso, sí, hay que ser cuidadoso de no poner valores incorrectos. En caso de poner el mismo valor repetido en distintas listas, parece ser que el juego lee los valores secuencialmente, por lo que el primero que encuentra (el vinculado a la habilidad más baja) es el que vale. Y si queremos abusar, pues nada, todo al tope…

Así pues, ya vemos que incluso juegos acabados de salir del horno pueden ser «pokeados» simplemente trasteando sus ficheros y rebuscando. Es solo paciencia y un poco de suerte. Como deberes, podéis echar un vistazo a la saga de juegos indie muy entretenida llamada Avernum, que también basan el comportamiento de sus personajes exclusivamente en scripts guardados en ficheros en texto plano.

Joan Arnedo es profesor de los estudios de Informática, Multimedia y Telecomunicaciones en la UOC. Director académico del Postgrado de Diseño y Programación de Videojuegos e investigador en el campo de la ludificación y los juegos serios en el eLearn Center. Su experiencia se remonta a cuando los ordenadores MSX poblaban la Tierra…

(Visited 24 times, 1 visits today)
Autor / Autora
Joan Arnedo Moreno
Comentarios
Deja un comentario