Entre os dias 02 de Setembro e 25 de Novembro de 2016, aconteceu a 4a Maratona Academia PDJ.

Esta é uma maratona online de desenvolvimento que eu faço com os membros da Academia de Produção de Jogos e tem como objetivo fazer o pessoal realmente colocar a mão na massa e usar tudo o que aprendeu na criação de um jogo.

No artigo de hoje, eu trago o postmortem do jogo No Math Cards, desenvolvido pela equipe Five Heads Studio durante a 4a Maratona Academia PDJ.

Se você achar o jogo interessante, não deixe de votar nele nesta página especial. Esta é a forma que os desenvolvedores têm de saber que o jogo que eles fizeram realmente cativou o público 🙂

Eu acredito que o postmortem abaixo será muito útil para quem desenvolve ou quer desenvolver jogos, pois discute as várias as fases do processo, as dificuldades e desafios da criação, o gerenciamento de tempo e outros pontos importantes.

No final deste artigo eu volto para fazer alguns comentários e te explicar como você pode fazer parte da Academia de Produção de Jogos e estar com a gente na próxima maratona.

Então agora divirta-se com o postmortem do jogo No Math Cards.

Com vocês, Five Heads Studio

Olá pessoal, tudo bem?

Eu sou o Ademilson Rodrigo Moreira, líder da equipe Five Heads Studio e criamos o jogo No Math Cards durante a 4ª maratona da Academia de Produção e Jogos.

Neste postmortem, compartilhamos como foi desenvolver o jogo, desde a concepção inicial, prototipagem e entrega do jogo.

Caso ainda não tenha jogado No Math Cards, poderá fazê-lo diretamente do browser, clicando aqui.

Como surgiu a equipe Five Heads Studio?

A Five Heads Studio (estúdio das 5 cabeças) se formou para a 2ª Maratona que teve início em janeiro de 2016.

Estávamos em 4 integrantes e procurávamos mais um membro que também ajudaria na concepção de ideias para o jogo.

Com a chegada do 5º integrante, surgiu o nome para a equipe. O jogo para a 2ª maratona não foi finalizado e está parado por enquanto, mas será retomado futuramente. Não participamos da 3ª maratona.

Os outros integrantes da equipe se chamam Alex Esteves, Andrezza Barbosa, Ângelo Paradiso e Leonardo Sousa. Nesta 4ª maratona a Andrezza não participou por estar muito atarefada com os assuntos da faculdade.

Embora a equipe já tenha alguns meses de existência, saibam que não somos vizinhos, colegas de faculdade e nem sequer moramos perto um do outro.

Cada integrante é de um estado e cidade diferentes. Sou do Paraná, mas o Alex mora no Ceará, Andrezza no Rio, Ângelo em Minas e o Leo em São Paulo. Apesar da distância, a equipe continua unida. 🙂

A escolha de qual jogo fazer

Como as maratonas de 12 semanas ou três meses não possuem um tema específico, fica por conta da equipe que tema e estilo de jogo criar. E ao contrário do jogo da maratona em que a equipe foi formada, queríamos fazer um jogo que fosse mais rápido de concluir e que não tivesse tanta animação para não saturar o artista. Ainda nos manteríamos no estilo de jogos 2D.

Antes do início da maratona, eu estava verificando um protótipo de um jogo de puzzle de matemática que comecei a fazer em 2010 e que cheguei a melhorar um pouco para inscrevê-lo no concurso Inovapps de 2015.

Foi então que joguei o jogo Uno e resolvi procurar jogos de cartas com matemática. Como não encontrei, e a mente já estava borbulhando com ideias, apresentei para a equipe o conceito e todos gostaram.

Então, decidimos fazer um jogo de cartas com uma estrutura semelhante ao Uno, mas com mecânicas próprias e diferentes de outros jogos de matemática.

No primeiro mês, focamos em criar o protótipo para validar a mecânica base e ver o que ficaria para a versão final e o que seria mudado. Se quiserem conferir como ficou o protótipo, é só acessar ele neste link.

Após receber alguns feedbacks sobre o protótipo e realizar testes com os membros da equipe, o GDD foi finalmente concluído.

Não é o melhor documento do mundo, mas ajudou bastante a deixar todos na equipe sintonizados. Caso tenham interesse, ele está disponível neste link.

Para criar o jogo, optamos mais uma vez pela engine Unity.

Para programar o jogo, foi utilizado o Visual Studio Community 2015 (é gratuíto) por permitir debugar o jogo passo a passo, sem ter que colocar no código aqueles “Debug.log()” ou “print()” para escrever textos na tela como a maioria dos tutoriais ensinam.

O processo de desenvolvimento

Antes de começarmos a trabalhar no jogo de fato, fizemos imagens conceito das cartas e de alguns elementos do jogo.

Criamos o Devlog no fórum da Academia de Produção de jogos, fizemos testes na Unity (como utilizar o serviço multiplayer da ferramenta) e assinamos o contrato entre os membros da equipe usando a ferramenta Hello Sign.

Também foi planejado o relacionamento dos objetos previstos na tela de gameplay (como relação das cartas com o baralho, mesa, mãos, etc), pois aprendemos no jogo da 2ª maratona (que também seria multiplayer) que um jogo off-line e um jogo multiplayer (dentro da engine Unity, com as ferramentas nativas) possuem algumas diferenças na questão da organização dos elementos. Começar o jogo com isso em mente evita muita dor de cabeça depois.

Para controlar o andamento do projeto, utilizamos a ferramenta online Asana e utilizamos a metodologia Scrum. Para a comunicação, utilizamos WhatsApp, Skype e e-mail.

Após essas etapas iniciais, iniciamos o protótipo (com apenas 29 cartas das 104 previstas) e percebemos que algumas coisas teriam que ser alteradas.

No protótipo, cada carta é um Sprite. Na versão final, se não considerarmos as cartas que se repetem, são 52 no total. Porém, seriam 52 em português e 52 em inglês, já que nosso jogo teria os dois idiomas ainda nesta maratona. Seria muito trabalho para o artista.

Então, decidimos que as cartas seriam apenas alguns sprites e as escritas nelas seriam feitas dinamicamente no início da partida, de acordo com o idioma setado.

As imagens abaixo representam os sprites das cartas que temos, já reduzidas um pouco se comparadas ao planejado no GDD.

Já as duas imagens seguintes, são as 52 primeiras cartas em inglês e as 52 seguintes em português, criadas dinamicamente na Unity através da programação.

Só para criar as cartas, são 4 scripts que executam as seguintes funções:

1. CreateDeckCards: cria uma lista para guardar as cartas criadas sequencialmente (como é mostrado na imagem do deck) e vai chamando a função (script seguinte) que aceita qual o tipo de carta criar (“inicial”, “final”, “esfria a mente”, etc), qual a operação matemática envolvida (Nenhuma, Adição, Divisão, etc), valor inicial da carta (caso tenha mais de um tipo e com valor), valor final da carta, quantas cartas terão no jogo (2, 4, etc);
2. CreateCardsByType: recebe os parâmetros do script anterior, executa um loop de acordo com os valores inicial e final da carta, bem como quantas terão no jogo e vai chamando o script seguinte;
3. CreateCard: recebe os parâmetros do script anterior e cria a carta de fato, setando qual o Sprite correto de acordo com o tipo e quais cores as bordas dos textos terão;
4. SetCardElements: lê os dados setados pelo script anterior e atribui os textos e cores corretamente;

Após esse processo, aquela lista inicial com as cartas em sequência é embaralhada e atribuída ao objeto “Deck”.

Embora tenhamos escolhido um jogo de cartas para não ter que criar tanta animação, não queríamos um jogo com movimentações bruscas como no protótipo.

Então decidimos melhorar o script de movimentação das cartas, da origem dela até algum destino (mão do jogador, mesa, baralho, etc) bem como organizar melhor como elas ficariam na mão do jogador (trocando a formação das cartas com uma animação programada).

Fizemos com que até 27 cartas em mãos, a formação seja em leque:

Para facilitar a geração desse leque, o objeto que é a mão do jogador possui um componente que organiza os objetos filhos horizontalmente, com um espaçamento que vamos alterando dinamicamente.

E para a carta nunca “se mexer” dentro da mão quando nesta formação, trocamos o “pivot” dela (ponto que marca a origem e centro) para a região central na base da mesma. Isso também facilitava alterar o ângulo que a carta estava rotacionada em relação à carta vizinha.

Após 27 cartas, a formação muda para horizontal (pois a formação anterior começava a ficar circular):

Estas foram as partes principais que foram alteradas do protótipo para a versão final. Mas várias outras, como animação do painel com os valores de controle da mecânica do jogo, controle da formação das cartas no baralho e verificação de quais cartas podem ser jogadas na mesa foram melhoradas.

Uma outra alteração sugerida pelo Alex é que não utilizássemos as cenas da Unity para termos nossas várias telas, mas que tivéssemos uma cena principal e nossas telas fossem Canvas (objeto na Unity que hospeda os elementos de interface com o jogador) para melhorar o desempenho quando fôssemos colocar o jogo em dispositivos mobile.

Com isso em mente, foi iniciado o desenvolvimento das várias telas previstas e a transição entre elas. Embora os sprites e imagens finais não existissem naquele momento, foi a primeira tarefa a ser concluída, antes ainda de iniciar o desenvolvimento da versão final do jogo.

Começar o jogo pelo final, ou seja, pelas telas, foi uma decisão bem acertada. No final, apenas trocávamos a imagem dos botões e do fundo da tela.

Dificuldades, problemas e cortes no projeto

Foram várias as dificuldades e problemas que surgiram. Eles sempre aparecem. Vou citar alguns de forma categorizada para separar melhor.

Dificuldades:

• A metodologia Scrum não funcionou muito bem para a equipe. Já trabalhei em empresas em que utilizávamos Scrum e é um excelente framework. Mas como a maioria dos integrantes da equipe desta 4ª maratona tinha pouco tempo para se dedicar ao projeto e nem sempre nos mesmos dias e horários, fora as dificuldades corriqueiras que surgem como falta de internet, de energia, e até mudança de endereço, o controle das tarefas, execução das sprints e reuniões para saber como estava o andamento do projeto não tiveram o efeito esperado;
• Alguns dias ficamos incomunicáveis devido à correria no dia a dia dos integrantes;

Problemas:

• A formação em leque das cartas na mão, com o “pivot” alterado para o centro da base, funcionou bem até o momento em que começou a ser programado a jogada da carta na mesa. Neste momento, o “pivot” deve voltar a ser central e isso alterava a localização da carta. Demorou um pouco para encontrar uma solução para isso e o primeiro atraso no projeto aconteceu neste momento;

• O script de movimentação das cartas, principalmente a parte do “flip” (simulando a troca do verso pela face da carta) demorou mais tempo que o previsto, e isso gerou mais atraso no cronograma;
• A animação da barra de tempo para a jogada não funcionou como previsto (necessitando de alteração posterior) e outros problemas e conflitos começaram a aparecer na véspera da entrega do projeto, o que nos fez desativar muita coisa para arrumar depois;
• Em algumas máquinas, o jogo apresenta problema de desempenho na tela de gameplay. Ainda estamos investigando onde exatamente está o problema.

Cortes no projeto para entregá-lo no prazo foram necessários devido às dificuldades e problemas que foram surgindo. Abaixo a lista do que foi necessário deixar para depois, em algum update futuro:

• Todo o jogo em multiplayer foi deixado para depois. Não chegou nem a ser programado devido aos vários atrasos;
• As roletas que teríamos no início da partida, para setar os valores iniciais do painel de valores do intervalo, foi cancelada pois não eram características primordiais e também não teríamos o multiplayer agora;
• As cartas podem ser jogadas na mesa com duplo clique ou com o arrastar e soltar. Mas também teríamos a seleção da carta por um clique, com um segundo clique para jogar a carta de fato. Para isso, ao dar o primeiro clique, a carta se destacaria das outras, mudando a formação na mão. Mas isto foi cancelado devido aos atrasos e por não ser tão rápido de implementar;
• A inteligência artificial dos oponentes teve que ser deixada para depois também. Ficando apenas a IA básica no modo “chutômetro”, igual a do protótipo. Seriam três níveis de IA, em que o último nível iria armazenar os valores do painel no momento em que um jogador comprasse uma carta do baralho, pois isso indicaria que a situação atual do painel impede aquele jogador de jogar as cartas. A IA usaria isso contra o jogador;
• Sistema de escolha dos avatares e de um nome para eles, bem como um “save” destas características e “High Score” também foram cortados;
• Faltam vários efeitos sonoros no jogo, mas serão implementados.

Enfim, foram vários os problemas que deram uma enxugada no projeto. Mas aos poucos estas características vão sendo implementadas e o jogo vai amadurecendo.

Conclusão

Entregamos o jogo e já melhoramos algumas coisas nele. Estamos bem felizes com o resultado e pretendemos melhorá-lo ainda mais e lançá-lo para mobile. Por este motivo, os elementos durante a partida são bem próximos e a carta ficou um pouco maior do que a versão do protótipo.

Mas, criar um jogo não é nada fácil. Cometemos o erro de subestimá-lo por se tratar de um jogo de cartas.

Achamos que seria tranquilo entregar no prazo todas as características previstas. Percebemos que não importa o estilo de jogo, tudo deve ser planejado e testado o máximo possível e nada deve ser subestimado.

Como planejamos bem as etapas e detalhes iniciais do projeto, os problemas só apareceram bem mais tarde, justamente nas partes em que não havíamos testado alguma mecânica antes ou não foi pensada direito a relação dos objetos durante o gameplay (como a mecânica da carta “Cavalo de Tróia”, que deu um trabalho a mais ser programada). Entretanto, já é uma boa evolução em relação aos projetos anteriores.

Conforme vamos atualizando o jogo, vamos informando no Presskit e na página do jogo no Facebook.

As dicas que deixo são planejamento, estudo e testes de mecânicas antes de chegar o momento de tê-las funcionando, e prototipagem. Com isso, e com o feedback do maior número de pessoas possível, a chance de terminar o jogo aumenta bastante.

Agradeço ao Raphael Dias pela oportunidade e a todos que leram até aqui.

Obrigado pessoal. Até mais. 🙂