Hola a todos:

El 24 de septiembre intentamos realizar la primera beta en vivo del sistema de reestructuración de mundos. Un momento que muchos llevabais tiempo esperando. Como muchos de vosotros ya sabréis, no fue exactamente como planeamos. Hoy volvemos para compartir con vosotros nuestro análisis a posteriori del evento. Para los que no conozcáis este término, un análisis a posteriori es un proceso en el que un equipo de desarrollo analiza un evento ocurrido (un lanzamiento, un apagón, etc.) e intenta identificar qué salió bien y qué podría haberse hecho mejor. El objetivo es identificar mejoras para el proceso que se puedan aplicar en proyectos futuros. Nos hemos tomado algunas libertades creativas con el formato para que sea algo más accesible para los lectores, pero esperamos que disfrutéis viendo qué se cocía entre bastidores.

En esta publicación os ofreceremos un resumen de la beta y un repaso del problema con el que nos encontramos, además de compartir con vosotros lo que hemos aprendido. Al final, hablaremos de nuestros planes para la siguiente beta.

Antes de empezar, queremos dejar claro que el breve parón de inicios de sesión que afectó a los servidores europeos justo antes de la beta fue un incidente distinto y sin relación. ¡Con eso desmentimos al menos una teoría de los fans!

Resumen

A las 19:00, hora peninsular española (10:00, hora del Pacífico) del viernes, 24 de septiembre, activamos la función de reestructuración de mundos durante el reinicio semanal de Mundo contra Mundo para Europa. En este reinicio, se saca a todos los jugadores de WvW, se reconfiguran los emparejamientos y se reinician las puntuaciones. Cambiar a la reestructuración de mundos durante el reinicio aseguró que tuviéramos un lienzo en blanco para el comienzo de la beta.

Logramos habilitar con éxito la reestructuración de mundos en los servidores de juego en vivo para Europa (nuestro primer obstáculo), pero casi de inmediato empezamos a recibir informes de que algunos jugadores estaban siendo colocados en equipos incorrectos. En una película, este sería el típico momento en el que empiezan a sonar las alarmas y las luces rojas empiezan a volverse locas. El problema de base era que algunos jugadores tenían fragmentos (malos) de datos desfasados que no se habían actualizado antes de que intentaran unirse a WvW. Cuando un jugador afectado intentaba entrar en WvW, su cliente de juego solicitaba entrar usando los datos de esos fragmentos malos, lo cual provocaba que acabaran en el mapa equivocado e incluso que se les asignara el equipo del color equivocado. Esto unido a un problema en el que la interfaz no mostraba los nombres de equipo correctos, creó mucha confusión.

Y en esto, llegó el segundo problema.

No hay duda de que había mucha agitación por la prueba beta. Además, el reinicio del viernes supuso que participó muchísima gente, por lo que algunos mapas tuvieron unas colas larguísimas. Naturalmente, los jugadores empezaron a entrar en el mapa de exceso, el Borde de la Niebla, para matar el tiempo mientras esperaban en su cola. Mientras estábamos ocupados arreglando el primer problema, recibimos un aviso de nuestro ingeniero jefe de servidores, Robert Neckorcuk (tal vez lo conozcáis por “Dentro de ArenaNet: Análisis de una desconexión del juego en vivo“). Nos alertó de que se estaban usando una cantidad anormal de recursos de servidor para las instancias del mapa del Borde de la Niebla. Nada menos que unas treinta veces más de lo habitual.

No obstante, esto no se debió a un aumento de la actividad de los jugadores. Estaba ocurriendo algo más insidioso. Vimos que se estaban creando instancias nuevas del Borde de la Niebla a pesar de que había capacidad de sobra para los jugadores en las instancias ya creadas. En otras palabras, se estaban creando demasiadas instancias de mapas en comparación con el número de jugadores activos, lo cual consumía una enorme porción de nuestros recursos de servidor. Y creednos: quedarse sin capacidad en los servidores no es nada bueno. Esto dio como resultado una cascada de problemas que debía vigilarse y arreglarse manualmente. Nos preocupaba el hecho de que no sabíamos por qué se estaban creando esas instancias, y fue minando nuestra confianza para poder resolver los problemas de la beta sobre la marcha. Y justo en ese momento, otro de nuestros ingenieros nos informó de que había visto un tercer problema. ¡Todo un festival!

Cuando lanzamos contenido nuevo, funciones, o realizamos pruebas beta, intentamos añadir registros adicionales. Estos registros contienen los eventos que tienen lugar dentro de un sistema. Se pueden usar para asegurar que el sistema funcione como se diseñó, ofrecen datos sobre cualquier problema con el que nos encontremos y nos ayudan a evaluar posibles arreglos. Tenemos servidores enteros dedicados a administrar todos los registros que se generan en el juego. Pues bien, ese día, esos servidores encontraron la horma de su zapato. BattleSrv, el nuevo servidor de reestructuración de mundos, registraba errores a un ritmo tan alto que empezó a estresar la infraestructura de registros. Estos servidores de registros son cruciales para operar Guild Wars 2, así que fue de lo más perturbador.

Puede que cueste creerlo, pero los cuatro párrafos anteriores describen lo que ocurrió en unas dos horas de eventos, durante las cuales la experiencia de juego en Europa se vio gravemente mermada. Nuestro equipo hizo piña e ideó dos posibles soluciones.

La opción A era implementar un puñado de mitigaciones a corto plazo para que la beta siguiera funcionando (la opción difícil). Esto habría incluido lanzar una “versión en blanco”, la cual habría requerido que los jugadores cerraran sesión y se descargaran una pequeña actualización del servidor. También habría supuesto forzar un refresco de datos para todos los jugadores afectados por el problema de datos desfasados que mencionamos antes, lo cual los habría asignado al equipo correcto. Cabría señalar que creemos que esto habría solucionado el problema, pero no podíamos probarlo antes de intentarlo. Además, no había ninguna garantía de que los demás problemas no siguieran apareciendo a lo largo de la semana a medida que más jugadores iniciaran sesión para participar en la beta. También era probable que necesitáramos hacer la misma “versión en blanco” tras el reinicio en Norteamérica, unas pocas horas después. En este escenario también habríamos tenido que deshabilitar el mapa del Borde de la Niebla durante toda la semana de la beta para mitigar el problema del uso del servidor. Encontramos una solución para el problema de registro, pero nos habría llevado algo de tiempo lanzar el cambio (en un viernes por la noche, nada menos), durante el cual nuestros servidores de registro habrían seguido sufriendo de lo lindo.

La opción B era cancelar la beta de forma prematura. Naturalmente, esta fue la opción por la que nos decantamos al final. La opción A tenía demasiados riesgos y demasiados factores desconocidos asociados. Una vez nos decidimos por cancelar la beta, pudimos volver a la unificación de mundos sin problemas tras un rápido reinicio de los mapas de WvW.

Más tarde ese día…

Tras un pequeño respiro, el equipo se reunió para llevar a cabo un análisis a posteriori y crear un plan de acción para los problemas que experimentamos. Estas fueron las mayores victorias del día:

La tecnología de la reestructuración de mundos funcionó bien a escala, aunque no lo pareciera. Este fue un gran hito que nos dio mucha más confianza en la tecnología detrás de la reestructuración de mundos. Por cada jugador que acabó en el equipo equivocado, hubieron muchísimos más que fueron emparejados correctamente. Dado que pudimos establecer con éxito la reestructuración de mundos, pudimos recopilar suficientes datos durante el intento de beta de dos horas que nos ayudaron a acotar en qué parte del código se encontraban estos problemas. Ver cómo estos problemas aparecieron en vivo también nos ayudó a comprender cómo podemos mejorar nuestros procesos de pruebas internos para detectar problemas en la reestructuración de mundos en desarrollo. Las funciones de servidor a gran escala pueden ser peliagudas de probar completamente en el entorno de desarrollo, sobre todo para un sistema tan hecho a medida como es la reestructuración de mundos.

En siguiente lugar, el algoritmo de emparejamiento que se usó para la primera beta creó una distribución increíblemente equilibrada de jugadores y clanes por todos los equipos. En el sistema de unificación de mundos, se puede ver hasta un 50 % de diferencia en la actividad de los jugadores entre mundos. En la primera beta, la mayor diferencia entre dos equipos fue solo del 2 %: una mejoría enorme. El objetivo principal de la reestructuración de mundos es crear emparejamientos equilibrados, así que nos emocionó mucho ver esto.

Por último, pudimos volver con éxito a la unificación de mundos sin muchos problemas una vez decidimos cerrar la beta. Lo importante de este punto es más el hecho de que el equipo estuvo bien preparado para este escenario, tras haber preparado una hoja de ruta detallada por adelantado para devolver el sistema a su estado original. Probamos este proceso varias veces en nuestros servidores de desarrollo, pero nunca a la escala vista en el juego en vivo. La práctica hace al maestro.

¿Y ahora?

Hemos identificado diez errores que debemos arreglar sin falta antes de volver a intentar la beta. La mayoría de los cuales están relacionados con el problema de atajar los datos desfasados que mencionamos antes, y con los nombres de los equipos que se mostraron de forma incorrecta. Hemos hecho un progreso significativo, pero todavía nos queda bastante por hacer. Ahora mismo, nuestro objetivo es arreglarlos para la actualización del 9 de noviembre, dado que la siguiente semana de beta comienza el 12 de noviembre.

Realizaremos algunos cambios de calidad de vida en Mundo contra Mundo para la actualización del 9 de noviembre. Vuestros comentarios nos lo han dejado claro: las rutas de recompensa de las escaramuzas son demasiado largas, sobre todo para jugadores nuevos o para aquellos que juegan en el equipo en tercer lugar de un emparejamiento. Para arreglar esto, aumentaremos el número de puntos de escaramuza conseguidos por puesto en partida de 3/4/5 a 4/5/6. También añadiremos un nuevo +1 de bonificación de puntos de escaramuza para jugadores que tengan un rango WvW entre 1 y 149. Las bonificaciones de puntos basados en el rango también aumentarán en +1 (para un total de +2 en bronce, +3 en plata y así sucesivamente).

También hemos echado un vistazo a los componentes de la ruta de escaramuzas y al sistema de participación, que no están cumpliendo con el objetivo para el que fueron diseñados. A corto plazo, experimentaremos con retirar incentivos en ciertas situaciones de jugabilidad no intencionadas, y también retiraremos el “periodo de gracia de participación” que se otorgaba por reparar estructuras en WvW. También retiraremos la bonificación de puntos de Sobrepasados, aunque el potenciador de estadística de Sobrepasado seguirá ahí.

¡Eso es todo para la actualización de hoy! Gracias por leer esto.

Nos vemos pronto.
–El equipo de Guild Wars 2