Pruebas automatizadas de juegos [cerrado]

¿Existen métodos de prueba automatizada de juegos?

Se aprecian experiencias específicas, con información relevante sobre el proyecto, como la plataforma y el tipo de juego, si eso ayuda con la aclaración.

Juego independiente para una persona. Era un juego de tanques multijugador con terreno destructible, y el terreno destructible y el código de colisión resultaron algo inestables.

Terminé manipulando algunas IA básicas tontas (por "tonto", quiero decir "absolutamente idiota", elegirían al azar "conducir hacia un tanque enemigo", "alejarse de un tanque enemigo" y "conducir en una dirección aleatoria" ", mientras dispara al azar el arma principal) y juega el juego a la velocidad de fotogramas máxima mientras graba pulsaciones de teclas. Tengo alrededor de 10-15x en tiempo real. El código se afirmó mucho, por lo que si algo salía mal, volcaría todo el registro de pulsación de teclas en el disco junto con un informe de error y la inicialización aleatoria inicial. Luego podría ir y reproducir el registro de pulsación de tecla para duplicar exactamente el estado, o simplemente depurar el informe de error.

Lo dejé funcionando constantemente durante literalmente meses. Al principio, rara vez pasaba una hora sin estrellarse: tuve que sentarme allí y cuidarlo durante una semana, matando a varios errores oscuros por día. Eventualmente llegó al punto en que estuvo funcionando durante una semana entre fallas, lo que se traduce en aproximadamente 1500 horas de jugador por choque.

Fue invaluable y lo recomiendo de todo corazón.

Para un MMO en el que trabajé (desarrolladores 100ish, centrados en PC), intentamos agregar una gran variedad de pruebas automatizadas con diferentes éxitos. Esto es lo que funcionó:

• Las pruebas básicas durante nuestro proceso de construcción automatizado fueron una gran victoria. Esto incluía tareas como crear un personaje, transferir mapas, ejecutar algunas pruebas de interfaz de usuario programables y buscar el comportamiento esperado. Esto detectó una gran cantidad de errores antes de que llegaran al resto de la empresa.
• En el lado de la infraestructura del servidor, desarrollamos un montón de diferentes pruebas automatizadas que simularon transacciones típicas de servidores MMO. Luego podríamos reproducirlos en una variedad de circunstancias para comparar el rendimiento o garantizar la seguridad. Con el tiempo, estas pruebas se hicieron cada vez más precisas hasta que se convirtió en una reproducción de datos grabados en vivo
• Escribimos un "jugador falso" que deambulaba aleatoriamente por el mundo, saltaba, mataba cosas y decía cosas al azar en el chat. Esto encontró una gran cantidad de problemas de física e infraestructura.

Lo que no funcionó:

• Intentamos agregar algunas pruebas automatizadas muy específicas orientadas al combate al constructor automatizado, pero esto básicamente nunca funcionó. Funcionaría durante aproximadamente 3 días después de su implementación, hasta que un diseñador o artista cambiara algo y la prueba fallara, desactivando las alarmas fallidas de compilación. El 90% de las veces no fue un problema real. Estas pruebas fueron demasiado frágiles, y en realidad probar juegos específicos en un mapa específico con poderes específicos puede ser imposible de mantener
• Intentamos implementar una prueba de rendimiento automatizada que comparara el rendimiento del cliente (FPS promedio, etc.) con el rendimiento registrado de hace una semana. Esto también fue bastante frágil ya que las demostraciones que usamos para esto tendían a pudrirse con bastante frecuencia, y era difícil determinar si la desaceleración era causada por una pérdida real en el rendimiento o algún efecto secundario del proceso de prueba.

Trabajando en un juego de estrategia 4x con combate en 3D (piense que Homeworld se encuentra con Masters Of Orion) que desafortunadamente nunca vio la luz del día ya que la compañía se quedó sin fondos.

Siempre me aseguré de que pudieras jugar el juego sin jugadores humanos para que pudiéramos dejar el juego funcionando durante la noche.

Podríamos desactivar el combate en 3D (simplificado a un resultado aleatorio) y dejamos el motor de estrategia de IA jugando solo. Esto encontró numerosos errores y problemas. No solo muestra errores de tapón, sino también errores de estrategia donde las (por ejemplo) estrategias de IA se estancarían y pasarían miles de turnos sin hacer "lo correcto". Este tipo de errores eran difíciles de detectar simplemente "jugando el juego".

En un juego de disparos en primera persona en el que trabajé (Descent 3 - linux / mac / windows, ~ 30 personas en el equipo en 1999), la capacidad de grabación / reproducción de demostración resultó ser extremadamente útil. Hice una opción en la que podía reproducir la demostración tan rápido como el juego podía renderizar cuadros, y esa se convirtió en una excelente manera de verificar el rendimiento después de que un montón de cosas cambiaran.

También ejerció gran parte del código más allá del sistema de renderizado, por lo que fue un buen control de cordura. Después de hacer un montón de cambios, pude ejecutar la reproducción de demostración de 10 minutos de juego. Muchas veces podría atrapar un error en un área que no hubiera pensado revisar yo mismo.

Tuvimos un juego de disparos de mundo abierto (x360, PS3, PC) que utilizó una prueba rápida de humo en el servidor de compilación: cargó el juego, atravesó la parte delantera, corrió [el avatar] hacia adelante, descargó una captura de pantalla y salió. Si cctray detectó la salida limpia, la compilación fue un éxito.

Lo ejecutamos durante el último año del proyecto, y con un tamaño de equipo de ~ 100 desarrolladores.

Fue eficaz para atrapar errores de showtopping, pero fue fácil crear una construcción que superó los niveles más reales pero falló en la mayoría de los niveles "reales", o no funcionó en el modo multijugador, o no tocó la IA, por lo que no fue perfecto. Definitivamente valió la pena hacerlo.

Escuché que, desde que me fui, comenzaron a ejecutar una gama más amplia de pruebas de humo, cultivadas en múltiples PC. Aparentemente, mantener las pruebas de humo es un problema, y ​​hay un pequeño equipo dedicado a mantener el mantenimiento de los servidores y el software, por lo que no puedo decir si eso fue un éxito o no.

Mi experiencia con las pruebas automatizadas durante el desarrollo de Crysis 2 está disponible aquí: http://yetanothergameprogrammingblog.blogspot.com/2010/06/aaa-automated-testing.html

Resumen:

• Las pruebas automatizadas mejoraron la estabilidad de los resultados, aumentando la productividad tanto para los creadores de contenido como para los ingenieros.
• Las pruebas automatizadas son una herramienta efectiva para mejorar la calidad del código y reducir las posibilidades de tener que trabajar horas extras
• La industria del juego en su conjunto es muy reaccionaria en general, las pruebas automatizadas cumplen varios argumentos irracionales contra
• No lo llame prueba, llámelo otra cosa, casi cualquier otra cosa (Mire el desarrollo impulsado por el comportamiento)
• Sea flexible, escribir buenas pruebas es difícil y requiere habilidades que no están ampliamente disponibles en la industria del juego

El desarrollo de juegos es en realidad uno de esos casos en los que las pruebas unitarias parecen tener algún sentido para mí, porque las interacciones entre sistemas discretos son muy comunes. El diseño por contrato es, por supuesto, una parte de esto, y debe planificarse desde el primer día de desarrollo, pero no veo por qué no se pudo implementar más adelante, suponiendo que existan los medios para hacerlo.

La parte difícil es, por supuesto, las pruebas de integración. Se puede probar mucho juego simplemente haciendo un bucle de demostración o algo así, pero conceptualmente es bastante fácil de depurar, donde estaría más interesado en dedicar mi tiempo a exponer errores que sucederán cuando un jugador hace algo, con la mentalidad de que un error que el jugador nunca ve es obviamente menos importante que un error que hace el jugador.

Lo cual es bastante difícil, obviamente. Las tácticas que funcionan en otras aplicaciones (fuzzing, esperado-aprobado / esperado-fallido, etc.) no funcionan tan bien aquí. En sistemas programables, parece que construir un conjunto de prueba de guiones para simular un jugador es el camino a seguir (ver la respuesta de JZig). Pero probar específicamente las cosas que un jugador puede encontrar directamente me parece el mejor lugar para enfocar su tiempo tanto para fines de pruebas humanas como automáticas.