Existem métodos de teste automatizado de jogos?
Experiências específicas são apreciadas, com informações relevantes sobre o projeto, como plataforma e tipo de jogo, se isso ajudar no esclarecimento.
Existem métodos de teste automatizado de jogos?
Experiências específicas são apreciadas, com informações relevantes sobre o projeto, como plataforma e tipo de jogo, se isso ajudar no esclarecimento.
Respostas:
Jogo independente para uma pessoa. Era um jogo de tanque multiplayer com terreno destrutível, e o terreno destrutível e o código de colisão se mostraram um tanto esquisitos.
Acabei criando algumas AIs idiotas básicas (por "idiota", quero dizer "absolutamente idiota" - eles escolheriam aleatoriamente "dirigir em direção a um tanque inimigo", "dirigir para longe de um tanque inimigo" e "dirigir em uma direção aleatória ", enquanto dispara aleatoriamente a arma principal) e joga o jogo com a taxa de quadros máxima enquanto grava as teclas pressionadas. Eu tenho 10-15x em tempo real. O código foi fortemente declarado; portanto, se algo desse errado, despejaria todo o log de pressionamento de teclas em disco, juntamente com um relatório de erro e a semente aleatória inicial. Eu poderia então reproduzir o log de pressionamento de tecla para duplicar exatamente o estado ou simplesmente depurar no relatório de erros.
Deixei-o funcionando constantemente por literalmente meses. No começo, raramente levava uma hora sem bater - eu tinha que ficar sentado lá e tomar conta dele por uma semana, matando vários bugs obscuros por dia. Eventualmente, chegou ao ponto em que estava rodando por uma semana entre falhas, o que se traduz em cerca de 1500 horas de jogador por acidente.
Foi inestimável e eu recomendo vivamente.
Para um MMO em que trabalhei (100 desenvolvedores, focados em PC), tentamos adicionar uma enorme variedade de testes automatizados com sucesso variável. Aqui está o que funcionou:
O que não funcionou:
Trabalhando em um jogo de estratégia 4x com combate em 3D (acho que o Homeworld encontra o Masters Of Orion) que infelizmente nunca viu a luz do dia enquanto a empresa ficava sem fundos.
Eu sempre garanti que você pudesse jogar o jogo sem jogadores humanos, para que pudéssemos deixar o jogo funcionando da noite para o dia.
Poderíamos desligar o combate em 3D (simplificado para um resultado aleatório) e deixamos o mecanismo de estratégia da IA jogando sozinho. Isso encontrou vários bugs e problemas. Não apenas mostra os erros de parada, mas os de estratégia, onde as estratégias de IA (por exemplo) ficariam em um impasse e passariam milhares de turnos sem fazer "a coisa certa". Esses tipos de bugs eram difíceis de detectar apenas "jogando o jogo".
Em um jogo de tiro em primeira pessoa em que trabalhei (Descent 3 - linux / mac / windows, ~ 30 pessoas na equipe em 1999), o recurso de gravação / reprodução demo acabou sendo extremamente útil. Optei por reproduzir a demo o mais rápido que o jogo podia renderizar quadros, e isso se tornou uma ótima maneira de verificar o desempenho depois que várias coisas mudaram.
Ele também exerceu grande parte do código além do sistema de renderização, por isso foi uma boa verificação de sanidade. Depois de fazer várias mudanças, eu poderia executar a reprodução demo de 10 minutos de jogo. Muitas vezes, ele pegava um bug em uma área que eu nem pensava em me controlar.
Tínhamos um shooter de mundo aberto (x360, PS3, PC) que usava um teste rápido de fumaça no servidor de compilação - carregava o jogo, passava pelo front end, corria o [avatar] para a frente, despejava uma captura de tela e saía. Se o cctray detectou a saída limpa, a compilação foi um sucesso.
Executamos o projeto no último ano do projeto e com um tamanho de equipe de ~ 100 desenvolvedores.
Foi eficaz na captura de bugs, mas foi fácil criar uma compilação que passasse dos níveis mais smoketest, mas falhasse na maioria dos níveis "reais", ou não funcionasse no modo multiplayer ou agredisse a IA, por isso não era perfeita. Definitivamente valia a pena fazer.
Ouvi dizer que, desde que saí, eles começaram a executar uma variedade maior de testes de fumaça, distribuídos em vários PCs. Aparentemente, manter os testes de fumaça é um problema, e há uma pequena equipe dedicada apenas a manter os servidores de compilação e o software mantidos, então não posso dizer se isso foi um sucesso ou não.
Minha experiência com o teste automatizado durante o desenvolvimento do Crysis 2 está disponível aqui: http://yetanothergameprogrammingblog.blogspot.com/2010/06/aaa-automated-testing.html
Resumo:
O desenvolvimento de jogos é realmente um daqueles casos em que o teste de unidade parece fazer algum sentido para mim, porque as interações entre sistemas discretos são muito comuns. O projeto por contrato é, obviamente, parte disso, e deve ser planejado desde o primeiro dia de desenvolvimento, mas não vejo por que não foi possível implementá-lo posteriormente, assumindo os meios para isso existir.
A parte difícil é, obviamente, o teste de integração. Muitos jogos podem ser testados apenas com um loop de demonstração ou algo assim, mas esse material é conceitualmente fácil de depurar - onde eu estaria mais interessado em gastar meu tempo expondo bugs que acontecerão quando um jogador fizer alguma coisa, com a mentalidade de que um erro que o jogador nunca vê é obviamente menos importante do que um erro que o jogador vê.
O que é bastante difícil, obviamente. As táticas que funcionam em outros aplicativos (difusa, passagem esperada / falha esperada etc.) não funcionam tão bem aqui. Em sistemas com scripts, parece que construir um conjunto de scripts de teste para simular um jogador é o caminho a seguir (consulte a resposta do JZig). Mas testar especificamente coisas que um jogador pode encontrar me parece diretamente o melhor lugar para focar seu tempo, tanto para fins humanos quanto para testes automatizados.