DESARROLLO: EL CICLO DE UNA VERSIÓN
El mes pasado, el equipo de la Grieta del Invocador (el grupo más grande que engloba al llamado “equipo de equilibrio”) se dedicó a tuitear a tiempo real el proceso de desarrollo de los cambios de equilibrio para la versión 9.13. Hoy os traemos algunos de esos Tweets y resumimos toda la información para mostraros en qué consiste el desarrollo de una versión.
Antes de explicar por qué hemos debilitado a vuestro campeón favorito, vamos a empezar por la parte más chula… la planificación.
Todo planeado… más o menos
Las versiones se ponen en marcha con una reunión de planificación del trabajo, en la que los diseñadores del juego deciden cuáles son las cuestiones de importancia media que quieren abarcar en este ciclo. Entre este tipo de cuestiones se incluyen los cambios a objetos (como Hoja de furia de Guinsoo), las mejoras de calidad a campeones (como la de la pasiva de la definitiva de Blitzcrank) y las correcciones asociadas a campeones que están al caer o que han salido hace poco. También planeamos cambios más importantes a la experiencia de juego para el futuro, como los de la pretemporada de 2020. En esta reunión no decidimos las mejoras y debilitaciones simples basadas en números; solemos trabajar en esos aspectos al final del ciclo de cada versión.
A la hora de elegir los asuntos de importancia media en los que trabajar, solemos hacernos las siguientes preguntas (en este orden):
- ¿Hay algo que el juego necesite urgentemente que no se pueda arreglar con un cambio simple y que requiera de una cantidad de testeo considerable?
- ¿Hay algo pendiente de versiones anteriores con lo que queramos seguir?
- ¿Hay algo que el juego necesite y que podamos terminar en unas 6 u 8 semanas?
Intentamos tomar estas decisiones con una visión de la experiencia de juego lo más amplia posible, teniendo en cuenta un conjunto de datos de todos los niveles de destreza y de la escena profesional, así como las impresiones globales del equipo acerca del estado actual de LoL.
Tras responder a estas preguntas en el contexto de la versión 9.13, decidimos centrarnos en Swain, Vara de las edades, Pyke en las calles en solitario, Udyr, Illaoi, Mordekaiser (con sus correcciones potenciales) y en los cambios para la pretemporada.
Elegir el enfoque
Después toca decidir cómo queremos alcanzar los objetivos para cada una de las cuestiones mencionadas. Puede sonar sencillo, pero suele ser lo que más tiempo nos lleva. A medida que vamos recopilando los comentarios de los jugadores, otros diseñadores y de los analistas de datos y de calidad, la lista de cambios se va actualizando constantemente.
Una de las formas más rápidas de hacernos una idea de lo que piensa el resto del equipo son las “charlas relámpago”, que tenemos cada dos días. En ellas, los diseñadores comparten con los demás sus propuestas de cambios, y el resto del equipo aporta ideas, comentarios y posibles problemas al respecto. En un grupo de diseñadores es muy fácil que algo así se vaya de las manos y se acabe hablando demasiado de cada cambio, así que establecemos un límite de cuatro minutos por tema. Pasado el tiempo establecido, votamos rápidamente para determinar si hace falta seguir hablando de ello o no.
Además de estas reuniones, todo el equipo de la Grieta del Invocador (analistas de datos, ingenieros y gestores incluidos) organiza y participa en sesiones de testeo dos veces al día. Esto les ayuda a hacerse una idea de la repercusión de los cambios en partida. Además, contamos un equipo completo de analistas de calidad de MMR alto que llevan a cabo sus propios testeos a diario y comparten sus comentarios con los diseñadores, para ayudarles a decidir si los cambios cumplen los objetivos previstos. Estas sesiones también son la ocasión perfecta para vacilarse un poco (de forma profesional y amistosa, por supuestísimo).
Por si os interesa, esta es la evolución de algunos de los ajustes de equilibrio de la 9.13 desde la reunión de planificación inicial hasta el final del ciclo de la versión.
Todo un reto
A veces, el equipo de la Grieta del Invocador y el de campeones unen sus fuerzas para desarrollar cambios importantes para algunos campeones. Suelen ser cosas con más impacto que las típicas mejoras o debilitaciones, pero a menor escala que una actualización (los cambios de Aatrox en la versión 9.9 son un buen ejemplo). Es algo que puede darse cuando los problemas de un campeón en concreto no se pueden solucionar con cambios numéricos o de calidad. En estos casos, suele haber múltiples estrategias para lidiar con los problemas, y no tenemos forma de saber cuál será la más efectiva hasta que las hayamos explorado todas. Por este motivo, esta clase de cambios suelen llevarnos más tiempo; no basta con un par de semanas.
En la versión 9.13, RiotRepertoir empezó a darle vueltas a cambios a largo plazo para Akali.
En este Tweet encontraréis el correo electrónico completo, en este, los comentarios de Riot Blaustoise y en este, la lista de cambios actual.
Incluso en el improbable caso de que el equipo se decida enseguida por una dirección determinada, los cambios de este estilo no aparecen en la siguiente versión. League of Legends tiene jugadores por todo el mundo que hablan distintos idiomas, así que es probable que cualquier cambio que requiera actualizar las descripciones de las habilidades en partida necesite ser pospuesto para que los equipos de localización tengan tiempo de traducir lo que haga falta.
Ya hemos lanzado los cambios a Illaoi pero, si os interesa, podéis encontrar la lista completa aquí.
Mejorad a mi campeón, porfi
Al final del ciclo de una versión, nos ponemos manos a la obra con la que a veces es la sección más polémica de los cambios de equilibrio: las mejoras y las debilitaciones de los campeones. Decidir este tipo de cosas al final del ciclo nos permite recopilar muchos más datos de la versión vigente, que hemos lanzado unos cinco días antes.
Cada dos semanas, el equipo organiza una reunión para discutir el estado del juego. En ella, analizamos los datos disponibles de la versión actual para decidir qué campeones necesitan un empujoncito y cuáles se tienen que relajar un poco. Para ello, el equipo se apoya en los umbrales recientemente establecidos, que aportan datos indiscutibles y evitan que tengamos que especular. Esto garantiza nuestra objetividad a la hora de determinar el nivel de poder de un campeón en todos los niveles de destreza e impide que se nos pase alguno por alto.
Aquí tenéis un recordatorio de estos umbrales:
Nivel | Debilitación si CUALQUIERA se cumple | Mejora si TODAS se cumplen |
Medio
Oro I y niveles inferiores | > 54,5 % de porcentaje de victorias si el porcentaje de bloqueo es inferior al PMB
HASTA > 52,5 % de porcentaje de victorias si el porcentaje de bloqueo es superior a 5 veces el PMB | < 49 % de porcentaje de victorias |
Alto Platino IV hasta Gran Maestro | > 54 % de porcentaje de victorias si el porcentaje de bloqueo es inferior al PMB
HASTA > 52 % de porcentaje de victorias si el porcentaje de bloqueo es superior a 5 veces el PMB | < 49 % de porcentaje de victorias |
De élite Aspirante | > 45 % de porcentaje de bloqueo | < 5 % de presencia |
Profesional
Las 5 mejores regiones profesionales | > 90 % de presencia en la versión actual
O > 80 % de presencia media en 2 versiones consecutivas. | < 5 % de presencia |
Esta es la información recopilada de la versión 9.12:
VER LAS 4 IMÁGENES
Según estos datos, los campeones y los objetos que necesitaban mejoras o debilitaciones en la 9.13 eran los siguientes:
Mejoras:
- Sylas
- Syndra
- Ornn
- Tristana
- Presagio de Randuin
Debilitaciones:
- Sivir
- Karma
- Sona
- Sejuani
- Segador de esencia
Esto es lo que pasa cuando vacilas con que van a debilitar a los campeones preferidos de otros jugadores y van y debilitan al tuyo.
Los datos nos suelen ayudar a ser objetivos, pero hay ocasiones en las que nos servimos de la experiencia conjunta de todo el equipo para realizar cambios subjetivos a pesar de que la información obtenida no indique que sean necesarios. En esta versión, el mejor ejemplo es Sona. Ha tenido una presencia muy alta en partidas de todos los niveles, pero el resto de indicadores no eran lo suficientemente altos como para sugerir una debilitación directa. Sin embargo, el equipo coincidía en que el estilo de juego que fomentaba no era algo positivo para el juego y merecía cambios, a pesar de los datos.
En el caso de objetos como Presagio de Randuin y Segador de esencia, no tenemos tanta información para documentar nuestras decisiones. A menudo, los objetos se cambian en función de la experiencia y las observaciones de los miembros del equipo. Al fin y al cabo, parte del trabajo del equipo de equilibrio es tomar decisiones basándose en su conocimiento del juego y del estado del metajuego en un momento determinado.
En este caso, decidimos debilitar Segador de esencia porque, tras una serie de mejoras y con la aparición de la configuración que lo combina con Filo infinito y Compás letal, estaba teniendo mejores resultados de lo que nos parecía aceptable.
Decidimos mejorar Presagio de Randuin porque su efectividad no estaba a la altura, teniendo en cuenta que debería brillar en el estado actual del juego al ser una buena respuesta a los objetos de crítico. Además, los tanques no tienen mucho peso en el metajuego actual, así que nos pareció que teníamos margen de maniobra para mejorarlo.
Mejorad a mi campeón un montón, porfi
Una vez que sabemos qué campeones (y objetos) mejorar o debilitar, tenemos que decidir cómo hacerlo.
Nuestra estrategia más frecuente de cara a las debilitaciones es preguntarnos: “¿Qué problema manifiesta este campeón?” o “¿Nos parece que sus puntos débiles no son suficientes?”. Sejuani, por ejemplo, solo se pasaba de la raya en las partidas de la escena profesional, así que queríamos centrarnos en el motivo por el que los profesionales la consideraban una buena elección. Solían comprar Armadura de Warmog bastante pronto, así que redujimos el crecimiento de vida por nivel de Sejuani con la idea de minimizar la efectividad de esa estrategia en la escena profesional sin afectar mucho a la cola en solitario (en general, los cambios a estadísticas básicas no afectan mucho a la escena competitiva, pero sí lo hace debilitar el punto fuerte que hacía destacar al campeón).
En el caso de las mejoras, nos preguntamos: “¿En qué grupo de jugadores está teniendo peores resultados el campeón?”. Por lo general, si mejoramos un campeón es porque tiene resultados por debajo de la media en general, pero suele haber niveles de destreza en los que el rendimiento es peor. Syndra es un buen ejemplo: le va bien en las partidas profesionales, pero tiene carencias aparentes en la cola en solitario. Sabemos que Syndra puede dominar el metajuego, sobre todo en la escena profesional, así que intentamos moderarnos a la hora de mejorarla. Modificamos su crecimiento del maná por nivel para hacerla más viable en las partidas de todos los niveles, especialmente en aquellas en las que es más probable que los jugadores tengan problemas con este recurso.
Cuando decidimos mejorar o debilitar a un campeón, también establecemos cuánto queremos que mejore o empeore su porcentaje de victorias en la cola en solitario (si debilitamos cualquier cosa con la escena profesional en mente, nuestro objetivo es evitar que sobrepase el umbral). Con Syndra, por ejemplo, buscábamos un aumento del 0,5 al 1 %. Este es otro de los motivos por los que decidimos cambiar su estadística de crecimiento del maná, ya que no suele tener mucho impacto en el porcentaje de victorias.
Por otro lado, si queremos incidir de forma más significativa en el porcentaje de victorias de un campeón (> 2 %), sabemos que los aumentos de poder al principio de la partida tienen mucha importancia en la cola en solitario. Así pues, quitarle 3 de DA a un ADC puede ser una debilitación muy significativa. De la misma forma, reducir el daño básico de las habilidades en los primeros niveles suele tener un impacto importante en el porcentaje de victorias de un campeón, mientras que hacer lo mismo en los últimos niveles o con habilidades que se suben de nivel más tarde tiene mucho menos peso.
Y después, ¿qué?
Pues lanzamos la versión… O casi. A continuación, escribimos las notas de la versión, donde recogemos todos los cambios y su contexto, y las enviamos a todas las regiones para que se traduzcan. Preparamos la versión para su lanzamiento, desactivamos los servidores durante un rato, pulsamos el gran botón verde en la oficina… ¡y ahí va la versión!
Y, a esas alturas, ya hemos vuelto a empezar el proceso para la siguiente.