postmortem

Postmortem: Happiness

Publicado em Atualizado em

Por Sharbel Freiberger – FIREhurricane

Apesar de já termos participado de algumas GGJs e várias Ludum Dares, tanto em equipe quanto solo, ainda assim todo evento sempre é uma surpresa. Existe alguns padrões de fatos que acontecem em todos eventos, e no geral sempre coisas boas. Nessa última GGJ por exemplo, já chegamos com algumas definições estabelecidas: quem faria o que, e o que usaríamos para desenvolver o jogo.

Unity3D era uma certeza. Ela é uma ferramenta muito boa, e eventos assim são ótimos para praticar e aprofundar o conhecimento em desenvolvimento. De fato foi isso realmente ocorreu no evento, já que fomos ao evento sem conhecer as novas atualizações da Unity para jogos 2D, e na programação tivemos problemas com algumas coisas que nunca tínhamos usado no desenvolvimento como o sistema de animação e os novos scripts de física, e isso gastou mais tempo do que prevíamos.

Quando recebemos o tema, tivemos um brainstorm muito rápido: como trabalhamos juntos a um tempo, já cometemos erros comuns como bolar projetos megalomaníacos, ou tentar elaborar um sistema de jogo muito complexo sem ter um conhecimento mínimo para usar uma mecânica similar. Escolhemos então o mais simples possível: Runner. Mas o tema permitia uma viagem de idéias maior, e foi quando eu pensei que seria interessante se no runner o jogador não tivesse que jogar o jogo como um Runner comum, assim ele poderia visualizar o “outro mundo”. Wallace havia pensado mais na parte da história, pois a idéia era não ter uma história muito óbvia, como acreditávamos que a maioria seria.

Como nosso time era composto por dois programadores a arte poderia ser um trabalho, porém o Wallace havia feito um curso recente de Pixel Art e ficou responsável pela arte, usando o tempo para colocar em prática tudo que tinha aprendido no curso. O curto espaço de tempo sempre é um problema, pois você sempre deseja fazer alguma coisa a mais, ou deixar seu jogo o melhor possível, mas cortar extras e fazer um escopo pequeno é essencial para chegar até o final e terminar o jogo nesse prazo. Keep It Simple.

Como são apenas 48 horas, você começa a restringir um pouco de sono e tentar se organizar o máximo possível pra conseguir fazer mais coisas. Isso é bem natural, principalmente quando se tem pouca experiência ou se tem um problema muito sério com o projeto. Mas também sempre é bom largar tudo um pouco e dar uma parada pra limpar a cabeça. O Wallace chegou a fazer isso algumas vezes entre um desenho e outro, e eu como estava na programação tendo dificuldades, quase que não fiz isso.

Uma das maiores vantagens da GGJ é você poder falar pessoalmente com as outras pessoas que estão fazendo os jogos, e ver o que eles estão fazendo. No nosso caso, uma coisa interessante pela qual nunca havíamos passado era a de ficar em uma das salas com outros dois grupos. Isso nos deixou mais próximos, e eventualmente pedíamos comida juntos, efetuávamos testes no jogos e opinávamos.

Isso tanto durante o desenvolvimento quanto na apresentação final, que você vê como ficou o final de todas equipes.

O Que Deu Certo?

  • Escopo do jogo: Por já termos feito algumas LDs e GGJs, já tínhamos noção do tamanho que deveria ser o projeto, o que fazer, o que cortar, como manter um mínimo jogável e a partir dali começar a implementar mais no jogo.
  • Separação de tarefas: O Wallace já estava bem “aquecido” como ilustrador, mas precisou treinar animações também. Eu consegui desenvolver uma mecânica bem interessante no qual utiliza inclusive o novo sistema de animação da Unity, coisa que eu nunca havia feito.
  • Música: Muitas pessoas que jogaram o jogo gostaram bastante da parte da transição, tanto dos gráficos, mas principalmente da música. Houve um cuidado do Wallace ao selecionar as músicas, pois ele selecionou músicas que tivessem o mesmo BPM e em um valor alto (170 no caso).
  • Gráficos “Kawaii”: Recebemos esse feedback que mostrava que os gráficos deram certo. Com o tema escolhido e o brainstorm definido foi possível imaginarmos várias possibilidades de cenários no momento que o jogador estava dopado.
  • Sacada Surpresa: O efeito da surpresa ao notar que o objetivo do jogo é desviar das moedas era sempre de encher os olhos de quem jogava. Um dos feedbacks pegou mais de 200 moedas e perguntou quantas moedas ainda precisava pegar. Ao descobrir que não era pra pegar as moedas e ver a transição, soltou um grito de surpresa, dizendo o quanto o jogo era bom (o termo usado não foi “bom”).

O Que Deu Errado?

  • Engine: Tivemos problemas principalmente por não termos conhecimento nas novas ferramentas da Unity. Isso nos travou por mais tempo do que gostaríamos, e me custou umas horas nas quais eu poderia ter dormido.
  • Animações: Pelo Wallace, uma das maiores dificuldades foi fazer as animações. Ele havia feito uma em Pixel Art dias antes do evento. Ele conseguiu aprender bem apenas no domingo.
  • Evolução dos desenhos: É possível notar nos desenhos uma certa mistura de traços. Como todo ilustrador em início de carreira, o Wallace ainda não tinha encontrado um padrão de desenho.

O Que Fazer Agora?

Atualmente o jogo esta disponível no Game Jolt, e estamos estudando uma forma de torna-lo um Runner com certa objetividade. A idéia é continuar a história após ele sair do transe dos remédios. Vamos deixando as pessoas informadas sobre no site da Game Jolt.

Postmortem: Exodus

Publicado em

Por Israel Steinmetz – Double Cheddar Team

Exodus foi um projeto feito mim e mais dois amigos para a Global Game Jam de 2014 no campus da Unisinos. A ideia de participar da Jam veio como forma de testar nossas habilidades e ver se conseguiríamos trabalhar em equipe. Quando montamos o time, decidimos os papéis de cada um baseado nas suas habilidades e no fim, tínhamos um programador, um artista e um gerente de projeto. Não sabíamos muito o que esperar da GGJ, já que esta iria ser a nossa primeira.

Logo ao chegar o evento, sem saber, um dos fatores que nos ajudou bastante foi definido; conseguimos uma sala, que por algum motivo nenhum outro time quis. Uma sala vazia, com espaço para desenvolver com calma, pensar, conversar e mesmo se entreter. Foi um fator essencial para as condições físicas e psicológicas do time. Ter a liberdade para por músicas nos alto-falantes e um ambiente descontraído foi benéfico para a moral do time. Quando o cansaço apertava e o rendimento diminuía, esses pequenos momentos de diversão ajudavam a equipe. Um outro pequeno detalhe que creio ter contribuído positivamente foi o layout do ambiente de trabalho. Como éramos três, dispusemos as áreas de trabalho do artista ao lado do programador, permitindo maior comunicação entre eles, já que o desenvolvimento requer muita troca de informação de ambas as partes, enquanto eu me posicionei perto dos quadros brancos, podendo ver o resto do time ao mesmo tempo que geria o projeto.

Tudo na Jam conta como fator de risco do jogo. Tempo curto, complexidade, diversão, qualidade. Por isso, no momento de criar o conceito do jogo fizemos um brainstorm levando em conta parte desses fatores. Na realidade foram feitos três brainstorms para não nos fecharmos numa só ideia e forçar a criatividade. Nosso primeiro conceito foi sobre um jogo extremamente metafórico e abstrato. O segundo foi a ideia que deu origem ao Exodus, e o terceiro consistia em outro plataformer, só que a mecânica principal sendo diferente, envolvendo ponto de vista do jogador ao se mexer para frente ou para trás. Escolhemos o conceito que seria do Exodus pois recebemos feedback externo, e vimos que seria interessante valorizar o gameplay, ao invés de fazer algo mais conceitual, e pensamos que a mecânica dessa segunda ideia era mais divertida e interessante que a da terceira. Feedback foi essencial, bem como sair da zona de conforto de uma só ideia no brainstorm.

Possuindo uma ideia, ambiente e o time pronto o que faltava agora era a espinha dorsal do desenvolvimento, a organização. Por exemplo, tanto arte como programação foram bastante discutidos com antecedência, para evitar improvisos ao decorrer das 48 horas. Como gerente do projeto, apliquei Scrum para guiar o time durante o desenvolvimento. Defini com eles as funcionalidades que o jogo deveria ter, e deleguei as funções para cada um. Cada tarefa era dada num intervalo de duas horas, as Sprints (apesar de termos feitos Sprints de três e também de uma hora e meia quando necessário). Cada tarefa ficava anotada num post-it, que era organizado num quadro branco dividido em três colunas: PB, Doing, Undo e Done. PB eram aonde ficavam as tarefas, os Products Backlogs. Doing, Undo e Done eram respectivamente as tarefas que estavam sendo realizadas na Sprint, as que tinham que ser refeitas e as terminadas. O Scrum nos foi útil por diversas razões: Dava feedback visual do andamento do jogo, tínhamos definido quando o jogo acabaria (uma das coisas mais importantes!), permitia administrar bem as horas de trabalho e de descanso, assim não sobrecarregava o time. Dentre tudo isso, obviamente a boa convivência e dedicação do time são essenciais. Café ajuda bastante.

Plataforma: Windows

Tamanho do time: 3 (1 programador, 1 ilustrador, 1 game designer/gerente de projeto)

Ferramentas de desenvolvimento: Wacom CTL-460 Bamboo, Adobe Photoshop (Trial de 30 dias) e a Unity3D.

Som:  usamos efeitos de bibliotecas públicas de som e a música é do Dan-O (licença aberta)