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.