Game dev: problemas e soluções
Desenvolvimento de jogos funciona do mesmo jeito que desenvolvimento de software? Talvez a resposta dessa pergunta não interesse muito a maioria dos gamers. Para os desenvolvedores de jogos, porém, é exatamente o contrário. Se estes dois mundos — jogos e software tradicional — têm semelhanças, isso significa que as soluções de Engenharia de Software já testadas e aprovadas na indústria tradicional podem ser aplicadas também aos video games, e isso é algo positivo.
Recentemente apresentei no GAS 2022 o artigo Video Game Project Management Anti-patterns, que desenvolvi em conjunto com Cristiano Politowski (Concordia University) e meus orientadores Dr. Yann-Gaël Guéhéneuc (Concordia University) e Dr. Fabio Petrillo (ÉTS). Neste trabalho, analisamos problemas e soluções que game devs ao redor do mundo reportaram em postmortems de seus projetos. A ideia era determinar se esses problemas têm algo em comum com os anti-patterns de Engenharia de Software já conhecidos e documentados na literatura.
Postmortems? Anti-patterns? O que é isso?
Quanto aos postmortems eu já escrevi um artigo por aqui um tempo atrás, mas caso você não esteja afim de lê-lo, aí vai um pequeno resumo: postmortems são documentos escritos ao final de um projeto, relatando o que deu certo e errado. A partir desses relatos, que são escritos por desenvolvedores de jogos, que extraímos uma lista de problemas/soluções que serviu como base de nossa análise.
Se você já trabalhou em qualquer projeto de software, sabe que os problemas enfrentados podem ser os mais diversos: questões técnicas, de infraestrutura, gerenciamento do time, do tempo, etc. Neste trabalho, porém, optamos por focar apenas nos problemas de gerenciamento do projeto, visto que existe bastante informação sobre eles tanto nos postmortems quanto na literatura de Engenharia de Software. E foi a partir disso que começamos a buscar semelhanças e correspondências.
Quanto aos anti-patterns, a tradução do nome já diz tudo: são “anti-padrões”, exemplos documentados do que NÃO fazer em seu projeto. No livro “AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis” os autores mencionam que anti-patterns de gerenciamento de projetos:
(…) descrevem como projetos de software são impactados por questões envolvendo pessoas, processos, recursos e relacionamentos externos.
Encontramos várias correspondências entre os anti-patterns descritos na literatura e problemas da indústria de jogos. Vamos mergulhar mais a fundo em alguns exemplos a seguir.
Anti-pattern: Death March
John Garvin, roteirista e diretor de Uncharted Golden Abyss, menciona que:
Golden Abyss [para o Playstation 3] tinha 34 fases com qualidade next-gen, cada uma com cinco vezes mais conteúdo do que a versão de PSP jamais teve. (…) De janeiro a dezembro de 2011, o time trabalhou praticamente sem parar, muitos de nós trabalhamos por meses durante noites e finais de semana.
Esse não é um caso isolado. Recentemente, devs da Rockstar e Epic Games reportaram jornadas de 100 horas semanais. Contudo, esse tipo de situação não é algo novo, e tampouco exclusivo da indústria de jogos. O engenheiro de software americano Edward Yourdon já cita esse anti-pattern, chamado de “Death March”, no livro homônimo publicado em 1997:
[U]m projeto death march é aquele em que um dos “parâmetros de projeto” excede a norma em pelo menos 50%. (…) O planejamento foi comprimido para menos da metade da duração estimada por um processo de estimativa racional. (…) Funcionalidades e outros aspectos técnicos são duas vezes maiores do que seriam em circunstâncias normais.
Esse é um caso onde encontramos uma correspondência — um “match” — entre um problema descrito por desenvolvedores de jogos e um anti-pattern descrito na literatura de Engenharia de Software. Na maioria dos casos, conseguimos fazer esse “match”, mas um caso específico chamou nossa atenção por sua prevalência em projetos de jogos: problemas por falta ou mau uso de ferramentas de desenvolvimento.
Anti-pattern: Ferramentas ausentes ou inadequadas
É claro que atualmente mesmo o software tradicional é altamente dependente em ferramentas: IDEs, sistemas de controle de versão, teste, build, deploy. No desenvolvimento de jogos, porém, essa necessidade se estende para além do código e alcança também disciplinas artísticas, como modelagem 3D, som, simulação física e animação. Como Richard Lerman explica no prefácio do livro Game Engine Architechture, de Jason Gregory:
O desenvolvimento de jogos contemporâneo é uma disciplina ampla. De design a desenvolvimento, de triple-As a hits indie, de renderização a colisão até programação de ferramentas, há muito a se dizer sobre os conjuntos de sistemas e competências inter-relacionadas na criação de um game.
Nesse contexto, encontramos nos postmortems vários relatos de desenvolvedores insatisfeitos com suas escolhas de ferramentas, ou com o fato de terem negligenciado essas escolhas, como no caso dos desenvolvedores de Sword & Soldiers:
[E]m retrospecto, talvez deveríamos ter dedicado algum tempo para criar um editor visual de levels. Isso, por consequência, teria nos permitido ajustar o jogo inteiro de maneira muito melhor, e também teria economizado muito tempo do resto do time.
Considerações finais
Há muitos fatores em comum entre desenvolvimento de jogos e software tradicional, embora os games possuam particularidades que não devem ser ignoradas, como a questão ferramental. Se você está desenvolvendo um jogo, tenha uma definição clara das ferramentas que pretende usar desde o início, e não tenha medo de prototipar para entender se elas atendem ou não suas necessidades.
Enfim, esse post foi uma versão bem resumida do nosso estudo, dissecando os principais pontos. Se você estiver interessado em saber mais, convido você a ler o pre-print do artigo no Arxiv.
Fontes:
