O Desenvolvimento Orientado a Testes é viável no desenvolvimento de jogos?

23

Como sendo certificado pelo Scrum, tenho tendência a me basear em metodologias ágeis ao desenvolver um sistema e até mesmo usar algumas telas da estrutura do Scrum para gerenciar meu trabalho diário.

Além disso, estou me perguntando se TDD é uma opção no desenvolvimento de jogos, se é viável?

Se eu acredito nessa pergunta GD, TDD não é muito útil no desenvolvimento de jogos.
Por que o MVC e o TDD não são mais empregados na arquitetura de jogos?

Eu venho da programação industrial em que grandes projetos com grandes orçamentos precisam funcionar perfeitamente, pois isso pode resultar em cenários catastróficos se o código não for testado completamente por dentro e por fora.

Além disso, seguir as regras do Scrum incentiva o cumprimento das datas de vencimento do seu trabalho, enquanto todas as ações no Scrum têm um prazo determinado! Então, eu concordo quando, na pergunta acima, eles dizem para parar de tentar criar um sistema e começar a escrever o jogo. É exatamente o que o Scrum diz: primeiro tente não construir o sistema perfeito: faça-o funcionar até o final da Sprint. Em seguida, refatorar o código enquanto trabalha no segundo Sprint, se necessário!

Entendo que, se nem todos os departamentos responsáveis ​​pelo desenvolvimento de jogos usam Scrum, o Scrum se torna inútil. Mas vamos considerar por um momento que todos os departamentos usam Scrum ... Eu acho que o TDD seria bom para escrever código sem erros, embora você não queira escrever o sistema / jogo "perfeito".

Então, minha pergunta é a seguinte:

O TDD é viável no desenvolvimento de jogos?

architecture software-engineering methodology testing test-driven-development Will Marcouiller
fonte
O que a discussão desta questão vai adicionar além da questão que você vinculou?
Apresento a estrutura do Scrum de gerenciamento de projetos no desenvolvimento de software Agile e discuto o que o Scrum deseja de um desenvolvedor durante um Sprint, tornando o TDD viável como uma opção. Quero obter o ponto de vista dos outros sobre o assunto do ponto de vista do Scrum, não apenas sob o aspecto TDD ou MVC. Eu quero entender como o TDD não é viável quando discutido deste lado da medalha, além de considerar o próprio TDD como uma abordagem independente.
Marcouiller
@Will TDD == Projeto de cima para baixo ou projeto orientado a teste? Eu estava pensando Top Down e estava indo para dar uma resposta de gerenciamento, a longo prazo, mas, em seguida, viu a outra resposta foram interpretar TDD de uma maneira que não era ...
James
@ James: Desenvolvimento Orientado a Testes.
caos
@ James: Desculpe pela confusão! Eu não sabia sobre o outro significado da sigla, pois o que eu tinha em mente era Desenvolvimento Ágil de Software com Scrum.
Will Marcouiller

Respostas:

11

É certamente viável, embora muitos programadores de jogos ainda não tenham entendido a idéia ainda, ou tenham um bom entendimento de como testar sistemas complicados. Eu admito que raramente o uso, exceto em sistemas não relacionados ao jogo que são fáceis de testar.

Espere usar muitos objetos simulados. Devido à interligação de muitos sistemas, é difícil testar componentes individuais disso.

Além disso, muitas coisas não podem ser exaustivamente testadas. Como você testa, digamos, um sistema de partículas? Como você testa se seu sistema de animação está funcionando corretamente? Muitas coisas são de natureza visual e não são óbvias (pelo menos para mim) sobre como fazer testes adequados.

No entanto, existem muitas coisas que não são necessariamente testes de unidade no sentido tradicional da palavra, mas existem como "testes" para recursos específicos. Coisas como níveis de teste para navegação de IA são bastante comuns, mas não são necessariamente as coisas mais fáceis de automatizar.

Existem certos aspectos dos jogos que podem (e provavelmente deveriam) ter testes de unidade escritos para eles. Qualquer tipo de sistema genérico de "leitura de arquivos" deve ser testado. Talvez tenha alguns testes para inicialização de itens de hardware (superfícies 3D, etc). Talvez tenha alguns servidores simulados e teste seu código de interação cliente / servidor. Coisas assim.

Tetrad
fonte
9
Essas são ótimas propostas para a presença de testes automatizados, mas não para o desenvolvimento orientado a testes.
1
Opinião interessante, Tetrad! Obrigado pelo seu grão de sal. Você pergunta como testar a animação visual? Difícil dizer quanto aos sistemas 3D, já que nunca escrevi um único jogo, talvez depois de alguns terem desenvolvido alguns minúsculos jogos! Além disso, em 2D, eu sempre vi objetos representados por matriz e analisadores de matriz para renderizar a imagem na tela. Portanto, certifique-se de que, depois de pressionar alguma tecla direcional, as informações corretas sejam encontradas no lugar certo na matriz resultante, eu acho. Ainda não sei o suficiente sobre os componentes visuais de um jogo, e com certeza ainda este ano! =)
Will Marcouiller,
Estou de volta, depois de alguma codificação, para dizer que respondi a uma pergunta esta semana (minha primeira no GD! =)) Que exigia conhecimento dos conceitos de POO. O OP queria mudar uma cobra em cima Keys.Down, Keys.Leftetc. Isso quer dizer que o jogo sabe onde o usuário deseja a cobra para ir, e a cobra tem que ir onde o jogo diz-lhe para, no entanto, que é apenas a serpente que sabe para se mover nas diferentes direções, daí também sua posição no jogo. Tendo dito isso, IMHO, torna a Snakeclasse testável! (Para ser continuado ...)
Será Marcouiller
Não só é testável, mas agora é um bom candidato para TDD. Digamos que a cobra seja inicializada na posição Vector2.Zero, com uma velocidade 10.0fnos eixos X e Y neste jogo 2D. A primeira pergunta é: está posicionado em sua suposta posição inicial e como testá-lo? Então, você acha que a Positionpropriedade deve ser exposta publicamente. Segundo: como fazê-lo se mover? Métodos de movimento deve ser bom, para que escrever um teste para cada método de direção MoveDown, MoveLefte assim por diante. Agora, escreva a sua declaração de método e veja se o teste se queixa. Então, reverificar posição da cobra
Will Marcouiller
após uma MoveDownchamada de método! Como você sabe que a Positionpropriedade foi completamente testada, é um membro com o qual você pode contar! Você pode adivinhar a continuação aqui! ;-) Isso quer dizer que os componentes visuais definitivamente não podem ser testados, mas a cobra deve se parecer com uma cobra, tudo dependendo do tipo de cobra que você deseja no jogo. O artista que desenha a cobra deve demonstrar satisfação suficiente com o desenho da cobra, que não deve ser testado através do TDD, é claro! Mas sua posição em relação a outros objetos pode, e a classe que representa essa cobra também. De fato, TDD
Will Marcouiller
11

Eu não acho que o TDD, como tal, seja apropriado como base para o desenvolvimento de jogos. Testes de unidade automatizados como parte da metodologia, com certeza, mas muitas das principais preocupações do desenvolvimento de jogos são subjetivas e não podem ser testadas em máquinas para que os testes sejam o condutor do desenvolvimento. Como você vai escrever um teste de script para saber se uma mecânica de jogo é divertida? Que um nível é visualmente atraente? Mesmo que um nível leve um jogador típico em torno de 15 minutos para ser concluído? O TDD se encaixa em situações nas quais a maturidade de um projeto pode ser medida quantitativamente em termos de conformidade com uma especificação, e isso simplesmente não é desenvolvimento de jogos.

caos
fonte
3
O que você quer dizer quando diz que o desenvolvimento de jogos não está em conformidade com as especificações? Meu argumento é que você deve saber que tipo de jogo você escreve quando deseja escrever um. Como tal, especificações, requisitos devem ser escritos como características ou similares; vamos dar um exemplo do Backlog do produto no Scrum. Você conhece as histórias de usuário que precisará desenvolver no seu jogo para escrever o jogo esperado! Então, para outro exemplo, talvez você precise detectar colisões em um jogo de luta, essas são coisas testáveis! Se o jogo é divertido é mais da história ou do que programação, IMHO.
Will Marcouiller
@ Will Marcouiller: não quero dizer que não temos especificações ou não podemos medir a conformidade com elas, mas menos do que é importante sobre o projeto pode ser especificado de maneira significativa do que em outros tipos de desenvolvimento. Você pode escrever "o jogo deve ser divertido" nas suas especificações, mas essa não é uma especificação com significado técnico. Você pode e deve testar o que é testável, mas o objetivo do TDD é que o teste não é apenas parte do processo, é toda a base do processo, uma mentalidade fundamental, e eu não vejo isso de graça. campo subjetivo.
caos
2
@Will Marcouiller, eu discordo muito que a diversão do jogo se resume à história. Toda a diversão do jogo se resume à jogabilidade, a história é apenas um bônus.
AttackingHobo
1
@ Will: Não, ele está dizendo que o prazer que um usuário obtém de um jogo não pode ser determinado por teste automatizado, e que os jogos têm grandes quantidades de coisas que só podem ser testadas enviando o jogo para as mãos do consumidor.
DeadMG
1
@DeadMG: Isso é mais verdadeiro do que qualquer um gostaria, mas meu argumento (não necessariamente do AttackingHobo) envolve o fato de que o próprio processo de desenvolvimento precisa incorporar testes, por designers e produtores, desenvolvedores e testadores, que não podem ser quantificados em uma unidade teste, que tem a ver com a qualidade da experiência, sensação, estilo e efeito estético que o jogo cria. Dizer às pessoas que estão fazendo TDD quando essa é uma parte tão importante do desenvolvimento é basicamente mentir para elas.
caos
6

É um pouco difícil descobrir exatamente o que você está perguntando, já que o título é puramente sobre TDD, mas você parece estar fazendo do Scrum parte integrante da pergunta também - e, pelo que entendi, uma não exige a outra.

Se eu acredito nessa pergunta GD, TDD não é muito útil no desenvolvimento de jogos.

Está correto. Acho que nunca ouvi falar dele usado na prática na indústria de jogos. (Mas também nunca ouvi falar dele usado fora da indústria de jogos - apenas por indivíduos.)

Eu venho da programação industrial em que grandes projetos com grandes orçamentos precisam funcionar perfeitamente, pois isso pode resultar em cenários catastróficos se o código não for testado completamente por dentro e por fora.

Os jogos não precisam funcionar perfeitamente. Portanto, há muito menos ênfase na correção do código. O TDD não garante a correção do código, mas algumas pessoas acham que isso reduz a correção. Ainda estou para ver a prova disso.

Além disso, seguir as regras do Scrum incentiva o cumprimento das datas de vencimento do seu trabalho, enquanto todas as ações no Scrum têm um prazo determinado!

Eu nunca vi uma metodologia que não incentivasse o cumprimento de datas de vencimento ou a realização de ações que não eram pontuais. O problema é que, independentemente da metodologia usada, estimar a complexidade do software é bastante difícil. Não é impossível, mas estimar com precisão não tem muito a ver com o processo. Se minha tarefa é adicionar um novo painel da GUI, ou corrigir um erro na animação ou adicionar uma nova estatística aos caracteres, o uso do Scrum não vai acelerar isso, e o uso do TDD será para retardar a tarefa (com o possível benefício de reduzir mais tarefas de manutenção posteriormente). Eles certamente não facilitarão a estimativa da duração da tarefa.

Eu acho que o TDD seria bom para escrever código sem erros, embora você não queira escrever o sistema / jogo "perfeito".

Se for comprovado que o TDD escreve um código melhor que outros métodos, então sim.

Existe prova disso? O fato de que a indústria possa usá-lo não é prova. A indústria é bem conhecida por produzir código ruim que é entregue com atraso. A ausência de exemplos de grandes projetos de TDD que falharam ou atrasaram pode ser apenas por ser uma nova abordagem e poucas pessoas realmente concluíram esse projeto ainda. (E os que estão atrasados ​​... ainda podem estar em execução.)

O TDD é viável no desenvolvimento de jogos?

Viável? Claro. Benéfico? Isso ainda está para ser provado.

Kylotan
fonte
1
Infelizmente, TDD e Scrum ainda são incompreendidos. E isso é verdade para projetos existentes que também não ajudarão a acelerar correções de bugs. O Scrum é uma estrutura para desenvolver sistemas complexos, como parece um jogo. O Scrum incentiva a correção de erros de um Sprint para outro, para que eles nunca se acumulem. TDD coloca você do lado do usuário. Por usuário, quero dizer colegas programadores que usarão seu código. Obriga você a pensar em como deve ser usado para tornar seu código fácil de usar para outras pessoas. Por isso, leva a um melhor design, por experiência. Dito isso, você tem visões interessantes sobre o assunto.
Marcouiller
1
Forçar bugs a não se acumularem apenas faz com que os recursos deslizem - você não pode produzir magicamente mais tempo. Meu entendimento é que o Scrum não possui nenhum método específico específico para bugs. Quanto ao TDD forçar você a pensar em como outras pessoas usarão seu código, não é a única maneira de fazer isso. Portanto, não é necessariamente melhor e, certamente, não é necessariamente o uso mais eficaz do tempo.
Kylotan
1
Para sua informação, Noel Llopis usa TDD para seus jogos independentes, e sua antiga empresa High Moon Studios o utilizou extensivamente. Não tenho uma citação, desculpe.
tenpn
Você tem alguns pontos interessantes interessantes para ler! Obrigado pela sua contribuição. No entanto, gostaria de acrescentar que o TDD é outra abordagem, assim como o XP (programação extrema). E sim, o Scrum não fornece nenhum método específico específico para bugs, e investe na auto-organização da equipe (dos desenvolvedores). O Scrum não diz como fazer as coisas, apenas diz o que deve ser feito. É o compromisso da equipe de percorrer o que deve ser feito. O Scrum aposta apenas em equipes multifuncionais auto-organizadas. É a equipe que decidir como os recursos devem ser desenvolvidos e testados, etc
Will Marcouiller
(continue ...) Respondi minha primeira pergunta esta semana sobre aulas aqui no GD. O OP queria saber como fazer seu sprite se mover com as teclas direcionais. Sentindo-me à vontade com os conceitos de OOP, descobri que talvez devesse usar classes para desenvolver meu primeiro jogo usando XNA. Dito isto, minha Spacecraftclasse se torna uma classe totalmente testável com métodos e propriedades. Este é o tipo de material que absolutamente pode, IMHO, ser totalmente testado usando TDD. Digamos que você precise de uma espaçonave e escreva os testes necessários para realizar um teste de cada vez.
Will Marcouiller
4

desculpe pelo meu inglês ruim e desculpe pelo meu ponto de vista tendencioso: eu não sou um designer de jogos, mas um programador.

Eu acho que há algum mal-entendido nesta discussão. Eu vou falar sobre TDD de forma mais geral, o chamado BDD. O desenvolvimento orientado ao comportamento não é uma maneira de testar o projeto (os testes são algo como efeitos colaterais). O BDD é uma maneira de projetar , uma maneira de refatorar e projetar o software durante toda a produção (veja alguns lemas como o KISS, "mantenha a qualidade", "teste com antecedência, teste com frequência") e não em uma fase isolada. O BDD é o oposto de algum processo clássico de software, como o processo em cascata ou alguma outra metodologia iterativa para criar software.

Outro ponto é que os testes automáticos são para os recursos que podem ser testados automaticamente por uma máquina computacional. não há teste de diversão nos jogos e não há teste de usabilidade de uma interface gráfica do usuário. diversão ou usabilidade são materiais para outros trabalhos e não para o desenvolvimento de software como designer de interação, mundo e nível d. da mesma maneira que as partes artísticas (modelagem, texturização etc.) são para artistas que usam computadores como ferramenta de criatividade - obviamente esses trabalhos podem ser executados pela mesma pessoa que escreve código, mas esse não é o ponto. a física pode ser testada, os algoritmos de otimização podem ser testados, o comportamento de objetos singulares pode ser testado (com zombarias, stubs e dummy, como mencionado anteriormente)

o último pensamento é que, imho, é que não apenas o design de jogos, mas todo o código de escrita é uma arte.

nkint
fonte
4

Aqui está um estudo de caso de alguém que acha que TDD e gamedev se misturam muito bem:

http://powertwenty.com/kpd/downloads/TestDrivenDevelopmentInPython.pdf

É certo que este é um projeto pequeno no Pygame, mas dá a idéia de quais partes podem ser testadas com um jogo gráfico e quais não. Fiquei surpreso com o quanto poderia ser feito com o TDD nesse cenário.

Brandon
fonte
1
Sem uma comparação com um grupo de controle que fez o mesmo projeto (clonar um jogo de arcade trivial existente em uma linguagem de nível muito alto), ele não diz nada sobre se o TDD é eficaz ou não. Apenas diz que ele usou TDD.
3

Não, o desenvolvimento orientado a testes não é adequado para o desenvolvimento de jogos. Claro que você pode escrever testes para algumas partes que deseja testar, mas o processo de desenvolvimento de jogos é completamente diferente do desenvolvimento orientado a testes, que exige especificações exatas antes do início do progresso.

Os jogos raramente têm especificações exatas quando iniciados. E se o fizerem, sempre mudam e evoluem durante o processo de desenvolvimento.

O design do jogo é uma arte, você não pode ter testes específicos para saber quando a arte é boa ou completa.

AttackingHobo
fonte
Você não acha que esse fator divertido deve ser considerado ao analisar o jogo em si, a análise funcional ou algo semelhante? Você pode configurar um conjunto de recursos que, juntos, tornarão o jogo divertido, e esses recursos serão testáveis! Estou apenas tentando apresentar opiniões diferentes para aprofundar o assunto e os argumentos que você apresenta. Obrigado pela sua contribuição! =)
Will Marcouiller
3
Muito desenvolvimento se resume a ajustar pequenas coisas e ver como elas são divertidas de jogar. Você não pode testar essas coisas, a menos que elas sejam 100% gravadas em pedra. E testar um sistema depois de concluído não é TDD, está testando, mas não o Desenvolvimento orientado pelo teste.
AttackingHobo
2
Se você acha que a maioria dos projetos do mundo real tem especificações exatas quando é iniciada, provavelmente não trabalhou em muitos projetos do mundo real.
BlueRaja - Danny Pflughoeft