¿Cómo se enfrentan realmente los desarrolladores a los bugs de sus juegos?

Todo el mundo sabe qué son los bugs. Los hay divertidos y los hay estúpidos. Los hay molestos y los hay que son realmente dañinos. Pero sea como fuere que se manifiesten, los bugs se sitúan entre el creador del juego y el jugador, como una súbita manifestación de los errores cometidos, como una brecha en la simulación, como un golpe que te devuelve a la realidad.

Desde el lado del jugador la experiencia con los bugs es muy directa. Generan diversión, irritación y en ocasiones auténtica ira, y todos deberían ser corregidos. Pero los jugadores no conocen realmente la experiencia desde el lado del desarrollador, y eso a pesar de que durante los últimos diez años la relación entre jugadores y creadores es cada vez más cercana. En plena era de parches distribuidos a través de internet, de Early Access y de la explosión del desarrollo indie, los jugadores se adentran en el proceso de desarrollo examinando los changelogs y ofreciendo feedback a los desarrolladores.

"Es una extraña bendición, el hecho de que puedas publicar tu juego y que la gente te diga lo que está roto, que puedas hablar con ellos y luego arreglarlo", explica Ricky Haggett, el desarrollador de Hohokum, Frobisher Says y, más recientemente, el curioso roguelike espacial Loot Rascals. "Es maravilloso, y al mismo tiempo increíblemente estresante. Porque también te sientes muy expuesto".

"Puede ser algo muy emocional", añade Cliff Harris, un veterano que ha trabajado en Positech Games, Lionhead y Elixir Studios y creado la saga Democracy, Gratuitous Spaces Battles y el simulador Production Line.

"Existe entre los jugadores la idea equivocada, creo, de que cuando hay un bug al desarrollador no le importa porque ya ha cobrado por el juego. Pero ahora, habiendo devoluciones en Steam, solo tenemos su dinero temporalmente, y pueden recuperarlo fácilmente. Cualquier bug que haya en mi juego, excepto si proviene del middleware para el sonido, es fallo mío, es una cagada mía. Y lo sé, no puedo pretender que no es cosa mía. Puedes notar como te bajan los niveles de serotonina cada vez que ves el reporte de un bug, o la palabra 'cuelgue'. Es algo que realmente te afecta".

Andrew Braybrook (Paradroid) sobre los bugs en Commodore 64

El ensamblador del 6502 era implacable. No había forma de parar y ver el punto exacto en el que se cometía el error, y en aquella época no teníamos ningún tipo de depurador. Imagina que un juego podía funcionar bien durante veinte minutos y de pronto colgarse. Esto es exactamente lo que le pasaba a Paradroid en septiembre de 1983, cuando faltaba menos de un mes para que se enviase a duplicación para su lanzamiento.

Normalmente si hay un bug significa que algo no funciona, pero Paradroid se comportaba aparentemente bien hasta que llegaba el momento del fallo crítico. Sin nada que indicase qué parte del código provocaba el error, pasé tres días leyendo todo el código fuente. Cuando me fui a casa al final del tercer día lo había reducido al sistema de colisiones. Y a las siete de la tarde, cuando estaba cenando, tuve un momento de inspiración. Descubrí qué había hecho mal: había usado un valor de índice incorrecto en la tabla de datos de los robots.

Hay una tabla con los veinticuatro tipos de robots, con valores para el número del robot, su velocidad máxima, la armadura, la energía inicial y las armas. También hay una tabla con los dieciséis robots en la cubierta, manteniendo su posición, energía y velocidad. Si usas el índice de veinticuatro elementos en la tabla de dieciséis elementos, cualquiera de los últimos ocho valores del índice causarán la lectura de datos no válidos y la potencial escritura más allá del final de la tabla. Solo cometí este error al resolver las colisiones, con lo cual puede que no te des cuenta de que un robot mensajero tiene más armadura de la que debería, pero sí cuando un gran robot choca contra otro y el juego se cuelga. Salí al jardín y pegué un buen grito. Había encontrado mi error.

Todos los desarrolladores se enorgullecen profundamente de su trabajo, o por lo menos buscan hacerlo. Es por ello que cuando aparecen los bugs, emergiendo de forma espontánea de la increíble complejidad de los sistemas, los desarrolladores se sienten mal, pese a que saben perfectamente que los bugs son casi inevitables.

Todos los desarrolladores se enorgullecen profundamente de su trabajo, o por lo menos buscan hacerlo. Es por ello que cuando aparecen los bugs, emergiendo de forma espontánea de la increíble complejidad de los sistemas, los desarrolladores se sienten mal, pese a que saben perfectamente que los bugs son casi inevitables. Pero no es hasta después del lanzamiento que los informes sobre auténticos bugs empiezan a producirse.

"A veces recibo emails sobre bugs", explica Harris. "Tengo un foro de soporte en mi página web en la que la gente puede postear bugs, aunque a menudo los postean en el foro de discusión. Recibo mensajes a través de Facebook. Recibo mensajes a través de la página en Facebook del juego. Recibo mensajes en hilos de Reddit, y mensajes en los foros de Steam, tanto en el correcto como en los equivocados. Y cada vez que anuncio algo, hay mensajes en los comentarios. Oh, y en YouTube. Cada vez que hago un vídeo alguien dice que el juego va a colgarse".

Los informes a veces detallan la máquina que tiene el usuario, el momento en el que aparece el bug y qué estaba haciendo. A veces incluyen una partida guardada. "Pero a menudo recibo correos que simplemente dicen 'tu juego está roto, por favor arréglalo'", cuenta Harris. "A veces ni siquiera me dicen qué juego es. ¡Dadme alguna pista! Y también hay tíos muy enfadados, lo cual no ayuda en absoluto".

Rob Dodd (Fireproof) sobre los problemas para replicar los bugs

Hace años trabajé en un FPS en el que los enemigos, al morir, dejaban caer su arma. Las armas se convertían en objetos físicos y caían sobre el suelo. Recibí el reporte de un bug en el que en ocasiones muy extrañas el arma caía y traspasaba el suelo. Era grave, porque había momentos en los que poder avanzar en el juego dependía de coger un tipo de pistola concreto del suelo. Hay muchas razones por las que las cosas pueden caer por debajo del suelo en un juego. Ver cómo ocurría no servía de nada; necesitaba reproducirlo, así que creé un código que generaba un arma cada segundo, cada una con su propia velocidad, giro y altura aleatoria, en diferentes posiciones de un nivel. Mantenía el control de todas, así que tras diez segundos la pistola estaba bajo el suelo, me indicaba los parámetros exactos que generaban el fallo.

Dejé el código funcionando toda la noche y cuando volví la mañana siguiente vi que el juego se había colgado a las pocas horas, pero en las que estuvo funcionando dejó caer varios miles de pistolas, y un par habían traspasado el suelo. Cambié mi entorno de pruebas para generar armas con esos parámetros iniciales, y de pronto tenía una lluvia de pistolas que traspasaban el suelo. Arreglarlo fue sencillo: era un problema con los giros y el sistema de colisiones y bastó una línea de código para evitar que el giro fuese excesivo.

Como desarrollador a veces es difícil recordar que esos furibundos correos son realmente expresiones de pasión por un juego. Pero simplemente contestando a ese jugador enfadado puedes convertir al agresor en alguien mucho más razonable. Harris cree que es una reacción natural en un mundo en el que tratar de comunicarse con organizaciones monolíticas como Google o Microsoft es, a menudo, como gritar al vacío; a veces resulta sorprendente ver que hay alguien humano tras la dirección de email de soporte técnico de un juego.

Como desarrollador a veces es difícil recordar que esos furibundos correos son realmente expresiones de pasión por un juego. Pero simplemente contestando a ese jugador enfadado puedes convertir al agresor en alguien mucho más razonable.

"Trato de contestarles al momento, sin importar la hora, diciendo que lo siento y pidiendo más información", añade Haggett. "La gente generalmente es fantástica; tenemos suerte de no tratar con tipos que realmente sean gilipollas. Y una vez pasas la parte de las disculpas y de la ayuda, es una interacción humana muy positiva, gente que se pone en contacto con el desarrollador para hablar con él. Me encanta tener conversaciones con la gente que juega a mis juegos".

Luego el desarrollador tiene que archivar el problema. Mientras Harris, que trabaja en solitario, lo archiva en su calendario con una fecha en bruto para arreglarlo, los grandes estudios usan herramientas de administración de tickets como Zendesk, coordinando el trabajo de los community managers, los equipos de QA y los programadores, que son quienes al final realmente solventan los problemas. Estos sistemas profesionales han avanzado muchísimo respecto a cómo funcionaban en la década de los noventa.

"Algo que encuentro increíble es pensar en lo primitivo que solía ser el proceso de reporte y solución de bugs", recuerda Dorian Hart, un programador y diseñador que trabajó en Looking Glass e Irrational. "Cuando trabajábamos en Underworld II y System Shock, no había un software dedicado para el reporte de bugs. Los testers y desarrolladores solían mandar un correo al líder del equipo de QA, quien recopilaba una gran lista. Luego, una vez al día, teníamos una reunión de equipo en la que el líder de QA leía en voz alta todos los bugs. El responsable de cada uno levantaba la mano y aceptaba solucionarlo. Si era un bug que ya tenía alguien antes, tenía que gritar '¡duplicado!', lo cual a menudo generaba una discusión sobre si los dos bugs realmente tenían el mismo origen. Discusiones parecidas empezaban cuando alguien aseguraba '¡no es un bug!' o si no nos poníamos de acuerdo en quien era la persona adecuada para arreglarlo".

Joris Dormans sobre los jefes finales perdidos en Unexplored

Cuando sacamos Unexplored de Early Access para publicar la versión final cometimos un estúpido error en uno de los últimos parches antes del lanzamiento. Básicamente hicimos que el número de jefes finales a generar fuese cero. Tardamos una semana más o menos en darnos cuenta de que habíamos sacado el juego sin ningún jefe final excepto el último, cuando un usuario que había jugado ya en el periodo Early Access nos indicó el problema. Lo arreglamos y de pronto teníamos un parche que añadía cincuenta jefes al juego, como primera actualización. Los jugadores se lo tomaron bastante bien. Es una suerte que seamos un equipo indie publicando en una plataforma online con actualizaciones ilimitadas: eso te permite salir vivo de situaciones así.

Pero independientemente de cómo se administren los reportes, el trabajo de verdad es encontrar la causa. "Depurar es como trabajar de detective: tienes que buscar pistas, hacer las preguntas adecuadas y examinar la escena del crimen", explica Andrew Braybrook, desarrollador del clásico de Commodore 64 Paradroid. "Es algo que no puedes obviar, es algo que debe hacerse. En el Commodore 64, además, debía hacerse antes del lanzamiento". Por aquel entonces el código era más bien pequeño, y como los programadores solían trabajar en solitario todo el código era suyo y sabían bien cómo funcionaba. "Eso te da una ventaja considerable, porque no está leyendo el código de otro buscando el error cometido por otro. La mayoría de bugs los podía encontrar y solucionar en minutos".

Los desarrolladores necesitan información detallada sobre las condiciones en las que estaba funcionando el juego cuando el jugador encuentra un bug; si un desarrollador puede reproducir ese bug, puede ver qué hacía el ordenador en el momento del fallo y a partir de ahí descubrir la causa.

"Por lo general todo depende de si puedo reproducir el bug", dice Harris, quien programa sus propios motores y, por lo tanto, puede ver y trabajar todos los aspectos de sus juegos. "Normalmente si veo un cuelgue, bang, lo arreglo". Es por ello que los desarrolladores necesitan información detallada sobre las condiciones en las que estaba funcionando el juego cuando el jugador encuentra un bug: si un desarrollador puede reproducir ese bug, puede ver qué hacía el ordenador en el momento del fallo y a partir de ahí descubrir la causa. A menudo el trabajo *real* es descubrir las extrañas combinaciones de eventos y variables que provocan el bug.

Pero también están otros tipos de bugs mucho más frustrantes. Harris los llama 'Heisenbugs', los cuales desaparecen o cambian en pleno proceso de depuración para examinarlos, haciendo que sean difíciles de identificar. Charles Randall, quien ha trabajado en muchos estudios, incluyendo BioWare Edmonton, Ubisoft Montreal y Capybara Games, habla de los 'meta-bugs', los cuales no surgen del código sino del compilador, el cual convierte el código en las instrucciones que ejecuta el ordenador.

"Culpar al compilador es el '¡no es lupus!' del desarrollo de videojuegos", explica. "Pero cuando *lo es*, vas a sufrir. En MDK 2 el tipo que trabajaba en el código del sonido tenía un problema con un sonido en concreto que el juego rechazaba reproducir. Al depurar descubrió que el código no estaba realmente ejecutando la función PlaySound(). Tras investigar mucho deducimos que el problema estaba en la nomenclatura y renombramos la función a algo parecido a PleaseLordSatanPlaySound(), y eso solventó el problema. Hasta donde sé, el juego se publicó así".

Charles Randall sobre un bug sin arreglar de Assassin's Creed 2

Había un problema recurrente en Assassin's Creed 2 que no podía solucionar, con animaciones de combate que no aparecían en el momento apropiado. Nunca pude descubrir cual era exactamente la combinación de circunstancias que activaban el bug. Es algo que me persiguió durante casi un año pero pude detectar el caso en el código y... simplemente hacer que funcionase. No de la manera correcta, eso sí. Cuando detectaba el error, simplemente reproducía otra animación. Asumo que era un problema extraño en el juego en el que veías una animación que no se sincronizaba, pero nadie se ha quejado nunca, así que supongo que al final resultó ser un arreglo válido. A veces hacer desaparecer un bug es casi tan bueno como realmente arreglarlo.

Publicar las actualizaciones es a día de hoy sencillo incluso en consola, con un proceso que está casi automatizado. Un error común es pensar que el proceso de certificación que imponen los fabricantes en todos los juegos para su consola gira alrededor de la búsqueda de bugs, pero simplemente es para garantizar que cumplen con la normativa de la plataforma.

Y, a veces, el reporte no es ni siquiera de un bug. "Estoy seguro de que los jugadores se piensan que es una excusa, pero muchas veces cuando la gente dice que un juego no funciona simplemente deben actualizar los drivers de su tarjeta gráfica", cuenta Harris. "Suena a excusa barata, como si estuvieses simplemente ganando tiempo, pero con los cuelgues el ochenta por ciento de las veces simplemente hay que actualizar drivers". En las versiones para Steam y PlayStation 4 Haggett se ha encontrado con jugadores que sufrían un cuelgue nada más cargar el juego, sin razón aparente. La causa nunca se descubrió, pero reinstalar el juego lo solucionaba por completo. "Pensamos 'wow, reinstalar. Eso todavía sigue siendo algo'".

Una vez arreglado, publicar las actualizaciones es a día de hoy sencillo incluso en consola, con un proceso que está casi automatizado. Un error común es pensar que el proceso de certificación que imponen los fabricantes de consolas en todos los juegos para su plataforma gira alrededor de la búsqueda de bugs. Para nada: simplemente es para garantizar que cumplen con la normativa de la plataforma. Loot Rascals, por ejemplo, se certificó con una versión que tenía varios bugs que colgaban el juego. Publicar un parche en PlayStation 4, por ejemplo, es gratis y normalmente suele tardar solo un par de días.

Y a veces, solo a veces, un bug simplemente no se puede arreglar. Esto es más raro de lo que puedas pensar -recuerda lo que hablábamos del orgullo de los desarrolladores con su obra- y por lo tanto cuando ocurre suele deberse a una decisión desde el punto de vista de negocio. "Si la próxima actualización de Windows provoca que Redshirt dejase de funcionar, no lo arreglaría", explica Harris. "Dejaría de venderlo. No vale la pena. Los programadores se avergüenzan de los bugs, los odiamos más que nadie porque sabemos que son un fallo nuestro. No quieres dejarlos ahí, a no ser que sea por una decisión comercial sensible. Siempre quieres que tu juego sea perfecto, así que no es decisión del programador".

Teddy Dief sobre la diferencia entre bugs y exploits en Hyper Light Drifter

Recuerdo enseñar Hyper Light Drifter en una convención en 2013. Fue como un sueño, poder mostrar nuestro juego y ver como la gente lo disfrutaba. Además, no había dormido la noche antes para poder tener la build lista. Cuando se acababa la jornada, un chaval con ínfulas se presenta en nuestro stand y nos dice que "voy a romper vuestro sistema de colisión", y empieza a lanzarse contra las paredes una y otra vez. Le dijimos que no podría. Él insistió en que sí. Discutimos durante diez minutos. Discutí con un chaval. Pero no encontró ningún bug. Dos años más tarde, mi compañero Beau Blyth y yo vimos juntos el evento Awesome Games Done Quick. Vimos como los speedrunners usaban glitches en Ocarina of Time para pasar a través de las paredes y saltarse niveles enteros. Y por primera vez me pregunté: y si alguien rompiese *realmente* nuestra colisión... ¿no molaría?

Seis meses después publicamos Hyper Light Drifter y pasaron solo dos días hasta que un speedrunner descubrió la forma de traspasar nuestras paredes impenetrables. Usó un glitch que no habíamos probado nunca, quedándose atrapado de forma intencional dentro de un cristal para forzarlo dentro de la pared y a partir de ahí moverse libremente. Pensamos arreglar eso. Alx Preston editó algunos de los diseños de nuestros niveles para mantener los cristales fuera de las paredes importantes al principio. Pero al final decidimos no arreglarlo del todo. Bueno, más bien no estábamos totalmente seguros de cómo hacerlo sin un retoque completo. Así que en vez de bloquear a los jugadores del exploit decidimos dejar que lo usasen... pero matarlos a los pocos segundos. Era lo suficientemente rápido como para evitar que los speedrunners hiciesen algo *demasiado* loco, pero los suficientemente lento para que un jugador despistado tuviese tiempo de darse cuenta de que estaba en un lugar en el que no debería estar. A veces simplemente matas al jugador y esperas que te perdone. Así que por favor perdonadme.

Ilustraciones por Anni Sayers. Traducción por Josep Maria Sempere.