¿Las pruebas de software son diferentes cuando tratamos con el desarrollo de juegos?

Estaba leyendo este documento sobre las diferencias entre el desarrollo de software en general y el desarrollo de juegos y los autores hicieron algunos buenos comentarios con respecto a las pruebas de software, señalando, por ejemplo, que

... los desarrolladores de juegos dudan en utilizar las pruebas automatizadas debido a la rápida obsolescencia de estas pruebas ante los cambiantes deseos creativos de los diseñadores de juegos.

Entonces, esta lectura me hizo pensar, ¿qué otros aspectos en las pruebas de software deberíamos considerar diferentes o particulares cuando tratamos / probamos un juego? ¿Alguien tiene experiencia con esto o alguien ha escuchado algo más al respecto?

Los juegos modernos son en realidad una tonelada de contenido de arte creativo desarrollado utilizando un motor de juego propio o propio. El motor en sí es comprobable por la unidad en su mayor parte (renderizado, geometría, física, módulos AI, etc.). Del mismo modo, también se pueden adjuntar pruebas simples a partes individuales del contenido desarrollado. Esto significa que las pruebas unitarias y de caja blanca son realmente factibles y exitosas.

En lo que respecta al "producto en su conjunto", un juego es una simulación. Puede tener más complejidad generativa que un simple programa de negocios. Piense en mundos interminables, únicos y generados por procedimientos versus un planificador de recursos empresariales con comportamientos contables y bien planificados. En pocas palabras, la cantidad de formas únicas posibles de hacer algo en el contexto de los juegos puede ser matemáticamente muy, muy grande. De hecho, se considera un punto de venta para juegos.

Agregue a eso el hecho de que la salida final es puramente audiovisual y no hay un estándar determinista de corrección absoluta de dicha salida. Los chips de GPU realmente no necesitan realizar cálculos precisos, solo muchos cálculos, incluso si algunos no son precisos.

Y finalmente, el objetivo principal es el entretenimiento . Los jugadores están de acuerdo con los problemas técnicos si ejecuta más de 60 FPS, se ve increíble y tiene un sinfín de horas de contenido entretenido.

Esto simplemente coloca las ideas tradicionales de pruebas automatizadas de caja negra en la región "no tan tangible y valiosa" cuando se aplica a los juegos.

Sin embargo, ha habido intentos recientes de entrenar a las NN para que jueguen , lo que es efectivamente una forma de prueba de mono de autoaprendizaje exploratoria.

Han pasado muchos años desde que hice gamedev, pero además de la buena respuesta, hay algunas cosas que quiero agregar y detallar.

Lo primero que ya se mencionó es que la salida es solo visual y auditiva frente a estrictas restricciones "críticas de FPS" y presupuestos computacionales / de memoria. Las ideas de corrección se vuelven borrosas cuando las preguntas son más como: "¿Se ve bien? ¿Funciona sin problemas y sin tartamudeos? ¿Suena genial?" mientras que los desarrolladores están ajustando y ajustando y aproximándose, mientras que las colaboraciones de diseñadores / desarrolladores hacen que las cosas se vean y suenen ligeramente diferentes con cada iteración rápida.

¡Otra es que los probadores pueden ser increíbles! Nunca he encontrado un grupo de evaluadores más dedicado en ningún otro dominio, ya que quierenpara probar el software Se están divirtiendo Son adictos y duermen al lado de la computadora mientras exploran todos los rincones de tu juego. Se vuelve bastante fácil descubrir incluso las fallas más oscuras cuando la gente se entretiene probando a fondo cada rincón del software mientras está prácticamente adicto a él. En mi industria actual, los probadores son un poco más difíciles de trabajar ya que muchos de ellos son profesionales que vinculan sus medios de vida al software, por lo que confían en un puñado de características para realizar su trabajo y no están necesariamente interesados ​​en agotar cada rincón y grieta todo el tiempo. Naturalmente, cuando no podemos confiar tanto en los probadores humanos, necesitamos más pruebas automatizadas.

Otra es que la base de código para un juego generalmente no se mantiene, modifica y amplía durante años y años. No es que los desarrolladores de Super Mario que lo desarrollaron originalmente en el ensamblaje 6502 hayan tenido que mantener algo parecido a ese código original mucho después del lanzamiento del juego. Doom 3 probablemente usa cero líneas de código (o cierre) de Doom 1. Si hay una franquicia continua, los juegos más nuevos se parecen más a "secuelas" que a "actualizaciones". La mayoría de los juegos se envían y tal vez lanzan algunos parches, DLC, y luego el código está listo. Es un gran contraste con mi industria de efectos visuales, donde trabajé para mantener el código que data de los días de Amiga, que había sido portado y mantenido durante décadas. Los juegos normalmente no '

Una de las razones de esta naturaleza de corta duración de las bases de códigos de juegos es que están tan vinculadas al hardware. Cuando se combinan con su naturaleza de vanguardia y los requisitos críticos de FPS, a menudo no se pueden desarrollar de una manera que abstraiga los detalles del hardware, ni siquiera los cierre. A menudo se escriben de manera muy específica para la generación de hardware objetivo, y generalmente no pasa mucho tiempo antes de que la PS3 se reemplace por una PS4 que luego se vuelve obsoleta y se reemplaza por una PS5, y así sucesivamente, y todo muy rápidamente. Las capacidades de hardware juegan un papel tan fundamental en el diseño y desarrollo del juego que generalmente no vale la pena tratar de mantener una gran cantidad del mismo código escrito para PSX que para PS4, por ejemplo, la mayoría de las franquicias de juegos que duran por generaciones todavía escriben sus motores de próxima generación. en gran parte desde cero para el hardware más nuevo.

Con una base de código de corta duración viene un tiempo de mantenimiento limitado (es decir, un tiempo limitado en el que el código debe modificarse). Con un tiempo limitado para cambiar el código que no abarca años con el alcance del motor cada vez más grande con cada actualización, y combinado con el hecho de que los juegos no son ni mucho menos críticos para la misión, no existe necesidad crítica de aplicar la unidad más exhaustiva y pruebas de integración Hacer esto garantiza la integridad de los cambios futuros si no se van a realizar cambios futuros, y el aspecto de prueba de unidad y refactorización de las bases de código heredadas es naturalmente irrelevante si no hay un "legado" en primer lugar.

Otro pequeño que no siempre es relevante es que un juego solo puede apuntar a un rango muy estrecho de hardware sin ningún puerto de escritorio. En esos casos, se elimina una gran fuente de fallas impredecibles en estos contextos, que son los usuarios que ejecutan el software con hardware y controladores radicalmente diferentes.

Dicho esto, las pruebas de integración en el nivel más alto / más grueso tienden a ser más útiles de inmediato. Por ejemplo, muchos juegos podrían utilizar una forma de registrar cómo el estado del juego está cambiando con el tiempo para las "repeticiones". Dichas funciones de repetición pueden garantizar que el juego sea determinista y que también se utilice como una herramienta de prueba por sí sola para reproducir una sesión de juego registrada previamente por otra persona.

También me he encontrado con gamedevs que trabajan en pequeños estudios que hicieron cosas como escribir bots para su juego y los hicieron jugar a su velocidad máxima y ejecutaron esa simulación, originalmente encontraron un oscuro accidente después de un día o dos, luego lo arreglaron, luego ejecutó la simulación nuevamente, y repitió hasta que no hubo más bloqueos espectaculares incluso después de ejecutarlo durante semanas. Por lo tanto, hay tipos interesantes de enfoques pragmáticos como el que he visto en gamedevs para probar su software, pero a menudo en formas que se asemejan al nivel más grueso de pruebas de integración y simulan cosas muy cercanas a cómo los jugadores realmente interactúan con el juego.

Finalmente, estos grandes motores de juegos AAA están comenzando a parecerse a un tipo de bestia completamente diferente: más longevos, abstrayendo con éxito el hardware un poco mejor, con bases de código más grandes y períodos de mantenimiento más largos mientras sus editores de nivel comienzan a parecerse a entornos de desarrollo completos. Me imagino que esos grandes motores probablemente requerirían un procedimiento de prueba más exhaustivo, especialmente si el tiempo que se mantiene su código se expande considerablemente. Todavía muchos estudios de juegos no escriben grandes motores de juegos AAA: los licencian o desarrollan un pequeño motor patentado que es considerablemente más pequeño y no se mantendrá durante años.