As aventuras de um estudante de anatomia (de software)
Quando eu falo que faço mestrado e tenho uma bolsa de pesquisa, quase sempre me perguntam logo em seguida: “mas você pesquisa o quê?”. Para não me perder numa explicação super técnica, geralmente digo que estudo a aplicação de Engenharia de Software no desenvolvimento de jogos. Embora essa resposta sirva para matar a sede dos curiosos, eu sei que ela não é lá muito explicativa. E o fato do tópico “vídeo games” ser algo relativamente novo e ainda não muito bem definido no imaginário da maioria colabora bastante para esse mistério ao redor do tópico.
Por exemplo, quando as pessoas pensam em ciência, imaginam alguém de jaleco branco trabalhando com tubos de ensaio ou qualquer coisa do tipo. Sendo assim, falar sobre vídeo games como objeto de estudo soa para muitos como coisa de cientista maluco (ou desocupado). E mesmo entre os que estudam e trabalham na área de tecnologia existe a percepção de que o desenvolvimento de vídeo games é algo artesanal e artístico, uma disciplina quase mais próxima das Artes Visuais ou do Design do que das Ciências Exatas e Engenharias.
E a verdade é que essas pessoas não estão completamente equivocadas. A Engenharia de Software é jovem comparada com outras áreas da ciência “clássica”, e quanto aos games, nem se fala. Neste post, vou falar sobre como essas áreas se cruzam, e como essa mistura de conhecimentos me permite lançar um novo olhar sobre um tópico pouco estudado: game engines.
As três comunidades
Na International Conference of Software Engineering (ICSE) deste ano, o pesquisador francês Lionel Briand fez uma apresentação entitulada Mathematicians, Social Scientists, or Engineers? The Split Minds of Software Engineering Researchers. Nela, Briand divide a área de Engenharia de Software em 3 comunidades:
- Métodos Formais e Garantias
- Engenharia de Soluções Automatizadas
- Estudos Humanos e Sociais
A primeira comunidade trata da parte “dura” da Engenharia, buscando provas matemáticas e estatísticas que mostrem que as inovações na área realmente funcionam. A segunda trabalha mais “com a mão na massa”, visando criar novos apps e ferramentas que ajudem a automatizar o trabalho do desenvolvedor de software, e por consequência melhorá-lo. Finalmente, a terceira estuda o próprio desenvolvedor e sua relação com o ambiente de trabalho, metodologias e ferramentas utilizadas.
Essas relações que o Briand aponta são bem evidentes não só na academia mas também na indústria. Quem já trabalhou como dev sabe que os fatores humanos e técnicos precisam andar juntos para que qualquer grande projeto de software possa dar certo. Contudo, alguns paralelos interessantes aparecem onde menos se espera.
Life finds a way
Algumas semanas atrás, enquanto pesquisava para a escrita de um artigo sobre Arquitetura de Software, acabei encontrando a frase abaixo. Para ficar um pouco mais divertido, ocultei uma palavra pra que você tente adivinhá-la:
O porquê de um _____ ser constituído de uma determinada maneira se relaciona com os requisitos funcionais que suas partes possuem. Forma e função estão acopladas. A comparação das partes destaca as diferenças e nos ajuda a fazer perguntas.
Então, como você preencheria a lacuna na citação? A palavra software parece se encaixar bem, não? Se você já estudou Engenharia de Software na faculdade, provavelmente ouviu seu professor falar diversas vezes sobre “requisitos funcionais”. Além disso, softwares possuem também diferentes formas e funções. Contudo, a resposta é a palavra animal! Afinal, esse trecho não vem de uma obra de Engenharia de Software, e sim de Biologia: o livro Vertebrates: Comparative Anatomy, Function, Evolution de Kenneth V. Kardong.
Eu comecei essa leitura, pois queria entender como a classificação dos seres vivos é feita no contexto da Biologia. Mas o que isso tem a ver com Arquitetura de Software? Pense no seguinte: o que a nadadeira de um peixe e a tela principal do seu app favorito tem em comum? Elas atendem requisitos funcionais, ou seja, estão ali para resolver um problema ou atingir um objetivo. No caso do peixe, as nadadeiras servem muito bem ao objetivo de se locomover dentro d’água. No caso de um app, um componente ou botão pode ter como objetivo de ajudar um usuário a buscar informações, fazer um pedido ou efetuar um pagamento.
Ou seja, fazendo um paralelo com a famosa frase do personagem Ian Malcolm em Jurassic Park: “life finds a way”. A vida encontra uma forma de selecionar naturalmente os requisitos funcionais que melhor cumprem um objetivo. No contexto de software essa seleção é artificial, feita pelo arquiteto ou engenheiro. Contudo, em um primeiro momento meu foco não é entender o processo de seleção em si, mas em que ele resulta. Afinal, por que escrevemos programas com o mesmo objetivo mas de maneiras diferentes? E como isso se reflete em sistemas de software complexos?
Game’s Anatomy
Depois de toda essa reflexão Darwiniana, vamos voltar ao termo que citei lá no início do texto: game engines. As game engines são ferramentas de criação de jogos, e permitem que designers e desenvolvedores criem de forma simples, rápida e padronizada. Unity, Unreal e CryEngine são exemplos famosos, e se você é gamer provavelmente já ouviu falar delas. Justamente por fazerem diversas coisas que são úteis para quem cria jogos, como fazer desenhos em 2D ou 3D na tela, reproduzir áudio e capturar interações do usuário, game engines são sistemas complexos e com várias partes “móveis” — ou seja, não muito diferentes de um ser vivo.
Atualmente, estou aplicando técnicas de classificação muito parecidas com as utilizadas na Biologia para estudar a arquitetura de game engines. Mas por que classificá-las? Pelo mesmo motivo que classificamos os seres vivos: para comparar forma e função. Com esse conhecimento em mãos, podemos fazer recomendações para desenvolvedores. Por exemplo, qual o melhor tipo de game engine para devs iniciantes? E para os que querem estudar o funcionamento ou criar sua própria engine? Quais são boas práticas de arquitetura ao criar uma engine? E que práticas não deveriam ser seguidas?
Além do porquê, é interessante se perguntar também como fazer essa classificação. Podemos classificar as engines pelas funcionalidades que possuem, pela forma como seu código é organizado ou mesmo sua estrutura de diretórios (na imagem acima, por exemplo, comparo o subsistema de áudio de Godot e o3de). Ainda estou explorando todas as possibilidades nesse campo, e meu objetivo é conseguir repetir essa análise de forma consistente em dezenas de engines e então comparar os resultados. Em outras palavras, um trabalho de anatomia comparativa.
Como este é um trabalho exploratório em progresso, ainda não tenho muitos resultados para mostrar. Porém, caso você tenha se interessado no tópico, recomendo a leitura do artigo Game Engine Comparative Anatomy que irei apresentar na IFIP-ICEC 2022. Nesse artigo eu aponto semelhanças e diferenças entre uma descrição de Godot Engine provida pelos desenvolvedores e a estrutura dos subsistemas do ponto de vista do código. Além disso, utilizei análise dinâmica para observar e comparar as chamadas de inicialização realizadas por Godot e Urho3D.
Fontes:
