Ponto V!

Home Mercado Post Mortem Spooky Mansion – Postmortem
Paulo V. W. Radtke
Spooky Mansion – PostmortemImprimir
Escrito por Paulo Vinicius Wolski Radtke

Escrever o postmortem de um jogo estrelado por um fantasma é esquisito, principalmente quando o projeto foi assombrado durante as 48 horas de desenvolvimento por vários problemas a ponto de chegar a ser surpreendente que ele não tenha ido pra cova antes mesmo de ficar pronto. Sim, Global Game Jam também ensina muito a gente quando tudo parece não ter mais salvação.

Definindo o Tema

Diferente da sede de Curitiba, onde conhecia a maior parte do pessoal e ia com equipe pronta, tive que caçar membros aqui. A sede em Montréal promove um brainstorm coletivo para as pessoas se conhecerem e propor suas ideias. Nesse brainstorm saímos eu e o Rafael Menelau, um amigo que trabalha comigo na ÉTS, com duas ideias a partir do Ouroboros proposto como tema. O primeiro jogo seria um plataforma de ação non-stop, no qual o jogador modificaria o cenário em um loop infinito e, eventualmente, ficaria impossível de continuar. A outra ideia era um jogo de nave que se adaptasse ao estilo do jogador, usando algo de aprendizado de máquina, repetindo eternamente a mesma fase até que o jogo ficasse bom o bastante para vencer o jogador. Ambas ideias interessantes, mas não tínhamos artistas.

Nisso entre o Fred Hulqtvist e seu amigo do Kentucky, o Michael “Crash” Adams (equipe internacional é isso, Brasil, Canadá e EUA). Começamos a conversar e, num segundo brainstorm na cafeteria da ÉTS, começamos a discutir conceitos. Momento no qual eu quase pulei fora, já que não compartilhava a mesma visão que estava sendo formada ali na mesa. Mas, como não queria fazer sozinho e não ia deixar o Rafael na mão, insisti. Até que o Fred ou o Michael (não lembro) comentou das cenas de perseguição de desenhos do Scooby Doo e outros similares, com portas malucas que você entra numa e sai em outra qualquer. No jogo, um fantasma perseguiria um personagem e teria que passar pela mesma sequência de portas (meio parecido com o Genius, verdade, só que sem a repetição, só incremental). Se errasse a porta ou demorasse demais, perdia o jogo, que ficava cada vez mais rápido de acordo com a pontuação do jogador, representando o Ouroboros. Bingo, fechamos uma ideia e eu fiquei contente por ter insistido.

DA ESQUERDA PARA A DIREITA, PAULO, RAFAEL, FRED E MICHAEL

Lost in Translation

Nem foi tanto problema de comunicação no inglês/francês nativo, mas sim a do ritmo e experiência de trabalho em conjunto. O Fred tinha alguma experiência em modelagem 3D para jogos, enquanto o Michael tinha experiência como modelador freelancer. Mas nenhum dos dois tinha feito um jogo 2D antes, que era a nossa proposta inicial. Como a Chien2D não tem esse nome por acaso, diga-se de passagem, tinha que ser em 2D. Demorou para que os termos fossem colocados e, o que para mim era simples e direto, para os dois não era tão evidente.

Passamos boa parte da noite discutindo que o engine conseguiria dar conta do recado, mas não estabelecemos (erro que apareceria mais tarde) metas do que produzir e para quando. Comparando com o Torquere e o Aliens and Zombies, começamos em desvantagem. Moral da história: vale procurar formar equipe antes para discutir a tecnologia antes. Procurar companheiros de trabalho no dia até vai se for um músico, mas se as ideias não forem uma sequência de epifanias em que tudo faz sentido e o jogo se concretize na cabeça de cada um, vai ser difícil.

Houston, We Have a Problem

Nisso já passava da meia-noite de sexta para sábado. Nos anos anteriores, já tínhamos um primeiro protótipo rodando, baseado nos exemplos da Chien2D. O problema dessa vez é que nunca fiz um exemplo de jogo de labirinto para a Chien2D, do jeito certo, usando um grafo. Depois de fazer um mockup do cenário em FullHD e preparar um renderer adaptativo para qualquer resolução (sim, dá pra fazer isso na Chien2D), começamos a ver alternativas de um algoritmo de Dijkstra para o personagem, definido como uma menina, pudesse percorrer o labirinto de uma porta a outra. Depois de passar com o Rafael umas duas horas com um exemplo perfeitamente modular em Boost mas que estava complicado adaptar para o nosso caso, resolvi dormir. Pra minha felicidade, não conseguia abrir a porta do meu laboratório, onde tem um sofá bem confortável e tive que esperar até as 7h30 para poder dormir, quando a trava eletrônica liberava a porta novamente. Tudo para levantar o moral.

Numa game jam a gente dorme muito pouco, 3 ou 4 horas, seja pela empolgação do jogo ou pelo nervosismo de que está atrasado, que era bem o que eu sentia no momento. Comparando com os anos anteriores, em especial com o andamento do Torquere na jam anterior, não tinha motivos para ficar tranquilo. O protótipo era um mockup sem um grafo funcional para o personagem andar e nessa hora cheguei mesmo a pensar se não seria hora de empacotar as coisas e ir para casa. Mas, como todo bom teimoso, resolvi insistir, já que por pior que o jogo ficasse, ficaria melhor do que não ter nenhum jogo.

Uma Luz no Fim do Túnel

Voltando para a jam, o Rafael discutiu comigo uma ideia para resolver a primeira versão: como o grafo era simples e seriam poucos caminhos (só entre os nós com portas), poderíamos fazer hard coded inicialmente, aí o foco ficaria na estrutura do grafo que resolvesse o nosso problema específico, depois daria para generalizar com um algoritmo de busca real. Fechado isso, o Rafael foi dormir um pouco e eu continuei fazendo o grafo.

Mockup

O Fred saiu para dormir nesse horário também e o Michael ficou fazendo o modelo do fantasma com o Zbrush, que usaríamos depois para gerar os sprites. Nessa hora comecei a discutir o estilo de arte (outro erro, isso tinha que ter sido feito no dia anterior), para seguir algo mais cartoon e o Michael topou. Isso foi bom, porque o fantasma era ideal para um filme de terror, não para a visão original de uma perseguição no estilo desenho animado. Mas não tinha visto ainda o cenário do Fred, o que só aconteceria muitas horas depois.

Em poucas horas tínhamos um protótipo com o personagem do jogador andando pelo grafo, inclusive atravessando as portas “malucas”. Faltava colocar o personagem do computador, que discutimos que seria uma menina brincando de pega-pega com o fantasma. No sábado a noite recebemos o primeiro esboço do cenário do Fred, em perspectiva 3D como na foto do site da jam. Depois de um tempo remapeando o grafo para o cenário novo, um problema apareceu: a perspectiva inclinada e girada em aproximadamente 30 graus dificultava interpretar o controle, ao contrário do mockup original, simples e direto, onde vertical e horizontal eram evidente. Depois de uma deliberação decidimos continuar com esse padrão, mas sabendo que poderiam haver problemas de jogabilidade.

marcacao

No final de sábado a noite tínhamos uma primeira versão funcional dos dois personagens caminhando pelo cenário beta. Hora de fechar o barraco e dormir, dessa vez em casa, para descansar um pouco mais.

Sprint Final

Já no Domingo de manhã, tínhamos uma lista bem definida do que fazer para garantir a entrega do jogo. Começamos colocando os critérios de distância entre um ponto e outro do grafo (para andar em velocidade constante), seguido pelo critério de game over e pontuação (calcula, só não mostra). Nessa hora o Fred entregou o cenário final, que era “ligeiramente” modificado em relação ao esboço. Coloco entre aspas porque apesar de visualmente a diferença ser pequena (e era mesmo), tivemos que mudar todos os nós do grafo. Para um jogo que seria feito rápido, posicionar os nós do grafo três vezes matou muito do nosso tempo. Menos do que desenvolver um editor de níveis durante o evento, mas, sinceridade, uma vez só bastava e aprendemos que não dá pra ficar mudando a geometria do cenário o tempo todo se não tem uma ferramenta que ao menos facilite a sua integração no jogo.

Perto do meio-dia apareceram os sprites do jogo, com o dobro do tamanho necessário e com o tamanho dos quadros errado em dois pixels (a mais) em cada eixo na coluna/linha externos. Por sorte não ficou evidente depois de escalonar para o tamanho certo e fazer um crop nos pontos extras. Feita a animação dos personagens e eliminados os bugs básicos (sim, sobraram bugs), faltava dar uma camada de apresentação no jogo. Até o momento não tínhamos tela inicial, instruções, nem nada e já eram duas da tarde. O Michael fez rapidinho uma tela de abertura, desenhei nela mesmo as instruções básicas e fiz um menu. Sem querer, descobri como travar o kernel do Linux numa placa de vídeo ATI onboard e memória compartilhada (só esquecer de chamar a glflush entre um quadro e outro, ou melhor, chamar o C2D2_Sincroniza). Passadas as reinicializações até descobrir o problema e das 3 horas da tarde, aproveitamos a sobrecarga nos servidores da Global Game Jam para dar uma última arrumada no jogo. Em torno das 3 e meia o servidor voltou e pudemos enviar o pacote com o fonte, binário Ubuntu 10.04 (Windows ficou só para a noite) e a documentação requerida.

title

Enfim, o Veredito

Uma coisa legal da sede da ÉTS em Montreal é que eles convidaram um pessoal da indústria (Gameloft, EA, Ubisoft e outras empresas terceirizadas) para fazer uma avaliação dos jogos. Depois de gastar o meu francês e explicar o que era o jogo, o primeiro teste apontou aquilo que tinha sido detectado antes como um problema: o cenário não favorecia os controles, que não eram claros. Em alguns momentos descer implica em virar para a direita, ou ir pra direita é equivalente a ir pra cima. Coisa que o primeiro cenário era mais direto, mas era menos “artístico”. Lição número 1, o jogo deve ser funcional, não bonito. Na próxima vez isso é algo a se discutir melhor.

screenshot1

Faltaram instruções ou um tutorial no jogo. Isso foi deixado em segundo plano, por termos poucas pessoas, mas deveria ter sido algo pensado mais cedo. No Aliens and Zombies tínhamos isso pronto com uma boa antecedência no prazo, então vimos que não dá pra deixar isso para o final. Sem contar que o código que tínhamos pronto com um sistema de menus não era fácil de adaptar em pouco tempo (uma hora), então, para o próximo ano, tem que literalmente chegar com a casca do jogo pronta (falei de fazer isso mas não fiz, culpa minha).

Definitivamente, atrapalhou a separação entre a “equipe de programação” e a “equipe de arte”, que ocorreu até por não termos tanta afinidade. O vídeo do time lapse da câmera da equipe deixa isso claro, no Sábado a tarde e no Domingo os artistas mal aparecem na câmera por estarem até mesmo em outra mesa, como se artistas e programadores fossem atrapalhar uns aos outros. Devíamos ter trabalhado mais próximos, isso foi um erro grosseiro nosso. Gostei do resultado final produzido pelo Fred e pelo Michael, mas teria sido melhor ter esse resultado final no sábado a tarde, para que eles pudessem ter se encarregado de uma abertura, menus e outros, onde eles poderiam ter soltado a veia criativa. Algo a se cuidar ano que vem, já que poderíamos ter visto muita coisa antes, inclusive músicas e efeitos sonoros.

Mas o mais importante dessa jam foi aprender a trabalhar sob pressão com pessoas com as quais não temos intimidade. Não tem espaço para estourar e continuar como se não tivesse acontecido nada. Um amigo de longa data sabe que aquilo é coisa do momento, e vice-versa, mas com alguém que você mal conhece há um dia é pedir para a coisa parar por ali. Também aprendi que conciliar as várias visões do jogo em algo comum deve ser feito o quanto antes. Queria ter gasto umas duas horas a mais na sexta fazendo o cenário base e explicando melhor para o Fred e o Michael como deveriam ser os arquivos que esperávamos e porque era importante decidir aquilo ali, naquele momento.

Resumindo o moral da história para quem quiser evitar esses mesmos problemas, eu incluso:

  1. A tecnologia e modo de produção deve ser domínio da equipe. Assim, tentar uma semana antes fazer uma prévia para que a coisa dê certo. Se for o caso, procure pessoas para a equipe no dia, mas vá preparado para os problemas.
  2. A mecânica do jogo deve ser decidida o quanto antes e um cenário base deve ser estabelecido. Uma vez feito isto, procurar mudar o menos possível para minimizar o retrabalho. Só se der realmente errado no primeiro protótipo você deve jogar isso fora e começar tudo de novo do zero.
  3. A equipe toda tem que ter a mesma visão do jogo e saber quais os assets que devem ser gerados. Nunca tinha trabalhado com um artista profissional e, apesar do resultado ser muito bom (o Spooky Mansion é o jogo mais bonito que eu já trabalhei), percebi que tornar a arte em algo funcional é complicado quando a visão artística não vai de encontro com o que funciona melhor para um jogo.
  4. Não fique com medo de usar uma solução simples para demonstrar que o jogo funciona, ao invés de usar o melhor algoritmo na sua melhor forma para isso. Numa jam fazemos um protótipo para mostrar uma ideia, não algo geral para todas as situações. Se tivéssemos feito os caminhos no braço, coisa que levou 15 minutos, evitaríamos o trabalho de tentar adaptar o algoritmo de Dijkstra pronto em Boost para o nosso caso bastante particular. Isso nos custou algumas horas que poderiam ter sido usadas para fazer os menus, tutorial, etc.
  5. Estabeleça um cronograma com toda a equipe. Arte e programação caminham de mãos dadas numa jam e, se um não anda, o outro não avança muito. O primeiro esboço do cenário apareceu só no Sábado a noite e era diferente do cenário final, entregue no Domingo de manhã.
  6. Procure se divertir mesmo se tiver problemas. Você não vai ficar rico com um jogo de jam, mas com certeza vai aprender mais do que fazendo jogos sozinho no seu canto e vai aprender a trabalhar com pessoas diferentes.

Pra quem ficou curioso, nem que seja a curiosidade de quem passa do lado de um acidente na estrada e não resiste dar uma olhada, o Spooky Mansion está disponível para download em http://globalgamejam.org/2012/spooky-mansion. Os time lapses estão no You Tube, tem o meu desktop em http://youtu.be/-QHkM2YNpxc (curto a parte em que desenhamos os caminhos no cenário) e a câmera da equipe em http://youtu.be/tPvY29eSvgg . Se você não acredita na separação da equipe de arte e programação, confira esse time lapse no fim do Sábado e no Domingo, não dá outra.

Bônus: acompanhei durante a jam alguns sites de jogos feitos no Brasil, que aparecem no meu timelapse do desktop. Numa dessas seu jogo, você ou a sua sede aparecem ali :).


Comentários (0)
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