SPJAM 2015

Ontem aconteceu o SPJAM 2015, que reúne diversos profissionais ou apaixonados por GameDev em uma maratona de programação. Dessa vez o evento contou com 220 participantes, que tiveram 48 horas para criar um game. Esse ano estive presente como programador em uma equipe de três pessoas. Seguem aqui os meus comentários pós-evento.

Equipe

Estava em uma equipe de três pessoas, mas com uma primeira grande dificuldade: produzir um jogo sem artistas ou designers. Poderíamos ter chamado outras pessoas, mas nessa ocasião específica o objetivo era manter a equipe.  Afinal, as equipes no mundo real são sempre limitadas. É importante compreender as falhas da equipe e contorná-las.

Entretanto, depois de refletir no pós-evento, gastamos muito tempo avaliando diferentes artes. Logo, deveríamos ter chamado outra pessoa. Ela poderia ajudar pontualmente, não precisando estar fixa na nossa equipe. Isso reflete a vida real, na qual precisamos reconhecer nossas limitações e pedir ajuda quando necessário.

48 Horas

Foram 48 horas de evento programando e admito que é difícil manter o grau de concentração. Aqui conseguimos organizar bem os objetivos pontuais usando uma metodologia similar ao Kanban com vários objetivos curtos. Foi isso que manteve a produtividade na madrugada.

Durante um momento de reflexão, vejo que é mais importante eficiência do que tempo adicional. Portanto, minha conclusão é que precisamos reconhecer os limites do corpo em relação ao sono e à alimentação. A competição é contra você mesmo e não contra as outras pessoas. Uma vez que compreendemos isso, então podemos gerenciar melhor o escopo do projeto e definir metas adequadas.

O objetivo deve ser sempre entregar um produto final com o “mínimo apresentável”, pois muitas vezes nos perdemos em um escopo grande e não entregamos nada no final.

Experimentar

O tema do SPJAM 2015 foi “viagem com G ou com J”. Gosto muito da ideia de temas porque abre a mente! Se não houvesse tema, acho que muitas pessoas fariam um Endless Runner ou um clone de Flappy Bird. Além do tema ser diferente, gosto de aproveitar esse tipo de evento para experimentar diferentes mecânicas ou tecnologias. Antes do evento imaginava usar um VR de Cardboard, Kinect v2 ou WebGL, que são tecnologias que conheço muito pouco e gostaria de me aprofundar. Durante o evento a equipe decidiu usar Unity 3D, que já estou bem acostumado a usar e não teria muita dificuldade. Então resolvi inovar na questão sobre o que fazer e criei um “Editor de Mapa Grid”.

O resultado foi ótimo! Em menos de 8 horas, consegui concluir o editor de mapa com funcionalidades de selecionar tiles, criar mundo e, mais importante, salvar em disco. A melhor parte é que posso usar em futuros projetos de games. Mas será que realmente o resultado foi bom?

Experimentar demais é igual a fazer experimentos, mas não projetos. Talvez devesse ter gasto mais tempo com o tema ao invés de construir uma ferramenta de suporte? Essa é uma questão em aberto.

Nossas Falhas

Erramos em várias coisas. Se tivesse que escolher apenas uma, então diria que o nosso maior problema foram as ferramentas. Nosso time não veio com as ferramentas pré-instaladas e testadas (Unity 3D). Estávamos também utilizando ferramentas diferentes para editar – Visual Studio Community e VS Code. Por fim, perdemos a manhã inteira configurando um servidor GIT para permitir trabalhar em equipe mesmo quando o sinal WiFi estivesse fora do ar. Por isso, acho que falhamos em chegar despreparado (do ponto de vista de ferramenta) no evento.

Começamos a trabalhar no sábado depois do almoço – restando apenas 30 horas das 48 totais. Portanto, vale a pena gastar um tempo antes com a questão de preparação no notebook e um teste de equipe.

Conclusão

Em nenhum momento desse post falei sobre o sistema de física da Unity ou então da renderização de shaders. Tudo que falei foi sobre questões que me lembram de projeto ágil.

• Definir uma equipe equilibrada
• Escopo do projeto é crucial
• Organização de tarefas otimizam o tempo

Na realidade, concluo que DevOps tem muito a nos ensinar. Nossa grande falha, por exemplo, foi durante a configuração do GIT e das ferramentas de trabalho para facilitar a colaboração entre nós três. Tenho certeza que isso faria toda a diferença no nosso caso.