Get best of the week

Probar el motor del juego Amazon Lumberyard. Enfoques y herramientas

Amazonas Juegos. ¿Suena inusual? ¿Cómo probar el producto tanto para desarrolladores como para jugadores? Bajo las pruebas de corte del motor de juego Amazon Lumberyard, los enfoques en las pruebas manuales y la automatización, así como las herramientas utilizadas en el proyecto.



Lumberyard es un motor de juegos multiplataforma donde puedes crear juegos gratis para la mayoría de las plataformas modernas: PC, Mac, iOS / Android, todas las consolas, incluidas las gafas de realidad virtual. También está bastante integrado con Amazon Web Services y el servicio de transmisión de juegos de Twitch.

Bajo el corte - video y transcripción del informe de Artem Nesiolovsky de la conferencia de Heisenbug .




Sobre el orador: graduado del Instituto de Física de Ingeniería de Moscú, Facultad de Cibernética, más de 8 años en desarrollo y pruebas. Trabajó tanto en proyectos de escritorio, como GeForce Experience, MMORPG Lineage II en línea como en dispositivos móviles, el juego Cut the Rope, así como en el proyecto web Yandex.Images. Actualmente es ingeniero de automatización en Amazon en el proyecto Amazon Lumberyard.

Estructura del poste


  • Motor del juego: características, así como diferencias entre probar el motor y probar juegos.
  • Pruebas manuales: cómo tratamos de descubrir la cobertura de las características del proyecto con pruebas funcionales.
  • Automatización: errores y golpes que llenamos y tratamos después.
  • Herramientas con las que automatizamos nuestro motor.
  • Errores interesantes de nuestro proyecto que probablemente conociste cuando jugaste a ti mismo.


Narración adicional en nombre del orador.



¿Por qué Amazon hace juegos? En 2014, Amazon, como muchos gigantes tecnológicos, señala que los juegos se están convirtiendo en la segunda forma de entretenimiento más popular para la humanidad. El primero, curiosamente, es la televisión, o más bien, todo lo relacionado con la transmisión de video (YouTube, Netflix y todo lo demás). Los desarrolladores de juegos también están comenzando a usar los servicios de AWS más activamente para sus juegos en línea.

Amazon decide construir un ecosistema en tres pilares: abrir su estudio de juegos para crear juegos que la gente luego transmitirá y verá en Twitch. Estos juegos también mostrarán qué ideas de juego interesantes se pueden implementar con AWS Cloud.

¿Cómo comenzó todo?


En 2004, la compañía alemana Crytek lanzó un juego llamado "FarCry". Después de un tiempo, Crytek comienza a licenciar su motor, en el que se construyó el juego, para que las empresas de terceros puedan tomar el motor terminado y comenzar a crear un juego, un juego, llenarlo con contenido sin una gran inversión en tecnología. Cuando Amazon comenzó a jugar, también abrió inmediatamente varios estudios y comenzó a desarrollar varios juegos.

Para que cada estudio no invente una bicicleta: su propio motor de renderizado, su sistema de animación, física, etc., Amazon licencia la versión 3 de CryEngine y lanza el desarrollo de varios juegos a la vez. El Grand Tour ya se lanzó en Xbox y PlayStation. Dos más están en desarrollo: MMORPG "New World" y el juego de disparos en línea "Crucible". Después de que el desarrollo de estos juegos ha comenzado, Amazon comienza a proporcionar de forma gratuita el motor en el que se desarrollan estos juegos. Debido a que está altamente integrado con los servicios en la nube de Amazon, puede atraer a más personas para usar AWS.



Un motor de juego es un conjunto de API, un motor de juego para construir un juego futuro. Para que los desarrolladores no necesiten escribir sus propios sistemas de juego, solo puede tomar un conjunto de API, es decir motor, y comience a escribir su propia lógica de juego, agregue contenido allí y participe en la creatividad, en lugar de desarrollar tecnología desde cero. Además, algunos motores tienen un editor. Este es un programa de escritorio en el que puedes crear niveles, es decir, abrir tu nivel y agregar contenido y lógica de juego allí.

En lugar de hablar mucho tiempo, a veces es más fácil mostrar un video:

Enlace al video 8: 33-9: 53

Aquí está nuestro editor y su interfaz. Se lanza un juego dentro de él, que proporcionamos junto con el motor. "Starter Game" existe para que las personas puedan iniciar sesión, jugar, cambiar algo y descubrir cómo funciona.

En general, los juegos en 3D se pueden imaginar como un conjunto de objetos tridimensionales que se mueven en un mundo tridimensional y de alguna manera interactúan entre sí. En este video puedes ver:

  • geometría estática con texturas: tierra, piedras, hierba, árboles;
  • geometría dinámica: el personaje está animado, reacciona a las acciones del jugador;
  • interfaz de usuario: vistas de tareas en la esquina superior izquierda.

El jugador puede encontrarse con personajes hostiles, aparecerá la lógica del juego, será posible disparar: los robots disparan en respuesta. Acerca de la física: el personaje comenzará a disparar a barriles, se moverá de colisiones con disparos e interactuará con el personaje. En el editor en cualquier momento, puede salir del modo de juego y volver al modo de edición, en el que puede cambiar inmediatamente las propiedades de los objetos, moverlos y esto aparecerá inmediatamente en el juego. ¿Imagina un número aproximado de lugares donde algo podría salir mal, descomponerse y dejar de funcionar correctamente?

¿Cómo probar el motor?


Probar el motor se basa en tres puntos principales. El primero es probar el editor y las herramientas: la operación correcta, las herramientas deben abrirse, nada bloquearse, todo debe mostrarse correctamente, los scripts de usuario deben ejecutarse sin errores, el proceso de crear un juego sin errores. Solo los creadores de juegos usarán el editor. El segundo es probar el motor en sí o la API del motor. El motor del juego, a su vez, es esa parte del código que funcionará incluso en las computadoras de los jugadores. Esta parte del proyecto se prueba a través de la creación avanzada de niveles y juegos. Posteriormente, los niveles creados se pueden probar en cada nueva versión del motor para asegurarse de que todos los elementos del juego utilizados en uno u otro nivel funcionen como deberían.Y el tercer componente es la prueba de infraestructura y compatibilidad: el motor se puede configurar y construir con diferentes parámetros, el juego se puede implementar en varios dispositivos y se verá y funcionará casi igual en todas partes.
Características del proyecto

La primera característica: admitimos la mayoría de las plataformas de juegos existentes. A pesar de que el editor solo funciona en PC, tiempo de ejecución, es decir El juego se puede construir en Mac, teléfonos inteligentes, consolas e incluso gafas de realidad virtual.

La segunda característica, nuestros usuarios, son dos tipos de personas con solicitudes completamente diferentes. Por un lado, estos son desarrolladores, programadores, artistas y diseñadores que trabajarán en la creación del juego. Y, por otro lado, estos son jugadores, en las máquinas en las que el juego funcionará. Los requisitos para estos dos grupos son completamente diferentes.

La tercera característica: en tales programas que le permiten crear algo nuevo, se implica de antemano la gama más amplia posible de productos posibles de esta aplicación. En nuestro motor, puede crear absolutamente cualquier juego, comenzando desde algo simple, como Tetris, y terminando con un complejo proyecto en línea, que juegan miles de personas al mismo tiempo.

Las tres características afectan en gran medida el número de scripts personalizados, cada uno de los cuales debe ser probado.



Mira esta captura de pantalla e imagina cuántos casos de prueba podrías escribir solo para esta parte de la funcionalidad. En total, tenemos más de 11 mil casos de prueba en el proyecto y esta base de datos está creciendo en aproximadamente 3-4 mil casos de prueba cada año.

Enlace al video 13: 20-13: 54

Encontramos la mayoría de los errores durante la interacción de varios componentes entre sí. En este video, la nieve en el estado normal se muestra en el cubo como debería, pero tan pronto como el personaje comienza a interactuar con él, la nieve comienza a desaparecer. La mayoría de los errores que encontramos están en esos lugares donde se unen varios componentes.

Enlace al video 14: 08-14: 41

Sin embargo, los errores no siempre ocurren cuando solo hay dos condiciones. A menudo sucede que aparecen errores cuando varios componentes convergen a la vez. En este caso, estamos considerando un error en el que, en una situación normal, el personaje simplemente se para en el suelo. Vale la pena agregar otro grado de libertad: elevar al personaje sobre el suelo: cuando cae, la animación comienza a reproducirse y la cámara se acerca / se aleja; la textura comienza a desaparecer. Aquí, tres componentes interactúan a la vez: altura, animación de personajes y distancia de la cámara. Es imposible pensar en todas estas opciones de antemano, y a menudo encontramos tales errores solo durante las pruebas ad-hoc.

Enlace al video 15: 02-15: 49

Hay otra característica: tenemos muchos sistemas no deterministas. Estos son sistemas en los que, con la misma entrada, el resultado final puede diferir. Un ejemplo simple es que hay variables aleatorias en el sistema. En nuestro caso, estos son sistemas de física en los que hay muchos cálculos con números de coma flotante. Las operaciones de punto flotante en diferentes procesadores o compiladores se pueden realizar de manera un poco diferente. Debido a esto, la funcionalidad resultante siempre será ligeramente diferente. Como resultado, estos sistemas son bastante difíciles de automatizar, porque es difícil explicarle a la máquina en qué caso se trata de un error, y en cuyo caso se trata de diferencias aceptables.

Enlace al video 16: 03-17: 14

Hay bastantes interacciones no triviales en el motor y en el editor mismo. Los usuarios a menudo interactúan dentro del espacio tridimensional usando el mouse y el teclado. Este video presentará una característica llamada Objeto simulado. Las cosas vestidas con el personaje deben moverse de acuerdo con las leyes de la física al mover el personaje en el que se usan estos artículos. Por ejemplo, ropa o un maletín. Como tal elemento en el video, la mano del personaje. Cuando el personaje se mueve, la mano también comienza a responder. A menudo, para probar dicha funcionalidad, debe realizar acciones no triviales: cambiar algo en la interfaz de usuario, mover objetos en un espacio tridimensional, arrastrar y soltar, también mirar los gráficos de animación que se encuentran a continuación y hacer todo en tiempo real. Esta característica afecta la complejidad de la automatización.

¿Cómo determinar la cobertura?


En algún momento, nos dimos cuenta de que escribimos muchos casos de prueba, pero fue difícil determinar qué cobertura teníamos. Encontramos los errores más críticos no durante nuestra prueba de regresión completa, sino durante las pruebas ad-hoc, que se llevaron a cabo al final del ciclo de lanzamiento. Empezamos a pensar: tenemos un motor con una gran funcionalidad, tenemos un repositorio en el que 12,000 casos: ¿cómo entender en qué lugares hay suficiente cobertura y en qué valdría la pena agregar casos de prueba?

Pasamos a la teoría de las pruebas, comenzamos a leer sobre cómo las personas definen la cobertura de las pruebas. Una forma es determinar a través del código fuente. En nuestro caso, es difícil de hacer. Tenemos varios millones de líneas de código y fue imposible completar esta verificación en poco tiempo. El segundo método es evaluar la cobertura a través de una evaluación de los requisitos. En los procesos ágiles, los requisitos a menudo se almacenan solo en la cabeza de las personas, y no en la documentación, por lo que a través de los requisitos para hacer una evaluación de cobertura tampoco era realista. Como resultado, recurrimos a la única forma posible para nosotros: la definición de cobertura a través de la redacción de un modelo.



Elegimos un modelo llamado ACC - Atributo, Componente, Capacidad. ACC es uno de los modelos más simples, que es bastante común en Amazon para el software de modelado. El modelo está construido sobre tres pilares principales. En primer lugar, estos son componentes, los sustantivos son las principales partes de trabajo del sistema. Para nosotros, esto es viewport, textura, esencia del juego. Las siguientes son capacidades, verbos, lo que estos componentes pueden hacer. Por ejemplo, pueden mostrar en la pantalla, calcular algo, mover algo, etc. Y la tercera parte son los atributos: adjetivos o adverbios relacionados con los componentes y sus capacidades. Los atributos describen los parámetros de las capacidades: rápido, seguridad, escalable, seguro, etc. Todo esto se puede reducir a tres preguntas: ¿quién? ¿qué está haciendo? ¿Y cómo?

Analizaremos este modelo con un pequeño ejemplo. A continuación se muestra una demostración de una pequeña parte de la funcionalidad:

Enlace al video 19: 59-21: 02

Viewport es la parte del editor donde el nivel es visible. El video mostró que es posible rotar la cámara, moverse por el nivel, es posible agregar un personaje del conductor local de los objetos del juego. Puedes mover un personaje, o crear una nueva entidad de juego haciendo clic derecho, puedes seleccionar todas las entidades actuales en el nivel y moverlas todas juntas. También puede agregar otro elemento geométrico y (como en todos los editores tridimensionales) cambiar no solo su posición en el espacio, sino también cambiar su ángulo y cambiar su tamaño. Una ventana llamada "Viewport" tiene diferentes modos de representación. Por ejemplo, las sombras se desactivan o se desactivan algunos efectos gráficos del procesamiento posterior. Puedes ingresar al modo de juego para probar inmediatamente los cambios que acabas de hacer.



Veamos el modelo ACC en sí. Rápidamente nos dimos cuenta de que estos modelos son muy convenientes para crear usando Mindmaps, y luego traducirlos a tabletas o directamente a la estructura en TestRail o en cualquier otro repositorio para casos de prueba. El componente principal en sí mismo es visible en el diagrama en el centro - Viewport - y más arriba de la rama roja está la función Viewport que le permite moverse por el nivel: puede girar la cámara, puede volar usando los botones "W", "A", "S", "D".

Su segunda oportunidad (rama naranja) es crear entidades de juego a través de Viewport o mediante arrastrar y soltar desde el explorador de juegos.

Y las entidades del tercer juego se pueden manipular: se pueden distinguir, cambiar su ubicación, rotar, etc. La rama verde a la izquierda es la configuración de Viewport al cambiar los modos de representación. Se resalta un atributo en la rama azul, lo que indica que Viewport también debe cumplir ciertos parámetros de rendimiento. Si se ralentiza, será difícil para los desarrolladores hacer algo.

Toda la estructura de árbol se transfiere a TestRail. Cuando transferimos los casos de prueba de nuestro sistema anterior a la nueva estructura, inmediatamente quedó claro dónde faltaban los casos de prueba, en algunos lugares aparecieron carpetas vacías.



Enlace al video 23: 01-24: 10

Estas estructuras crecen bastante rápido. Viewport en realidad se refiere al editor, que es solo una parte del motor. Dos partes principales: el editor en sí y el motor del juego. A la derecha en la imagen de arriba puede ver varios componentes que no están relacionados con el árbol. Por ejemplo, en un sistema de representación o scripting, las animaciones están separadas, porque se relacionan inmediatamente tanto con el editor como con el motor. Es decir, el sistema de renderizado funcionará en tiempo de ejecución en los dispositivos finales, pero en el editor en sí será posible cambiar algunos parámetros: hora del día y noche, edición de materiales, sistema de partículas.

Resultados y conclusiones


El modelado de ACC ayudó a resaltar áreas en las que los pacientes cubiertos por la prueba. Al llenar los vacíos en la cobertura, el número de errores encontrados después de nuestro pase de regresión completo se redujo en aproximadamente un 70%. Los modelos ACC fáciles de construir también han demostrado ser una buena fuente de documentación. Las nuevas personas que vinieron al proyecto los estudiaron y rápidamente pudieron hacerse una idea del motor. La creación / actualización de modelos ACC está estrechamente incluida en nuestro proceso de desarrollo de nuevas características.



Comenzamos a automatizar el motor a través de la automatización de la interfaz de usuario. La interfaz del editor está escrita en la biblioteca QT. Esta es una biblioteca para escribir IU multiplataforma para aplicaciones de escritorio, que puede funcionar tanto en Mac como en Windows. Utilizamos una herramienta llamada Squish de Froglogic, que funciona en un sistema similar con WebDriver, ajustado para el entorno de escritorio. En esta herramienta, se utiliza un enfoque similar al Objeto de página (del mundo de WebDriver), que se llama de manera diferente: Arquitectura de elementos compuestos. Los selectores se realizan en los componentes principales (como una "ventana" o "botón") y se registran las funciones que se pueden realizar con estos elementos. Por ejemplo, "clic derecho", "clic izquierdo", "guardar", "cerrar", "salir". Entonces estos elementos se combinan en una sola estructura,puede acceder a ellos dentro de su script, usarlos, tomar una captura de pantalla y comparar.

Problemas y soluciones


El primer problema es la estabilidad. Escribimos pruebas que prueban la lógica empresarial a través de la interfaz de usuario: ¿cuál es el problema? Cuando la lógica empresarial no cambia, pero la interfaz cambia: las pruebas caen, debe cargar nuevas capturas de pantalla.

El siguiente problema es la falta de funcionalidad. Muchos casos de usuarios no son solo presionar un botón, sino interactuar con el mundo tridimensional. Esta biblioteca no permitía esto, se necesitaban nuevas soluciones.

El tercer problema es la velocidad. Para cualquier prueba de IU, debe renderizar completamente el motor completo. Lleva tiempo, las máquinas para estas pruebas deben ser lo suficientemente potentes.



La solución llegó en forma de una biblioteca Shiboken. Esta biblioteca proporciona carpetas del código C ++ en Python, lo que hace posible llamar directamente a las funciones proporcionadas por el editor o el motor sin representar el editor de la interfaz de usuario. Un análogo del mundo de la web: la automatización sin cabeza (algo similar a PhantomJS): puede automatizar una aplicación web sin iniciar un navegador. En este caso, un sistema similar, solo para una aplicación de escritorio escrita en C ++.

Después de comenzar a invertir en este marco, nos dimos cuenta de que puede usarse no solo para automatizar las pruebas, sino también para automatizar cualquier proceso dentro del motor. Por ejemplo, un diseñador necesita poner 100 fuentes de luz en una fila (por ejemplo, hace un camino y usted necesita poner luces). En lugar de representar manualmente todas estas fuentes de luz, simplemente escribe un guión que crea una entidad de juego, agrega una fuente de luz puntual allí y prescribe que cada 10 metros necesita copiar la luz de punto creada previamente. Una bonificación para nuestros usuarios en forma de una herramienta para automatizar tareas rutinarias.



La segunda parte de la solución al problema. Rápidamente nos dimos cuenta de que para automatizar varias partes de nuestro motor, por ejemplo, gráficos y partes de red, necesitábamos marcos completamente diferentes. Es imposible crear un marco único y monstruoso que ayude a automatizar todo a la vez. Por lo tanto, comenzamos a desarrollar un marco llamado Lumberyard Test Tools (para abreviar - LyTestTools). Está basado en Pytest (muchas cosas están escritas en el motor en Python). Decidimos usar la llamada arquitectura Plug-and-play: el grupo central de ingenieros de automatización escribe la parte principal del marco, que puede descargar, configurar el motor, implementarlo en varias plataformas, ejecutar pruebas y recopilar registros, cargar informes en nuestra base de datos o S3 y dibujar gráficos en Quicksight. Plug-and-play se logra a través de Test Helper's,que será escrito por equipos en el campo que desarrolla características.

Es decir, el equipo de desarrollo de gráficos probará con capturas de pantalla y el equipo de interacción de red verificará los paquetes reenviados. Al mismo tiempo, todos estarán conectados a nuestro marco común (ya que ambos equipos desarrollan y prueban módulos de un solo motor) para que todos tengan las mismas interfaces para ejecutar pruebas y generar informes, de modo que todo funcione de manera más o menos estándar y funcione correctamente con nuestro CI / Discos compactos.

Interacción con Lumberyard


¿Cuáles pueden ser las formas de interacción / automatización de una aplicación de escritorio? El primer tipo de interacción entre el marco y el motor: directamente desde Python, el proceso se inicia utilizando la función Subproceso, si la aplicación implica el inicio a través de la línea de comandos. Puede leer la entrada / salida de la entrada / salida estándar y, por lo tanto, hacer afirmaciones. El siguiente tipo, esta interacción a través del análisis de registros, puede leer y analizar los registros que deja la aplicación. El tercero es a través de la red. En los lanzadores de juegos, hay un módulo llamado Consola remota. Cuando un determinado puerto está abierto en el dispositivo, nuestro marco puede enviar paquetes / comandos específicos. Por ejemplo, tome una captura de pantalla o abra un nivel específico. Otro método es la interacción mediante la comparación de información visual, es decir. capturas de pantallaTambién se mencionó anteriormente el método de invocar la funcionalidad de la aplicación directamente a través de la API del producto (en nuestro caso, es una llamada a través de enlaces de Python a la funcionalidad del editor / motor C ++).

Pasemos a ejemplos de uso de nuestro marco para automatizar el motor.

Echa un vistazo a esta captura de pantalla.



El detalle en este sitio es bastante alto: una gran cantidad de vegetación. En los juegos modernos, los niveles pueden tomar hasta varias decenas y cientos de kilómetros de juego. Naturalmente, cada uno de estos arbustos de juegos no se coloca manualmente, de lo contrario los desarrolladores simplemente se volverían locos. Para ellos, nuestro motor tiene herramientas especiales.

Uno de ellos se llama la herramienta de vegetación. Pequeña demostración:

Enlace al video 32: 18-34: 06

Vemos el inicio estándar del nivel. Hay terreno y se puede hacer un alivio muy rápidamente: en el fondo hacer montañas, en la parte central también se destaca una pequeña colina. Puedes pintar el suelo de verde con una textura de hierba. El proceso de agregar vegetación, en este caso, árboles, se demuestra aún más. La geometría (árboles) se agrega a la herramienta; se resalta un subconjunto de ellos y se puede dibujar cualquier dibujo necesario con estos árboles. Este es un ejemplo bastante simple, esta herramienta tiene muchos parámetros personalizables. Por ejemplo, puede seleccionar no un árbol, sino varios a la vez y establecer un parámetro para ellos, pararse a cierta distancia uno del otro, o establecer parámetros aleatorios para el tamaño o la rotación de estos árboles. Puedes agregar un personaje del juego e inmediatamente correr en el nivel, probar,¿Qué acabas de cultivar en tu propio jardín de juegos?

Veamos ahora cómo automatizamos esta función con nuestro marco utilizando un par de pruebas como ejemplo.

Enlace al video 34: 20-34: 58

Hay un terreno estándar y se cultiva mucho del mismo tipo de césped. Este tipo de renderizado es muy intensivo en el procesador. Si hay muchos de estos elementos, puede hacer una prueba de carga. Aquí se ha agregado un script de juego, que al iniciar el modo de juego simplemente hará un vuelo a través de este nivel. La tarea es probar esta funcionalidad y verificar que el iniciador del juego sea estable y no se bloquee.



Este es un ejemplo de cómo el equipo que desarrolló la función para cultivar vegetación escribió Test Helper, que le permite trabajar con estas funciones. Este es un ejemplo de uso de nuestro marco. La clase de iniciador se resalta en verde. Cuando comienza la prueba, se despliega el iniciador, comienza con los parámetros de tiempo de espera y hacemos una afirmación para verificar que el iniciador no se bloquee después de un tiempo. Luego lo apagamos.



El código de parametrización anterior muestra que podemos reutilizar el mismo código en diferentes plataformas. Además, podemos reutilizar el mismo código en diferentes niveles o proyectos. Por ejemplo, las plataformas se resaltan en rojo: en un caso es Windows, en otro caso es Mac; el proyecto se resalta en amarillo; el nivel del nombre se resalta en amarillo claro.

Enlace al video 36: 07-36: 47

Ahora sobre la prueba, en este caso, ejecútela a través de la línea de comando. Se abre un programa llamado Asset Processor, una de las partes principales del motor. Este programa procesa los recursos de origen (por ejemplo, modelos y texturas creados por artistas) en formatos que son comprensibles para el motor y escribe todo en la base de datos (SQLite) para que el motor pueda navegar y cargar rápidamente los datos necesarios durante el juego. A continuación, se inicia el iniciador, se inicia el modo de juego, la cámara vuela por encima del nivel durante varios segundos y finaliza la prueba. Vemos que una prueba fue exitosa y se saltaron dos pruebas. Esto sucedió porque durante la grabación del video, la prueba se persiguió en Windows, y en la parametrización hay dos plataformas más que se omitieron respectivamente durante este lanzamiento.



Hay una opción más difícil. No solo iniciamos el iniciador con el nivel final, sino que el script interactúa directamente con el editor. Azul indica el nombre de un script separado que funcionará con el editor y extraerá varios comandos a través de la API.



Arriba está el nivel de prueba. En este caso, se dibuja una sonrisa en el terreno estándar utilizando una textura preparada previamente (máscara). Es necesario verificar que al usar la máscara, la pintura se llevará a cabo solo a lo largo de un contorno previamente seleccionado y no irá más allá.



El equipo que trabaja con el mundo del juego escribió su extensión para trabajar con terrane, que luego se inserta en nuestro marco. Se crea un nuevo pincel, que se dibujará en la máscara "Adoquines", el pincel se establece en rojo y se pinta la capa seleccionada.



A continuación, se crea un nuevo pincel, se establece una intensidad diferente para él. La máscara ya no se usa, y en el ciclo, ya en otra parte del nivel, se dibuja un nuevo elemento.

Veamos cómo funciona este script.

Enlace al video 38: 42-39: 35

Primero, se iniciará el Procesador de activos, que verificará el estado de la base de datos de activos y procesará los elementos recién agregados si es necesario. A continuación, comienza el editor. El nivel se abrirá con una sonrisa y se iniciará un script que se ejecuta con el editor. Pinta la capa sobre la máscara, luego crea un círculo azul y comienza a tomar capturas de pantalla. Posteriormente, las capturas de pantalla se compararán con las de referencia y, si todo está en orden, la prueba se completará.

La prueba toma tales capturas de pantalla para compararlas con los estándares. Aquí puede ver que la imagen fue claramente a lo largo del borde.

Artes graficas


También utilizamos nuestro marco para probar gráficos.

Enlace al video 40: 04-40: 56

Gráficos: una de las partes más difíciles del motor, que ocupa la mayor parte del código. Puede y debe verificar todo, comenzando con cosas simples, como geometría y texturas, y características más complejas: sombras dinámicas, iluminación, efectos de procesamiento posterior. En el video en la esquina derecha puede ver el reflejo en el charco: todo funciona en tiempo real en nuestro motor. Cuando la cámara vuela hacia adentro, puede ver elementos de renderizado más avanzados, por ejemplo, reflejos, elementos transparentes, como el vidrio, así como la visualización de elementos como superficies metálicas. ¿Cómo se prueba esta funcionalidad con capturas de pantalla?



Este es nuestro personaje, Rin. Con él, a menudo probamos tuberías de artistas. Los artistas crean algo en su editor (por ejemplo, un personaje) y luego dibujan texturas en él. Asset Processor procesa los datos originales para desplegarlos en varias plataformas, y el motor gráfico se ocupará de la pantalla.



Seguramente encontraste un error cuando "las texturas no se cargaron". De hecho, hay muchos problemas cuando algo sucede al mostrar texturas.



Pero todos ellos están bien atrapados al comparar capturas de pantalla. En la primera captura de pantalla puede ver un error: algunos materiales no se cargan bien. En estas capturas de pantalla, el mismo nivel donde estaba la motocicleta y la cámara voló dentro del café, que se mostró en el video anteriormente. ¿Por qué todo parece tan aburrido aquí? Debido a que las capturas de pantalla no se toman en la última etapa de la representación, cuando el motor gráfico presenta todos sus efectos, sino por etapas. Al principio, solo se toma la representación de geometría y texturas simples: se eliminan las sombras, se eliminan los elementos de iluminación complejos. Si prueba todo en la última etapa y mira Diff Image, será difícil decir qué se rompió exactamente.



Si hace esto por etapas, puede comprender aproximadamente en qué parte del motor de gráficos algo salió mal. Aquí está el algoritmo por el cual comparamos las capturas de pantalla.



Al comparar capturas de pantalla, puede probar gráficos, elementos de visualización, texturas, materiales, sombreadores.

Daré un ejemplo de un error de la versión anterior de nuestro motor cuando no teníamos este marco.

Enlace al video 43: 10-43: 44

Se relaciona con el sistema de Vegetación. Después de agregar árboles, la parte gráfica comienza a dibujar sombras debajo de ellos. Es necesario presionar "Ctrl + Z" ("Cancelar"), los árboles desaparecen y las sombras permanecen. Si toma una captura de pantalla al principio, cuando el árbol está de pie y después de hacer clic en "Cancelar", es fácil detectar dicho error en modo automático después de compararlo con las capturas de pantalla de referencia de Antes y Después.

Al comparar capturas de pantalla, la canalización de activos también está muy bien probada. Cuando los artistas crearon algo en editores 3D (Maya, 3dsMax), debes comprobar que todo se muestra en el juego de la misma manera y que no se perdió nada: el pollo tiene plumas, todos los animales tienen pelaje, las personas tienen la textura de piel correcta y otras cosas.

Enlace al video 44: 16-44: 52

En el lado derecho del programa se encuentra el Procesador de activos, que monitorea la visualización en el juego de todo lo que pintó el artista. Nos dirá que todo está en orden con estos activos: deberían funcionar. En el video puedes ver que algunos árboles se volvieron negros. Algunos se muestran normalmente, y algunas texturas verdes simplemente desaparecieron. Naturalmente, de esta forma no puede liberar un motor o activos.

No todo puede ser atrapado


Enlace al video 45: 03-45: 17

Algunos tipos de errores comienzan a formarse solo cuando varios elementos interactúan entre sí. Dos modelos Rin se muestran normalmente si se eliminan entre sí, pero si los acerca, comienzan los problemas con la geometría. Desafortunadamente, estos errores son difíciles de atrapar incluso antes de la automatización. A menudo se pueden notar solo cuando los probadores comienzan a hacer algo en el modo de prueba exploratoria o cuando el motor ya cae en manos de los clientes.



Al comparar capturas de pantalla, puede probar la interfaz del editor en sí.

Componentes del juego




Además, las capturas de pantalla pueden probar algunos componentes simples del juego. Un ejemplo es un nivel simple en el que hay una puerta y un script que, cuando presiona la barra espaciadora, inicia la puerta para abrir y cerrar.

Puede tomar una captura de pantalla al principio y al final. Si todo coincide, el script que cambia la ubicación del elemento funciona correctamente.

DEFORMACIÓN


Rápidamente nos dimos cuenta de que las capturas de pantalla de la misma funcionalidad son muy diferentes en diferentes plataformas, en algunos casos puede haber diferencias en la misma plataforma dependiendo del tipo de tarjeta de video. ¿Cómo lidiar con esto, para no almacenar capturas de pantalla de 100500? Existe una herramienta, Windows Advanced Rasterization Platform es un procesador de software que le permite hacer todos los gráficos sin recurrir al controlador y la tarjeta de video. Con esta herramienta, puede conducir la mayoría de las pruebas de gráficos funcionales sin depender de los controladores y el hardware.

Actuación


Por último, pero no menos importante, ¡el motor del juego debe ser productivo! Las GPU se pueden probar utilizando varios perfiladores gráficos, como PIX. La RAM se puede probar en Visual Studio. Además, más sobre cómo se prueba el rendimiento del procesador con la herramienta RADTelemetry.

¿Sabes qué es Input Lag?

Enlace al video 47: 29-48: 21

Retraso de entrada: es el retraso entre que el jugador presiona la tecla del controlador / teclado y el momento en que el juego comienza a responder al presionar. El retraso de entrada ocurre debido a la transmisión de datos a través de la red, cuando los paquetes duran mucho tiempo o el servidor responde durante mucho tiempo, así como en los motores y sin usar la red. Cuando alguien se equivoca en el código responsable de la animación, el retraso de entrada puede llegar a ser tan alto que el personaje comienza a responder demasiado tarde. En una aproximación simple, esto se prueba con bastante facilidad: se abre un teclado virtual y se graba un video, en el que se registran el momento de presionar la barra espaciadora y el momento del inicio de la animación.

Observamos cuántos cuadros por segundo está dando el motor. Puede calcular cuánto tomó cada cuadro en milisegundos (1000 / FPS). Si reproduce el video cuadro por cuadro, puede calcular cuántos cuadros han pasado desde el clic antes de que el personaje comience a moverse. Sabiendo cuántos milisegundos ocupa cada cuadro, se puede calcular que, por ejemplo, pasaron 200 milisegundos entre presionar un espacio y el comienzo de la animación. Con una respuesta humana estándar de 100 milisegundos, esto es demasiado lento y los jugadores dirán de inmediato que tal retraso no tiene valor. Este método de prueba tiene sus problemas. En primer lugar, habrá errores. Por ejemplo, el teclado virtual tendrá un retraso. En segundo lugar, en los juegos, los artistas suelen hacer animaciones para que el personaje no comience inmediatamente a hacer el movimiento principal. Existe la llamada anticipación: antes de la acción principal,Por ejemplo, al saltar, el personaje primero se dobla un poco y solo entonces comienza a saltar. Esto puede tomar un par de cuadros. ¿Cómo luchamos contra esto? Comenzamos a probar esta parte con un enfoque más preciso.

Hay un programa llamado RADTelemetry.

Enlace al video 49: 44-50: 47

Le permite perfilar el procesador. Los cuadros verticales se presentan aquí: No. 629, 630: puede ver cuánto tiempo tomó cada cuadro. Horizontalmente, los núcleos del procesador o los subprocesos de ejecución de la aplicación se descartan si la aplicación es multiproceso. Si hace clic en cualquiera de los hilos, el nombre de todas las funciones que estaban en este hilo cuando se iniciaron, cuánto tiempo tardaron en ejecutarse desde el total, cuántas veces se ejecutaron, se mostrará a la izquierda. Con esta aplicación, puedes comprender con precisión cuánto tiempo ha pasado desde el momento en que el juego registró la pulsación del teclado, antes de que lanzara la función Play Animation. Este programa puede colocar sus registros en archivos de texto, y luego, al usarlos, puede dibujar gráficos de rendimiento útiles de diferentes compilaciones en la distribución del tiempo.

¿Y dónde está AWS aquí?


En conclusión, algunas palabras sobre AWS. Por un lado, lo usamos para conducir nuestras pruebas. Realizamos pruebas en EC2 y en dispositivos de Device Farm. Los resultados se agregan a la base de datos en S3 y los gráficos se muestran en Quicksight. Las estadísticas de prueba se pueden ver en CloudWatch. Dado que el motor está altamente integrado con los servicios de AWS, también probamos estas integraciones, tanto de forma manual como automática. Por ejemplo, CloudCanvas es un servicio que le permite crear funcionalidades para juegos en línea sin programación, es decir, en el servidor simplemente puede configurar chips como tablas de clasificación, tablas de puntuación y logros. Para cosas como la monetización de juegos, no puede buscar el programador de su servidor, sino que inmediatamente comenzará a usar CloudCanvas. Amazon GameLift es esencialmente un sistema escalable para servidores de juegos.Integración con Twitch: cuando los usuarios miran la transmisión de dos jugadores que compiten entre ellos. Se crea una encuesta de Twitch "¿A qué jugador apoyas?" - las personas comienzan a votar en el chat, el juego lee las respuestas y uno de los jugadores (como en los Juegos del Hambre) puede perder un bono extra o evitarlo.

Resumen


Lo primero que nos dimos cuenta es que en proyectos tan grandes no hay una sola bala de plata con la que pueda automatizar todo. En nuestro caso, el marco Plug-and-play funcionó bien. Escribimos un marco común y permitimos que el resto de los equipos integraran convenientemente sus soluciones. Utilizando ejemplos de capturas de pantalla y comparación de vegetación, el sistema mostró cómo funcionan estos marcos. Espero que algunas aplicaciones y soluciones industriales (como el Software Renderer de Microsoft o RADTelemetry) que se proporcionan en este artículo sean útiles para los ingenieros que trabajan en juegos o sistemas CAD.

En conclusión, enlaces a todas las herramientas que se mostraron en el informe:



Espero haber logrado decir cómo las pruebas de motores difieren de las pruebas de juegos. Recientemente, el proceso ha avanzado mucho: probar motores de juegos no es para nada simple, pero es muy interesante.

Si está interesado en el tema de probar juegos, le recomendamos que consulte otros informes:

More articles:


All Articles