Resumen de la mesa Restaurar la historia: WoW: Classic

En el seno de la comunidad, hace ya bastante tiempo que se habla de la esperada experiencia de World of Warcraft: Classic, pero para comprender bien la tarea de crear dicha experiencia con el nivel de calidad que caracteriza a Blizzard, nos subimos al escenario junto con los ingenieros de software Brian Birmingham y Omar Gonzalez y el director de juego Ion Hazzikostas.

Encontrar las piezas

Omar simplificó los fundamentos de la creación de un juego dividiéndolos en tres factores: datos de la base de datos, materiales artísticos y código fuente.

• Los datos de la base de datos incluyen los puntos de salud de una criatura, el aguante de un objeto, las ubicaciones de aparición por el mundo y millones de cosas más.
• Los materiales artísticos incluyen desde el aspecto que tiene un elfo de la noche cuando usa Fusión de las sombras hasta el movimiento de un orco al blandir su hacha, pasando por los sonidos que hace Piroexplosión.
• El código fuente son las instrucciones necesarias para mostrar el juego, procesar las entradas y conectar a los jugadores.

Para comenzar, tuvimos que averiguar hasta qué fecha abarcaba nuestro código fuente y descubrimos que el depósito de código se remontaba al año 1997, mucho antes de que se empezara a desarrollar World of Warcraft.

Fue un buen comienzo, pero hubo problemas con la forma de gestionar las actualizaciones de la base de datos que tenían antes los desarrolladores. A diferencia de nuestro código, que tiene múltiples bifurcaciones del juego con las que se podría trabajar y desarrollar por separado, los primeros datos de la base de datos se sobrescribían con cada actualización. Por suerte, solucionamos ese problema muy rápido tras el lanzamiento y, después de buscar, encontramos datos que se remontaban a la versión 1.12, e incluso más.

Por último, encontramos nuestros materiales artísticos en copias de seguridad antiguas, que coincidían con todos los datos de la base de datos que conservábamos.

Con la unión de los tres componentes, pudimos realizar una prueba e iniciar sesión en el juego, crear nuevos personajes, matar jabalíes y completar algunas misiones.

Estilo de juego clásico en un mundo moderno

Aunque teníamos una versión del juego funcional, había que solucionar muchos más retos. La tecnología que sustenta el juego ha evolucionado mucho desde su primer lanzamiento: compatibilidad con la nube, integración con la aplicación Battle.net, características de asistencia al cliente y un montón de errores y exploits que se han corregido desde entonces.

Para superar estos obstáculos, nos fijamos en lo que nos gustaba (arte y datos) y lo que no (el código). Queríamos comprobar si era posible utilizar los materiales artísticos y los datos clásicos en nuestro código moderno sin que volase todo por los aires. Las cosas no fueron bien desde el principio, pero, a base de ensayo y error, desarrollamos una prueba de concepto del proceso de integración que podía desembocar en algo jugable. Esto aumentó nuestra fe en nuestra capacidad de crear una experiencia con el nivel de calidad que caracteriza a Blizzard en nuestra plataforma moderna.

Desde el prototipo a la demo

Los pilares fundamentales, los datos de la base de datos, el código fuente y los materiales artísticos se unen para crear características de cara a los jugadores, como el terreno, las mecánicas de juego, la animación y la iluminación. Las diferentes características requieren que los elementos fundamentales se relacionen entre sí de diferentes formas.

Para entender por completo la interacción, pongamos como ejemplo el terreno. Esto incluye la ubicación de las colinas y valles, árboles, edificios y demás. Cuando conectamos los archivos de datos de terreno antiguos al nuevo sistema de juego, nos dimos cuenta de que este analizaba los datos de forma diferente. Como consecuencia, el sistema actualizado y los datos clásicos no se alineaban bien, por lo que nos encontrábamos cosas como hogueras Kolkar bajo el agua o árboles quemados de la época del Cataclismo.

Por suerte, nuestro editor moderno es capaz de realizar algunas conversiones sobre estos datos. Los datos del terreno podemos convertirlos con el mismo editor que usamos en Battle for Azeroth. El editor moderno sabe cómo cargar el formato antiguo del terreno, transformarlo al formato nuevo y exportarlo a nuestro motor moderno. Esto corrigió los problemas relacionados con las ubicaciones de las hogueras y la aparición de árboles, entre otras cosas.

Otro obstáculo que superamos fue la forma de almacenar y combinar los datos. World of Warcraft tiene múltiples parches en desarrollo en todo momento porque cada parche se encuentra en una etapa de desarrollo diferente. Si añadíamos un elemento artístico o un archivo de terreno a un parche, queríamos que apareciese de forma automática en los parches siguientes. En los catorce años del proyecto, esto siempre se ha hecho siguiendo una secuencia cronológica. Si hubiésemos implementado el nuevo parche de Classic en el desarrollo actual, habríamos sobrescrito cosas como el dique actual en Loch Modan con la versión restaurada anterior. Esto habría provocado problemas con el lanzamiento de Battle for Azeroth.

Para evitar esto, les enseñamos a nuestras herramientas algunos trucos para poder implementar parches de Classic sin que afectasen a la versión actual del juego. Copiamos los datos de la versión 1.12 en un nuevo proyecto, enseñamos a las herramientas a distinguir entre ellos y ahora, al crear parches, todos los cambios permanecen en el proyecto clásico sin interactuar con los parches principales. Esto puede parecer sencillo —tanto como copiar un directorio—, pero la parte difícil es enseñar a las herramientas a entender el proceso para que puedan hacer modificaciones por nosotros de forma automática. La posibilidad de usar nuestras herramientas internas es una gran ventaja y queríamos asegurarnos de que Classic tuviera acceso a todos nuestros datos e infraestructuras.

Animaciones y modelos clásicos

También aprovechamos para restaurar por completo los modelos con su apariencia clásica, pero, durante el proceso, descubrimos que algunos estaban «rotos». En algunos casos nos faltaban las texturas, así que tuvimos que investigar para averiguar cómo debían aparecer estos elementos y corregirlos dentro del sistema.

También restauramos las animaciones originales, pero como nuestro sistema de animación está muy unido al código de juego, tuvimos que realizar cambios tanto en los datos como en el código para que las animaciones recuperaran el aspecto de la versión 1.12. Durante el proceso encontramos algunos fallos; por ejemplo, algunos modelos que debían aparecer tumbados lo hacían derechos, y viceversa. Sin embargo, pudimos corregirlos fácilmente.

Restaurar el sistema de clases

Aunque hemos realizado grandes progresos convirtiendo los datos en código, algunos sistemas carecen de equivalente moderno. Probablemente, la clase más afectada sea la del cazador. Los sistemas de lealtad y felicidad de las mascotas se habían eliminado, así como el entrenamiento de mascotas y la capacidad de usar tanto un arma a distancia como un arma cuerpo a cuerpo. En estos casos, convertir los datos antiguos al nuevo sistema no habría funcionado, puesto que no existía para ellos. Por lo tanto, teníamos que recuperar el código antiguo, y lo hicimos. Por suerte, el proceso de restauración fue como la seda..., pero la realidad de tener que comprar flechas o alimentar a las mascotas de nuevo pilló a muchos por sorpresa.

Este problema no estaba solo en el cazador. También tuvimos que cambiar el código de los puntos de combo de los pícaros, puesto que nuestro sistema de recursos moderno sabe cómo ganar y gastar los puntos de combo, pero no cómo perderlos al cambiar de objetivo. También debíamos tener en cuenta otras fórmulas de combate antiguas. En este caso recuperamos el código para las fórmulas de combate anteriores, incluidos los golpes críticos y los golpes aplastantes. La posibilidad de que se produzcan se modifica también por la diferencia entre la defensa del defensor y la habilidad de arma del atacante. ¡Sí, la habilidad con las armas ha regresado! Teníamos los datos, pero necesitábamos restaurar el código que aumentaba vuestras habilidades cuando las usabais y hacía que vuestro nivel de habilidad incidiera en la posibilidad de golpear o dar un golpe de refilón.

Interfaz de usuario e iluminación

El menú del personaje es un gran ejemplo de una interfaz de usuario emblemática que había que restaurar, esforzándose al máximo para que siguiera transmitiendo las mismas sensaciones, desde los efectos en pantalla hasta la iluminación del personaje. Aunque no queremos prometeros que será perfecta, os aseguramos que estamos realizando comparaciones paralelas sin escatimar trabajo para crear una experiencia auténtica.

Otro ejemplo de iluminación sería el Bosque de Elwynn. En la historia de Warcraft hubo un periodo en el que cambiamos todas las ecuaciones lumínicas y, como consecuencia, los grafistas de entorno tuvieron que repasar todas las zonas para mejorar la iluminación y aprovechar las nuevas ecuaciones. Para recrear la experiencia original hemos tenido que revertir dichos cambios. En primer lugar restauramos los datos de iluminación antiguos, lo que nos acercó mucho más a la iluminación original. Aplicando algunos cambios más en las fórmulas de niebla y distancia, así como una serie de modificaciones en las sombras, conseguimos acercarnos aún más a la iluminación original.

¿Habéis terminado ya?

Después de tanto trabajo, seguramente os preguntaréis si hemos terminado ya o si no habría sido más fácil que nos limitáramos a actualizar el cliente de referencia.

Tras pasar un año entero trabajando en este proyecto y bregando con diferentes errores y desafíos, hay un tema recurrente: que la diferencia entre lo que tenemos y lo que queremos es claramente visible. Cuando observamos el World of Warcraft actual, podemos ver las diferencias que existen. Si intentáramos actualizar el cliente de referencia, detectaríamos un montón de cambios invisibles, como vulnerabilidades potenciales, cierres inesperados que no aparecerían hasta que hubiera millones de jugadores jugando en línea a la vez, etc. Decimos abordar este problema de una forma que hiciera que nuestro trabajo fuera evidente, no algo difícil de detectar. 

Pero todavía no hemos terminado: aún tenemos que examinar un montón de características de las capitales, como los bancos y las casas de subastas. También tenemos que probar las mazmorras y bandas para asegurarnos de que las habilidades de jefe sigan funcionando correctamente. Y además, tenemos que examinar todos los sistemas JcJ.

Filosofía y planes de futuro

Al restaurar World of Warcraft: Classic, queríamos ofrecer una experiencia auténtica para que, si alguien no había jugado al juego desde los primeros tiempos, pudiera retomarlo exactamente donde lo dejó. Puede que ahora las cosas vayan más fluidas y los equipos sean mejores, pero debería provocar las mismas sensaciones que al jugar a World of Warcraft en 2006. Incluso más allá de las ecuaciones del combate y la habilidad, una parte importante de ello son las dinámicas sociales y la dependencia en los demás; por ejemplo, la dificultad para encontrar un grupo y la confianza que se deposita en él cuando se entra en una mazmorra o en un combate.  Además, no queríamos vernos obligados a cambiar los datos de la versión 1.12 y la consiguiente experiencia de juego.

Muchas decisiones que tomamos estaban bastante claras. Era obvio que teníamos que quitar cosas como el buscador de mazmorras. También nos aseguramos de dejar fuera los grupos entre reinos, el sistema de logros, las casas de subastas unificadas y, sí, la capacidad de volar. 

Otras decisiones fueron un poco más complejas. Hubo una época en la que el límite de perjuicios era 8. Luego se amplió a 16 y más tarde se eliminó definitivamente. Este cambio dio un giro radical al equilibrio de clases y a las estrategias de perjuicios que podían usar los jugadores para superar el contenido. Para no tener que modificar los datos de la versión 1.12, nos decidimos por el límite de 16 perjuicios para Classic.

En la actualidad, el correo electrónico dentro del juego entre compañeros de hermandad es instantáneo, pero antiguamente tenía un retardo de una hora, al igual que entre desconocidos. El cambio al correo instantáneo facilitó las cosas, pero eliminó la interacción social de tener que quedar con alguien para realizar una transacción si se necesitaba algo antes. Por esta razón hemos reintroducido ese retardo. Hemos dejado otros cambios de tipo práctico, como el autocompletado de nombres o el vaciado rápido del buzón. Esta decisión fue bastante sencilla ya que cualquiera podría crear un complemento que hiciera lo mismo, y no nos parecía que tuviera sentido eliminar ese tipo de ayudas.

Antes, el intercambio de botín solía requerir la implicación de Asistencia al cliente si alguien obtenía por accidente algo que no debía. Con el actual sistema, más moderno, los jugadores tienen un periodo de tiempo en el que pueden intercambiarse botín. Nos pareció que merecía la pena mantener esta función en Classic para evitar un montón de solicitudes de asistencia que eran completamente innecesarias (¡lo sentimos, acaparadores!).

Para las clases que dependen de la regeneración de energía, como los pícaros, las cosas también han cambiado mucho desde los tiempos de Classic. Antes la regeneración se daba a intervalos, al ritmo del «latido» del servidor. Así, para ganar 20 de energía, se tardaban dos segundos enteros. Hoy en día, el sistema se ha perfeccionado, de forma que se regenera 1 de energía cada décima de segundo. Esta diferencia ha cambiado la frecuencia con la que se pueden usar ciertas habilidades. Lo que ahora podría parecer una ventaja menor, en realidad cambia el flujo mismo de las rotaciones de combate y la capacidad de daño explosivo del juego clásico. Nos parecía importante recuperarlo para ofrecer una experiencia auténtica.

Los complementos han cambiado mucho a lo largo de los años; se han vuelto mucho más sofisticados a medida que sus autores han ido ganando experiencia y conocimientos. Aún no hemos encontrado una solución plenamente coherente sobre lo que significa esto para Classic, pero lo que sí sabemos es que no vamos a volver a la API de complementos de la versión 1.12. De hacerlo, abriríamos la puerta a automatizar las decisiones de combate casi por completo, un comportamiento típico de «bots» que es contrario a la experiencia de juego de WoW. Tenemos claro que eso no lo queremos. Al otro lado del espectro, la API moderna ofrece más funcionalidad a la hora de crear características sociales que también podrían deteriorar la experiencia auténtica de Classic. Aún estamos puliendo los detalles y buscando un equilibrio entre los dos extremos. Estaremos muy pendientes de los comentarios de la comunidad y de los creadores de complementos para decidir dónde establecemos los límites.

Plan de lanzamientos del contenido

Aunque vamos a empezar con la versión 1.12, también queríamos estar seguros de ofrecer el viaje que esperan los jugadores. Como itinerario para ese viaje, tenemos cuatro etapas adicionales que pensamos incorporar a la experiencia con el tiempo.

• Etapa 1: Núcleo de magma, Onyxia, La Masacre, Kazzak, Azurgos
• Etapa 2: Guarida de Alanegra, Campos de batalla y recompensas JcJ, Zul'Gurub
• Etapa 3: Ahn'Qiraj (incluido el evento de apertura), nivel 0,5, contenido de Silithus, dragones verdes
• Etapa 4: Banda de Naxxramas, Invasión de la Plaga

Dichos planes podrían cambiar, pero queríamos contaros lo que tenemos preparado. Estamos deseando conocer vuestra opinión, a pesar de que nos queda mucho trabajo por delante.

Los asistentes a la BlizzCon y aquellos que posean la Entrada Virtual de la BlizzCon 2018 ya pueden probar la demo de Classic! Para saber más, leed la última entrega de Un café con los diseñadores y la publicación en el foro con las restricciones de la demo.