Este será el primer artículo que realice como ─aún novato─ desarrollador de videojuegos, en mi caso concreto ocupando un puesto de QA (beta tester). Seguramente siga aprendiendo toneladas de cosas ya desde dentro de la industria, pero en estos meses he absorbido y puesto en práctica conocimientos como una esponja y me ha hecho darme cuenta del no poco complejo mundo actual del videojuego, estés desarrollando algo pequeño o más grande. Vamos a examinar hoy una realidad poco consciente e interesantísima, todo en base a esa experiencia que me estoy forjando (recordad que voy a hablar en primera persona de los siguientes fenómenos). Espero que este artículo algo más técnico os pueda resolver dudas fundamentales que todos nos hemos hecho.
1.- Un desarrollo no se cierra coincidiendo con el día de publicación
Una realidad que como consumidores ya habréis apreciado. El día que se decide lanzar a la bestia ─tu juego─ al mercado, no se está pensando ni muchísimo menos en respirar aliviados. El proceso de corrección se pone en marcha y comienza una fase de pulido y soporte que puede prolongarse casi tanto como la fase del desarrollo. Yo, como mucha otra gente, me he hecho siempre la pregunta esencial: "¿y por qué diablos no se prueba todo bien antes de lanzarlo?". Los motivos son variopintos, pero es facilísimo caer en una dinámica ad infinitum de corrección, testeo, programación y vuelta a empezar. Cuando se detecta un fallo y se corrige se toca el código, de modo que el QA debe volver a probar todo si se quiere asegurar de que no se ha comprometido lo ya funcional. Es absurdamente sencillo cargarse algo sin querer al corregir otra cosa distinta, el llamado efecto mariposa existe en esto de los videojuegos.
Esto supone más horas o días de trabajo, lo que retrasa los lanzamientos por tener que mover el día elegido. Durante esas verificaciones que el QA realiza, podría volver a detectar algo, lo que reinicia el ciclo. Por supuesto, el producto saldría más pulido, pero el empresario, productor o persona que pone la pasta empieza a perder dinero. Hay una especie de "antagonismo" entre la figura de un programador y el de QA o tester ─siempre que se separen y no recaigan en la misma persona, que es lo idóneo─, ya que es un tira y afloja laboral bastante curioso, donde lo que uno hace el otro lo deshace ─o lo intenta─, una dinámica bastante peculiar y romantizada pero que desde dentro puede resultar tedioso para todas las partes... Lo que inevitablemente lleva a querer lanzar el producto aún teniendo ciertos bugs localizados. Por ello los bugs se separan en función de su gravedad.
No es que un juego no se pruebe bien antes de lanzarlo (doy fe la de horas, recursos e imaginación que hay que ponerle a esta tarea), es simplemente que a sabiendas de que algunas cosas pueden mejorar, la bestia debe lanzarse cuanto antes (con una calidad mínima exigible, claro está) para que todos los compañeros puedan cobrar su trabajo y así seguir corrigiendo lo que ya se sabe en siguientes parches. ¿Os suena el parche de día 1? Se lanza tan rápido precisamente porque ya se tienen los bugs localizados. Cuando alguien se siente un pequeño Indiana Jones descubriendo bugs, el equipo de desarrollo seguramente ya los tenga documentados y más que señalados, pero es el tiempo el culpable de no haberlos podido corregir (por entrar en ese bucle malvado que comenté más arriba). En un buen producto, sin el parche de día 1 el juego debería poder ser jugable de principio a fin, o ahí ha fallado algún eslabón de la cadena. Esos parches deben servir para pulir lo máximo posible el producto en todo caso, no para hacerlo funcional. Y ahora entramos en qué pasa después o durante esa dinámica.
2.- Se puede medir lo que la gente hace e influir en el resultado
Entonces, ¿qué pinta el online en juegos sin multijugador o con las mínimas funciones online? Vamos a ir respondiendo. Los diseñadores del videojuego son personas que deben pensar de forma omnisciente; eslabones de la cadena que barajan múltiples escenarios, que imaginan dónde un jugador o jugadora va a encontrar dificultades, o qué interacciones cree que va a hacer, e incluso, estima mediante estadística y probabilidad cuál va a ser el éxito, las ventas o simplemente otros parámetros medibles. Esta persona o personas tienen a su disposición una batería amplísima de herramientas en esta época para medir lo que hace una persona en tu videojuego, desde programas que detectan dónde mueres en la aventura hasta si has sido capaz de desbloquear un contenido. Estas herramientas pueden ser más sofisticadas (de pago, como Amplitude, con cuotas para la empresa), hasta herramientas gratuitas con límites ─plataformas como Steam o Google tienen sus servicios para estos menesteres─. Los desarrolladores pueden verlo casi todo, y esto abre un escenario muy curioso y útil. De hecho, aunque juegues offline, todas esas estadísticas invisibles a tus ojos se guardan y son enviadas cuando vuelves a conectarte.
Cuando metéis o descargáis un videojuego en vuestras consolas u ordenador, lo más seguro es que tenga asociada alguna función online, posea o no modos multijugador. Un guardado en la nube, unos términos y condiciones que se deben aceptar... lo que sea que implique una conectividad. No todo lo denominado como online sirve para que estés implícitamente haciendo algo en línea. Simplificando muchísimo el asunto; mientras estás jugando conectado envías datos a un servidor, el cual traduce eso a unas analíticas en tiempo real que el equipo de desarrollo lee. Es decir, se puede saber lo que un jugador hace. Esto es vital, ya que el diseñador o diseñadores han podido confiar en una manera de hacer las cosas, en crear una curva de dificultad que ni el propio equipo ha podido calibrar correctamente ─ya que, en algún momento, el QA y los programadores, e incluso los mismos diseñadores, se han viciado tanto que ya conocen cada rincón, suponiendo que va a ser sencillo para el resto─, una "falta indirecta de empatía" esta que es inevitable en la mayoría de casos, ya que es fácil memorizar tu propia creación si te pasas 8 horas diarias o más trabajando en ella.
Los datos que se recaban son utilísimos y determinantes, llegando a influir en el desarrollo. Si mucha gente llega al jefe 2 (imaginemos que un 60%), pero sólo el 10% o menos consigue llegar al jefe 3, algo falla, algo le pasa a tu curva de dificultad. Supone que de 1000 jugadores, sólo 100 han llegado hasta ese punto, lo que demuestra que quizá te has excedido... o simplemente no has tenido en cuenta que tu público target no es el que pensabas, o que abandonan antes por mil motivos, tedio o aburrimiento incluidos. Pueden darse millones de escenarios, y evidentemente los diseñadores de videojuegos no son el Doctor Strange por mucho que quieran. Las analíticas o métricas son pequeñas líneas de código o variables que envían un parámetro a un servidor cuando el jugador hace algo: cruza por una puerta, mata un jefe, toca un menú o compra algo por ejemplo. Esas estadísticas se agrupan de diversas formas y son leídas e interpretadas luego por el equipo (siendo más trabajo asociado al diseñador, que es el cerebro). Os sorprendería demasiado la de cosas que damos por sentadas los que llevamos años jugando. Nos creemos muchas veces que todos tienen nuestro nivel de compromiso jugando y no, nada más lejos de la realidad. Ese 10% que nos llegamos al jefe 3 no podemos pensar por el otro 90% restante. Mi trabajo actualmente es empatizar con ese 90% más incluso si cabe. Yo tengo que ser capaz de superar todo un videojuego, pero también ser capaz de imaginarme no haciéndolo. Un trabajo mentalmente difícil este, os lo aseguro. También es sorprendente cómo se afronta un videojuego en distintos países del mundo. Da para libros y libros (los cuales ya existen).
Todo esto desemboca en lo siguiente: Las estadísticas pueden cambiar totalmente un videojuego. El equipo, habiendo confiado en el éxito, puede haberse equivocado, o todo lo contrario; puede haber descubierto que una feature o característica de su videojuego es mucho más divertida que otra. Esto debió ocurrir con Spore de PC cuando se lanzó al mercado: recuerdo muchísima más gente en internet divirtiéndose con el editor de criaturas que con el propio videojuego. Es muy duro concebir una idea siguiendo una dirección y que la gente haga lo contrario, pero también es un proceso mágico y bonito examinar a qué le da valor la comunidad de jugadores. En este punto, ignorar las estadísticas en función de tu ego puede ser irresponsable, y es una lucha interna entre lo que tú quieres que hagan o cómo quieres que jueguen y cómo terminan jugando finalmente. Si mucha gente baila como los personajes de Fortnite, significa que hay potencial en eso y tienes que hacer algo con ello. Hay que escuchar, corregir y estar dispuesto a potenciar una parte de tu juego que podría no necesitarlo según tu criterio ─e incluso sacrificar de raiz algo que no funciona, hasta modos enteros─. Las manías y hábitos de los jugadores pueden darte claves de éxito si sabes verlas, si estás en su onda. Al igual que el algodón, las estadísticas de juego no engañan. Son transparentes, y aunque indirectas (el jugador ni se cosca), nos están ayudando a diario a dejar de cagarla o a mejorar. Se debe buscar el beneficio, pero también ser éticos y reconocer cuándo algo puede mejorar.
3.- El control de calidad se ramifica y entran en juego nuevas figuras
Una vez entendido que todo es cuantificable (o casi todo), medible y estudiable, entra en juego la figura del usuario como tester indirecto. Esto suscita problemas éticos de los que es irresponsable escapar o ignorar. Evidentemente la gente que compra los primeros días te está haciendo un trabajo, incluso si no emiten feedback. Es tu responsabilidad devolverles lo más corregido posible eso que están jugando, de modo que también ha tenido que ser un compromiso de todo el equipo el hecho de haber lanzado eso en unas condiciones mínimas. Por desgracia, debido a los altos costes de mantener a una plantilla y un desarrollo en el tiempo, esas condiciones mínimas de lanzamiento van a ir acompañadas de bugs y alguna que otra traba. Como ya he comentado, las estadísticas van a ayudar en pocos días a tomar un nuevo rumbo o seguir mejorando lo ya hecho.
Ya no sólo existe el feedback directo (en foros o redes sociales), ahora es posible darse cuenta de errores simplemente sabiendo lo que la gente hace. Un campo de cultivo este que puede parecer injusto desde fuera (y es que lo es, para qué engañarnos), pero que es inevitable. Inevitable debido al dineral que cuesta mantener un juego a flote en su fase de desarrollo hasta el día de su lanzamiento y después. Es jodido saber que todo es perder dinero hasta que comienzas a recuperarlo ─si es que pasa─. Es un ejercicio tan difícil y con tantas lecturas que yo aún no tengo la cabeza hecha a ello, por eso sigo pensando la mayoría del tiempo como un usuario más, porque es donde yo me siento más a gusto.
Yo, como QA, tengo que anticiparme e ir tres jugadas por delante del usuario; mi trabajo es esencial, puesto que puedo detectar las cagadas antes que nadie y hacer presión para que se solucionen antes de que a nadie más le pase. Pero yo no soy una barrera infranqueable, se me puede argumentar y se me argumenta por qué ignorar la corrección de un error que yo considero indispensable solucionar antes de la salida... y me tengo que callar, duela o no. Y lo tengo que entender. En un desarrollo idílico y utópico, todos los bugs que encuentro son corregidos antes de la salida, nadie pierde dinero y encima no se producen retrasos, pero como no estamos en ese escenario, dependo muchas veces de que la gente me ayude indirectamente. Es jodido, porque ellos no cobran y yo si, pero también saben a lo que se atienen al desembolsar dinero por un videojuego hoy día.
Afortunadamente mi terreno laboral actual es el Free to Play, por lo que respiro tranquilo en la cuestión de los que llegan los primeros a probar uno de los juegos en los que participo; no lo estaría tanto si estuviésemos haciendo aventuras completas o desarrollos AAA complejos donde desembolsas el dinero de una vez. En definitiva, el usuario hoy día forma parte activa de la calibración de un videojuego, y hay que agradecérselo corrigiendo todo, dándole contenido y estar agradecido con ellos por su paciencia y disposición. Un terreno pantanoso moralmente hablando, pero que nos toca vivir.
4- Ese error ya lo sabía, ¡lamento que te lo hayas tenido que comer!
Esto es cachondo en cierto grado, pero como dije hace algunos párrafos, el jugador encuentra cosas que seguramente algún miembro del equipo, todos o yo ya sabían. Es mi trabajo pensar en muchísimas direcciones simultáneamente, y resignarme cuando toque. Encontrar un error puede ser fácil, solucionarlo ya no tanto. De hecho, puedes encontrar errores a tal nivel de profundidad que requerirían deshacer una estructura sólida de código, pudiendo comprometer el juego entero... y qué diablos, a veces hasta no se pueden arreglar por cómo ha sido programado algo.
Hay también otro asunto gracioso, y es que un bug o error puede hacer más atractivo un juego. Se me ha llegado a argumentar por qué dejar ciertos errores y no corregirlos. Resulta que algunos aumentan la retención de los jugadores (el tiempo que se quedan y que les hace volver al juego), e incluso la fama. Algunos videojuegos y sagas famosas hoy día partieron de errores que se dejaron o se les sacó partido. Grand Theft Auto renació de su cuasi cancelación precisamente por un error que volvió el juego divertidísimo. No es un caso común ni mucho menos, pero en estos escasos meses de experiencia ya me he encontrado con errores de esos que "no se tocan", por cariño del equipo o por cariño de los jugadores hacia ellos. ¡Hay gente que se queja y se cabrea si corriges algunos bugs míticos!
Aún con todo, hay otros errores nada graciosos que lastran la experiencia, que afean el producto o simplemente que no deberían estar presentes, y es una pena que aún teniendo la mayoría más que cazados y documentados, por presiones, deadlines o cuestiones técnicas no se puedan arreglar a tiempo. Todo esto evidentemente sin contar con aquellos errores que ningún miembro del equipo pueda haber detectado, y errores todavía más extraños si ya tienen que ver con hardware o software. Por ello es importante leer las estadísticas ─si se tienen─. Por ejemplo, si un 0% de personas tienen un logro o un 0% de personas no han hecho algo, significa que tu juego falla por ahí.
El mundo del control de calidad y QA es maravilloso, algo que me suscita pasión infinita y del que espero seguir aprendiendo. Estar en el centro de la balanza (cerca de los usuarios y cerca del equipo de desarrollo), me hace feliz, dichoso y querer esforzarme diez veces más. Espero que os haya gustado este texto, habrá más en el futuro cuando sepa un poco más. ¡Un abrazo!
fran_friki
No hay comentarios:
Publicar un comentario