Tomato Hunter - developer post-mortem

(English version coming soon)

Este é o jogo que eu trabalhei como desenvolvedor para a GBJam 5, como integrante do Pxl Squad:

Tomato Hunter é um jogo top-down feito no estilo dos jogos de GameBoy, com Unity3D e Tiled. Vou listar abaixo algumas coisas que deram certo e outras que nem tanto, do ponto de vista do desenvolvedor:

O que deu certo:

• Unity3D - Já trabalhei em outros projetos usando essa engine, então não precisei pensar muito pra escolher; tentar aprender a usar outro framework/engine simplesmente não daria tempo. Uma das vantagens de usar Unity3D é ter um workflow bem definido sobre como fazer determinadas tarefas, o que facilita a divisão de tarefas e o trabalho em equipe, além de ter diversas ferramentas que permitem que todos os integrantes da equipe trabalhem diretamente na engine, ao invés de dependerem exclusivamente do(s) desenvolvedor(es).

• Trabalho em equipe: Durante os 10 dias da GBJam 5, nenhum dos membros da equipe precisou se encontrar: usamos um grupo no Telegram pra se comunicar e compartilhamos arquivos pelo Google Drive, dentre assets e documentação, e os builds eram feitos em HTML5 e disponibilizados em uma página Web. Dessa forma era bem fácil pedir ajustes em um asset e depois ir pegar no Drive, enquanto os parâmetros do jogo eram ajustados diretamente via ScriptableObjects no editor, sem precisar mexer no código em si (ainda falarei mais sobre ScriptableObjects por aqui).

• Tiled: Criar mapas/fases baseadas em tilesets é moleza utilizando essa ferramenta, e dá pra importar sem grandes problemas como asset no Unity3D e em diversas outras engines/frameworks. Não apenas dá pra criar as fases como também adicionar objetos nas mesmas, permitindo que game e level designers possam trabalhar tranquilamente sem depender de outros sistemas. É "de grátis", mas vale a pena desembolsar uns cascalhos caso você ache o programa útil (eu já fiz a minha contribuição :D).

O que não deu muito certo:

• Unity3D - Embora facilite muito as coisas por um lado, o fato de ter um workflow bem definido se torna um problema quando você quer fazer as coisas de maneira diferente. O jogo deveria ter uma vibe bem Game Boy, e pra isso teria que ser 2D e pixel perfect, duas coisas que ainda podem ser um tanto problemáticas na engine. Devido ao tempo e a outras atividades resolvi implementar de um jeito que ficasse "bom o bastante", mas ainda assim ainda faltam diversos ajustes pra se aproximar mais do estilo Game Boy de ser. Num próximo jogo pixel perfect que eu porventura venha a fazer, estou estudando utilizar outros frameworks como por exemplo LÖVE e Nez.

• Reaproveitar código - Pra ganhar tempo, fui reaproveitando alguns blocos de código de outros projetos, e acabou que eu perdi um tempo considéravel adaptando estes códigos ao invés de continuar programando coisas do jogo mesmo. Se você já ouviu alguma coisa do tipo "é só copiar e colar que funciona", saiba que isso é uma das lendas mais antigas e infundadas da Computação - nunca é "só" copiar e colar, códigos não existem em um vácuo e é preciso que sejam feitos de uma maneira específica para que sejam reutilizados. Certas vezes chega a ser mais rápido reescrever um algorimo/função/classe do zero do que adaptar uma já existente.

No geral, foi uma experiência bem interessante, e ver outros desenvolvedores comentando coisas do seu jogo (nem sempre positivas) é um pouco assustador, mas ao mesmo tempo é algo que contribui para o aprendizado, pra tornar os próximos jogos melhores.

Bom, é isso. Que venham as próximas jams!

Atualização 17/10/2016: Adicionada uma seção na parte "o que deu certo"