¿Olvidates tu contraseña?

Choque de píxeles

2013-05-14
12 comentarios

La mezcla de tecnofília y detallismo obsesivo que acostumbra a rondar al videojuego trae consigo un desbordamiento de siglas, anglicismos y demás palabrotas con las que conformar esa jerga que tanto gusta de usarse cuando se habla sobre los fotogramas por segundo, los enemigos en pantalla o la cantidad de toques de rol que se incluyen en un título concreto. Asuntos que normalmente preocupan al usuario medio lo suficiente como para alabar o hacer ascos a según qué juegos en base a ellos, pero que en realidad, no son más que la consecuencia directa de otros aspectos un tanto más profundos y en los que rara vez se repara. Hablamos, por ejemplo, del manejo de colisiones. Pocas veces veremos que en una discusión entre jugadores habituales salga a la luz este término – de hecho, es más que probable que muchos de ellos ni siquiera sepan el significado del mismo. Sin embargo, el sistema de colisiones del que haga uso un juego es el verdadero responsable de ese golpe que, pese a esquivarse, sigue restando vida; de las ralentizaciones que sufren muchos títulos cuando aparecen demasiados elementos en pantalla, y hasta el aspecto físico de algún que otro personaje se ha visto determinado por cómo se habían gestionado las colisiones en la programación.

La detección de colisiones constituye la base tanto de la interacción entre humano y máquina como del idioma visual que se emplea en el videojuego. Para que el programa pueda reaccionar ante cualquier suceso, primero, debe saber cuándo hacerlo. Huelga decir, por tanto, que es uno de los aspectos fundamentales cuando se aborda un desarrollo. Hasta tal punto es así que, ya a principio de la década de los setenta, la considerada como primera videoconsola comercial de la historia, Magnavox Odyssey, incluía en su circuitería un sencillo sistema con el que distinguir los instantes en el que las figuras dibujadas en pantalla chocaban entre ellas para poder actuar en consecuencia. Una práctica que se extendió también a la segunda generación de consolas con el empleo sistemas más complejos dedicados únicamente a estas funciones; buen ejemplo de ello son los ocho registros de colisiones con los que cuenta la mítica Atari 2600 para gestionar todo el abanico de situaciones que puedan darse.

No obstante, el avance implacable de la tecnología, las exigencias del público y el ansia creativa de algunos programadores no tardó en dejar este enfoque como algo arcaico. Detectar y administrar el impacto o rebote ocasional de un bloque contra otro sobre un fondo de color plano es una cosa, pero hacer lo propio con escenarios compuestos y una buena cantidad de elementos diferentes en pantalla es otra muy diferente. Además, cada juego necesita gestionar las colisiones de una manera completamente diferente según el enfoque del mismo: mientras un título como Pitfall! (id; Activision, 1982) se basta con mantener al personaje sobre suelo firme y comprobar que no entra en contacto con ningún obstáculo, otro como Metroid (id; Nintendo, 1985) necesita conocer detalles al respecto de qué tipo de proyectil está golpeando a qué tipo de objeto e incluso en qué zona lo hace. Por lo que dejar que sea la implementación realizada en el código del programa (y no únicamente un puñado de señales eléctricas) quién se encargará de estas labores, dejaba de ser una opción para convertirse en algo imperativo.

Como en todo planteamiento algorítmico que se haga, el punto de partida debe ser la resolución del problema por uno mismo, ‘a mano’; sin ayuda de la máquina. Así pues, para un humano, la manera más evidente de comprobar si dos figuras han colisionado entre ellas es observar si una intenta invadir el espacio que ocupa la otra, esto es, que se superpongan. Trasladar este método a un proceso mecánico que la CPU de turno pueda realizar es una tarea harto sencilla: tan sólo se debe comprobar en cada fotograma si, la posición ocupada por cualquiera de los píxeles que forman parte de una imagen, coincide con la posición ocupada por cualquiera de los píxeles que forman parte de otra diferente. Una definición de manual tras la que se esconde la obligatoriedad de recorrer uno a uno todos los píxeles que estén incluidos en cualquiera de los figuras en pantalla y comprobar si se ha visto superpuesto. Tarea que, a pesar de que sólo con su definición ya se intuye como titánica, puede llegarse a plantear como una solución viable debido a su sencillez. Nada más lejos de la realidad. Echando mano brevemente a la matemática podemos comprobar que, si tenemos una cantidad n de figuras, compuestas cada una de ellas por un máximo de m píxeles, nos veremos forzados a efectuar n elevado a m cálculos; una cota que en el campo de la complejidad algorítmica se considera de inaceptable. Siendo más claros: aunque nuestra máquina pudiera realizar un millón de cálculos por segundo, comprobar las colisiones entre diez figuras compuestas por diez píxeles, le llevaría algo más de dos horas y cuarto. Para colmo, este cálculo se hace necesario en cada fotograma, por lo que alcanzar los famosos y ansiados sesenta fotogramas por segundo es una meta, todavía, muy lejana.

Llegados a este punto, la necesidad de pulir el método se hace más que evidente. El proceso de optimización es una parte natural en la búsqueda de un algoritmo. Eliminar pasos innecesarios, limitar el alcance del mismo (deteniéndolo una vez llegados a un punto concreto) o, llegados al caso, sacrificar parte de su precisión en pos de una mayor eficiencia, son prácticas habituales en este terreno y cuya aplicación al caso que nos ocupa se hace inmediata. Por ejemplo, si los elementos en pantalla se mueven únicamente de un píxel al siguiente, sin ‘saltos’, podemos reducir nuestra búsqueda de colisiones si, en lugar de explorar el completo de las figuras, lo hacemos únicamente en su contorno; ya que, de producirse un impacto, lo haría forzosamente en ese área. Incluso se podría ir un paso más allá, contabilizando únicamente unos cuantos puntos situados estratégicamente en la imagen, de tal manera que sea imposible golpear zona alguna de esta sin hacerlo también en dichos puntos. El éxito cosechado por esta técnica en juegos para consolas de 8-bits, como la versión para máquinas de Nintendo de McDonaldland (M.C. Kids; Virgin Interactive, 1992), se debía a que brindaba la posibilidad de construir personajes con una cantidad de píxeles relativamente alta sin renunciar a un rendimiento aceptable. Pese a todo, la viabilidad de esta optimización depende de otro recorte importante en la cantidad de comprobaciones a realizar: limitar nuestra atención a lo que impacta contra nuestro personaje y obviar todo lo demás. Este ajuste consigue reducir enormemente la complejidad del algoritmo y lo desplaza hacia unas cotas de tiempo de procesado aceptables, sin embargo, también toma la culpa de una dolencia que se ha repetido de forma incansable en el videojuego: la aparente falta de solidez entre enemigos que se atraviesan unos a otros.

En todo caso, si aumentamos el número de elementos en pantalla, no tardaremos en encontrarnos de nuevo frente a un grave problema de ralentización en el cálculo de colisiones lastrando todo el desarrollo. Por ello, otro acercamiento más usual de cara a esta detección de choques es la de emplear la geometría. La matemática está repleta de métodos para hallar respuesta a todo tipo de cuestiones sobre figuras geométricas, y localizar si una se superpone a otra es una tarea trivial para una máquina; al menos siempre que se traten formas simples, como rectángulos. Tal es la ventaja que supone ‘encerrar’ a cada objeto que se dibuja dentro de un rectángulo – limitando así las comprobaciones necesarias a una por cada imagen – que, con el paso de los años, el uso de estas llamadas ‘cajas de colisiones’ o ‘bounding boxes’ se ha convertido en un estándar de facto a la hora de diseñar videojuegos.

Aún con todo, el uso de este método acarrea una gran imprecisión en ciertas ocasiones. Un caso típico y que deja en evidencia este fallo: imaginemos un juego donde el papel protagonista lo ocupe una nave triangular con las alas de base desplegadas, si encajamos esta figura dentro de un rectángulo y consideramos que todo lo que entre en contacto con éste también lo hace con la nave, obtendremos una alarmante cantidad de falsos positivos por el espacio ‘vacío’ que hemos tomado como zona de impacto. Este es el motivo de que muchos personajes clásicos tengan una forma tan cuadriculada, disminuyendo así las posibilidades de que se produzcan colisiones inapropiadas con el objeto. Claro ejemplo de esto último es el orondo aspecto de Super Mario, del que el propio Shigeru Miyamoto ha señalado como responsable al sistema de colisiones basado en ‘bounding boxes’ que se empleó en Super Mario Bros. (id; Nintendo, 1985).

Encontrar técnicas con las que ajustar la precisión con las que las ‘bounding boxes’ detectan colisiones ha sido una preocupación responsable de no pocos dolores de cabeza entre los programadores. Por supuesto, siempre está la opción de usar otras formas geométricas que se ajusten mejor al elemento en cuestión. Así, para una moneda, es preferible usar una circuferencia, ya que dejará menos espacio libre que cualquier paralelogramo. Otra opción es reducir el tamaño de la zona de impacto de tal manera que, aunque en ciertas áreas del personaje el choque no sea captado por la máquina, la mayor parte de él quede dentro del sector. Pero ninguna de estas opciones suele ser viable cuando el dibujo en cuestión presenta una complejidad excesiva, por lo que en estos casos, se recurre a usar varias cajas de colisiones en conjunto para cubrir toda la superficie con una mayor exactitud. La concepción desde la que se trabaja la idea es similar a la comentada párrafos atrás a la hora de colocar puntos de impacto estratégicos en el personaje, pero con la clara ventaja de poder hacer uso de todas las facilidades que ofrecen las formas geométricas. No obstante, estas metodologías siguen haciendo un sacrificio de precisión que, dependiendo de la ocasión, llega a resultar fundamental para el buen funcionamiento del juego. En estos casos, la solución más común pasa por emplear un algoritmo desarrollado en varias etapas: comprobando primero si alguna de las ‘bounding boxes’ se superpone a otra para que, en caso afirmativo, se haga un estudio exhaustivo píxel a píxel y averiguar así si realmente existe dicha colisión o no. Con ello se consigue tanto ahorrar la parte más dura de la búsqueda (siempre que se pueda prescindir de ella), como eliminar todos los falsos positivos que nos pudieran devolver las cajas de colisiones; aunque no sin antes pagar el correspondiente coste en tiempo de computación. Uno los suficientemente alto como para haber relegado esta técnica a un segundo plano.

Pero al margen de todas estas vicisitudes pseudotécnicas, lo que es indudable es que los creativos se han ganado a pulso su calificativo con el uso que han hecho durante décadas de herramientas y limitaciones por igual. Así, aprovechar la inexactitud que adolecen las ‘bounding boxes’ ha sido un factor clave en el desarrollo de juegos que hacen uso de cierto volumen en sus escenarios, como los empleados en el género beat’em up o en la perspectiva cenital de The Legend of Zelda (id; Nintendo, 1986), consiguiendo dar el efecto de tridimensionalidad deseado gracias a situar una zona de impacto en la parte inferior de los personajes, con la consecuente de que la superior siempre atraviesa todo obstáculo que se le cruce. Con una motivación un tanto diferente, dentro del conjunto de shoot’em up denominados como danmaku o ‘bullet hell’, también es costumbre reducir la caja de colisión hasta el mínimo imprescindible, logrando así que el jugador tenga mayor facilidad para esquivar los miles de proyectiles que se precipitan sobre él, al tiempo que se impregna al título de un ritmo mucho más fluido. A fin de cuentas, el germen del videojuego no es sino emplear con ingenio los mecanismos de los que se disponen, incluso cuando estos no son evidentes a simple vista.

Texto publicado en la Revista Games Tribune Magazine nº50

Inicio Foros Choque de píxeles

  • Imagen de perfil de SaxKazeinSaxKazein
    Participante
    #38386

    La mezcla de tecnofília y detallismo obsesivo que acostumbra a rondar al videojuego trae consigo un desbordamiento de siglas, anglicismos y demás pala
    Lee el artículo completo en http://www.zehngames.com/developers/choque-de-pixeles/

    Imagen de perfil de ViWallsViWalls
    Participante
    #38387

    Que caña, ¿no?

    Siempre me ha interesado saber al respecto de este tema, y te has bordado un articulazo de mil duros. Nunca te acostarás sin saber nada nuevo.

    Imagen de perfil de EnCarmenaEnCarmena
    Participante
    #38388

    Cajas de impacto… tal y como está aquí explicado suena a titánico no, lo siguiente. Pero desgraciadamente es de esas cosas que, si se perciben, es porque salen mal -obviando los bullet hell en los que te enseñan la caja de impacto directamente-. Anda que no me era sangrante ver partidas de shooters en los que disparaba al aire y salía sangre de la nada, cayendo un enemigo a metro y medio de distancia… y con los juegos de lucha ni hablemos.

    Un artículo macanudo, enseña bastante sobre un tema curioso y poco conocido, gran trabajo.

    Imagen de perfil de Adrián SuárezAdrián Suárez
    Participante
    #38389

    Este tema empecé a verlo al comenzar a jugar a Street Fighter IV. Encontré foros con peña señalando las cajas de colisiones en función qué situaciones… una locura. Sabía poco del tema, gracias tito Sax por la clase 😀

    Imagen de perfil de SikusSikus
    Participante
    #38390

    Gran articulo. Todo una lección de historia para los que deseen programar videojuegos. Parece mentira que realmente el sistema de colisión sea algo tan tonto como definir unos puntos.

    El secreto esta en hacerlo bien, una caja de impacto mal diseñada puede arruinar un juego.

    Imagen de perfil de Raul FactoryRaul Factory
    Super administrador
    #38391

    El señor SaxKazein es un caja de impactos en sí mismo, pero llena de sorpresas. 🙂
    El artículo está muy bien redactado, atrae al lector despertando interés sobre un tema muy técnico, pero no por ello se hace farragoso. B-RAVO!!

    Dicho esto, sin ser consciente de ello, creo que he experimentado en más de una ocasión con cajas de colisiones. Nunca os habéis quedado al borde de una plataforma sin caeros cuando gráficamente el avatar está en el aire? Supongo que se aguanta por la caja, no?

    Imagen de perfil de SaxKazeinSaxKazein
    Participante
    #38392

    El tema es interesantísimo y da para mucho más. Lástima que pudiera extenderme más porque hay mucha curiosidad con todo esto.

    Imagen de perfil de SaxKazeinSaxKazein
    Participante
    #38393

    Antetodo, un placer que haya disfrutado el artículo. Efectívamente, es un tema que todos los que llevamos un tiempo en los videojuegos hemos conocido o intuido de una manera u otra pero que, irónicamente, rara vez se nombra. Por cierto, algo similar a lo comentas de disparar al “aire” casi se puede ver en la captura de Megaman, que si afinas el ojo puedes ver como muere más de un enemigo antes de que el dibujo de la bala llegue a “tocarle”.

    Imagen de perfil de SaxKazeinSaxKazein
    Participante
    #38394

    Sobre juegos de lucha es muy sencillo encontrar por la red estudios exhaustivos del funcionamiento de las zonas de colisión para optimizar estrategias. Un trabajo, diría, que más duro que el propio diseño de las mismas…

    Imagen de perfil de SaxKazeinSaxKazein
    Participante
    #38395

    Muchas gracias, Sikus. ¡Y tanto que puede arruinarlo! No son pocos los casos de juegos en los que uno acababa frustrado por no saber calcular que distancia guardar con los enemigos a causa de un sistema de colisiones mal implementado. Al final es como en todo: hasta los detalles más tontos pueden afectar de forma negativa si no se cuidan lo suficiente.

Viendo 10 publicaciones - del 1 al 10 (de un total de 13)

Debes estar registrado para responder a este debate.