Ghostcrawler: El índice de cambio

Greg «Ghostcrawler» Street, diseñador jefe de sistemas de World of Warcraft, recientemente nos hablaba sobre algunos cambios futuros como la mitigación activa y el futuro del caballero de la Muerte Sangre, hoy intenta explicar una pequeña parte de la filosofía de Blizzard en lo que respecta al cambio, cuánto es demasiado, y cuándo se considera que un cambio es necesario.

Cita de: Ghostcrawler (Fuente)

¿Cómo deciden los desarrolladores qué hay que cambiar y cuándo?

Mis dos últimas entradas del blog explicaban varios cambios futuros. Esta no va a ser una de esas entradas. Si lo que más os interesa son las noticias sobre World of Warcraft, y no tanto el proceso de diseño que hay detrás del juego, os podéis saltar esta entrada sin problema.

Gran parte del diseño del juego consiste en encontrar un equilibrio, y con esto no solo me refiero a asegurarnos de que todas las clases diferentes y otros aspectos del juego sean lo bastante justos, sino también a lo fácil que es irse a uno u otro extremo. También hay que encontrar un equilibrio respecto a la cantidad de cambios que se hacen. En un extremo estaría no cambiar nada, con lo que parece que el juego se queda obsoleto, y es comprensible que los jugadores se frustren al comprobar que nadie resuelve esos errores o problemas del juego que surgieron hace ya tiempo. En el otro extremo estaría el exceso de cambio, que puede provocar lo que solemos llamar «efecto montaña rusa», porque el diseño del juego parece inestable y los jugadores, en especial los que juegan de forma más esporádica, no pueden mantener el ritmo. Hoy me gustaría explicar una pequeña parte de nuestra filosofía en lo que respecta al cambio, cuánto es demasiado, y cuándo consideramos que un cambio es necesario.

Primero, algunos conceptos técnicos básicos

World of Warcraft es un juego cliente-servidor. Los servidores (que son nuestros equipos) gestionan importantes elementos reguladores, como los cálculos de combate y el sistema de botines. Hay un par de motivos para esto. En primer lugar, hace mucho más fácil compartir información entre grupos. Cuando un pícaro apuñala a vuestro sacerdote, es importante que tanto vuestro ordenador como el del pícaro estén de acuerdo en cuándo o dónde ha sucedido el golpe y cuánto daño ha infligido (y qué procs se han activado como resultado, etc.). En segundo lugar, el servidor es mucho más fiable de lo que puede ser un ordenador personal o público.

Con el tiempo, a medida que nuestro equipo de programadores ha ganado experiencia y se ha hecho con más ingenieros experimentados, hemos podido hacer actualizaciones de mayor envergadura, y en ocasiones más atrevidas, en los servidores sin tener que actualizar también vuestro cliente. La actualización del cliente (el juego en vuestro ordenador) requiere un parche. Puede ser un parche grande, como el 4.2, que introdujo la zona de misiones del Frente de Magma y las bandas de las Tierras de Fuego, o puede ser uno pequeño, como el 4.2.2, que corrigió algunos errores. Los parches cliente son un tanto complicados. Se tarda mucho en crearlos y probarlos, y conllevan cierto riesgo, dado que si estropeamos algo, tenemos que lanzar otro parche cliente para arreglarlo. Ahora nos resulta mucho más fácil modificar el código del juego en el servidor. También conlleva cierto riesgo, pero nos resulta mucho más fácil arreglar cualquier error. A estos cambios en el servidor los llamamos correcciones en vivo, porque a menudo podemos aplicarlos incluso mientras jugáis. Si introdujéramos una corrección en vivo para el daño de Golpe mortal, de pronto, en medio de una pelea, este podría pasar a infligir más o menos daño. A veces, si todavía no hemos anunciado la corrección en vivo (o en el caso poco común de que optemos por no anunciarla en absoluto) los jugadores llamáis a este tipo de cambios «beneficios o desmejoras silenciosas». Por lo general no podemos modificar cosas como imágenes, sonido y texto con una corrección en vivo (al menos por el momento), así que, por ejemplo, no añadiremos un nuevo jefe ni cambiaremos la apariencia de un arma sin un parche cliente (aunque sí que podríamos usar las correcciones en vivo para activar un jefe que se hubiera añadido con anterioridad con un parche cliente).

Os comento todo esto para explicar que una de las razones por las que veis tantas correcciones en vivo hoy en día es que disponemos de la capacidad técnica para hacerlas. Eso no quiere decir que el juego contenga más errores, más decisiones torpes de diseño o más problemas de equilibrio entre clases que antes. Solo significa que ahora podemos arreglar esos problemas en el momento, cuando en el pasado habríamos (y habríais) tenido que esperar meses hasta el gran día del lanzamiento del siguiente parche. En general, no nos parece justo para los jugadores hacerles esperar a todos por cosas que nos resulta fácil corregir. Que a los jugadores les guste o no el cambio depende en gran medida de la naturaleza del mismo. Si corregimos la facultad de una clase que presentaba un error, a menudo los jugadores que juegan con esa clase agradecen el cambio… excepto si la corrección disminuía el daño recibido, o si para beneficiarse de la facultad recién reparada tienen que cambiar gemas o encantamientos.

Un gran poder implica…

Este es el reto que se plantea aquí. Si vuestro cazador casi alcanza el máximo en los contadores podríais preguntar: ¿a qué viene tanta prisa? Y muchos jugadores lo hacen. Pero debéis tener en cuenta que a otros jugadores les molesta que el líder de su banda deje en el banquillo a un brujo para incorporar a un tercer cazador (porque su daño es formidable) o podría frustrarles su alta probabilidad de perder contra vuestro cazador en JcJ. El grado de «necesidad» de un cambio depende de la perspectiva de cada uno.

Tratamos de reunir gran cantidad de información voluntaria de los jugadores, por ejemplo, cuando cancelan sus suscripciones, acerca de los motivos que los han llevado a sentirse así. A medida que pasa el tiempo, vemos que ha disminuido la preocupación respecto al equilibrio entre clases y ha aumentado la preocupación por los frecuentes cambios en el juego. Sin duda existe el riesgo de que cambiemos demasiado las cosas y al hacerlo espantemos a los jugadores. El efecto montaña rusa de un exceso de cambios puede cansar a la comunidad, aunque cada cambio específico tenga un objetivo noble. Tenemos que sopesar nuestro objetivo de proporcionar correcciones cuando nos parezcan estar justificadas y la fatiga que pueden sentir los jugadores por tener que aprender una y otra vez las mecánicas del juego. Mantenemos discusiones de forma constante acerca de si es necesario o no aplicar cierto cambio de inmediato, o si se trata de un problema con el que podemos convivir durante un largo periodo de tiempo.

No hay ninguna regla establecida o rápida que nos ayude a resolver estos conflictos, por lo que me ha parecido más fácil daros varios ejemplos sobre el tipo de cosas que estaríamos tentados o no de cambiar en una corrección en vivo, en un parche o en una expansión.

Primer ejemplo: La paridad entre especializaciones

Después de observar gran cantidad de análisis sobre bandas, llegamos a la conclusión de que el daño del mago Arcano supera al del mago Fuego de forma rutinaria. (Ahora mismo estoy dejando de lado muchos de los elementos relacionados con esta discusión, para así intentar centrar el ámbito de la decisión en algo que se pueda explicar de forma sencilla). Por ejemplo, si Fuego es mejor que Arcano en las peleas con área de efecto, este es un factor a tener en cuenta. Si es más difícil jugar con la especialización Fuego, o si esta es más aleatoria de forma inherente, ese también es otro factor a tener en cuenta. Aun dejando de lado todos los aspectos confusos, esta no deja de ser una tarea de gran complicación. Lo ideal sería que los jugadores a los que les gusta Fuego pudieran jugar con esta especialización sin sentir que son un obstáculo para sus amigos.

La medida en que Fuego puede estar por detrás de Arcano sin por ello dejar de ser «viable» depende de muchos factores. Algunos jugadores consideran aceptable una diferencia entre el daño infligido por ambas especializaciones por debajo del 10%. Otros cambiarán de especialización por una ganancia teórica (esto es, que ni siquiera se ha demostrado de forma empírica) de un 1%. Si viésemos la posibilidad de realizar algunos ajustes numéricos a Fuego con la confianza de que lo situarían a la altura de Arcano, consideraríamos que les debemos esta modificación a los jugadores.

Pero esta decisión conlleva ciertos riesgos. Si los beneficios aplicados sobre Fuego pudieran hacer a esta especialización más peligrosa en JcJ, tendríamos que tener mucho cuidado con el cambio. Si el hecho de que más magos pasaran a Fuego implicara que algún beneficio o utilidad de bandas proporcionado por los magos Arcano se volviera más difícil de conseguir, tendríamos que tener cuidado con el cambio. Pero el peor desenlace, en nuestra opinión, sería exceder nuestro objetivo. Si esto sucediera, los jugadores interesados por Arcano se sentirían obligados a cambiar a Fuego, con la consiguiente necesidad potencial de cambiar gemas y encantamientos o reforjar, y podrían enfadarse por haber dejado pasar cierto objeto que cayó la semana anterior. Esto coloca a los jugadores en una posición incómoda.

Cuando los jugadores mencionan que se sienten como en una montaña rusa de mecánica del juego suelen referirse a esto. La semana pasada Arcano era la especialización más interesante con la que jugar. Y puede que, antes de eso, lo fuera Escarcha. La semana que viene, quién sabe cuál será. En el pasado hemos metido la pata hasta el fondo en este sentido, en ocasiones en las que pensábamos estar mejorando la paridad entre, por ejemplo, las especializaciones del cazador, el guerrero o el caballero de la Muerte, pero en realidad llevamos a los jugadores a sentir que debían cambiar de especialización. Si contamos con tiempo suficiente, podemos conseguir resultados bastante buenos en los ajustes de equilibrio, pero las correcciones en vivo, y a menudo incluso los cambios de los parches, no siempre proporcionan suficiente experiencia empírica.

Recordad, no se trata de ver cuánto daño infligen el mago Fuego y el mago Arcano sobre una diana. Lo que les importa a los jugadores (y a nosotros) es ver cómo se las arreglan en encuentros específicos, para lo que hay que tener en cuenta la experiencia de una amplia selección de jugadores con diferentes grados de habilidad, diferentes formaciones de bandas y cambios continuos en el equipamiento, los demás jugadores en JcJ, etc. A menudo tomamos riesgos mayores cuando existen diferencias importantes en el estilo de juego. Es más difícil pedir a un chamán Mejora que cambie a Elemental que pedir a un brujo Demonología que cambie a Destrucción. Es posible que a los jugadores a los que les gusta mucho Demonología no les parezca justo, pero hemos de tener en cuenta los riesgos que representan hasta los cambios más pequeños y en principio seguros para el juego y la comunidad de jugadores al completo.

Segundo ejemplo: El uso creativo de las mecánicas de juego

Hay mucha gente inteligente trabajando en World of Warcraft, pero no tenemos forma alguna de competir en términos intelectuales ni creativos con los esfuerzos combinados de millones de jugadores. A pesar de nuestros esfuerzos, los jugadores cuentan con un aterrador ingenio capaz de idear soluciones creativas que a nosotros nunca se nos habían ocurrido. Aquí nos encontramos con una gran variedad de ejemplos: un jugador encuentra un abalorio, un arma basada en el proc o un bonus de conjunto muy antiguo y que tiene muy buenos resultados en el contenido nuevo. Una banda urde una estrategia que hace que un jefe sea mucho más fácil de vencer de lo que esperábamos. Un equipo de arena encuentra un modo de gestionar su control de masas o su daño por ráfaga que es casi imposible de contrarrestar.

Gran parte de la diversión de World of Warcraft se basa en la resolución de problemas. Por lo general, nuestra filosofía no pasa por castigar a los jugadores por ser creativos. Siempre que podemos, intentamos dar a los grupos el beneficio de la duda. Si un jefe acaba siendo más fácil de lo esperado porque los jugadores se agrupan cuando contábamos con que se desperdigaran, o consiguen aplicar un control de masas sobre los agregados con mayor potencia de la que creíamos que tendrían, simplemente felicitamos a los jugadores de forma silenciosa por su ingenio. Si un jefe acaba siendo más fácil de lo que esperábamos, puede que actuemos al respecto. (Aunque, en general, en las correcciones en vivo y en los parches añadimos muchas más desmejoras que beneficios a los encuentros).

Es más probable que actuemos en situaciones que obligan a los jugadores a comportarse de forma extraña, en especial si es algo con lo que no van a disfrutar. Si para completar una banda consideran que deben ir a buscar un abalorio específico de entre contenido muy antiguo, o dejar en el banquillo a seis jugadores para que entre una especialización específica que tiene una facultad que simplifica la pelea, entonces es probable que tengamos que actuar. Este tipo de cambios son muy subjetivos e implican una gran discusión interna. Recordad que nuestra prueba de fuego suele ser: «¿Se lo están pasando bien los jugadores?», y no «¿Están haciendo algo con lo que no contábamos?».

Tercer ejemplo: La dificultad de un encuentro

En lo que respecta a los encuentros, las decisiones casi siempre se reducen a si hacer o no una corrección en vivo. Si esperamos al parche 4.3 para hacer cambios importantes en encuentros del 4.2, cuando la atención de los jugadores ya se haya trasladado a 4.3, es probable que ese no sea un tiempo de desarrollo bien invertido. Cuando lanzamos nuevas mazmorras o bandas, nuestra filosofía inicial consiste tan solo en dejar todos los clavos a la misma altura, lo que implica sacar un poco los que se han quedado cortos y dar un golpecito con el martillo a todos aquellos que sobresalen demasiado. Pasada una semana, más o menos, es raro el caso en el que mejoramos un encuentro para que sea más difícil. Tendemos a agrupar varias de estas modificaciones, con frecuencia al empezar una nueva semana, de modo que parezca una especie de mini-parche en lugar de un flujo constante de desmejoras de los jefes.

Para las bandas, observamos los gráficos que indican el número de jugadores nuevos que han superado un encuentro concreto cada semana. La pendiente suele ser pronunciada al principio, cuando las bandas más experimentadas se enfrentan al contenido, y después se suaviza, a medida que otros jugadores van avanzando. Cuando la línea se vuelve horizontal y ningún jugador nuevo supera el contenido llega el momento para nosotros de entrar en acción. Es un poco más fácil para las mazmorras de 5 jugadores, porque queremos que los jugadores ganen la mayoría de las veces. Nadie quiere volver semana tras semana al Trono de las Mareas hasta conseguir vencer por fin a Lady Naz’jar.

Las estadísticas en las que más nos fijamos son el número de intentos que necesitáis para vencer al jefe de una mazmorra, la cantidad de bajas que causa el jefe, y el tiempo que tardáis en completar la mazmorra. En el lanzamiento de Cataclysm había jefes como Ozruk, del Núcleo Pétreo, que destacaban por su fuerza. A veces podemos gestionar estos cambios con unos simples ajustes (como, por ejemplo, reduciendo el daño del jefe) y otras veces es necesario modificar la mecánica del encuentro tanto como podemos mediante las correcciones en vivo, que en realidad nos dan un buen margen de maniobra, ya que casi toda la información acerca de la criatura está en el servidor.

Cuarto ejemplo: Los cambios de la rotación de las clases

Aquí nos encontramos con un par de subcategorías: los cambios voluntarios y los involuntarios. Con frecuencia hacemos correcciones para que resulte más divertido jugar con cierta clase. Permitir a los guerreros Armas reiniciar Desgarrar sin tener que volver a aplicar de forma constante el perjuicio fue un cambio que les mejoró la calidad de vida, dado que hacía la rotación un poco menos insoportable. También acabó suponiendo una leve mejora de DPS. Forzó a los jugadores Armas a aprender la ligera modificación que había sufrido su rotación, pero fue una mejora global, y no hubo muchos jugadores que protestaran.

Quinto ejemplo: Las especializaciones demasiado potentes

Este podría parecer un caso bastante fácil de resolver, pero es uno de los más polémicos, porque la comunidad nunca estará de acuerdo en si alguien tiene demasiado poder, o si su exceso de poder llega a tal nivel que es necesario que los desarrolladores actúen. Que nos apliquen desmejoras es un asco. Y punto.

Por lo general, los jugadores preferirían que beneficiáramos a todas las demás especializaciones a que desmejoráramos la suya; incluso si el resultado fuera el mismo. Entra dentro de la naturaleza humana querer que las desmejoras a aplicar sobre las demás especializaciones sean inmediatas, pero cuando es vuestro personaje el que está en tela de juicio, os preguntáis: ¿para qué tanta prisa? Una vez más, no depende de si los desarrolladores somos unos bastardos sin corazón (que lo somos), sino de si los jugadores se divierten o no. Os divierte ser un ejército de un solo hombre. No os divierte que un ejército de un solo hombre os arrolle. Os divierte alcanzar el máximo en los contadores. No os divierte sentir que no tenéis esperanza alguna de competir con el tipo que alcanza el máximo en los contadores.

Además, tened en cuenta que cuando hacemos cambios en las clases mediante de correcciones en vivo, tratamos de encontrar la corrección más sencilla posible que resuelva el problema, para minimizar el riesgo de romper alguna otra cosa, y la cantidad de pruebas necesarias antes de poder aplicar el cambio. Esta es la razón principal por la que es más probable que usemos la corrección en vivo para desmejorar una clase que para beneficiar a todas las demás, porque requiere menos cambios. (Recordad que si beneficiáramos el DPS de todos para equipararlo al del demasiado poderoso, es probable que tuviéramos que beneficiar también a las criaturas, para evitar que cierto contenido perdiera todo vuestro interés. Esto complicaría aún más el cambio).

También quiero dejar claro que hoy por hoy casi nunca aplicamos desmejoras silenciosas a las clases, al menos no de forma intencionada. Los jugadores se vuelven muy paranoicos al pensar que su daño puede cambiar de pronto. Como mucho, podría pasar que nuestros programadores aplicaran un cambio antes de que el equipo de comunidad pudiera informar al respecto en la última entrada de correcciones en vivo del blog, pero por lo general, una situación de este tipo no debería durar más que unas horas.

Sexto ejemplo: La explotación

No es fácil diferenciar entre cuando los jugadores saben que están haciendo algo que no deberían, y cuando no están seguros de si los desarrolladores podrían considerar que su acción se pasa de la raya. Como he dicho antes, por lo general damos a los jugadores el beneficio de la duda. Si descubren algo ingenioso que pueden hacer y no les da una ventaja injusta ni hace que otros jugadores se sientan en inferioridad de condiciones, por lo general no hacemos nada al respecto, por lo menos no a corto plazo.

Por desgracia, hay un montón de chicos malos ahí fuera que intentan romper el juego para obtener un beneficio personal, o para satisfacer su mera naturaleza maliciosa. Consideramos que es nuestro deber para con los demás jugadores acabar con estos abusos cuando suceden. Comprensiblemente, tampoco queremos publicitar estos cambios en exceso. Si alguien ha descubierto el modo de acabar con un jefe en solitario para hacerse con gran cantidad de ganancias en oro, no queremos darles ideas a miles de jugadores explicando la fisura que encontramos en el juego y cómo la hemos arreglado. Tampoco son cambios sobre los que podamos meditar durante mucho tiempo. Tenemos que sacarlos enseguida.

La razón de que os comente esto es que a veces a algunos jugadores les sorprende que saquemos un parche desarrollado para prevenir o disuadir a los jugadores de usar un comportamiento explotador. Una reacción común es la de preguntar: «¿De verdad alguien estaba haciendo eso?». Recordad que por su propia naturaleza, estos tipos de cambios son silenciosos, y deben seguir siéndolo.

Séptimo ejemplo: Las expansiones

Por lo general reservamos un montón de cambios de diseño para las expansiones. Sabemos a algunos jugadores hasta esto les parece demasiado, porque no quieren tener que volver a aprenderse la rotación de su personaje, y mucho menos el funcionamiento de los glifos o la nueva filosofía de la dificultad en JcE. Sin embargo, consideramos que si queremos que los jugadores sigan jugando, tenemos que resolver en algún momento los problemas descubiertos en el diseño del juego. En este caso, nos parece interesante añadir una cantidad razonable de cambios por el mero hecho de cambiar.

Algunos jugadores dicen: «Hace años que mi personaje no ha tenido ningún cambio importante», y quieren algo, lo que sea, que les permita mirar a su personaje con ojos nuevos. Por supuesto, no pretendemos arreglar cosas que no estén rotas, pero sí intentamos asegurarnos de que cada nueva expansión tenga un aire nuevo. Las expansiones nos dan la oportunidad de reforzar la base de jugadores y el propio juego. Por lo tanto, no deberíais asumir que cada vez que hay cambios en una clase, esto se debe a que tenía graves defectos y navegaba a la deriva sobre el mar de ignorancia y apatía de los diseñadores. Es probable que nunca lleguemos a un punto en el que una clase concreta alcance la perfección y no sea necesario ni un solo retoque más. El cambio, con moderación, es sano.

Son aspectos como este los que me llevan a decir que el diseño de juegos es un arte, y no una ciencia. Si os dieran la oportunidad, no hay duda en que varios de vosotros tomaríais decisiones de diseño diferentes a las nuestras, y en algunos casos, no tengo duda alguna de que vuestra decisión sería incluso mejor. Nos encantaría ver que hay discusión sobre este tema. ¿Cuánto cambio es bueno? ¿Cuándo podemos dejar que un problema repose varios meses y cuándo requiere atención inmediata? ¿Qué nivel de riesgo deberíamos asumir al aplicar cambios pequeños que mejoran la calidad de vida? ¿Vamos por buen camino? ¿Estamos locos? ¿Creéis que esto no es más que propaganda adicional lanzada desde el trono de las mentiras de Ghostcrawler?

Greg «Ghostcrawler» Street es el diseñador jefe de sistemas de World of Warcraft. Siente un rechazo antinatural por el juego de hombros del elfo de la noche.


Sé el primero en comentar

Deja tu comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.