Ponto V!

Home Mercado Post Mortem Reapers Collector - Postmortem
Bruno Crivelari Sanches
Reapers Collector - PostmortemImprimir
Escrito por Bruno Crivelari Sanches

Este ano de 2013 mais uma vez tive a oportunidade de participar do Global Game Jam na PUC-PR, que para quem ainda não conhece é um evento que ocorre todo ano onde o objetivo é a criação de um jogo em 48 horas, o resultado é claro foi mais um jogo, que de forma impressionante, ficou pronto horas antes do fim do evento, enquanto muitas equipes corriam com últimos ajustes, a nossa equipe visitava as demais equipes e aproveitava para descansar um pouco, nas próximas linhas, pretendo contar um pouco mais de como foi feito o jogo, as coisas boas e ruins do nosso projeto.

Global Game Jam

O evento, como já comentado ocorre todos os anos e o objetivo é a criação de um jogo em 48 horas. É um evento mundial dividido em centenas de sedes, onde cada sede abriga uma ou mais equipes. Cada equipe desenvolve um ou mais jogos, no prazo estipulado e de acordo com o tema proposto.

O tema do jogo é revelado minutos antes do inicio, de forma que todas as equipes possam competir em iguais condições. A disputa propriamente dita é um tanto subjetiva, já que não existem prêmios ou qualquer coisa do gênero, sendo que o “prêmio” é na verdade poder se orgulhar de ter um jogo feito e ainda por cima em um prazo tão apertado.

Outro “prêmio” é ter mais um jogo para seu portfólio / currículo, sem falar que alguns jogos criados durante a Jam acabam se tornando produtos comerciais e gerando renda a seus criadores, este ano, das produções brasileiras o destaque foi para o Surgeon Simulator da Bossa Studios.

Equipe

A equipe é o principal fator a se preocupar de quem participa do evento, sendo que o principal item a considerar é a confiança e motivação dos membros, que chega a meu ver ser mais importante do que conhecimentos técnicos individuais, estes ajudam, mas de nada adianta ter um “guru” na equipe, se este não é muito colaborativo.

8415237705_7bdda83990_oEste ano minha equipe foi formada por:

  • Bruno Crivelari Sanches (@bcsanches): programação
  • Danny Angelo Carminati Grein (fungos): programação
  • Marlus Cadanus da Costa: programação
  • Murilo Cadanus da Costa: programação

Como podem notar, a equipe foi formada exclusivamente por programadores e o grande problema disso é que arte e parte sonora do jogo iriam sofrer, algo que já sabíamos desde o começo. Quando começamos os primeiros contatos encabeçados pelo Danny meses antes da Jam sempre tivemos déficit de artistas, que infelizmente não conseguimos resolver.

A tacada final foi tentar conseguir artistas no próprio evento, pois é comum ocorrer de pessoas se inscreverem na Jam sem terem equipes, o que pode tornar o evento também um ótimo meio de aumentar a rede de contatos. Mas como todo ano, artistas são artigo de luxo e no final, tivemos que nos virar com a famosa arte de programador.

Sede

O Game Jam é dividido em diversas sedes e a cada ano que passa, mais e mais sedes são criadas no Brasil. Esta foi minha segunda participação na Game Jam (para saber sobre a minha primeira, vejam detalhes aqui) e novamente escolhi a PucPr, os motivos foram em grande parte pessoais, pois:

  • É a universidade onde me formei, então conheço bem a cidade e a universidade, (para quem não sabe hoje vivo a 630 km de Curitiba) então acabo me sentindo “em casa”, mesmo tendo que lidar com o stress da viagem.
  • Por ter estudado no local e também ter passado parte significativa da minha carreira como desenvolvedor de jogos na cidade, tenho muitos contatos, o que ajuda na formação de equipe.
  • A PucPr é veterana na Jam e investe muito no evento, principalmente por causa equipe que não mede esforços para fazer o evento um sucesso. Por ser uma sede veterana, é bem incomum pessoas terem grandes problemas com infraestrutura, você não precisa se preocupar em resolver problemas de internet ou achar uma tomada, além de coisas mundanas como ter um banheiro descente, local para dormir e até chuveiros a disposição.
  • É uma ótima oportunidade para rever antigos amigos!

Não conheço outras sedes, mas até o momento, não tenho a menor vontade de “trocar” de sede.

Então a dica é: na hora de escolher sede, nem sempre a mais próxima pode ser o melhor local para você, escolha aquela onde você tiver a melhor rede de contatos e infraestrutura.

O Jogo

Finalmente vamos falar do jogo: O tema deste ano foi o som do coração ou batidas do coração, que foi apresentado apenas como som das batidas de um coração. De cara descartamos os temas óbvios como amor e romance, que aparentemente não era de interesse de ninguém da equipe.

Como na minha participação anterior, decidimos ir para a lanchonete fazer um lanche a aproveitar para discutir as ideias, sair da “muvuca” da Jam ajuda muito neste momento inicial.

Antes de desenvolver a ideia do jogo, algumas coisas já tínhamos deixado claro: o jogo seria em 2d, afinal, 48 horas já é um prazo apertado para um jogo, ainda mais com toda sobrecarga extra de um possível jogo 3d, tanto para programação, quanto para arte.

Aos poucos foi surgindo a ideia, que no final acabou no conceito da morte selecionando um qualquer para ajudar ela a coletar “vidas”, representada no jogo pelos corações. A morte lhe persegue o jogo todo e apenas se satisfaz quando você coleta um coração para ela, caso você não o faça, ela “coleta” o seu.

Com a ideia e o “design” pronto, era partir para a implementação, pois já tínhamos um caminho a seguir.

Iniciando o Projeto

Antes de escrever qualquer linha de código, desenhar qualquer pixel: configure um sistema de controle de versão. Eu fico impressionado como novamente, algumas equipes mal sabiam do que se tratava isso e muitas, ainda negligenciam essa ferramenta tão importante e básica para qualquer projeto.

E mais uma vez esse ano, vi equipes se queixando que no meio da madruga se deram conta que haviam perdido diversas modificações ou até tudo, porque alguém apagou / sobre-escreveu arquivos errados ou uma ferramenta resolveu corromper arquivos.

Hoje temos diversos serviços grátis e excelentes como Google Code, Github, Bitbucket e até o Sourceforge (esse ultimo não sou grande fã), onde em alguns minutos se cria uma conta e um projeto e já se pode desde a primeira linha de código ter tudo versionado e dentro do sistema de controle de versão.

O controle de versão foi essencial para a nossa equipe, sendo que em alguns momentos na ultima madrugada, tínhamos fila no sistema, onde entre um update e commit, você já se encontrava desatualizado e precisava fazer outro update. Mas graças ao git, não perdemos um byte sequer. No sábado tivemos 58 commits e no domingo foram 105!

Para se ter uma ideia de como o controle de versão ajuda e ainda nos da informações bem interessantes, abaixo temos o gráfico de quanto código foi produzido nos dois dias e a produção de cada desenvolvedor, mesmo eu considerando que “número de linhas de código” não é uma métrica para se avaliar um desenvolvedor, é bacana como fica o gráfico gerado:

Capture_git

Para quem tiver curiosidade, nosso repositório: https://github.com/ggj/reapers

Outra dica específica de Game Jam, mas fundamental: teste todas as ferramentas e tudo mais antes do evento. Eu, por exemplo, semanas antes do Jam já tinha testado todas as ferramentas que havíamos concordado em usar, ao chegar no Jam, bastava apenas ligar o computador, estava tudo instalado, configurado e funcionando. Não desperdice seu escasso tempo configurando computador, deixe ele para coisas mais importantes como acessar o twitter Smile.

Definido o projeto, era hora de começar a codificar, mas começar por onde?

Desenvolvimento

Projeto definido, hora de codificar. Todos da equipe já eram programadores experientes na área de jogos, apesar de eu ver o Jam como uma ótima oportunidade para aprender, não é o melhor local, já que o prazo apertado não da muito espaço para isso. Então foi mais uma questão de olharmos para o que tínhamos pela frente e decidir o que fazer. Mas sem dúvida alguma, é um ótimo local para se ganhar experiência na produção de um jogo.

A linguagem de desenvolvimento foi o C++ com a Seed Framework, que é uma biblioteca para criação de jogos 2d desenvolvida pelo Danny. A Seed sofreu diversas mudanças nos últimos anos e já tinha algum tempo que não era usada em projetos, o Danny queria criar um demo para a biblioteca, eu queria usar C++, então como se diz popularmente: juntou a fome com vontade de comer.

O uso da Seed foi um dos pontos arriscados do projeto, pois a biblioteca naquela época estava ainda em um ponto “instável” e carente de algumas funcionalidades, que acabamos por desenvolver durante a Jam. Por outro lado, a biblioteca nos forneceu inúmeras facilidades, não era preciso se preocupar com diversos mecanismos básicos e outros nem tão básicos assim de um jogo, pois ela já cobria tudo e muito bem. Sem falar que tínhamos nosso “especialista em Seed” de plantão, o Danny.

Não é recomendável no Jam querer fazer um motor, mas nós fizemos os dois: criamos um jogo e ainda incrementamos o motor.

O jogo em toda sua glória

A divisão de tarefas foi fundamental: partindo de um dos exemplos da Seed, criamos a mecânica básica de um jogo: splash screen – menu – jogo. Em pouco tempo tínhamos então o esqueleto do jogo rodando, foi então hora de dividir tarefas tirando o melhor proveito possível das experiências de cada um: Inicialmente foquei em criar os mecanismos de gameplay, como gerenciamento de entidades, processamento de input, etc, enquanto os demais trabalhavam nos componentes básicos do esqueleto do jogo. Com essas tarefas concluídas, a equipe partiu para tarefas, como, por exemplo, integrar a biblioteca de física box2d com a Seed e o jogo, que se me lembro direito, foi o Danny quem iniciou a integração e depois eu terminei, ao mesmo tempo os irmãos Cadanus trabalhavam na movimentação do jogador e mais tarde o Danny passou então a focar no suporte técnico e correção de bugs da Seed.

Com o sistema de gameplay funcionando e a movimentação do jogador, passei a trabalhar no sistema de colisão, afinal, uma biblioteca de física cuida de fazer as coisas colidirem, mas a resposta no gameplay é problema seu. Então implementei os mecanismos para gerar eventos de colisão, o que nos permitiu assim saber quando o jogador era atingido, coletava itens, teletransporte, etc. Ao mesmo tempo o resto da equipe vestiu a camisa de level designer e começaram a trabalhar na criação de níveis. Com a física funcionando, passei a fazer um pouco de play testing e a criar itens e o inimigo do jogo.

Durante o play testing encontrei diversos problemas nos níveis, como pontos inacessíveis nos mapas e pontos de enrosco, onde o jogador ficava preso. Os demais membros da equipe também começaram a arranhar como artistas, caçando imagens e tilesets livres na internet e dando retoques em algumas imagens.

Com o gameplay funcionando resolvi vestir a camisa de sound designer e usando o excelente sfxr em pouco tempo criei todos os efeitos sonoros do jogo.

Por fim, partimos para os ajustes e problemas finais, correção de bugs e testes, muitos testes. No final da manhã do último dia consideramos o jogo estável o bastante e sem nenhum bug visível, era hora de empacotar. Criei as versões Windows, enquanto o Danny cuidou das versões Linux e MacOS.

É notável aqui que não detalhei muito o trabalho dos colegas, em especial porque a divisão de tarefas era tão boa, que cada um cuidava muito bem da sua parte, com pouca interação, então fica difícil recordar em detalhes o que cada um realizou.

Pontos Positivos

O principal ponto foi: criamos um jogo completo! Muitos projetos acabam com apenas um nível jogável e olhe lá. Antes do prazo final já tínhamos o jogo completo, com splash screen, um menu funcional, diversos níveis, com direito a nível final e fim de jogo. Além de um hud funcional, mostrando vidas e outras informações, além de efeitos sonoros.

A divisão de tarefas foi algo importante, como a equipe já era experiente, simplesmente listamos os principais trabalhos a serem feitos e cada um foi assumindo aquilo que lhe era mais familiar e/ou conveniente, dessa forma rapidamente foi possível ter o jogo funcionando.

Outro ponto bom foram os testes de gameplay, quando nos demos por satisfeito com o jogo e já tínhamos tudo integrado, foi hora de jogar. Todos os membros da equipe jogaram o jogo por completo ao menos uma vez, isso é fundamental para se encontrar falhas no design e principalmente no level design.

Além do nosso play testing, foi enviada a versão beta para alguns conhecidos (aqueles que apareceram online na hora certa receberam uma cópia), que logo apontaram alguns probleminhas que deixamos passar, sendo o principal: como se joga? Problema que foi facilmente resolvido com a adição de instruções na primeira fase, que é extremamente simples e força o jogador a aprender a jogar de forma intuitiva, sem necessidade de tutoriais ou instruções, como nos antigos jogos.

A ferramenta sfxr (http://www.drpetter.se/project_sfxr.html) foi fundamental para suprir o cargo de “sound designer”. Claro que a ferramenta não substitui um músico e/ou designer de som, mas facilita em muito a criação de sons até mesmo para estes profissionais, no nosso caso, ela foi o nosso “sound designer”.

Um fato diferente nessa Jam é que algumas horas depois do inicio do evento, acabamos decidindo por ir trabalhar na casa do Danny, pois com o cansaço avançando e membros querendo ir para casa para descansar e um banho, concluímos que a separação da equipe poderia ser algo fatal (eu no final das contas era o único da equipe preparado para passar às 48 horas na PUC, com roupas, artigos de higiene e até colchão inflável), então fomos para a casa do Danny que acabou virando nossa sede, muito mais tranquila que a sede oficial em alguns aspectos.

O jogo ficar pronto antes da hora foi um fato positivo, primeiro que o jogo não sofreu alterações e modificações significativas de ultima hora, o que minimiza muito a chance de problemas e bugs, por fim, a versão final enviada ao site do evento foi muito testada por nós e pessoas de fora, o que nos permitiu tempo para uma segunda submissão com correções, em especial adição de um pequeno texto explicativo na primeira fase (contribuição do ViniGodoy), como pode ser visto na imagem abaixo:

screen03

ps: não ter artistas era uma vantagem também, assim não precisamos aguentar eles reclamando das ferramentas e nem ouvir suas ideias malucas Smile (brincadeira hein? ).

Pontos Negativos

Sem dúvida, o principal ponto negativo foi a falta de artista, que teve diversas consequências, a mais óbvia é claro, os gráficos do jogo que foi baseado em arte vinda da internet, com exceção apenas do personagem principal que era arte não usada de um dos projetos profissionais dos irmãos Cadanus.

Outra consequência da falta de artistas foi o consumo dos nossos recursos de programação, pois estes tiveram que atuar como level designers, artistas e sound designer. O que nos forçou a abortar ideias de gameplay como elevadores, portas e até mesmo a adição de inimigos mais inteligentes.

O uso da casa do Danny foi um ponto positivo, mas ao mesmo tempo um ponto negativo, em específico por causa do Jam. Isso fez com que nossa equipe isola-se, perdendo assim a possibilidade de mostrar o jogo durante desenvolvimento, o que poderia ter criado modificações ou até sugestões interessantes, ao mesmo tempo perdemos também a oportunidade de ver o trabalho das demais equipes enquanto elas evoluíam, um dos pontos altos do Jam é justamente a interação.

Marketing do nosso jogo foi ruim ou inexistente. No final do Jam todos apresentam o seu projeto e na nossa equipe ninguém é grande fã de fazer apresentações, acabou que no final ninguém se animou de fazer tal façanha, o que gerou muita decepção com o projeto e de nossos conhecidos.

Futuro

O futuro já é passado para este projeto, pois esse post-mortem esta chegando meio tarde, praticamente seis meses após o evento. O meu principal objetivo com a Jam sempre foi me divertir e encarar o desafio como realização pessoal de ter mais um jogo no currículo e em especial, mais um feito em 48 horas.

Eu particularmente gostei muito dessa Jam, nossa equipe estava muito bem entrosada e foi diversão do começo ao fim, sem qualquer tipo de discussão ou desentendimento, como é comum em tantos projetos, ainda mais em projetos tão estressantes como este.

Sempre existe a ideia de manter o projeto e transformar ele em um jogo comercial indie, mas aparentemente ninguém da equipe parece estar com vontade e/ou disposição para fazer isso acontecer, então acredito que a vida do projeto se encerrou com o final da Jam.

O que provavelmente vai acontecer cedo ou tarde é o Danny incorporar partes do jogo na Seed, pois muitas coisas feitas durante o Jam já foram feitas de forma genérica para um reuso futuro em outros projetos, assim acredito que a ultima coisa em relação a este jogo vai ser este post-mortem, que o Reapers Collector descanse em paz!

Ferramentas

As principais ferramentas foram:

Download

Jogo: http://globalgamejam.org/2013/reapers-collector

Código fonte: https://github.com/ggj/reapers


Comentários (3)
  • João  - muito legal
    avatar

    cara "eu tenho um sonho", eu queria saber se vc pode me recomendar alguma leitura - daqui mesmo ou de fora- pra eu entender o que é uma biblioteca tipo essas :Seed Framework, Box2d, SDL e OpenAL. que eu sou meio lento mesmo e naum achei no google, valew.

  • Anônimo
    avatar

    Oi João,

    não consigo pensar em alguma leitura que explique o que é uma biblioteca especifica. Pois é como perguntar: O que é o livro "O Senhor dos Anéis", o que é o livro "20.000 leguas submarinas", etc.

    Bibliotecas a melhor forma de entender elas é procurar no google, se não consegue usar o google, então procure aprender. Geralmente o site oficial explica tudo sobre a biblioteca.

  • João  - valeu
    avatar

    O mundo da informatica é assim afinal de contas certo? Mas valeu.

Escrever um comentário
Your Contact Details:
Gravatar enabled
Comentário:
[b] [i] [u] [url] [quote] [code] [img]   
:angry::0:confused::cheer:B):evil::silly::dry::lol::kiss::D:pinch::(:shock:
:X:side::):P:unsure::woohoo::huh::whistle:;):S:!::?::idea::arrow:
Security
Por favor coloque o código anti-spam que você lê na imagem.
LAST_UPDATED2  

Busca

Linguagens

Twitter