Postmortem de projeto: Robots vs Aliens

Autor: Fabrício Guedes Faria

Semestre: 2019.1

Equipe:

• Fabrício Guedes Faria: Líder, Programador
• Gabriel Carvalho: Programador
• Tiago Mariano Silva: Programador
• Eike Sanches: Artista
• Enzo Sanches: Artista
• Thiago Carvalho: Artista
• Leonardo Tórtoro Pereira: Product Owner

Disponível em: https://fog-icmc.itch.io/robots-vs-aliens

Agradecimentos adicionais:

Gostaria de agradecer ao Fellowship of the Game, que proporcionou um ambiente propício para que pudéssemos desenvolver o jogo, e à Popcap Games, criadores do Plants vs Zombies (PvZ), que serviu de inspiração direta para o projeto.

Sobre o jogo:

Robots vs Aliens surgiu com a ideia de aperfeiçoarmos nossas habilidades técnicas de desenvolvimento sem necessariamente termos que nos preocupar com o aspecto criativo da produção de um jogo. Queríamos pular toda a parte de pensar num jogo original, alguma mecânica diferente, e testar para ver se seria divertido para os jogadores. Isso economiza nosso tempo, que com a graduação já é limitado, para podermos nos dedicar ao nosso aprendizado.

Com esse objetivo em mente, decidimos escolher um jogo já existente e popular e fazer um clone dele. A lógica era que se o design do jogo já foi comprovado pelo seu sucesso, então se copiarmos ele terminaríamos com um jogo igualmente bom (pelo menos no aspecto do design). Um objetivo bônus é o de podermos analizar e fazer uma espécie de engenharia reversa nos aspectos centrais do jogo, seja mecânicas ou visuais.

Após listarmos alguns jogos possíveis (Jetpack Joyride, Fruit Ninja e Metal Slug eram outras opções), escolhemos replicar o PvZ, por simples motivos de preferência e por que achamos a complexidade apropriada para o tempo que tínhamos reservado para o desenvolvimento, de 4 meses.

Os robôs aliados defendem a nave contra as hordas de aliens

O que deu certo:

1. Idéia inicial: De fato, a proposta de copiar o design do Plants vs Zombies deu bons resultados. Ninguém do grupo precisou se estressar para pensar nas mecânicas, no balanceamento do jogo e na UI e UX do jogo. A qualquer momento que iríamos implementar uma nova feature, simplesmente referenciamos o PvZ e copiamos (adaptando onde necessário) para o nosso jogo.
2. Temática escolhida: Para tornar a experiência do jogo pelo menos um pouco diferente, um pouco mais pessoal nossa, queríamos trocar a temática de plantas e zumbis por algo diferente, mas ainda manter o mesmo sentimento geral de “suspense bobo”. Como sabíamos que no PvZ o objetivo era ser um tower defense em que os inimigos se moveriam devagar (zumbis) e as “torres” seriam imóveis (plantas), pensamos em replicar isso jogando para uma temática espacial, com aliens e robôs. Ambos tipos de personagens podem ser extremamente variáveis, sendo que não há um “padrão” definido, então nos proporcionou uma boa liberdade para criar de uma maneira apropriadamente boba. Além disso, logo no início do desenvolvimento, tivemos a ideia de que cada robô teria alguma associação com um animal, a fim de tornar mais estilizado e ser engraçado para o jogador.
3. Autonomia da equipe de arte: Decidimos logo no início do projeto em dividir o grupo em 2 subgrupos: o de programadores (liderado por mim), e o de artistas (liderado pelo Thiago). Dessa maneira, os próprios artistas poderiam dividir entre si as tarefas que cada um seria mais capacitado de fazer, e isso se mostrou positivo. Normalmente o líder, que nem sempre é alguém com conhecimento profundo de técnicas artísticas, deve tentar propor tarefas e estipular prazos incertos. Mas desse jeito, a carga de monitorar a produção de arte foi retirada dos outros membros e os desenhistas teriam sua liberdade artística não-comprometida.
4. Arquitetura fortemente orientada a componentes: Outra decisão tomada logo no início, dessa vez pelos programadores. Nós 3 tínhamos programado outros jogos na Unity antes, mas sempre de maneira pouco organizada e modularizada. Queríamos tentar ao máximo dividir todas as funcionalidades diferentes em componentes separados e suficientemente independentes para aprender esse paradigma. Isso provou ser beneficial para criação de novos objetos, pois podíamos reutilizar componentes criados anteriormente com alterações mínimas.
5. Acompanhamento do PO: Nosso product owner, um membro do FoG responsável por supervisionar o projeto e controlar de perto o escopo, fez um bom trabalho durante o desenvolvimento. Em destaque fica a definição do escopo e das metas iniciais, que nos ajudou a ter uma noção inicial do que esperar de cada membro durante os sprints. Também irei citar a sugestão durante o projeto de cortarmos o escopo excedente que não conseguiríamos alcançar no ritmo que estávamos, e focarmos bastante em terminar e polir o nosso MVP. No fim das contas, foi o que fizemos, e ainda quase não conseguimos terminar isso a tempo (com o nível de dedicação que estávamos tendo ao fim do projeto).

Representação da situação do campo no meio de uma partida

O que deu errado:

1. Escopo e planejamento de sprints: Surpreendentemente, descobrimos que embora desenvolver um clone tenha seus benefícios, descritos acima, também trouxe alguns problemas, o principal deles sendo o planejamento do escopo nas sprints. Visto que estamos nos baseando num jogo completo com um bom polimento e várias features implementadas, ficamos com a mentalidade de que seria necessário ter todas aquelas features para que o jogo fique bom, e que o nível de polimento deveria ser o mesmo que o original. Porém, em diversos sprints, tivemos membros que não conseguiram terminar o que se propuseram a fazer, ou features que achamos que estavam completas mas necessitavam de muito mais trabalho nelas. Admito também que uma parcela da culpa foi minha que, como líder, não tive a visão necessária para prever esses problemas logo no início, e tivemos que nos virar durante o desenvolvimento.
2. Falta de priorização do projeto: Na minha visão como líder, pareceu que para a maioria dos membros o projeto estava com baixa prioridade com relação à outras atividades (me incluo nessa concepção também). Por conta de diversos outros compromissos e assuntos pessoais, não estávamos nos dedicando tanto para este projeto quanto poderíamos realisticamente. Estávamos menos dispostos a colocar além do esforço mínimo a cada sprint, e isso resultou em um aparente desânimo e atraso nas entregas. No fim das contas, acabamos tendo que focar apenas em terminar o MVP proposto e não tentar implementar features adicionais, que poderiam ter acrescentado bastante ao projeto.
3. Reuniões não-presenciais: Como dois membros não estavam morando em São Carlos durante o semestre do projeto, nossas reuniões semanais de 1h deveriam ser feitas por Discord. Na minha visão, o fato de não haver um compromisso de ir até um local presencialmente toda semana no mesmo horário, a reunião tinha maior chance de ser esquecida ocasionalmente por alguns (ou todos) os membros. Além disso, a ausência de interação face-a-face regular não permitiu a aproximação dos membros, e gerou um certo disconexo do que todos estavam fazendo (fora das reuniões, ninguém sabia qual tarefa cada pessoa estava desempenhando).
4. Polimento deixado de lado: Como já estávamos correndo para terminar as features básicas que iriam no MVP, acabamos não conseguindo deixar o jogo tão polido quanto queríamos. Algumas coisas estão presentes, como animações na tomada de dano. Infelizmente, se tivéssemos cortado features mais cedo, talvez conseguíssemos ter adicionado mais polimento.

Conclusões:

O projeto no geral foi uma experiência positiva para os membros. Todos nós aprendemos bastante no quesito técnico, seja o treino do paradigma de Programação Orientada a Componentes ou o aprendizado da técnica de pixel art. Conseguimos ter um produto final razoável, jogável e minimamente polido. Embora eu acredite que os membros do grupo não tenham ficado super envolvidos com o jogo, não foi uma experiência desagradável para ninguém. Eu definitivamente recomendo que mais projetos “clones” sejam feitos dentro do FoG, especialmente para membros cujo objetivo seja treinar suas habilidades, e para grupos que não dispõe de algum membro específico para o game design. Se eu pudesse mudar algo desde o início, teria sido escolher outra pessoa mais interessada no projeto para liderar, pois acho que faltou alguém para realizar esse papel de puxar os membros a se envolverem com o projeto, criar hype interno, deixar todos motivados constantemente e com alta produtividade.