Páginas

quinta-feira, 9 de setembro de 2010

You Are Trash! - Post Mortem

No jargão dos video games, um post mortem é uma análise crítica de como foi o processo de desenvolvimento de um jogo, analisando o que deu certo e o que deu errado. Um exemplo é este do Indigo Prophecy na página do Gamasutra. No meu caso, procurei me centrar na parte que me coube a me arriscar falando do trabalho dos outros, que serão tratados em outros posts. E como toda pós análise que faço, sou muito crítico comigo mesmo pouco enaltecendo o que saiu de bom, como já apontado pelo Vinícius na minha defesa de projeto final, o que é uma falha minha.

Esse mesmo post está replicado no blog do Gamerama. Espero que vocês aproveitem.

---------------------------------------------------------------

Uma frase recorrente minha quando apresento o YAT para outras pessoas é “Hoje eu teria feito diferente, mudaria muita coisa”.

O processo de desenvolvimento do YAT começou quando o Guilherme avisou que teríamos que fazer o jogo em Java para atender os requisitos de portabilidade. Como os 3 programadores (esse recurso escasso) daquela edição já tinham alguma experiência (acadêmica) com Java, aceitamos sem reclamar muito, afinal a escolha de uma linguagem comum favoreceria a troca de experiências. Entretanto, a primeira pedra surgiu quando os jogos seriam diferentes na implementação: basicamente 2 em tileset e o YAT como jogo de plataforma. Os outros 2 (BioDragon e CMYK) usariam um motor caseiro, feito especificamente para resolver o problema deles em tiles, enquanto para o YAT decidi procurar um motor gratuito (e aberto) que oferecesse um bom suporte ao 2D sendo menos restritivo. Foi assim que conheci o GTGE, que já estava parado há algum tempo mas pareceu servir às necessidades.

Devido ao curto prazo do Gamerama, prototipagem e teste rápidos eram necessários. Os artistas produziam a arte, eu produzia o código. Nosso primeiro milestone foi colocar um sprite andando livremente pela tela. Depois um sprite animado, em seguida física de jogos plataforma (coisa básica como gravidade, colisão entre objetos). Enquanto eu aprendia como o motor GTGE funcionava (e aplicava alguns conceitos de motores de jogos estudados na minha iniciação científica), os outros membros da equipe aprendiam seu ofício e como todos conversaríamos a mesma língua.

Por volta de 2 semanas de produção já tínhamos um esboço de  jogo plataforma com música. Nada mal para um pessoal que estava fazendo seu primeiro jogo e aprendendo a usar ferramentas novas. A primeira pausa então ocorreu. Com o fim do Gamerama, coube apenas aos grupos se organizarem e agora sem um lugar comum com obrigatoriedade de reuniões, além da volta às aulas, os participantes acabaram se distanciando.
Foi por volta do final do semestre, quando estava lendo uma entrevista de John Carmack que tive um estalo e resolvi retomar a programação do YAT. Contactei o Arthur e demos início ao processo, precisávamos enviar o jogo o mais próximo possível de estar completo ao Festival de Jogos Independentes do SBGames 2009, que aconteceria na PUC-Rio. Mão na massa, suor na camisa.

Com prazos apertados, bugs a corrigir e alguns trabalhos deixados de lado em favor de terminar o YAT, além da falta de experiência anterior, “bacalhaus” começaram a ser introduzidos no código, decisões erradas de design de código e o pouco estudo do motor contribuíram para muitos erros que persistiram até os últimos dias de produção (o último erro foi percebido perscrutando o código e reparando que uma determinada atualização de física estava no lugar errado, sendo executada em determinadas circunstâncias apenas). Foi um parto doloroso.

Mesmo inacabado, YAT foi enviado para o SBGames 2009. Em 2010 retomamos o desenvolvimento para terminar de vez e enviar para o SBGames 2010, acabando por introduzir mudanças na proposta a fim de ter um jogo fechado. Essa finalização teve seu ponto culminante com 2 finais de semana em “crunch“, onde nos juntamos na casa do Arthur para focarmos na finalização de código e conteúdo. Contamos também com playtesting intensivo de pessoas de fora do projeto, o que foi essencial para a calibração da dificuldade, já que anteriormente tivemos poucos testes e em sua maioria sem critérios.

Como eu disse parágrafos atrás, hoje teria feito tudo diferente. A primeira parte seria adotar estratégias de engenharia de software como diagramas de classe e adoção de design patterns, tudo isso baseado em conversas com o “cliente” (o game designer, no caso). Dessa forma, muitos erros e bacalhaus poderiam ter sido evitados e um software mais polido e eficiente poderia ter sido criado, permitindo a extensibilidade sem ter que mexer em um ninho de mafagafos. Usar um sistema de controle de versão também teria facilitado, tanto para os recursos quanto para o código, ao invés de simplesmente postar zips de milestones no Google Groups.

Dessa experiência, tiramos que:
  • princípios de engenharia de software devem ser adotados o quanto antes em seu projeto a fim de facilitar alterações posteriores e uma melhor legibilidade e compreensão de código.
  • playtesting com pessoas externas ao projeto é essencial para evitar vícios de teste interno.
  • crunches funcionam no final do prazo, apesar de não serem saudáveis. Leia uma opinião contrária aqui.
  • controle de versão evita dores de cabeça, permite voltar no tempo e mantém a equipe trabalhando atualizada.
  • A portabilidade de Java é questionável (mais uma vez), como percebemos em alguns métodos relativos ao som.
  • a primeira vez pode não ser a melhor, mas ficará marcada em você.
You Are Trash! pode ser baixado nos seguintes sites:
GameJolt
IndieDB

O código fonte do YAT está disponível sob a licença LGPL no Google Code. Se você deseja ver as decisões erradas e os consertos a la McGyver para contornar buracos, sinta-se à vontade, mas não aponte o dedo na minha cara =)

Um comentário:

  1. Aí, Baère, eu gostei do seu post mortem, mas vamo atualizar essa bagaça, que o jogo já foi pré-aprovado! xD

    ResponderExcluir