Como o Forager nos mostra a importância da Game Architeture e das boas práticas

Talvez você conheça o Forager, um jogo indie lançado em 2019, focado em exploração e construção. E talvez também tenha ouvido falar das polêmicas que ocorreram durante e depois do desenvolvimento desse jogo, que partem desde base de script completamente bagunçada e vão até bugs, uma enorme quantidade de expansões e até em desavenças entre os envolvidos na produção do game.

Mas, para nossa discussão, o que importa é como Forager exemplifica a importância da arquitetura (Game Architeture) e do planejamento no desenvolvimento de jogos.

A tendência é que, quanto mais experiente é um desenvolvedor, maior será o cuidado com a forma como que faz seus scripts e monta os sistemas de jogo. Em outras palavras, maior será sua preocupação com a Arquitetura de Jogo.

De maneira simples, a Arquitetura de jogo na mais é do que a definição de como os diferentes sistemas e componentes de um projeto se conectam e interagem entre si. Um exemplo próximo na vida real, é a planta baixa de uma casa, que determina a disposição dos cômodos, a infraestrutura e o funcionamento em conjunto. Essa é base da construção de um jogo e afeta diretamente sua qualidade e escalabilidade.

É comum que desenvolvedores mais inexperientes, deixem de lado esse planejamento e achem que "o importante é fazer funcionar", o que leva a eventuais arranjos e conexões mal estruturadas entre scripts e sistemas - as famosas "gambiarras".

Esse foi o caso de Forager. O principal desenvolvedor, HopFrog, admitiu que ter falhado com a base do jogo, e destaca como o código do jogo foi construído de forma desorganizada e com muitas "gambiarras", o que dificultou a manutenção e a adição de novas funcionalidades.

A situação ficou tão crítica, que a ideia de Multiplayer para o jogo foi completamente abandonada, já que a única forma de tornar isso possível era o refazendo inteiro. A base frágil de código e a alta rotatividade de programadores, que preferiam isolar suas tarefas do código principal, transformaram o problema em uma bola de neve que quase comprometeu o projeto.

É claro que, o caso do Forager é bem mais complexo. Mas, como mencionamos, o ponto principal aqui é mostrar como a falta de planejamento, experiência e boas práticas podem comprometer a construção de um jogo a longo prazo.

Mas então, como montar uma boa Arquitetura de Jogos? Bom, é algo que depende de muitos aspectos, como o gênero do seu projeto, as plataformas em que estará disponível e as mecânicas presentes. Não vamos adentrar esse assunto em detalhes aqui, mas podemos dar algumas dicas baseado em nosso trabalho:

• Mantenha os scripts e sistemas genéricos: um bom exercício é se perguntar, "a forma como estou esta programando o script, ou conjunto de scripts, poderia ser usado em outro jogo?". Se a resposta for não, então talvez você tenha que pensar melhor na forma como esta programando. Obviamente, existem exceções.

• Lógica, efeitos sonoros, efeitos visuais e controle de UI separados: dentre os vários padrões de projeto, o que mais vai te salvar de problemas é a segregação de funções. Se você está fazendo um sistema de vida, não coloque o sistema de barra de vida (HUD), o controle de efeitos sonoros (som de hit, por exemplo) e o controle de partículas em um mesmo script. Separe em scripts com funções especificas e complementares.

• Pensamento em longo prazo: é importante montar seus sistemas de jogo pensando que podem haver mudanças, grandes ou pequenas, no projeto em longo prazo. Um bom questionamento a se fazer é "o quão difícil seria implementar uma mudança X no meu projeto?". Se a resposta for "muito difícil", talvez haja partes a se melhorar.

• Refatore e repense seus scripts: as vezes, aprendemos novas funcionalidades que podem facilitar o entendimento, funcionalidade e/ou performance dos sistemas que temos atualmente. Ou ainda, depois de terminar um sistema, entendemos as suas necessidades plenamente e assim temos ideias de como melhora-lo. Se forem esses os casos, considere não avançar e se dedicar ao refatoramento do que já tem (você vai se agradecer depois).

Para finalizar o assunto queremos enfatizar o seguinte: não seja paranoico!

Pensar demais pode te trava, e se tratando principalmente de projetos solo, vai tornar a experiência de desenvolvimento bem desagradável. O método "vou fazer funcionar primeiro depois vejo o que faço" tem suas vantagens. Na verdade, pode ser uma ótima ideia usar esse método dependendo do que está programando.

Pense que, depois que tudo estiver funcionando, você vai entender melhor os sistemas, seus comportamentos e suas necessidades. Isso vai te ajudar muito a repensar e refatorar seu jogo. Mas não deixe nunca virar uma bola de neve.

Com o tempo, vai ficando mais fácil e direto a construção de sistemas e pensar na arquitetura.

Acredite em você e confie no processo.