Os testes de software são diferentes quando estamos lidando com o desenvolvimento de jogos?

Eu estava lendo este artigo sobre as diferenças entre desenvolvimento de software em geral e desenvolvimento de jogos, e os autores fizeram alguns pontos positivos em relação ao teste de software, apontando, por exemplo, que

... os desenvolvedores de jogos hesitam em usar testes automatizados devido à rápida obsolescência desses testes em face da mudança dos desejos criativos dos designers de jogos.

Então, essa leitura me fez pensar, que outros aspectos nos testes de software devemos considerar diferentes ou particulares quando estamos lidando com / testando um jogo? Alguém tem experiência com isso ou alguém ouviu algo mais sobre isso?

Os jogos modernos são, na verdade, uma tonelada de conteúdo de arte criativa desenvolvido usando um mecanismo de jogo interno ou proprietário. O próprio mecanismo é testável por unidade na maior parte (renderização, geometria, física, módulos de IA etc.). Da mesma forma, testes simples também podem ser anexados a partes individuais do conteúdo desenvolvido. Isso significa que o teste de unidade e caixa branca é realmente viável e bem-sucedido.

No que diz respeito ao "produto como um todo", um jogo é uma simulação. Pode ter uma complexidade mais generativa do que um simples programa de negócios. Pense em mundos gerados sem fim, únicos e processuais, em comparação com um planejador de recursos empresariais com comportamentos bem planejados e contáveis. Simplificando, o número de possíveis maneiras únicas de fazer algo no contexto de jogos pode ser matematicamente, muito, muito grande. Na verdade, é considerado um ponto de venda de jogos.

Acrescente a isso o fato de que a saída final é puramente audiovisual e não existe um padrão determinístico de exatidão absoluta dessa saída. Os chips de GPU realmente não precisam executar cálculos precisos, apenas muitos cálculos, mesmo que alguns não sejam precisos.

E, finalmente, o objetivo principal é entretenimento . Os jogadores concordam com falhas se rodarem mais de 60 FPS, parecem incríveis e têm inúmeras horas de conteúdo divertido.

Isso simplesmente coloca as idéias tradicionais de teste de caixa preta automatizada na região "não tão tangível e que vale a pena" quando aplicada aos jogos.

No entanto, houve tentativas recentes de treinar NNs para jogar , o que é efetivamente uma forma de teste de macaco exploratório e de auto-aprendizagem.

Já se passaram muitos anos desde que eu jogueiev, mas, além da boa resposta, há algumas coisas que quero adicionar e detalhar.

O primeiro já mencionado é que a saída é apenas visual e auditiva contra restrições "críticas ao FPS" e orçamentos computacionais / de memória. As idéias de correção ficam embaçadas quando as perguntas são mais como "Parece bom? Corre sem problemas, sem gaguejar? Parece ótimo?" enquanto os desenvolvedores estão aprimorando, ajustando e aproximando, enquanto as colaborações designer / dev levam a coisas que parecem e soam ligeiramente diferentes a cada iteração rápida.

Outra é que os testadores podem ser incríveis! Nunca encontrei um grupo de testadores mais dedicado em nenhum outro domínio, pois eles desejampara testar o software. Eles estão se divertindo. Eles são viciados e dormem ao lado do computador enquanto exploram todos os cantos do seu jogo. Torna-se bastante fácil descobrir até as falhas mais obscuras quando as pessoas se divertem realmente testando minuciosamente todos os cantos do software enquanto são praticamente viciadas nele. No meu setor atual, os testadores são um pouco mais difíceis de trabalhar, já que muitos deles são profissionais que vinculam seus meios de subsistência ao software e, portanto, confiam em vários recursos para realizar seu trabalho e não estão necessariamente interessados ​​em esgotar todos os cantos e recantos o tempo todo. Naturalmente, quando não podemos confiar tanto em testadores humanos, precisamos de testes mais automatizados.

Ainda outro é que a base de código de um jogo normalmente não é mantida, modificada e estendida por anos e anos. Não é como se os desenvolvedores de Super Mario, que originalmente o desenvolveram na montagem 6502, tivessem que manter algo parecido com o código original muito tempo depois do lançamento do jogo. Doom 3 provavelmente usa zero linhas de código (ou fecha) do Doom 1. Se houver uma franquia contínua, os jogos mais recentes são mais como "sequelas" do que "atualizações". A maioria dos jogos é lançada e talvez libere alguns patches, DLCs e, em seguida, o código está pronto. Esse é um grande contraste da minha indústria de efeitos visuais, onde trabalhei na manutenção de códigos que remontam aos dias de Amiga, portados e mantidos por décadas. Jogos normalmente não

Uma das razões para essa natureza de curta duração das bases de códigos de jogos é que elas estão tão ligadas ao hardware. Quando combinados com sua natureza de ponta e requisitos críticos de FPS, eles geralmente não podem ser desenvolvidos de uma maneira que abstraia detalhes de hardware, nem mesmo perto. Geralmente, eles são escritos de maneira muito específica para a geração de hardware alvo, e geralmente não demora muito para que o PS3 seja substituído por um PS4, que se torna obsoleto e substituído por um PS5, e assim por diante, e tudo muito rapidamente. Os recursos de hardware desempenham um papel tão importante no design e desenvolvimento do jogo que geralmente não vale a pena tentar manter muito do mesmo código escrito para o PSX e para o PS4, por exemplo, a maioria das franquias de jogos que duram gerações ainda escrevem seus motores de última geração em grande parte do zero para o hardware mais novo.

Com uma base de código de curta duração, chega um tempo limitado de manutenção (ou seja, um tempo limitado no qual o código precisa ser modificado). Com um tempo limitado para a alteração do código, que não se estende por anos, com o escopo do mecanismo cada vez maior a cada atualização e combinado ao fato de que os jogos não são nem um pouco críticos, não existe necessidade crítica de aplicar os testes mais exaustivos de unidade e integração. Não há nenhum benefício em fazer isso para garantir a integridade de futuras alterações, caso não sejam feitas alterações futuras, e o aspecto de teste e refatoração de unidades de bases de código herdadas é naturalmente irrelevante se não houver "herdado" em primeiro lugar.

Outro pequeno que nem sempre é relevante é que um jogo pode ter como alvo apenas uma gama muito estreita de hardware sem portas de desktop. Nesses casos, uma enorme fonte de falhas imprevisíveis nesses contextos, que são os usuários que executam o software com hardware e drivers radicalmente diferentes, é eliminada.

Dito isso, o teste de integração no nível mais alto / mais grosseiro tende a ser mais útil imediatamente. Por exemplo, muitos jogos podem utilizar uma maneira de registrar como o estado do jogo está mudando ao longo do tempo por "replays". Esses recursos de reprodução podem garantir que o jogo seja determinístico e também ser usado como uma forma de ferramenta de teste para reproduzir novamente uma sessão de jogo gravada anteriormente por outra pessoa.

Também encontrei gamedevs trabalhando em pequenos estúdios que faziam coisas como escrever bots para o jogo deles e os fazia jogar na velocidade máxima e executavam a simulação, encontrando originalmente uma falha obscura depois de um dia ou dois, depois a consertavam e depois executou a simulação novamente e repetiu até que não houvesse mais falhas de parada de programa, mesmo depois de executá-la por semanas a fio. Portanto, existem tipos interessantes de abordagens pragmáticas como a que eu já vi nos gamedevs para testar seu software, mas geralmente de maneiras que se assemelham ao nível mais grosseiro de testes de integração e simulam as coisas muito de perto com a forma como os jogadores realmente interagem com o jogo.

Finalmente, esses grandes mecanismos de jogos AAA estão começando a se parecer com um tipo totalmente diferente de animal: vida mais longa, abstraindo com sucesso o hardware um pouco melhor, com bases de código maiores e períodos de manutenção mais longos, enquanto seus editores de nível começam a se parecer com ambientes de desenvolvimento completos. Eu imagino que esses grandes mecanismos provavelmente exigiriam procedimentos de teste mais detalhados, especialmente se o tempo em que o código for mantido se expandir consideravelmente. Ainda assim, muitos estúdios de jogos não escrevem grandes mecanismos de jogos AAA: eles os licenciam ou desenvolvem um pequeno mecanismo proprietário que é consideravelmente menor em escopo e não será mantido por anos.