Teste automatizado de jogos [fechado]

54

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.

fatia de limão
fonte

Respostas:

74

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.

ZorbaTHut
fonte
11
Realmente liso! Sim, o keylog é pura vitória.
David McGraw
11
Estou confuso: "montando algumas IAs idiotas básicas" e "gravando teclas pressionadas" - quem pressiona as teclas? Eu pensei que você deixasse sua IA jogar sozinha sem humanos? Você realmente deixou sua IA jogar o jogo simulando pressionamentos de tecla em vez de chamar funções de API? Agora isso seria liso!
Dave O.
4
@ Dave Sim, eu admito que é potencialmente confuso. As AIs foram projetadas para fornecer toda a sua saída através de controladores simulados. Eles tomaram o estado do jogo como entrada, mas não modificaram o estado do jogo de nenhuma maneira. Provavelmente, essa seria uma ideia horrível com a interface do usuário do mouse, mas toda a interface era feita com gamepads, por isso era um pouco feia, mas funcional. Gravei as teclas virtuais das IAs e, além disso, o mesmo código registrou as teclas reais ao testá-las com os amigos.
ZorbaTHut
32

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:

  • Testes básicos durante nosso processo automatizado de compilação foram uma grande vitória. Isso incluía tarefas como criar um personagem, transferir mapas, executar alguns testes de interface do usuário com script e procurar o comportamento esperado. Isso capturou um grande número de bugs antes que eles chegassem ao resto da empresa.
  • No final da infraestrutura do servidor, desenvolvemos vários testes automatizados diferentes que simulavam transações típicas do servidor MMO. Poderíamos então reproduzi-los em várias circunstâncias para comparar o desempenho ou garantir a segurança. Com o tempo, esses testes se tornaram cada vez mais precisos até se tornar uma reprodução de dados gravados ao vivo
  • Escrevemos um "jogador falso" que percorria o mundo aleatoriamente, pulava, matava coisas e dizia coisas aleatórias no bate-papo. Isso encontrou um grande número de problemas de física e infraestrutura.

O que não funcionou:

  • Tentamos adicionar alguns testes automatizados orientados ao combate muito específicos ao construtor automatizado, mas isso basicamente nunca funcionou. Ele funcionaria por cerca de três dias após a implementação, até que um designer ou artista alterasse alguma coisa e o teste falhasse, acionando os alarmes com falha na compilação. 90% das vezes não era um problema real. Esses testes eram muito frágeis e, na verdade, testar a jogabilidade específica em um mapa específico com poderes específicos pode ser impossível de manter.
  • Tentamos implementar um teste de desempenho automatizado que comparasse o desempenho do cliente (FPS médio, etc.) com o desempenho registrado de uma semana atrás. Isso também foi bastante frágil, pois as demos que usamos para isso tendem a apodrecer com bastante frequência, e era difícil verificar se uma desaceleração foi causada por uma perda real no desempenho ou algum efeito colateral do processo de teste.
Ben Zeigler
fonte
18

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".

PhillC
fonte
Hum, eu não pensaria nisso como testes automatizados - mas acho que você está certo. Faço a mesma coisa há alguns anos, mas nunca pensei nisso dessa maneira.
mmyers 18/07/10
13

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.

kevin42
fonte
8

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.

tenpn
fonte
6

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:

  • Testes automatizados melhoraram a estabilidade das entregas, aumentando a produtividade para criadores e engenheiros de conteúdo
  • O teste automatizado é uma ferramenta eficaz para melhorar a qualidade do código e reduzir as chances de ter que trabalhar horas extras
  • A indústria de jogos como um todo é muito reacionária em geral, os testes automatizados atendem a vários argumentos irracionais contra
  • Não chame isso de teste, chame de outra coisa, quase qualquer outra coisa (veja Behavior-Driven-Development)
  • Seja flexível, escrever bons testes é difícil e exige habilidades que não estão amplamente disponíveis na indústria de jogos
Francesco Carucci
fonte
2

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.

Ed Ropple
fonte
9
Mas os jogadores nunca fazem o que você esperaria que uma pessoa sã fizesse. É por isso que você não vê coisas como as falhas do elevador em Call of Duty até depois do lançamento. Porque existem milhares de pessoas fazendo coisas que os desenvolvedores e os testadores nunca pensaram em tentar. Assim que alguém cria a simulação perfeita de um jogador obsessivo-compulsivo 16 anos vamos ter alcançado o desenvolvimento singularidade jogo :)
Casey Wagner