Acertos e erros: GMTK Jam 2019 (postmortem)

Tela principal do jogo cheia de referências a nosso ambiente de trabalho 🙂

Há alguns meses eu falei um pouco aqui no blog sobre postmortems e a importância deles na análise de projetos e melhoramento de processos na indústria de games (e em outras indústrias também). Após participar da GMTK Jam pela segunda vez esse ano e perceber que, para minha frustração, vários problemas se repetiram e muitos outras novas situações apareceram, resolvi utilizar o conhecimento que obtive através da análise de postmortems para escrever um sobre nosso jogo da jam, o Coffee Break.

O que é Coffee Break?

Em Coffee Break, o objetivo do jogador é encher recipientes com café até uma determinada marca. Os recipientes se movem através de uma “esteira” imaginária que passa na frente do dispenser da cafeteira, e esse movimento é contínuo. O jogador pode fazer a esteira parar segurando a barra de espaço. O objetivo do jogo é parar a esteira exatamente no momento que o recipiente passa pelo dispenser, permitindo que esse recipiente seja enchido até um determinado nível e então siga seu caminho na esteira. O jogador perde quando o recipiente passar sem ter enchido até o mínimo requerido, ou caso deixe o recipiente transbordar.

O que deu certo?

1. Design e aderência ao tema

Tivemos tempo adequado para discutir ideias, sem pressa para pensar no que queríamos fazer e levando em consideração sugestões de todos os membros do grupo. A mecânica de jogo conseguiu unir simplicidade e diversão, seguindo a temática da jam e trazendo uma experiência agradável ao mesmo tempo. O visual da UI e do jogo em si também ficou muito bom, passando um ar de conforto e “fofura” ao jogo. Ao meu ver, Coffee Break é o perfeito endless runner casual, daqueles feitos para relaxar, nos moldes de Alto’s Adventure ou Race to the Sun (que apesar de terem modos mais desafiadores, deixam o jogador apenas relaxar e seguir o fluxo).

2. Mais talentos no time

Diferente da edição de 2018, onde contamos apenas com 2 programadores, nessa edição participaram do time também 2 designers e mais 1 programador. Isso nos permitiu melhorar exponencialmente a qualidade dos assets, e permitiu também que cada membro pudesse focar melhor em suas atividades, sem ficar com responsabilidades demais.

3. Experiência prévia com o itch.io

Como já tínhamos experiência da jam de 2018, o processo de inscrição e upload do jogo no itch.io quase não tomou tempo. Há algumas especificidades no upload de jogos HTML5, mas como já conhecíamos o workflow não perdemos tempo algum com isso. Inclusive, conseguimos fazer upload e testar o jogo no ar de antemão, o que foi uma mão na roda. Ter alguma ideia de como fazer o marketing (utilizando redes sociais e contatos dentro do próprio itch.io) também foi algo de grande valia para espalhar a “palavra” do Coffee Break e conseguir chamar o máximo de atenção possível durante o período de avaliação da jam.

4. Level design escalável

Apesar de não ter ficado perfeito, foi relativamente fácil escalar a dificuldade do jogo sem prejudicar seu design: bastou aumentar a velocidade da esteira. Criar recipientes de diferentes volumes teria adicionado um charme e complexidade adicional, mas não acredito que tenha sido uma grande perda visto que o jogo tem uma proposta mais casual e “despreocupada”.

5. Sem feature creep

Uma vez definidas as funcionalidades necessárias para fazer o jogo funcionar, não fugimos muito delas e nos focamos em desenvolvê-las da melhor forma possível. Um dos perigos durante o desenvolvimento de qualquer jogo é o “feature creep“, ou seja, aquele famoso momento onde alguém diz “só mais uma coisinha”, e essas várias “coisinhas” acabam se acumulando de forma a expandir demais o escopo. Percebi que isso não aconteceu nem por parte do desenvolvimento, nem por parte do design.

O que deu errado?

1. Falta de modelagem conceitual

Enquanto os designers conseguiram produzir de forma bem uniforme, sem atrapalhar uns aos outros, o mesmo não aconteceu com os desenvolvedores. Como cada um tinha diferente níveis de experiência, foi difícil criar uma estrutura de projeto na qual todos realmente entendessem o que estavam fazendo. Com exceção de uma rápida discussão, não fizemos modelagem de entidades, nem de módulos, nem da comunicação entre esses módulos.

Isso resultou em uma frequente “incompatibilidade” de modelos: se Programador A escreve um módulo para Programador B utilizar, ambos devem estar alinhados quanto às entradas e saídas esperadas para o módulo, e como este se integra com os demais. Esse tipo de desentendimento tornou difícil o desenvolvimento de uma aplicação realmente modular e puxou o freio da produtividade.

Essa falta de modelagem acarretou também em um código que não faz tudo que se propõe a fazer da maneira esperada (ou seja: possui bugs), embora tenha boa flexibilidade para futura expansão. Acredito que todos poderiam estar mais cientes do funcionamento do jogo se tivéssemos modelado a aplicação de forma clara, utilizando UML ou outro padrão visual e universal.

2. Má escolha de ferramentas

Não utilizamos frameworks, nem bibliotecas, nem engines. Fizemos o jogo inteiro manipulando um Canvas HTML5 com JavaScript. Apesar dessa abordagem permitir desenvolver qualquer funcionalidade como bem entendêssemos, sem ficarmos preso a limitações pré-definidas, isso também significou que todas as responsabilidades ficaram na nossa mão. Renderizar sprites, controlar movimento e colisões, controlar o game loop, gerenciar inputs, tudo precisou ser feito do zero.

Desenvolver isso é sempre interessante, pois temos a oportunidade de ver como uma game engine realmente funciona e entender mais de seus “bastidores”, porém no contexto de uma jam, onde o tempo é reduzido, desenvolver cada mínimo detalhe foi uma perda de tempo enorme e na próxima jam sem dúvida iremos utilizar uma game engine, mesmo que isso signifique ter que ler a documentação por horas até encontrar uma forma de desenvolver o que queremos.

3. Sobrecarga e mau escalonamento de tarefas

Como a modelagem do “core” ficou apenas na cabeça de um dos programadores, que tinha mais experiência com as minúcias do desenvolvimento de uma game engine, este acabou acumulando boa parte das tarefas para si. Isso acarretou não só na sobrecarga desse programador, mas também na “falta” de trabalho para os demais, que ficavam impossibilitados de ajudar por não entenderem nem o domínio, nem a arquitetura do projeto (vide item 1).

Na próxima jam, creio que seria uma boa ideia alinhar todos os programadores com uma determinada ferramenta, de forma que todos possam ajudar e ninguém se sinta “impotente” em meio a uma lista cheia de tarefas. Muito da diversão da jam é sentir-se produtivo, e quando você apena senta e assiste alguém programar, por mais que você possa aprender muito, simplesmente não é tão recompensador quanto colocar as mãos na massa por conta própria.

4. Cortes de funcionalidades

A jam começou às 16h de sexta, mas por limitação de tempo dos membros do grupo iniciamos somente à 13h de sábado. Ou seja, já começamos com 21h de atraso, o que significava que nosso tempo era reduzido em comparação aos demais participantes da jam. Ainda assim, focamos em criar um jogo profundamente visual, na confiança de que isso seria fácil visto que tínhamos designers no time.

Contudo, embora desenhar seja rápido, encaixar esses recursos na experiência interativa pode levar tempo. No fim das contas alguns detalhes visuais foram cortados da versão final, como animações de enchimento dos recipientes, variabilidade de objetos disponíveis e geração de recipientes com diferentes alturas/volumes. Na próxima jam acho que seria interessante definir bem o que é “indispensável” e o que é apenas “perfumaria”. Antes cortar o barato no início do que ter que deixar várias coisas pra trás no final.

5. Problemas no itch.io

Com mais de 7000 participantes e mais de 2500 jogos entregues, a GMTK Jam 2019 foi uma das maiores da plataforma itch.io, que não deu conta de receber tantos uploads de jogos. A página ficou inoperante por quase 3h após o fim da jam, o que fez com que tivéssemos que esperar um pouco para upar e testar a versão final.

Considerações finais

Foi ótimo poder organizar os problemas através de um postmortem e discutí-los posteriormente com membros do meu time da jam. Espero que possamos melhorar em muitos destes aspectos em uma próxima oportunidade, afinal, essa é a proposta desse tipo de evento: criar algo novo e, ao mesmo tempo, desafiar a si mesmo a fazer o melhor com tempo e recursos limitados.

Jogue aqui! Coffee Break by Bluend