Insanidade, suor e um Post Mortem.

Apesar de o semestre ainda não ter oficialmente acabado é um alívio poder dizer que no final, ficou de fato, tudo bem. É um alívio poder dizer que entregamos o resultado do esforço(MUITO) suado de um ano de dedicação com êxito. É um alívio o jogo ter se saído tão bem. E é um alívio ele ter superado as nossas expectativas e aparentemente as de quem acompanhou o desenvolvimento.

Na verdade é mais que um alívio. É verdadeiramente recompensador.

Screen de um dos quartos do jogo

Para os que não têm saco possuem a intenção de ler esse Post Mortem e, com sorte, aprender uma ou outra coisa sobre o Insanitas e seu processo de criação, e só querem o link pra jogar, infelizmente decepcionar-los-ei adiando em alguns dias o download. Ainda estamos polindo e corrigindo alguns detalhes. :P

Entrada da cripta

Aos que decidiram prosseguir com a leitura e não sabem do que diabos estou falando, apresentamos semana passada o Insanitas, jogo de terror e puzzle desenvolvido como trabalho interdisciplinar (o famigerado TI, apesar de que para alguns o trabalho valeu como TCC) no curso de Jogos da PUC. O jogo foi o resultado do trabalho de um ano que, entre trancos e barrancos, acabou sendo o projeto cuja versão final mais se aproximou do conceito que havíamos planejado originalmente.

E aos que não sabem o que é um Post Mortem, aconselho assistir uma aula de gerência de projetos ou clicar aqui.

Dito isso, deixo registrado a seguir, o meu primeiro (mini) Post Mortem. :D
Mas antes, um curto vídeo pra relembrar o teor/introduzir do conteúdo do projeto:

O jogo, cujo desenvolvimento teve início no segundo semestre de 2012, é um escape de terror onde o jogador controla Lillian, uma ex-enfermeira que acorda no sanatório onde costumava trabalhar. Lillian não se lembra das circunstâncias que antecederam sua chegada e precisa lutar para sobreviver em um ambiente claustrofóbico e cercado de mistérios.

Exterior

Durante o desenvolvimento atuei principalmente como programador e eventualmente dei pitacos em game design. O jogo possui 3 cenários principais e aproximadamente 3000 linhas de código (4500 contando os recursos que não são de nossa autoria).

Então, sem mais delongas, o que deu certo:

• Começar de novo: A primeira parte do projeto teve início no segundo semestre do ano passado e protagonizou um desfecho não muito bom. A falta de comprometimento do grupo (inclusive deste que vos escreve) aliada ao não cumprimento de uma lista de tarefas bem específicas repercutiu em um jogo mal terminado e recheado de erros. E construir o resto do TI baseado em um sistema que não funcionava ou perder tempo corrigindo os vários erros para aproveitar o pouco que funcionava efetivamente não pareciam ser opções viáveis. Ao reiniciar o projeto, nós "perdemos" seis meses de trabalho, mas ganhamos em qualidade e workflow. Especialmente considerando que já conhecíamos os principais problemas com os quais teríamos de lidar.
• Orientação a objetos: Apesar de conceitual, a matéria se mostrou milagrosa muito útil no processo de planejamento e implementação dos sistemas presentes em Insanitas. Há padrões de projeto no sistema de itens, interface, menus, quests.... Estudar um pouco mais a fundo o funcionamento da programação orientada a objetos garantiu a criação de código mais robusto e reaproveitavel (inclusive fora do TI), o que foi essencial para garantir o progresso rápido na reconstrução do conteúdo que teoricamente deveria estar pronto no semestre anterior. 
• gGUI: Apesar de ser um jogo de terror cuja ambientação demanda uma HUD limpa, toda a interação com itens e outros objetos do cenário é feita através de interfaces específicas. Aos familiarizados com a Unity, não creio eu ser mistério algum que o a GUI da engine é a razão pela qual Deus nos odeia lamentável de se trabalhar com, o que foi motivação suficiente para que eu escrevesse minha própria classe baseada em MonoBehaviour, a gGUI. Inspirado pelo sistema implementado por um ex-colega de trabalho (sendo o "g" uma homenagem a ele), cada botão, box, label e elemento de interface é um objeto separado cujo tamanho é calculado a partir da porcentagem baseada no tamanho da tela ou do objeto pai. Essa implementação economizou um bom tempo e tornou mais rápida e menos dolorosa a lenta e dolorosa tarefa de programar todos os elementos de todas as telas de todas as interfaces.
• Gerência de projetos: Não subestimem-na. Ter alguém responsável por cronogramas, documentação, reuniões, cobranças, chicotadas e chocolate provou ser essencial para a conclusão do projeto. A maioria subestima o valor da organização e acaba tendo que fazer o TI completo nas últimas duas semanas. Um cronograma bem pensado e bem cobrado garantiu que a história do semestre anterior não se repetisse e o Insanitas tivesse uma conclusão relativamente saudável, com bastante tempo pra polimento, compensando nosso atraso inicial de seis meses. Aos que têm interesse em gerência e/ou possuem uma deficiência que precisa ser sanada na área, aconselho firmemente a assistir a matéria de Gerência de Projetos, especialmente se você faz Jogos na PUC (Tia Rosi, se estiver lendo isso, acho que mereço um ponto ou dois pela propaganda, hein?).
• Programação em dupla: Um grupo grande tem como preço grandes exigências. E infelizmente, minha habilidade como programador não era o suficiente para atender todas elas. Ter um outro programador trabalhando com o que eu não sabia/não tinha tempo pra aprender tirou um ENORME peso das minhas costas e garantiu que todos os recursos exigidos pelos professores fossem integrados com sucesso no projeto. Assim eu pude focar nos detalhes ao contrário de quebrar a cabeça com problemas que para mim seriam insolúveis.

Corredor

Cripta

E eis os problemas, trancos e barrancos:

• Começar de novo: Okay, fizemos bobagem com o projeto na primeira metade do desenvolvimento, e okay, recomeçar era a saída mais válida e nos ajudou em vários aspectos. Mas não deixou de ser um problema no que se tratava de cumprir prazos. Corremos brutalmente contra o tempo e tivemos de adaptar vários detalhes pra conseguir entregar tudo a tempo, o que teria sido consideravelmente menos trabalhoso se tudo tivesse sido melhor planejado desde o princípio. Teríamos tido pelo menos um mês a mais para polir o projeto, mas ao invés disso tivemos algumas tardes turbulentas no GEDAI e algumas horas além do recomendado para se trabalhar a noite (não chegamos e varar a madrugada, mas quando se estuda e trabalha, cada minuto de sono é valioso).
• Integração: Somos uma equipe pequena do ponto de vista da indústria, mas do ponto de vista de um TCC, somos uma equipe grande. Cada um produzindo recursos individualmente ao mesmo tempo. O que significa ter que parar tudo e juntar os pedaços algumas várias vezes e, até definirmos um modelo que funcionava (um log de acesso ao projeto e algumas especificações de importação e exportação), perdemos tempo, material e passamos por alguns apertos com entregas. Tendo definido nosso fluxo de trabalho, mantivemos um sistema que garantiu uma integração suave e evitou trancos e barrancos tardios no projeto.
• Falta de comentários: Programar em dupla foi absolutamente essencial para o projeto, porém meu PÉSSIMO costume de não comentar os scripts que escrevo limitou/atrasou a integração dos recursos que não eram de minha autoria. Tendo explicado meus códigos os sistemas teriam sido terminados mais cedo e, novamente, teríamos mais tempo pra polir tudo e testar com maior certeza. Lição aprendida e, espero eu, repassada.
• Polimento demasiado: Às 16:22 de segunda feira, dia 20/05, entrei bufando no Bloco E do São Gabriel pra entregar o projeto cujo limite para entrega era 16:30. Momentos antes de eu quase vomitar meus pulmões, ainda estávamos gravando os DVDs e uma hora antes ainda estávamos fazendo mudanças no projeto. Polir garantiu uma qualidade acima da média para o jogo final, mas saber quando dizer "Chega, o projeto está pronto" teria sido de grande valor para uma entrega menos conturbada e estressante. Além de que mudanças de última hora quase impediram o projeto de ser entregue com todas as exigências básicas de um TI/TCC. Reservar um tempo para polir é necessário, mas saber não exceder esse tempo é ainda mais necessário.
• Minha condição humana:

Adoeci, fiquei cansado, fiquei com preguiça, não consegui conciliar algumas responsabilidades. Sou humano (ainda) e apesar disso não ser culpa minha, foi um fator que afetou e atrasou um pouco o projeto (teria rendido mais algumas semanas de polimento). 

A escuridão esconde algumas surpresas

Do ponto de vista do programador, acho que foram esses os pontos mais destacáveis/relevantes do projeto para se deixar registrado como aprendizado para futuros projetos. Aos que leram até aqui, espero sinceramente que alguma coisa em algum lugar deste post tenha servido como aprendizado.

Assutador

E apesar de já ter agradecido anteriormente e pessoalmente, deixo aqui um agradecimento especial a todos que apoiaram e torceram pelo projeto. Especialmente aos professores do curso de Jogos da PUC Minas e a galera que quase literalmente morou no GEDAI com a gente nas semanas anteriores à entrega final. E também ao Tio Nery que, além de professor e orientador, foi parte da nossa equipe como Environment Artist. :D

Dúvidas, criticas, sugestões, denuncias de erro de português e/ou etc, sintam-se a vontade para comentar e/ou mandar uma mensagem. :)