A indústria de jogos usa testes automatizados para partes visuais de jogos / renderizações? Como?

Algumas partes de um jogo são fáceis de testar de maneira automatizada (lógica, matemática, manipulação de entradas); mas também há muito que é puramente visual e não é facilmente testável.

Eu ficaria surpreso se a indústria de jogos deixasse tudo isso para testes manuais; há dinheiro suficiente para eu adivinhar que foi feito um esforço para ser capaz de testar de regressão pelo menos algum aspecto visual dos jogos.

Isso é verdade? Em caso afirmativo, quais são as formas possíveis de testar a renderização de jogos? Captura de saída e comparação de imagens (isso pode ser confiável?)? Interceptando dados da placa gráfica em um nível baixo? Capturar informações vértice (etc.) em seu caminho para a placa gráfica? Parece que existem muitas possibilidades; mas não consigo encontrar nenhuma informação sobre isso :(

Nota: Esta pergunta foi marcada como uma bobagem desta , mas não estou perguntando sobre estruturas / ferramentas / técnicas específicas sobre como fazer isso, mas de maneira mais ampla as idéias em torno dessa prática e o que a indústria de jogos real faz (se eles fazem).

unit-testing testing game-development

— Danny Tuppeny
fonte

Eu diria que provavelmente eles usam apenas uma biblioteca gráfica bem testada (de terceiros ou desenvolvida internamente). Quando eles começam a projetar um nível de jogo, eles não verificam se todos os objetos estão exatamente nas coordenadas X, Y, Z ou se a perspectiva está correta, mas coisas mais simples, como garantir que os objetos estejam lá e não sejam bloqueados por paredes, etc. E se a biblioteca de gráficos for desenvolvida internamente, os testes serão automatizados e mais básicos.

— SJuan76

@ SJuan76 Eu acho que se você está construindo em cima de um motor, a questão aplica-se ao teste do motor

— Danny Tuppeny

Esta questão não é um pouco mais abrangente do que aquela em que foi marcada como duplicata? O OP não mencionou C ++ ou OpenGL. A indústria de jogos é maior que isso.

— toniedzwiedz

Provavelmente é mais fácil provar formalmente que o código está correto, uma vez que as APIs gráficas estão livres de erros do que testar o hardware está fazendo seu trabalho. Como os drivers da AMD e da NVidia são proprietários, imagino que qualquer protocolo envolvido na comunicação com a placa gráfica seja 1) proprietário, 2) sujeito a alterações e 3) varie de placa para placa. Além disso, mesmo que os dados enviados para a placa gráfica estejam corretos, como você sabe que a placa gráfica não possui uma falha de hardware?

— Doval

Tentei reabrir isso, já que o alvo dupe era mais especificamente sobre estratégias em testes automatizados de gráficos OpenGL. Essa não é minha especialidade, mas confio no feedback de outras pessoas que conhecem muito bem a indústria de jogos, então quero dar outra chance. Para referência a uma pergunta semelhante, consulte aqui: programmers.stackexchange.com/questions/150688/…

— maple_shaft

Qualquer empresa fará de maneiras diferentes, até jogos diferentes serão testados de maneira diferente.

Talvez a falta de informações sobre gráficos seja porque a renderização é realmente "repetitiva" (não consigo pensar em uma palavra melhor, desculpe) e em uma cena complexa típica haverá combinações primitivas suficientes para que a maioria das pessoas possa ver facilmente a maioria das falhas ( com exceção dos shaders menos usados, mas pode ser usado um nível / demonstração especial de stress-shader). Lembre-se de que os humanos eram caçadores há milhares de anos :) então provavelmente somos projetados para ver falhas.
Além disso, a liberdade de movimento presente na maioria dos jogos e a randomização de outros elementos em um jogo típico que a faz parecer mais "realista" costumam ser um pesadelo para a aplicação de testes automatizados puros: na verdade, um testador humano encontrará mais rapidamente e mais erros do que qualquer teste automatizado. Você pode codificar uma lógica para tempos de registro, estatísticas e posições / ângulos / outras variáveis sempre que um testador estiver tocando ... assim, mesmo em testes não automatizados, você terá feedback como testes automatizados. Geralmente, é útil ser capaz de reproduzir qualquer sessão gravada do testador beta (e geralmente também é um bom recurso para o jogo final).
Sobre estatísticas de renderização, por exemplo, você pode obter: as estatísticas de contagem de chamadas para cada um dos shaders (como você fará as chamadas, é suficiente para manter alguns contadores), o carregamento conta (o mesmo, você controlará quando Os buffers da GPU são atualizados), os tempos (não apenas os fps, também os intervalos entre cada chamada), etc. Se necessário (mas acredito que isso não é recomendado, exceto ao procurar um erro específico), você pode obter estatísticas da própria placa gráfica (por exemplo, você pode obter taxas de preenchimento e outras usando consultas de oclusão).
Finalmente, outro motivo para usar os testadores beta é que diferentes placas gráficas provavelmente terão comportamentos diferentes ... talvez você precise ter um conjunto de máquinas de teste o_O. Os amados testadores beta humanos suavizarão toda essa bagunça.

Espero que ajude!

Exoneração de responsabilidade: Eu não sou um apostador, sou um desenvolvedor XDDD.

— user1039663
fonte

Concordo plenamente que os seres humanos são projetados para ver padrões, falhas ... Somos realmente seres visuais.

— Trilarion