Postmortem de jogo: Comic Sans

Autor: Leonardo Maronezi Pizani

Semestre: 2018.2 e 2019.1

Equipe:

• Jorge Luiz Bulhões Tosta: Artista
• Leonardo Maronezi Pizani: Líder de projeto
• Luís Eduardo Rozante: Programador
• Miguel Gardini: Músico
• Ricardo Luiz Cardoso Menezes: Programador
• Yago Pessoa: Product Owner

Disponível em: https://fog-icmc.itch.io/comic-sans

Proposta

Nossa proposta era desenvolver um jogo Shoot’em up com estilo Bullet Hell focado em combates contra chefes, ou seja, com um personagem jogável que deve desviar de uma grande quantidade de ataques dos chefes enquanto tenta derrotá-los.

Xing Ling, uma dos chefes do jogo, representando o estilo de desenho de mangá

O início do jogo se dá já no confronto com um chefe predeterminado. Quando ele é derrotado abre espaço para uma área onde se encontram os caminhos que levam aos demais chefes, sendo de livre escolha do jogador em qual ordem enfrentará cada um deles.

No total planejou-se três chefes, sendo que cada um representa um estilo artístico diferente. Consequentemente, cada chefe seria desenhado apropriadamente para tal estilo e acompanhado por uma trilha sonora que complemente o visual, tornando a batalha mais imersiva.

Cada chefe deveria possuir uma quantidade de ataques equivalente ao seu número de estágios mais o seu ataque base. Cada estágio, definido pela barra de HP do chefe,

libera um novo ataque e modifica seu comportamento. Quando sua barra de HP zerar o jogador vence o nível. Ao ser atingido por qualquer ataque do chefe o jogador perde um de seus poucos contadores de vida, sendo que ao perder todos também perde a partida.

Resultado

O produto final, por assim dizer, comporta muitas das características almejadas, que tornam o jogo um divertido Bullet Hell. Entretanto algumas das propostas presentes no Ten-pager não foram concretizadas.

O coelho acabou não sendo obrigatoriamente o primeiro a se enfrentar, podendo ser deixado por último e não houve tempo hábil para implementar os “upgrades”, que o jogador desbloquearia para o stickman conforme ele derrota os chefes, nem as borrachas, que apagariam da tela todos projéteis inimigos.

A ideia inicial era que o projeto durasse por apenas um semestre, mas, devido ao enorme sucesso obtido nesse tempo, optamos por prolongar o desenvolvimento por mais um semestre. Queríamos implementar tudo o que havia faltado e mais.

Contudo, um de nossos programadores precisou se ausentar do projeto nessa nova etapa e infelizmente não conseguimos outra pessoa para o cargo. Sendo assim o projeto acabou por não avançar tanto quanto gostaríamos, mas conseguimos polir o que tínhamos, corrigir os seus bugs e entregar um novo chefe.

O que deu certo

• Motivação dos membros: o grupo pequeno ajudou consideravelmente na organização e divisão de tarefas, mas apenas isso não foi suficiente. O maior diferencial foi a motivação e participação dos membros, que constantemente trocavam ideias e se comunicavam no slack, não faltavam nas reuniões sem justificativa ou aviso prévio e faziam as tarefas designadas.
• Documentação: a documentação do projeto foi seguida conforme os padrões estipulados pelo coordenador de desenvolvimento da época e, embora sucinta, ela se mostrou bastante completa e fonte de consulta para os membros do grupo durante o desenvolvimento do projeto.
• Escopo: ele foi pequeno desde a concepção do projeto, com poucas “features” básicas e nenhuma muito mirabolante. Além disso, durante o decorrer do projeto soubemos efetuar cortes acertados, que permitiram concluir o projeto com um jogo muito próximo do que tínhamos em mente dentro do prazo.
• Identidade visual: é um dos pontos mais acertados do jogo, tendo não só ficado melhor e mais parecido com um caderno de desenhista do que esperávamos, como também é facilmente identificável e marca desse jogo.

Punk Meu Queixo, representando o estilo “punk” de grafite

• Planejamento de código: a etapa de Pré-produção, além de ser destinada à elaboração da documentação, foi também utilizada para planejamento de código, como por exemplo, com a elaboração de um Diagrama de Classe. Além disso os desenvolvedores se mostraram competente e organizados durante todo o desenvolvimento.

O que deu errado

• Tempo: os problemas citados anteriormente, como por exemplo falta de alguns padrões de ataque em um dos chefes, ou ausência de features planejadas, mas não executadas foram provocados principalmente devido a falta de tempo para implementá-las. Apesar disso ainda conseguimos criar um jogo completo.
• Carência de um programador: no segundo semestre de desenvolvimento do projeto perdemos um programador e com isso, mesmo tendo mais tempo para trabalhar no jogo, esse tempo se mostrou bem menos produtivo.
• Divulgação: apesar do empenho da equipe de RP com iniciativas como o “screenshot saturday” e das divulgações do “SoundCloud” do músico, sentimos que poderíamos ter feito mais nesse quesito.

Trello

Esse é um ponto interessante, o Trello foi essencial no início do desenvolvimento, dando um norte para o grupo sobre quais tarefas eram necessárias para o projeto e mantendo uma consistência nos “sprints” (entregas) semanais. Contudo, mesmo sendo ele consultado em todas as reuniões, no final do projeto ele foi parecendo cada vez mais irrelevante. As tarefas foram se tornando gradualmente maiores e por diversas vezes não houveram mudanças de tarefas no Trello, uma vez que ela passaram a levar mais semanas para serem concluídas. Além disso, após tanto tempo de desenvolvimento, todos os membros já possuíam claro conhecimento de seu papel no projeto e sabiam claramente quais tarefas deveriam ser efetuadas mesmo sem o Trello, uma vez que muitas delas eram uma repetição de tarefas anteriores.

Quadro do Trello da equipe, perto do fim da primeira parte do desenvolvimento

O que aprendemos

Além dos aprendizados individuais, como por exemplo o método de se desenvolver uma nova tipografia por parte do artista e de como construir e seguir um diagrama de classes por parte dos programadores, houve um aprendizado que todos os membros do grupo puderam partilhar, que se trata de uma questão já discutida por muito tempo no Fellowship of the Game, grupo e escopo pequenos funcionam!

Além da facilidade organizacional desse tipo de projeto é importante destacar que grupos pequenos são mais fáceis de se manter motivados, e membros motivados produzem melhores resultados, que por sua vez mantém o grupo motivado. A falta de motivação de um único membro é suficiente para desestimular os demais e comprometer o projeto e quanto maior o grupo, maior as chances disso acontecer.

O escopo pequeno também é vital nesse aspecto, uma vez que resultados são perceptíveis mais rapidamente e permitem prazos menores, sendo portanto mais improvável que os membros se cansem do projeto durante seu desenvolvimento. Isso também se aplica às diferentes etapas de desenvolvimento do projeto, no início da fase de produção as coisas se desenvolvem aparentemente mais rápido, enquanto na etapa de polimento o progresso não é tão visível, mas isso de forma alguma significa que ele não existe.

Também vale ressaltar que o número de integrantes do grupo deve ser coerente com o escopo do projeto. Durante o segundo semestre de desenvolvimento percebemos o quanto a ausência de um único membro teve impacto no escopo estipulado para essa nova etapa de desenvolvimento, que teve de ser drasticamente reduzido.

Havíamos planejado não apenas polir o que tínhamos, mas também adicionar todo o conteúdo que não conseguimos no primeiro semestre juntamente com um novo personagem. Porém acabamos por ter que decidir o que era mais relevante adicionar ao jogo e desistir do que não era. Por sinal isso também foi um grande aprendizado para o grupo, saber o que deve ser mantido no projeto e o que pode ser cortado quando necessário.