¿Olvidates tu contraseña?

Bugs y glitches

2013-04-18
1 comentario

Los videojuegos son productos culturales caros, y como compradores de éstos, exigimos que los juegos estén lo más pulidos posible. Como jugadores, es lógico y normal querer encontrarnos un producto sin fallos, de la misma manera que un espectador espera ver una película y no notar los trucos en los efectos especiales o malas actuaciones de los actores.
Sin embargo, desde el punto de vista de un desarrollador, los archiconocidos y odiados bugs y glitches no son simplemente descuidos u holgazanería traducidos en errores en el producto final. En este sentido, el objetivo es siempre presentar el juego con el mínimo de errores posibles, pero la propia naturaleza de los bugs y los glitches hace que al intentar corregir ciertos errores se produzcan todavía más errores, como dragones marcándose un “Moonwalk”.

Para comprender por qué ocurre esto, primero hay que comprender la naturaleza de los videojuegos. A diferencia de los productos culturales más tradicionales (cine, música, teatro…) los videojuegos son productos interactivos que no presentan un entorno lineal. Dicho de otro modo, son productos en los que el jugador puede (y debe) mezclarse para que tengan éxito. Traducido a lenguaje Dev, esto significa que el desarrollador no tiene el control de su juego. El desarrollador tiene el control de los límites del juego (dicho de otra manera, el desarrollador controla hasta que punto puede interactuar el jugador con el juego, pero no controla el proceso de esta interacción) pero no tiene el control sobre las acciones del jugador. Esto crea un conflicto diplomático interficial grave provocando todo tipos de problemas fruto de situaciones no previstas por el desarrollador. Dicho de otra manera, los desarrolladores esperamos que el jugador se comporte de ciertas formas, aunque intentamos plantearnos todos los escenarios posibles, por muy estúpidos o ilógicos que parezcan.

Un pasillo con una luz al final. El jugador empieza en la otra punta del pasillo. El objetivo es asustar al jugador teletransportando a un fantasma delante del jugador cuando este va por la mitad del pasillo ¿Cómo actúa el jugador? Es un misterio, pero las previsión meteorológica indica que el jugador caminará hacia al final del pasillo dirigiéndose a la luz. Entonces, se pondrá “botón” invisible en mitad del pasillo, y cuando el jugador lo toque aparecerá el fantasma delante del jugador. Este tipo de situaciones (tocar un botón invisible y activar algo) son muy cotidianas en todos los videojuegos, parodojicamente, en esta sencilla situación surgen toneladas de bugs.

Por un lado, puede ser que el jugador avance, pero caminando hacia atrás. O que el jugador esté mirando hacia una pared cuando ocurre el evento de la aparición del fantasma. El inocente desarrollador, para solucionar esto, hace que el fantasma no aparezca delante del jugador, sino que aparezca delante del campo de visión del jugador, independientemente de hacia adonde esté mirando. Bien. ¿Bug solucionado? No.

¿Qué ocurre si el jugador está muy pegado a una pared? Pues que el fantasma aparecerá atravesando la pared y quedará poco realista. En este caso, hay dos opciones. Por una parte, en vez de un pasillo se rediseña el nivel para que sea un puente y el fantasma pueda spawnearse volando a ambos lados del pasillo. Por otro lado, se puede deshacer todo lo hecho e indicar al juego que no spawnee el fantasma si el jugador no está mirando hacia adelante. Lo que sería algo negativo, porque sería quitar contenido a los jugadores exploradores, que son los que quieren adorar cada detalle del juego (es decir, los jugadores que miran hacia la pared).

Si en algo tan sencillo como cruzar un pasillo y teletransportar algo ya ocurren tantas situaciones negativas que pueden dar lugar a bugs, es obvio que en productos más complejos como juegos de mundo abierto (adiós pasillo) la cantidad de bugs y glitches derivados de la complejidad de las situaciones a las que se enfrenta el jugador sea mucho más elevada.
Por eso muchos juegos optan por la solución quintaesencia, siempre que se puede: disfrazar a los bugs de features. Es decir, transformar los errores en valor jugable adicional. En mi experiencia, desarrollando Coma: a mind adventure surgió una situación de este tipo muy encomiable. En el juego, hay unas bolas (afectadas por la física) que sólo existen de noche, y cuando el jugador desactiva la noche, se desvanecen. Obviamente, cuando el jugador vuelve a activar la noche, las bolas vuelven a aparecer. Desde el punto de vista del jugador, este espera encontrarse cuando vuelva a activar la noche la esfera justo donde se ha desvanecido. ¿Qué ocurre si la esfera se desvanece en una pendiente? Tras una argumentación interna conmigo mismo, decidí que cuando la esfera empieza a desvanecerse, pierde todas sus propiedades físicas. Es decir, se queda estática, y en ese instante, empieza a desvanecerse. Entonces, cuando se volvía a activar la noche, la esfera volvía a tener propiedades físicas, aunque empezando quieta (no conserva la velocidad con la que se ha desvanecido).

Desde el punto de vista estético, esto no quedaba del todo bien, pues la esfera perdía toda su inercia de sopetón y podía percibirse como un bug, pero las nuevas propiedades de la esfera al desvanecerse (pérdida de velocidad y aceleración) hicieron que pudiera generar nuevos puzles. En estos puzles, el jugador debe desvanecer esferas para que estas pierdan su inercia y volver a activarlas para que se inicien sin inercia alguna, evitando caer donde no deben. Escrito suena muy complicado de entender, pero es algo muy explícito dentro del juego por la propia naturaleza del bug: es impactante ver como una esfera con inercia se detiene instantáneamente. Y así es como se convierten los bugs en features.

No es una locura encontrar 10.000 bugs en un juego o incluso muchos más mientras se desarrolla el juego, y es inevitable que unos cientos de estos se cuelen en el producto final. Y no tiene nada que ver con equipos de desarrollo con prisas, productos poco pulidos o a medio hacer, una programación poco estable o desarrolladores holgazanes. Es cierto que muchos bugs surgen por lo dicho anteriormente, pero en la gran mayoría de casos, los bugs surgen con la misma facilidad con la que cae una hoja de un árbol en un bosque. Sí, hay bugs y glitches que son injustificables y una vergüenza que hayan logrado hacerse paso silenciosamente en el producto final, pero hay leyendas que son falsas; no, los juegos antiguos no tenían menos bugs. Los juegos antiguos tenían una cantidad de bugs acorde con su nivel de interacción. Havok tiene la culpa de todo. No es que sea un mal motor de físicas, es que programar con físicas hace ciertos procesos en los videojuegos ciertamente inestables. Por eso desde que se empezaron a estandarizar los modelos de interacción físicos en los videojuegos, la cantidad de bugs ha aumentado. Siendo así, invertir más tiempo en nuevas herramientas de desarrollo se torna imprescindible para la nextgen.

Inicio Foros Bugs y glitches

  • Imagen de perfil de Carlos CoronadoCarlos Coronado
    Super administrador
    #38530

    Los videojuegos son productos culturales caros, y como compradores de éstos, exigimos que los juegos estén lo más pulidos posible. Como jugadores, es
    Lee el artículo completo en http://www.zehngames.com/developers/bugs-y-glitches/

    Imagen de perfil de GredXIIGredXII
    Participante
    #38531

    Me ha gustado mucho este artículo y en especial el pensamiento que me ha venido a la mente tras leerlo de que cuanta más libertad tienen los jugadores más difícil es para los programadores predecir todas las acciones que un jugador puede hacer. Hay bugs y bugs, unos son comprensibles otros son criticables.

    Pongamos pro ejemplo un juego de fútbol “triple A”, si cuando un jugador celebra un gol (escena programada) y este jugador queda hundido en el suelo o atraviesa cuerpos físicos que no debería poder cruzar es un fallo difícil de perdonar; que en el mismo juego un jugador que haga 50 regates seguidos mientras corre hacia atrás esquivando entradas duras de los rivales y al hacer el regate 51 el terreno de juego se vuelve gris, pues sigue siendo un fallo, pero hay que alterar más variables para que esto suceda.

    Creo que iré a reflexionar un rato sobre lo aquí leído.

Viendo 2 publicaciones - del 1 al 2 (de un total de 2)

Debes estar registrado para responder a este debate.