Get best of the week

Testando o mecanismo de jogo do Amazon Lumberyard. Abordagens e Ferramentas

Amazonas Jogos. Parece incomum? Como testar o produto para desenvolvedores e jogadores? Sob o teste de corte do mecanismo de jogo Amazon Lumberyard, abordagens nos testes e automação manuais, bem como as ferramentas usadas no projeto.



O Lumberyard é um mecanismo de jogo multiplataforma onde você pode criar jogos de graça para as plataformas mais modernas: PC, Mac, iOS / Android, todos os consoles, incluindo óculos de realidade virtual. Também está profundamente integrado ao Amazon Web Services e ao serviço de transmissão de jogos do Twitch.

Sob o corte - vídeo e transcrição do relatório de Artem Nesiolovsky da conferência Heisenbug .




Sobre o palestrante: se formou no Instituto de Física de Engenharia de Moscou, Faculdade de Cibernética, mais de 8 anos em desenvolvimento e testes. Ele trabalhou em projetos de desktop, como a GeForce Experience, o MMORPG online Lineage II e em dispositivos móveis - o jogo Cut the Rope, bem como no projeto web Yandex.Images. Atualmente, ele é engenheiro de automação na Amazon no projeto Amazon Lumberyard.

Estrutura do posto


  • Mecanismo de jogo: recursos e diferenças entre testar o mecanismo e testar os jogos.
  • Teste manual: como tentamos descobrir a cobertura dos recursos do projeto com testes funcionais.
  • Automação: erros e inchaços que preenchemos e tratamos posteriormente.
  • Ferramentas com as quais automatizamos nosso mecanismo.
  • Erros interessantes do nosso projeto que você provavelmente conheceu quando jogou sozinho.


Narração adicional em nome do orador.



Por que a Amazon está fazendo jogos? Em 2014, a Amazon, como muitos gigantes da tecnologia, observa que os jogos estão se tornando a segunda forma de entretenimento mais popular para a humanidade. O primeiro, curiosamente, é a televisão, ou melhor, tudo relacionado a streaming de vídeo (YouTube, Netflix e tudo mais). Os desenvolvedores de jogos também estão começando a usar os serviços da AWS de forma mais ativa em seus jogos online.

A Amazon decide construir um ecossistema em três pilares: abrir seu estúdio de jogos para criar jogos que as pessoas transmitirão e assistirão no Twitch. Esses jogos também mostram quais idéias interessantes de jogo podem ser implementadas usando o AWS Cloud.

Como é que tudo começou?


Em 2004, a empresa alemã Crytek lançou um jogo chamado "FarCry". Depois de algum tempo, a Crytek começa a licenciar seu mecanismo, no qual o jogo foi construído, para que empresas terceirizadas possam pegar o mecanismo pronto e começar a criar um jogo, jogabilidade e preenchê-lo com conteúdo sem um grande investimento em tecnologia. Quando a Amazon começou a jogar, também abriu imediatamente vários estúdios e começou a desenvolver vários jogos.

Para que todo estúdio não invente uma bicicleta - seu próprio mecanismo de renderização, seu sistema de animação, física etc. -, a Amazon licencia o CryEngine versão 3 e lança o desenvolvimento de vários jogos ao mesmo tempo. O Grand Tour já foi lançado no Xbox e PlayStation. Mais dois estão em desenvolvimento: o MMORPG "New World" e o shooter online "Crucible". Após o início do desenvolvimento desses jogos, a Amazon começa a fornecer gratuitamente o mecanismo no qual esses jogos são desenvolvidos. Por estar altamente integrado aos serviços em nuvem da Amazon, você pode atrair mais pessoas para usar a AWS.



Um mecanismo de jogo é um conjunto de APIs, um mecanismo de jogo para criar um jogo futuro. Para que os desenvolvedores não precisem criar seus próprios sistemas de jogos, basta usar um conjunto de APIs, ou seja, e comece a escrever sua própria lógica de jogo, adicione conteúdo e envolva-se em criatividade, em vez de desenvolver tecnologia do zero. Além disso, alguns mecanismos têm um editor. Este é um programa de desktop no qual você pode criar níveis, ou seja, abrir seu nível e adicionar conteúdo e lógica de jogo.

Em vez de conversar por um longo tempo, às vezes é mais fácil exibir um vídeo:

link para o vídeo 8: 33-9: 53

Aqui está o nosso editor e sua interface. Um jogo é lançado dentro dele, que fornecemos junto com o mecanismo. O "Starter Game" existe para que as pessoas possam entrar, jogar, mudar alguma coisa e descobrir como funciona.

Em geral, os jogos em 3D podem ser imaginados como um conjunto de objetos tridimensionais que se movem em um mundo tridimensional e de alguma forma interagem entre si. Neste vídeo você pode ver:

  • geometria estática com texturas: terra, pedras, grama, árvores;
  • geometria dinâmica - o personagem é animado, reage às ações do jogador;
  • interface do usuário: visualizações de tarefas no canto superior esquerdo.

O jogador pode se encontrar com personagens hostis, a lógica do jogo aparecerá, será possível atirar - os robôs atiram em resposta. Sobre física: o personagem começará a atirar em barris, passará de colisões com tiros e interagirá com o personagem. No editor, a qualquer momento, você pode sair do modo de jogo e voltar ao modo de edição, no qual é possível alterar imediatamente as propriedades dos objetos, movê-los e isso aparecerá imediatamente na jogabilidade. Imagine um número aproximado de lugares onde algo pode dar errado, quebrar e parar de funcionar corretamente?

Como testar o motor?


O teste do mecanismo é baseado em três pontos principais. O primeiro é testar o editor e as ferramentas: a operação correta, as ferramentas devem abrir, nada para travar, tudo deve ser exibido corretamente, os scripts do usuário devem ser executados sem erros, o processo de criação de um jogo sem erros. Somente criadores de jogos usarão o editor. O segundo está testando o próprio mecanismo ou a API do mecanismo. O mecanismo de jogo, por sua vez, é a parte do código que funcionará, inclusive nos computadores dos jogadores. Esta parte do projeto é testada através da criação avançada de níveis e jogos. Posteriormente, os níveis criados podem ser testados em cada nova versão do mecanismo para garantir que todos os elementos do jogo usados ​​em um ou outro nível funcionem como deveriam.E o terceiro componente é o teste de infraestrutura e compatibilidade: o mecanismo pode ser configurado e construído com diferentes parâmetros, o jogo pode ser implantado em vários dispositivos e parecerá e funcionará quase da mesma forma em todos os lugares.
Recursos do projeto

O primeiro recurso - suportamos a maioria das plataformas de jogos existentes. Apesar do editor em si só funcionar no PC, o tempo de execução, ou seja, O jogo pode ser construído em Mac, smartphones, consoles e até óculos de realidade virtual.

O segundo recurso - nossos usuários - são dois tipos de pessoas com solicitações completamente diferentes. Por um lado, são desenvolvedores, programadores, artistas e designers que trabalharão na criação do jogo. E, por outro lado, são jogadores, nas máquinas em que o jogo funcionará. Os requisitos para esses dois grupos são completamente diferentes.

O terceiro recurso - nesses programas que permitem criar algo novo, a maior variedade possível de produtos possíveis desse aplicativo é implícita com antecedência. Em nosso mecanismo, você pode criar absolutamente qualquer jogo, começando por algo simples, como o Tetris, e terminando com um projeto on-line complexo, jogado por milhares de pessoas ao mesmo tempo.

Todos esses três recursos afetam bastante o número de scripts personalizados, cada um dos quais precisa ser testado.



Olhe para esta captura de tela e imagine quantos casos de teste você poderia escrever apenas para esta parte da funcionalidade? No total, temos mais de 11 mil casos de teste no projeto e esse banco de dados cresce cerca de 3-4 mil casos de teste a cada ano.

Link para o vídeo 13: 20-13: 54

Encontramos a maioria dos erros durante a interação de vários componentes entre si. Neste vídeo, a neve no estado normal é exibida no cubo como deveria, mas assim que o personagem começa a interagir com ele, a neve começa a desaparecer. A maioria dos erros que encontramos estão em locais onde vários componentes se juntam.

Link para o vídeo 14: 08-14: 41

No entanto, os erros nem sempre ocorrem quando existem apenas duas condições. Muitas vezes acontece que os erros aparecem quando vários componentes convergem ao mesmo tempo. Nesse caso, estamos considerando um bug no qual, em uma situação normal, o personagem simplesmente fica no chão. Vale acrescentar outro grau de liberdade - para elevar o personagem acima do solo: quando ele cai, a animação começa a tocar e a câmera se aproxima / se afasta - a textura começa a desaparecer. Aqui, três componentes interagem ao mesmo tempo: altura, animação dos personagens e distância da câmera. É impossível pensar em todas essas opções com antecedência, e geralmente encontramos esses erros apenas durante testes ad-hoc.

Link para o vídeo 15: 02-15: 49

Há outra característica - temos muitos sistemas não determinísticos. São sistemas nos quais, com a mesma entrada, o resultado final pode ser diferente. Um exemplo simples é que existem variáveis ​​aleatórias no sistema. No nosso caso, são sistemas de física nos quais existem muitos cálculos com números de ponto flutuante. As operações de ponto flutuante em diferentes processadores ou compiladores podem ser realizadas de maneira um pouco diferente. Por esse motivo, a funcionalidade resultante sempre será ligeiramente diferente. Como resultado, esses sistemas são bastante difíceis de automatizar, porque é difícil explicar à máquina, caso em que isso é um bug e, nesse caso, essas diferenças são aceitáveis.

Link para o vídeo 16: 03-17: 14

Existem algumas interações não triviais no mecanismo e no próprio editor. Os usuários geralmente interagem no espaço tridimensional usando o mouse e o teclado. Este vídeo apresentará um recurso chamado Objeto simulado. As coisas vestidas com o personagem devem se mover de acordo com as leis da física ao mover o personagem com o qual esses itens são usados. Por exemplo, roupas ou uma maleta. Como um elemento no vídeo - a mão do personagem. Quando o personagem se move, a mão também começa a responder. Freqüentemente, para testar essa funcionalidade, é necessário executar ações não triviais: alternar algo na interface do usuário, mover objetos no espaço tridimensional, arrastar e soltar, também ver os gráficos de animação localizados abaixo e fazer tudo em tempo real. Esse recurso afeta a complexidade da automação.

Como determinar a cobertura?


Em algum momento, percebemos que escrevemos muitos casos de teste, mas era difícil determinar qual cobertura tínhamos. Encontramos os erros mais críticos, não durante o teste de regressão completo, mas durante o teste ad-hoc, que foi realizado no final do ciclo de lançamento. Começamos a pensar: temos um mecanismo com muita funcionalidade, temos um repositório em que 12.000 casos - como entender em que lugares há cobertura suficiente e em que valeria a pena adicionar casos de teste?

Voltamos à teoria dos testes, começamos a ler sobre como as pessoas definem a cobertura dos testes. Uma maneira é determinar através do código fonte. No nosso caso, é difícil de fazer. Temos vários milhões de linhas de código e foi impossível concluir esta verificação em pouco tempo. O segundo método é avaliar a cobertura por meio de uma avaliação de requisitos. Nos processos ágeis, os requisitos geralmente são armazenados apenas na cabeça das pessoas, e não na documentação; portanto, os requisitos para fazer uma avaliação da cobertura também não eram realistas. Como resultado, nos voltamos para a única maneira possível para nós - a definição de cobertura através da criação de um modelo.



Escolhemos um modelo chamado ACC - Atributo, Componente, Capacidade. O ACC é um dos modelos mais simples, bastante comum na Amazon para modelagem de software. O modelo é construído em três pilares principais. Em primeiro lugar, esses são componentes, os substantivos são as principais partes de trabalho do sistema. Para nós, isso é viewport, textura, essência do jogo. A seguir estão os recursos - verbos - o que esses componentes podem fazer. Por exemplo, eles podem ser exibidos na tela, calcular algo, mover algo e assim por diante. E a terceira parte são atributos - adjetivos ou advérbios relacionados aos componentes e suas capacidades. Os atributos descrevem os parâmetros dos recursos: rápido, segurança, escalável, seguro e assim por diante. Tudo isso pode ser reduzido a três perguntas: quem? o que ele está fazendo? E como?

Vamos analisar esse modelo com um pequeno exemplo. Abaixo está uma demonstração de uma pequena parte da funcionalidade:

Link para o vídeo 19: 59-21: 02

A viewport é a parte do editor em que o nível é visível. O vídeo mostrou que é possível girar a câmera, mover-se ao redor do nível, é possível adicionar um personagem do condutor local dos objetos do jogo. Você pode mover um personagem ou criar uma nova entidade do jogo clicando com o botão direito do mouse, você pode selecionar todas as entidades atuais no nível e movê-las todas juntas. Você também pode adicionar outro elemento geométrico e (como em todos os editores tridimensionais) alterar não apenas sua posição no espaço, mas também alterar seu ângulo e redimensionar. Uma janela chamada "Viewport" possui diferentes modos de renderização. Por exemplo, as sombras estão desativadas ou alguns efeitos gráficos do pós-processamento estão desativados. Você pode entrar no modo de jogo para testar imediatamente as alterações feitas.



Vejamos o próprio modelo ACC. Nós rapidamente percebemos que esses modelos são muito convenientes de usar o Mindmaps e depois os convertemos em tablets ou diretamente na estrutura no TestRail ou em qualquer outro repositório para casos de teste. O componente principal em si é visível no diagrama no centro - Viewport - e mais acima do ramo vermelho está o recurso Viewport que permite que você se mova pelo nível: você pode girar a câmera, voar usando os botões "W", "A", "S", "D".

Sua segunda oportunidade (ramo laranja) é criar entidades de jogo através da Viewport ou através do recurso arrastar e soltar do explorador de jogos.

E as entidades do terceiro jogo podem ser manipuladas: elas podem ser distinguidas, sua localização alterada, rotacionada e assim por diante. O ramo verde à esquerda é a configuração do Viewport ao alternar os modos de renderização. Um atributo é destacado na ramificação azul, o que indica que o Viewport também deve atender a determinados parâmetros de desempenho. Se diminuir, será difícil para os desenvolvedores fazerem qualquer coisa.

Toda a estrutura da árvore é então transferida para o TestRail. Quando transferimos os casos de teste do nosso sistema anterior para a nova estrutura, ficou imediatamente claro onde os casos de teste estavam faltando - em alguns lugares, pastas vazias apareceram.



Link para o vídeo 23: 01-24: 10

Essas estruturas crescem rapidamente. A viewport na verdade se refere ao editor, que é apenas parte do mecanismo. Duas partes principais: o próprio editor e o próprio mecanismo de jogo. À direita na figura acima, você pode ver vários componentes que não estão relacionados à árvore. Por exemplo, um sistema de renderização ou script, as animações são separadas, porque se relacionam imediatamente ao editor e ao mecanismo. Ou seja, o sistema de renderização funcionará em tempo de execução nos dispositivos finais, mas no próprio editor será possível alterar alguns parâmetros: hora do dia e da noite, materiais de edição, sistema de partículas.

Resultados e Conclusões


A modelagem do ACC ajudou a destacar áreas nas quais os pacientes cobertos pelo teste. Preenchendo as lacunas na cobertura, o número de bugs encontrados após nossa passagem de regressão completa foi reduzido em cerca de 70%. Os modelos ACC fáceis de construir também provaram ser uma boa fonte de documentação. As novas pessoas que vieram para o projeto as estudaram e rapidamente puderam ter uma idéia do mecanismo. A criação / atualização de modelos ACC está intimamente incluída em nosso processo de desenvolvimento de novos recursos.



Começamos a automatizar o mecanismo através da automação da interface do usuário. A interface do editor é gravada na biblioteca QT. Esta é uma biblioteca para escrever a interface do usuário de plataforma cruzada para aplicativos de desktop, que pode funcionar no Mac e no Windows. Usamos uma ferramenta chamada Squish da Froglogic, que funciona em um sistema semelhante ao WebDriver, ajustado para o ambiente de desktop. Nesta ferramenta, é utilizada uma abordagem semelhante ao Objeto de Página (do mundo do WebDriver), denominada de maneira diferente - Arquitetura de Elementos Compostos. Os seletores são feitos nos componentes principais (como uma "janela" ou "botão") e as funções que podem ser executadas com esses elementos são registradas. Por exemplo, “clique com o botão direito”, “clique com o botão esquerdo”, “salvar”, “fechar”, “sair”. Então esses elementos são combinados em uma única estrutura,você pode acessá-los dentro do seu script, usá-los, tirar uma captura de tela e comparar.

Problemas e Soluções


O primeiro problema é a estabilidade. Escrevemos testes que testam a lógica de negócios por meio da interface do usuário - qual é o problema? Quando a lógica de negócios não muda, mas a interface muda - os testes caem, você precisa fazer o upload de novas capturas de tela.

O próximo problema é a falta de funcionalidade. Muitos casos de usuários não estão apenas pressionando um botão, mas em interação com o mundo tridimensional. Essa biblioteca não permitia isso, novas soluções eram necessárias.

O terceiro problema é a velocidade. Para qualquer teste de interface do usuário, você precisa renderizar completamente o mecanismo inteiro. Leva tempo, as máquinas para esses testes devem ser poderosas o suficiente.



A solução veio na forma de uma biblioteca Shiboken. Essa biblioteca fornece ligantes do código C ++ no Python, o que possibilita chamar diretamente as funções fornecidas pelo editor ou pelo mecanismo sem renderizar o editor da interface do usuário. Um análogo do mundo da Web - automação sem cabeça (algo semelhante ao PhantomJS) - você pode automatizar um aplicativo da Web sem iniciar um navegador. Nesse caso, um sistema semelhante, apenas para um aplicativo de desktop escrito em C ++.

Após começarmos a investir nessa estrutura, percebemos que ela pode ser usada não apenas para automatizar testes, mas também para automatizar qualquer processo dentro do mecanismo. Por exemplo, um designer precisa colocar 100 fontes de luz seguidas (por exemplo, ele faz uma estrada e você precisa colocar luzes). Em vez de representar manualmente todas essas fontes de luz, você simplesmente escreve um script que cria uma entidade do jogo, adiciona uma fonte de luz pontual e prescreve que a cada 10 metros você precisa copiar a luz de ponto criada anteriormente. Um bônus para nossos usuários na forma de uma ferramenta para automatizar tarefas de rotina.



A segunda parte da solução para o problema. Logo percebemos que, para automatizar várias partes do nosso mecanismo - por exemplo, peças gráficas e de rede - precisávamos de estruturas completamente diferentes. É impossível criar uma estrutura única e monstruosa que ajude a automatizar tudo de uma vez. Portanto, começamos a desenvolver uma estrutura chamada Lumberyard Test Tools (abreviação - LyTestTools). É baseado em Pytest (muitas coisas estão escritas no mecanismo em Python). Decidimos usar a arquitetura chamada Plug-and-play - o grupo central de engenheiros de automação escreve a parte principal da estrutura, que pode baixar, configurar o mecanismo, implementá-lo em várias plataformas, executar testes e coletar logs, fazer upload de relatórios para o nosso banco de dados ou S3 e desenhar gráficos no Quicksight. O plug-and-play é alcançado através do Test Helper,que será escrito por equipes no campo que desenvolve recursos.

Ou seja, a equipe de desenvolvimento de gráficos testará com capturas de tela e a equipe de interação de rede verificará os pacotes encaminhados. Ao mesmo tempo, todos eles serão conectados à nossa estrutura comum (à medida que as duas equipes desenvolvem e testam módulos de um único mecanismo) para que todos tenham as mesmas interfaces para executar testes e gerar relatórios, para que tudo funcione de maneira mais ou menos padronizada e correta com o nosso IC / Cd.

Interação com a Lumberyard


Quais podem ser as formas de interação / automação de um aplicativo de desktop? O primeiro tipo de interação entre a estrutura e o mecanismo - diretamente do Python, o processo é iniciado usando a função Subprocess, se o aplicativo implicar o lançamento pela linha de comando. Você pode ler entrada / saída da entrada / saída padrão e, assim, fazer afirmações. O próximo tipo - essa interação através da análise de logs - você pode ler e analisar os logs deixados pelo aplicativo. O terceiro é através da rede. Nos lançadores de jogos, há um módulo chamado console remoto. Quando uma certa porta está aberta no dispositivo, nossa estrutura pode enviar pacotes / comandos específicos. Por exemplo, faça uma captura de tela ou abra um nível específico. Outro método é a interação através da comparação de informações visuais, ou seja, screenshots.Também mencionado anteriormente foi o método de chamar a funcionalidade do aplicativo diretamente por meio da API do produto (no nosso caso, é uma chamada através de ligações do Python à funcionalidade de editor / mecanismo do C ++).

Vamos passar a exemplos de como usar nossa estrutura para automatizar o mecanismo.

Dê uma olhada nesta captura de tela.



Os detalhes neste site são bastante altos - uma grande quantidade de vegetação. Nos jogos modernos, os níveis podem levar várias dezenas e centenas de quilômetros de jogo. Naturalmente, cada um desses arbustos não é descartado manualmente, caso contrário, os desenvolvedores simplesmente enlouquecem. Para eles, nosso motor possui ferramentas especiais.

Um deles é chamado de ferramenta de vegetação. Pequena demonstração:

Link para o vídeo 32: 18-34: 06

Vemos o início padrão do nível. Há terrane e você pode rapidamente fazer um alívio: ao fundo, faça montanhas, na parte central também destaque uma pequena colina. Você pode pintar o chão de verde com uma textura de grama. O processo de adição de vegetação, neste caso, árvores, é ainda demonstrado. A geometria - árvores é adicionada à ferramenta - um subconjunto é destacado e qualquer desenho necessário pode ser desenhado com essas árvores. Este é um exemplo bastante simples, esta ferramenta possui muitos parâmetros personalizáveis. Por exemplo, você pode selecionar não uma árvore, mas várias de uma vez e definir um parâmetro para elas, permanecer a uma certa distância uma da outra ou definir parâmetros aleatórios para o tamanho ou a rotação dessas árvores. Você pode adicionar um personagem do jogo e executar imediatamente no nível, teste,o que você acabou de cultivar em seu próprio jardim infantil?

Vamos agora ver como automatizamos esse recurso com nossa estrutura usando alguns testes como exemplo.

Link para o vídeo 34: 20-34: 58

Há um terrane padrão e muito do mesmo tipo de grama é cultivado nele. Esse tipo de renderização é muito intensivo para o processador. Se houver muitos desses elementos, você pode fazer um teste de carga. Um script do jogo foi adicionado aqui, que ao iniciar o modo de jogo simplesmente fará um vôo através deste nível. A tarefa é testar essa funcionalidade e verificar se o iniciador de jogos está estável e não falha.



Este é um exemplo de como a equipe que desenvolveu o recurso para o cultivo de vegetação escreveu o Test Helper, que permite trabalhar com esses recursos. Este é um exemplo de uso de nossa estrutura. A classe do iniciador é destacada em verde. Quando o teste é iniciado, o iniciador é implantado, começa com os parâmetros de tempo limite e fazemos uma declaração para verificar se o iniciador não falha depois de um tempo. Então desligamos.



O código de parametrização acima mostra que podemos reutilizar o mesmo código em plataformas diferentes. Além disso, podemos reutilizar o mesmo código em diferentes níveis ou projetos. Por exemplo, as plataformas são destacadas em vermelho: em um caso, é Windows, em outro, é Mac; o projeto é destacado em amarelo; o nível do nome é destacado em amarelo claro.

Link para o vídeo 36: 07-36: 47

Agora, sobre o teste - nesse caso, execute-o na linha de comando. É aberto um programa chamado Processador de ativos, uma das principais partes do mecanismo. Este programa processa os recursos de origem (por exemplo, modelos e texturas criados por artistas) em formatos compreensíveis para o mecanismo e grava tudo no banco de dados (SQLite) para que o mecanismo possa navegar rapidamente e carregar os dados necessários durante o jogo. Em seguida, o iniciador inicia, o modo de jogo inicia, a câmera voa acima do nível por vários segundos e o teste termina. Vimos que um teste foi bem-sucedido e dois foram ignorados. Isso aconteceu porque durante a gravação do vídeo o teste foi perseguido no Windows e na parametrização existem mais duas plataformas que foram respectivamente ignoradas durante este lançamento.



Existe uma opção mais difícil. Não apenas iniciamos o iniciador com o nível finalizado, mas o script interage diretamente com o editor. Azul indica o nome de um script separado que funcionará com o editor e puxará vários comandos pela API.



Acima está o nível de teste. Nesse caso, um sorriso é desenhado no terreno padrão usando uma textura previamente preparada (máscara). É necessário verificar se, ao usar a máscara, a pintura será realizada apenas ao longo de um contorno previamente selecionado e não ultrapassará.



A equipe que trabalha com o mundo dos jogos escreveu sua extensão para trabalhar com a Terrane, que é inserida em nossa estrutura. Um novo pincel é criado, que será desenhado na máscara "Cobblestones", o pincel será definido para vermelho e a camada selecionada será pintada.



Na continuação, um novo pincel é criado, uma intensidade diferente é definida para ele. A máscara não é mais usada e, no ciclo, já em outra parte do nível, um novo elemento é desenhado.

Vamos ver como esse script funciona.

Link para o vídeo 38: 42-39: 35

Primeiro, o Processador de ativos será iniciado, o qual verificará o status do banco de dados de ativos e processará os itens adicionados recentemente, se necessário. Em seguida, o editor inicia. O nível será aberto com um sorriso e será iniciado um script que será executado com o editor. Ele pinta a camada sobre a máscara, cria um círculo azul e começa a tirar screenshots. Posteriormente, as capturas de tela serão comparadas com as de referência e, se tudo estiver em ordem, o teste será concluído.

O teste faz essas capturas de tela para comparação com os padrões. Aqui você pode ver que a imagem foi claramente ao longo da fronteira.

Artes gráficas


Também usamos nossa estrutura para testar gráficos.

Link para o vídeo

Gráficos 40: 04-40: 56 - uma das partes mais difíceis do mecanismo, que ocupa a maior parte do código. Você pode e deve verificar tudo - começando com coisas simples, como geometria e texturas e recursos mais complexos - sombras dinâmicas, iluminação, efeitos de pós-processamento. No vídeo no canto direito, você pode ver o reflexo na poça - tudo funciona em tempo real no nosso motor. Quando a câmera voa para dentro, é possível ver elementos de renderização mais avançados, por exemplo, brilho, elementos transparentes, como vidro, bem como a exibição de elementos como superfícies metálicas. Como essa funcionalidade é testada com capturas de tela?



Este é o nosso personagem, Rin. Com isso, frequentemente testamos os canais de artistas. Os artistas criam algo em seu editor (por exemplo, um personagem) e depois desenham texturas nele. O Processador de ativos processa os dados originais para implantar em várias plataformas, e o mecanismo gráfico lidará com a exibição.



Certamente você costumava encontrar um bug quando "as texturas não eram carregadas". De fato, há muitos problemas quando algo acontece com a exibição de texturas.



Mas todos eles são bem capturados pela comparação de capturas de tela. Na primeira captura de tela, você pode ver um erro - alguns materiais não estão bem carregados. Nestas capturas de tela, o mesmo nível em que a motocicleta estava e a câmera voou dentro do café, como foi mostrado no vídeo anterior. Por que tudo parece tão chato aqui? Porque as capturas de tela não são tiradas na última etapa da renderização, quando o mecanismo gráfico apresenta todos os seus efeitos, mas em etapas. A princípio, apenas a renderização de geometria e texturas simples é obtida: sombras são removidas, elementos de iluminação complexos são removidos. Se você testar tudo na última etapa e observar a Diff Image, será difícil dizer o que exatamente quebrou.



Se você fizer isso por etapas, poderá entender em que parte do mecanismo gráfico algo deu errado. Aqui está o algoritmo pelo qual comparamos as capturas de tela.



Ao comparar capturas de tela, você pode testar gráficos, exibir elementos, texturas, materiais, sombreadores.

Vou dar um exemplo de um bug da versão antiga do nosso mecanismo quando não possuímos essa estrutura.

Link para o vídeo 43: 10-43: 44

Está relacionado ao sistema Vegetação. Depois de adicionar árvores, a parte gráfica começa a desenhar sombras sob elas. É necessário pressionar “Ctrl + Z” (“Cancelar”), as árvores desaparecem e as sombras permanecem. Se você capturar uma captura de tela no início, quando a árvore estiver em pé e depois de clicar em "Cancelar", é fácil capturar esse bug no modo automático depois de comparar com as capturas de tela de referência de Antes e Depois.

Ao comparar as capturas de tela, o pipeline de ativos também é muito bem testado. Quando os artistas criaram algo nos editores 3D (Maya, 3dsMax), é preciso verificar se tudo é exibido no jogo da mesma maneira e nada foi perdido: a galinha tem penas, todos os animais têm pêlos, as pessoas têm a textura de pele correta e outras coisas.

Link para o vídeo 44: 16-44: 52

No lado direito do programa está o Asset Processor, que monitora a exibição no jogo de tudo o que o artista pintou. Ele nos dirá que está tudo em ordem com esses ativos - eles devem funcionar. No vídeo você pode ver que algumas árvores ficaram pretas. Alguns são exibidos normalmente e algumas texturas verdes simplesmente desapareceram. Naturalmente, neste formulário você não pode liberar um mecanismo ou ativos.

Nem tudo pode ser pego


Link para o vídeo 45: 03-45: 17

Alguns tipos de bugs começam a se formar apenas quando vários elementos interagem entre si. Dois modelos Rin são exibidos normalmente se forem removidos um do outro, mas se você os aproximar, os problemas com a geometria começam. Infelizmente, esses erros são difíceis de detectar, mesmo antes da automação. Frequentemente, eles podem ser notados apenas quando os testadores começam a fazer algo no modo de teste exploratório ou quando o mecanismo já cai nas mãos dos clientes.



Ao comparar as capturas de tela, você pode testar a interface do próprio editor.

Componentes do jogo




Além disso, as capturas de tela podem testar alguns componentes simples do jogo. Um exemplo é um nível simples no qual há uma porta e um script que, quando você pressiona a barra de espaço, inicia a porta para abrir e fechar.

Você pode tirar uma captura de tela no início e no final. Se tudo corresponder, o script que altera a localização do elemento funciona corretamente.

URDIDURA


Percebemos rapidamente que as capturas de tela da mesma funcionalidade são muito diferentes em plataformas diferentes; em alguns casos, pode haver diferenças na mesma plataforma, dependendo do tipo de placa de vídeo. Como lidar com isso, para não armazenar 100500 capturas de tela? Existe uma ferramenta, a Plataforma de Rasterização Avançada do Windows é um renderizador de software que permite que você faça todos os gráficos sem recorrer ao driver e à placa de vídeo. Usando esta ferramenta, você pode realizar a maioria dos testes gráficos funcionais sem depender dos drivers e do hardware.

atuação


Por último, mas não menos importante, o mecanismo do jogo deve ser produtivo! As GPUs podem ser testadas usando vários perfis gráficos, como o PIX. A RAM pode ser testada no próprio Visual Studio. Além disso, mais sobre como o desempenho do processador é testado usando a ferramenta RADTelemetry.

Sabe o que é Input Lag?

Link para o vídeo 47: 29-48: 21

Atraso na entrada - esse é o atraso entre pressionar a tecla do controlador / teclado pelo jogador e o momento em que o jogo começa a responder à pressão. O atraso de entrada ocorre devido à transmissão de dados pela rede, quando os pacotes ficam muito tempo ou o servidor responde por muito tempo, assim como nos mecanismos e sem o uso da rede. Quando alguém estraga o código responsável pela animação, o atraso na entrada pode se tornar tão alto que o personagem começa a responder tarde demais. Em uma aproximação simples, isso é testado com bastante facilidade: um teclado virtual é aberto e um vídeo é gravado, no qual o momento de pressionar a barra de espaço e o momento do início da animação são gravados.

Examinamos quantos quadros por segundo o mecanismo está distribuindo. Você pode calcular quanto cada quadro levou em milissegundos (1000 / FPS). Se você reproduzir o vídeo quadro a quadro, poderá calcular quantos quadros passaram desde o clique antes do personagem começar a se mover. Sabendo quantos milissegundos cada quadro ocupa, pode-se calcular que, por exemplo, 200 milissegundos passaram entre pressionar um espaço e o início da animação. Com uma resposta humana padrão de 100 milissegundos, isso é muito lento e os jogadores imediatamente dizem que esse atraso é inútil. Este método de teste tem seus problemas. Em primeiro lugar, haverá erros. Por exemplo, o teclado virtual terá um atraso. Em segundo lugar, nos jogos, os artistas costumam fazer animações para que o personagem não comece imediatamente a fazer o movimento principal. Existe a chamada antecipação: antes da ação principal,por exemplo, pulando, o personagem primeiro se dobra um pouco e só então começa a pular. Isso pode levar alguns quadros. Como lutamos contra isso? Começamos a testar esta parte com uma abordagem mais precisa.

Existe um programa chamado RADTelemetry.

Link para o vídeo 49: 44-50: 47

Ele permite que você crie um perfil do processador. Os quadros verticais estão dispostos aqui: Nº 629, 630 - você pode ver quanto tempo cada quadro levou. Horizontalmente, os núcleos do processador ou os threads de execução do aplicativo são dispensados ​​se o aplicativo for multithread. Se você clicar em qualquer um dos encadeamentos, o nome de todas as funções que estão nesse encadeamento quando foram iniciadas, quanto tempo levaram para serem executadas a partir do total, quantas vezes foram executadas, será exibido à esquerda. Usando este aplicativo, você pode entender com precisão quanto tempo se passou desde o momento em que o jogo registrou o pressionamento de tecla, antes de iniciar a função Reproduzir Animação. Este programa é capaz de colocar seus logs em arquivos de texto e, usando-os, você pode desenhar gráficos de desempenho úteis de diferentes compilações na distribuição de tempo.

E onde está a AWS aqui?


Em conclusão, algumas palavras sobre a AWS. Por um lado, nós o usamos para conduzir nossos testes. Executamos testes no EC2 e em dispositivos do Device Farm. Os resultados são adicionados ao banco de dados no S3 e os gráficos são exibidos no Quicksight. As estatísticas de teste podem ser visualizadas no CloudWatch. Como o mecanismo é altamente integrado aos serviços da AWS, também testamos essas integrações - manual e automaticamente. Por exemplo, o CloudCanvas é um serviço que permite criar funcionalidades para jogos em rede sem programação, ou seja, no servidor, você pode simplesmente configurar chips como placares de líderes, tabelas de pontuação e conquistas. Para coisas como monetização de jogos, você não pode procurar o programador do servidor, mas comece imediatamente a usar o CloudCanvas. O Amazon GameLift é essencialmente um sistema escalável para servidores de jogos.Integração com o Twitch - quando os usuários assistem à transmissão de dois jogadores que competem entre si. Uma pesquisa do Twitch é criada: "Qual jogador você apoia?" - as pessoas começam a votar no bate-papo, o jogo lê as respostas e um dos jogadores (como nos Jogos Vorazes) pode perder um bônus extra ou impedi-lo.

Sumário


A primeira coisa que percebemos é que, em projetos tão grandes, não existe uma única bala de prata com a qual você possa automatizar tudo. No nosso caso, a estrutura Plug-and-play funcionou bem. Criamos uma estrutura comum e permitimos que o restante das equipes incorporasse convenientemente suas soluções. Usando exemplos de capturas de tela e comparação de vegetação, o sistema mostrou como essas estruturas funcionam. Espero que alguns aplicativos e soluções industriais (como Software Renderer da Microsoft ou RADTelemetry.) Fornecidos neste artigo sejam úteis para a prática de engenheiros que trabalham em jogos ou sistemas CAD.

Em conclusão, links para todas as ferramentas mostradas no relatório:



Espero ter conseguido dizer como o teste de motores difere do teste de jogos. Recentemente, o processo avançou muito - testar os mecanismos de jogos não é nada simples, mas é muito interessante.

Se você estiver interessado no tópico de teste de jogos, recomendamos que você analise outros relatórios:

More articles:


All Articles