Recentemente eu resolvi participar de uma Game Jam sozinho – como o título já diz – a Ludum Dare 33! (vulgo #LDJAM no Twitter)

Eu praticamente só pude ficar em casa na segunda-feira, o equivalente às últimas 24 horas de Jam. Entretanto, fiquei satisfeito por ter conseguido fazer um jogo simples mas coerente – com seus devidos bugs, como todo bom produto de Game Jam.

Como estava “all by myself”, sempre que corrigia algum problema, apareciam outros 340 mais graves. É muito ruim você não ter alguém para falar “estou no meio de um negócio aqui, você pode dar uma conferida nisso?”. Ao mesmo tempo, foi uma experiência muito boa porque cada falha que ocorria eu sabia quem era o culpado: o Windows eu.

Foi justamente a possibilidade de ver os gargalos em cada etapa do processo  e as gambiarras implementações que eu fiz para contorná-los que me deu vontade de escrever esse post. Vou enumerar os meus principais erros e o que eu acredito que deveria ter feito.

Antes, gostaria que vocês dessem uma olhada no jogo na página da Ludum Dare.
Pois bem, vamos à lista de erros:

1 – Comecei primeiro com o secundário.

A mecânica principal do jogo é muito simples: apertar Up ou Space para emergir do lago e matar os cubos brancos eskimós.

Entretanto, eu gastei a maior parte da manhã/início da tarde da segunda-feira tentando fazer o player se movimentar automaticamente da direita para a esquerda enquanto variava a altura também (pra não ficar linear); criando a camada de gelo e fazendo este subir e descer quando o monstro colidisse com ele; e depois de tudo isso eu tinha 0 eskimós para serem devorados. Ou seja, não tinha jogo.

Apesar de ter achado a pedra de gelo subir e descer um efeito muito legal, e de no fim das contas o movimento do personagem não estar tão linear, teria sido muito melhor se o pulo e a colisão com os eskimós já estivessem prontos. Só depois de muito tempo que eu pensei “Ok, por que eu não faço um movimento linear e um pulo qualquer, e depois me preocupo com esses detalhes?”

Acredito que eu teria poupado muito tempo, levando em conta que é jogo extremamente simples. Quanto mais complexo o jogo, mais planejamento e uma visão da “big picture” antecipada são necessários.

2 – Tentei aprender a mexer com uma ferramenta – durante a Jam.

Eu sou uma negação para mexer com sistemas de animação. Eu não consigo de maneira nenhuma lembrar dos detalhes e acabo perdendo horas em fóruns e revisando o manual da Unity. Pois bem, foi isso que aconteceu. Por algum motivo de estupidez imensa eu resolvi fazer a movimentação do monstro ser uma animação. Deu tudo errado, resolvi excluir todas as animações e, com elas, umas 3 horas de Game Jam.

Veja bem, você deve aprender a mexer em diversas ferramentas durante a sua vida. Mas quando o tempo está corrido isso atrasa o projeto e desanima: você vai se ver investindo tempo em uma tarefa que não fornece um resultado satisfatório na maioria das vezes. Isso é bem frustrante.

3 – Não desenhei.

Não me leve a mal: eu sou programador e tenho dificuldades até para sublinhar livros usando uma régua. Porém, fazer desenhos das mecânicas que você pretende implementar: como os personagens vão se mover, como é o pulo, etc., são coisas que todo programador deve fazer.

Quando eu terminei de implementar os eskimós, eu nem pensei que eles cairiam nos buracos deixados quando o monstro colidisse com um bloco na frente deles. “E se tiver um buraco em frente ao eskimó?”, é uma pergunta que teria surgido se eu tivesse desenhado e analisado com mais calma o cenário e suas possibilidades.

Outra situação: e se o eskimó estiver em cima do bloco de gelo? Vai voar? Vai morrer? Eu não tinha decidido nem isso! E só comecei a pensar quando implementei e vi isso acontecendo. Acabei tendo que dar várias soluções na pressa e que até funcionaram, mas ainda me pergunto se foram as melhores.

Ou seja, pegue seu lápis e borracha e DESENHE. Isso vai te ajudar a enxergar os what if's.

4 – Não fiz modelagem alguma.

Todo projeto eu prometo a mim mesmo que vou ser mais organizado. E sempre acabo colocando tudo no mesmo script. Eu sei que fazer uma boa modelagem dá muito trabalho, na verdade, eu nem conseguiria fazer uma - boa - já que só pude programar na segunda-feira. Mas “sair programando” nunca é a melhor solução.
Acho que o meu jogo tem uns 4 scripts, 2 deles devem ter umas 10 linhas (Score e o fade do título) e outros 2 umas 100-200 linhas (MonsterController e EskimoController) fazendo tudo que é possível. Tenho várias flags em cada arquivo o que faz com que o sistema fique muito mais instável – e com que eu tenha muito mais dificuldade para realizar qualquer correção ou ajuste que não seja a “moveSpeed” do player.
Se eu tivesse utilizado pelo menos 1 hora pensando e desenhando diagramas, por mais simples que fossem, eu teria poupado muitos Ctrl+Z/Ctrl+Y e muitas horas da Game Jam.

5 – Tamanho importa.

E coisas pequenas devem ser feitas com cuidado.
Claro que deixei pra pensar em sons e músicas no fim de tudo, como todo péssimo bom desenvolvedor. Logo, tive que apelar para o BFXR e gerar um som aleatório de pulo – que foi muito criticado aliás, com razão.

Quanto às builds… a - misericordiosa - Ludum Dare deixa você enviar correções depois, caso contrário meu jogo estaria totalmente perdido. Fiz e refiz várias builds e perdi umas boas horas da minha terça-feira com essa desgraçada maravilhosa tarefa.
Inclusive, a que está online permite que você mova o monstro no ar, o que eu tinha colocado só pra teste e esqueci.
Esses pequenos detalhes - música, imagens, lixo no código - não podem ficar para as últimas horas. Pelo menos tenha em mente o que você pretende fazer e anote em algum lugar! Vai te poupar muito tempo e proporcionar um projeto com muito mais qualidade.

Conclusão: apesar de todos esses erros – e muitos outros – o jogo foi enviado, bem elogiado e eu escrevi um post! Quem sabe na próxima Game Jam eu não dê uma relida antes?

Pretendo gravar um vídeo mostrando o jogo e explicando algumas implementações, inclusive que as gambiarras para tratar dos what if's que falei.

Um grande abraço!

Nort surgiu da ideia de juntar de alguma forma o combate com combos de jogos Arcade de luta com jogos Shoot'em Up. Não queríamos um jogo de nave comum que você sobe, mata inimigos que aparecem na tela e no máximo você consegue upgrades de tiros e etc. E a mecânica pareceu algo que pode combinar com isso.

Mas essa foi apenas uma das várias ideias que tivemos durante o brainstorming e que, sinceramente, foi bem custoso de definir uma ideia para seguir. Depois de um tempo maior do que imaginávamos para uma reunião de brainstorming decidimos ir por esse caminho. Então começamos a desenvolver no final da noite de sexta-feira até mesmo por causa de compromissos que já tínhamos.

O problema mais frustrante certamente foi os relacionados ao versionamento. Usamos o mercurial (Hg) e sabemos que a maioria dos erros foi por nossa culpa, mas serviu como um bom aprendizado para todos. Porém, apesar de todos os problemas, ficamos bastante felizes com o resultado final! Tem muita coisa que gostaríamos de acrescentar ao jogo ainda, mas conseguimos fechar um produto mínimo viável (MVP) que creio passar bem a nossa ideia.

Para ver como ficou o jogo, segue o link para a página do jogo.

Nesse final de semana (17/07 ~ 19/07) participamos de uma GameJam pela primeira vez juntos para aprendizado. E não temos duvida que aprendemos muito! Apesar de quase não conseguir enviar a tempo conseguimos no ultimo minuto e o resultado é esse: http://gamejolt.com/games/nort/80852. Trata-se de um top-down space-shooter, onde o jogador pode fazer combos para lançar uma habilidade especial - até agora só temos um raio laser.

Como toda Game Jam, tivemos vários problemas que atrapalharam nossa produtividade. Dentre eles o principal foi o nosso controle de versão. Ainda não sabemos exatamente a causa, mas provavelmente configuramos o documento de "arquivos a serem ignorados" errado, então toda vez que realizávamos um pull do projeto, perdíamos diversas referências entre os Game Objects, imagens, etc. Por exemplo, a imagem do tiro de um dos inimigos (as torres) sumiu e não percebemos antes de enviar a build.

Claro que se tivéssemos nos programado melhor teríamos mais tempo para fazer testes e ver o que estava errado/faltando antes de enviar a versão final para o site. Isso fez com que planejamento e time-box fossem itens adicionados à nossa lista de "o que melhorar".

Tivemos várias ideias que não puderam ser colocadas no jogo, por exemplo, um boss que ao ser derrotado desse uma nova habilidade para o jogador (um novo combo, por exemplo). Essa semana nos reunimos depois da Jam e decidimos consertar os defeitos do jogo e tentar implementar as ideias que não deu tempo nas 72 horas.

Assim que o projeto estiver atualizado, vamos avisar aqui!