¿Qué causa los errores graciosos en los juegos (como objetos congelados en el aire)?

Incluso el juego más simple es una pieza compleja de software. Pero los juegos AAA a menudo llevan muchos años con grandes equipos para crear. Con tal complejidad, es inevitable que se pierdan algunos errores.

Hay muchas maneras en que pueden ocurrir errores. En su ejemplo, usted menciona “cosas congeladas en el aire”. Si lo viera, supondría que fue culpa de las optimizaciones del motor de física.

Cuando tiene muchos objetos simulados físicamente, pueden ser bastante pesados ​​de procesar, y si ingenuamente prueba todos los objetos para colisiones contra todos los demás en cada cuadro, entonces solo podrá tener un puñado de objetos simples en su mundo.

Entonces, las optimizaciones tienen en cuenta la distribución espacial y las velocidades de los objetos. Cuando las cosas se mueven en realidad, rebotan un poco y se detienen. No se mueven nuevamente a menos que nuevas colisiones u otras fuerzas interactúen con ellos. Entonces, en un sistema de física simulada, una optimización básica es la capacidad de poner objetos a “dormir” cuando su movimiento se vuelve muy pequeño. En este estado de suspensión, sus ecuaciones de movimiento no se actualizan y sus pruebas de colisión pueden ser mucho más simples / rápidas. Solo cuando sean golpeados por otro objeto ‘despertarán’ nuevamente.

Un objeto que flota en el aire suena como un conjunto muy raro de circunstancias que engañaron al algoritmo para poner el objeto a dormir prematuramente. El algoritmo necesitaría ser un poco más robusto, tal vez almacenar un poco más de datos o hacer algunas pruebas más, para asegurarse de que no vuelva a suceder.

Ciertamente, esa no es la única causa posible de ese tipo de error, pero eso es lo que vería al principio. También podría ser una malla de navegación / colisión del terreno fuera de sincronización o desplazada. Tal vez es el volumen delimitador establecido demasiado grande o está descansando en un cuadro delimitador invisible de otro objeto que se eliminó incorrectamente. Tal vez los huesos del objeto están establecidos en posición absoluta en lugar de relativa. Tantas posibilidades

Esos errores tienden a suceder en el nivel de construcción y, a menudo, no son errores de software en el sentido tradicional.

Así por ejemplo:

> un personaje congelado en el aire,

Posibilidades:

  1. El sistema de detección de piso funciona mal debido a la configuración incorrecta de los caracteres. Algunos aspectos / componentes responsables de la caída no están presentes, la animación de otoño no está presente o cosas como esta. Falta el controlador de animación, el movimiento raíz está habilitado en todos los ejes mientras no hay animación, etc.
  2. No es un personaje, sino un objeto de escenario colocado allí por accidente.
  3. ES un personaje, pero por alguna razón tenía algún tipo de bandera en el conjunto que inhabilita temporalmente la interacción con la física (por ejemplo, con fines de escena o algo así).
  4. El personaje es impulsado por un sistema de física (es una muñeca de trapo) que congela objetos inactivos. El personaje no pudo “descongelarse” a tiempo.

Una vez tuve el carácter de “Caminando por el aire” debido al mal funcionamiento del sensor de piso junto con los clips de animación configurados incorrectamente.

> o atravesando paredes \ pisos

Alguien olvidó colocar un colisionador en la pared, y el control de calidad nunca verificó esta área en particular.

Este material no es su error de software normal y gran parte de él no se puede probar automáticamente también.

Entonces esas cosas pasan.

Porque si bien la física es bastante común, los controladores de personajes generalmente están hechos a medida para un juego específico, y su implementación varía.

La mayoría de los errores son atendidos durante el control de calidad. Sin embargo, algunos de ellos son increíblemente difíciles de reproducir, y las causas pueden ser tan oscuras debido a las capas de sistema sobre sistemas.

De hecho, diría que a medida que los juegos se vuelven más complejos y los sistemas se vuelven más extensos, la probabilidad de estos errores aumentará. Los sistemas IK, por ejemplo, que hacen posible una increíble animación realista, siempre tendrán casos extremos donde se rompe por completo. Es difícil detectarlos, y aún más difícil reprobarlos.

En un juego en el que trabajé, por casualidad, encontré un isse donde si te acercabas a uno de los personajes desde cierto ángulo, él comenzaría a girar porque el IK intentaría ajustar la posición de los huesos para que te mirara. ¿Por qué? Debido a que la rotación se estaba calculando con buenos ángulos de Euler, lo que resulta en algunos problemas al superar los 180 grados, en lugar de Quaternion. ¿Por qué estaba usando eso? Me gana Probablemente el programador estaba usando los ángulos de Euler para crear un prototipo y, debido a la falta de tiempo / cambio de prioridades, no pudo cambiarlo por completo al Quaternion más seguro.

Al final, la causa de la mayoría de los errores es la falta de tiempo para optimizar / implementar cosas.

Diferencias importantes entre juegos en 3D y algo como desarrollo web / de aplicaciones:

  • Colisión 3D
  • Física
  • Animaciones que involucran a esos ^
  • Álgebra lineal (matemática vectorial)
  • Precisión mundial (esto se vuelve muy complicado con mundos grandes, ya que los flotadores solo pueden contener tantos datos)
  • IA (concedido, la IA del juego suele ser estática y no implica el tipo de aprendizaje profundo que la IA general hace)
  • Interacción causada por el jugador entre instancias muy variadas de todos esos ^

Para algo como cortar un muro, se trata más de sistemas en conflicto que de nada. Tienes tu muro con colisión definida. Excelente. Tienes tu jugador / IA con colisión definida. Increíble. Pero esa colisión es dinámica. Cambia según las animaciones y el movimiento, más de 30 a 60 veces por segundo. Entonces, si el juego le dice a un personaje que se mueva a (593.849103, -11939.838111, 50.116376), y eso es ~ 20 unidades lejos del muro, pero la colisión del personaje se extiende ~ 10 unidades más allá del muro, tienes sistemas en conflicto. ¿Qué pasa si haces eso con una velocidad extremadamente alta y hay una caída framrate? Esa es la razón por la que, básicamente, en todos los juegos con armas, no disparas una bala física y reaccionas al golpear un objetivo. Simplemente calcule si el objetivo es bueno y muestre un destello del hocico, tal vez una racha, y simule una reacción física en el extremo receptor. Pero no puedes simplemente “fingir” un personaje caminando o una mesa volando hacia una puerta porque realmente necesitas ver esas cosas. Muchas posibilidades

Las posibilidades, específicamente, son el problema.

Entonces, si está creando un reproductor de video, solo hay tantos casos de prueba y estados en cuanto a cómo el usuario podría interactuar con él. Incluso la interfaz de una tienda en línea tiene una cantidad limitada de casos que se pueden predecir bastante bien con minuciosidad y buena depuración. No estoy sugiriendo en absoluto que sean tareas inherentemente simples; solo que es más fácil predecir resultados en comparación. Aunque personalmente diría que manejar millones de compradores simultáneos en línea es mucho más difícil que evitar que un objeto recorte algo que no debería. Pero entonces … ¿qué tal un MMO? Presenta ambos desafíos.

Pero mantengamos esto en un juego para un solo jugador, solo para expresar su problema específico de por qué hay errores:

Pon un jugador en Skyrim y di “vete” … Las posibilidades son enormes. Incluso si pasas un año adicional después de la creación de oro de un juego (versión de lanzamiento) centrado exclusivamente en errores, inevitablemente verás una serie de problemas completamente nuevos que surgen cuando un millón de personas nuevas (incluso miles) joden tu juego en como les plazca.

Se trata de alcance, de verdad. La libertad del jugador para hacer las cosas da como resultado un aumento exponencial de las posibilidades y, por lo tanto, errores imprevistos. Obviamente, es más fácil manejar las interacciones 3D en un corredor infinito que en un juego de plataformas de mundo abierto.

Dicho todo esto, es posible que puedas apreciar el legendario nivel de pulido de los juegos de Nintendo con mecánicas extravagantes e interconectadas. The Legend of Zelda: Breath of the Wild y Super Mario Galaxy 2 te permiten hacer cosas ridículas y de alguna manera casi nunca ves un error físico importante, incluso en el lanzamiento.

Por lo general, tiene que ver con la detección de colisiones como un dolor grave. El mayor problema con la detección de colisiones es que debe equilibrar el rendimiento con precisión. Puede hacer una detección de colisión extremadamente precisa, lo que probablemente eliminaría la mayoría de estos tipos de errores, pero los costos de rendimiento serían locos y no prácticos para el entorno en tiempo real de un videojuego. Como resultado, los algoritmos de detección de colisión son menos precisos para ejecutarse en tiempo real, pero pueden dar lugar a “agujeros” en el entorno donde puede caerse o detectarse una colisión cuando no debería ser así y los caracteres u objetos flotantes . (Esto último generalmente se debe más a que las casillas son más grandes que el modelo gráfico al que están vinculadas). El otro problema que podría tener es si se supone que el objeto o personaje es estacionario y las coordenadas iniciales de generación son malas con las que podría terminar flotando cuando deberían estar en el suelo.

Realmente no hay nada que los cause. Es más bien el desarrollador el que necesita escribir código para que cada evento se maneje correctamente. A su vez, el trabajo de los evaluadores es encontrar todos estos casos en los que el código de los programadores no funciona como debería.

Pero sí, por qué ocurren estos casos, diría que son muchas razones. Uno de los probadores + programadores no tiene tiempo para encontrarlos a todos. A medida que los juegos, etc., se hacen más grandes, también se vuelve mucho más difícil y costoso probar cada lugar, etc. en el juego. Algunos momentos del juego, como grandes partes del efecto massa anfromeda, incluso pueden haber sido incluidos en la secuencia de comandos y nunca haber sido probados una vez porque la compañía intenta admitir múltiples caminos en la historia, etc.

Pero sí, estoy de acuerdo en que algunas veces se vuelve algo embarazoso. Como cuando un personaje está sosteniendo una pistola hacia atrás o cuando una cabeza está siendo torcida 180 grados, etc., o un personaje está subiendo por el techo. En estos casos, los desarrolladores meaby deberían haberlo hecho para que cosas como esas sean imposibles de hacer.

Al igual que este ejemplo, meaby un poco más de pruebas podría haber sido algo bueno. No me malinterpreten, los juegos anteriores en realidad han sido bastante buenos, pero sí, este juego está teniendo tanta mierda en este momento. Entonces, meaby habría sido mejor retrasarlo de 6 meses a un año más o menos.

Los juegos son las simulaciones más complicadas que se ejecutan en los hogares de las personas. Simulan física, elementos y personas que no existen en la realidad. Necesitan calcular y realizar un seguimiento de miles de elementos, en un mundo de elementos virtuales en constante evolución y movimiento.

Ocasionalmente, uno de estos elementos hará algo que no se le dijo al motor que esperara.

Esto puede ser tan simple como algo que se mueve más rápido de lo que se puede calcular en el tiempo dado. O tan complejo como alguien que usa un lanzacohetes para lanzarse al aire 🙂

El motor de física no hace preguntas, solo procesa los números e intenta resolver lo que sucederá aproximadamente sesenta veces por segundo.

Si un jugador lanza una granada y la sincroniza con algo que explota y los NPC (personajes que no son jugadores) también lanzan una granada. Concentrarás demasiada fuerza en un área para que el juego funcione. NO lo calculará correctamente, no puede, sin romper el nivel.

Una explosión en el mundo real, aplastará el concreto y abrirá un agujero en el piso. Los creadores de juegos no pueden dejar que las explosiones rompan el nivel, por lo que le dicen al motor que ignore esa parte.

Cuando un NPC muere, no pueden seguir calculando la física del cadáver, por lo que le dicen al motor que ignore esa parte.

Todos estos pequeños fragmentos de código que dicen ‘ignorar ese bit’ a veces se alinean. Golpeaste la pared entre cheques. Su superposición con la pared, por lo que en lugar de golpear la pared, el código dice ‘ignora ese bit’ y lo atraviesas.

Te bajas de la caja. El motor verifica tu posición, ve que la caja está cerca y piensa que todavía estás en la caja. Mientras flota en el aire, el motor no vuelve a comprobar, se le ha dicho que “ignore esa parte” hasta que se mueva.

Es una lista enorme de verificar esto, no verifique eso. No puede realizar un seguimiento de todo, ya que solo hay tantas comprobaciones que puede hacer en un segundo.

Cuando las personas se congelan en el aire o atraviesan una pared, generalmente no es culpa del motor de física. Lo que sucedió es que la gente ha agregado demasiadas reglas de “ignorar ese bit” y el motor no tiene un modelo de realidad para compararlo.

La gente que vuela está perfectamente bien para un motor de física, no entiende, solo computa. Cuando un personaje muere y cae desde una altura, se le dijo al motor que ‘ignorara esa parte’ para que el personaje quede flotando en el aire.

No es un error. Los creadores del juego agregaron esa regla a propósito. Lo que estás viendo es el motor tratando de hacer frente a los datos que no se les dijo que esperaran 🙂

A veces, el motor de física tiene conflictos, o está tratando de generar algo que no “sabe” cómo generar. Por lo tanto, produce errores y coloca una muñeca de trapo o un gib extraño en el cielo. Esa es básicamente la larga historia corta.

Espero que esto ayude.