"Por que isso é assim em vez de ser do outro jeito? Levaria literalmente um dia para mudar!" lemos diariamente em comentários em vídeos de gameplay, em notícias sobre um jogo, nas reviews do Steam. Eu já li inúmeras versões deste mesmo pensamento em comentários sobre meus jogos, sobre outros jogos indies, sobre jogos AAA, sobre filmes… A lista é infindável. E, embora eu simpatize com a frustração, com o desejo que algo seja diferente, seja melhor, minha empatia acaba na total falta de compreensão sobre como é o processo de desenvolvimento de um artefato cultural, como um jogo.

Como jogadores, temos contato com o produto final e experienciamos ele conforme ele se mostra para nós. Luz, paredes, objetos vão aparecendo e vamos formando opiniões. Como jogos são interativos e vão se desdobrando ao nosso redor, acabamos levando essa percepção auto-centrada ao julgarmos o jogo, ou ao que ele apresenta para nós, na dada ordem em as coisas se mostram para nós.

Pode ser surpreendente para alguns, mas um jogo não é feito na ordem em que é jogado. A gente não faz o tutorial e depois a primeira fase ou a segunda. Na real, geralmente, o tutorial é a última coisa a ser feita pois queremos ter certeza que ele explica tudo corretamente conforme as últimas mudanças e atualizações. E também não começamos pelo palco que o jogador interage, pelo level design. O level design só começa do meio para o fim do projeto, quando a maioria das partes móveis, como mecânicas, estão mais claras e funcionando em conjunto.

Geralmente, o tutorial é a última coisa a ser feita pois queremos ter certeza que ele explica tudo corretamente conforme as últimas mudanças e atualizações

De forma geral, um projeto de jogo passa por três grandes períodos de tamanhos aproximadamente iguais: Pré-produção, Produção e Pós-produção. Sabe quando a gente começa a de fato mexer no jogo? Isso mesmo, na Produção. Para essa resposta, já imagino alguns leitores coçando o topo de suas cabeças com um misto de surpresa e indignação ao pensarem "então, o que vocês ficam fazendo todo o tempo da Pré-produção, coçando o saco?" ao que já me adianto em revelar: sim e não.

Para referência durante esse artigo, observe essa imagem. Ela não é precisa, não se trata de nenhum jogo em particular, e cada jogo em individual pode ser enormemente diferente disso. Ainda assim, é um bom exemplo para ilustrar, em média, como funciona o processo de desenvolvimento de um jogo inteiro. Hoje, vamos falar da Pré-produção e deixar os outros dois para as próximas semanas.

Pré-Produção

Sabe quando você tem "aquela ideia incrível para um jogo"? Esse é o começo da pré-produção, e ela só termina quando, de fato, você pode começar a fazer o jogo. E não, não é logo em seguida.

Aqui, é quando nós exploramos o que essa ideia realmente quer dizer, quais os limites dela, e como ela vai progredir pelo jogo. "Atirar em zumbis" é uma ideia de jogo, mas não é o suficiente para começar a fazer um jogo. Atirar com o quê? Quais armas estão disponíveis? Quando elas estão disponíveis? E os zumbis? Com certeza, atirar no mesmo tipo de zumbi pode ser divertido, mas perde a graça rápido se nada de diferente é introduzido, como novos tipos de zumbis e novas mecânicas de como neutralizá-los. E o mundo? Vamos fazer um jogo linear, como Left 4 Dead, ou aberto, como DayZ? Para tanto, o ideal é pesquisar, em jogos e outras mídias, o que esse jogo vai ter de ambientação, como vão ser os personagens, o estilo estético e tudo mais.

Outra coisa que deveríamos nos perguntar, inclusive antes disso tudo, é como esse jogo é diferente dos, aproximadamente, 7.324.678.213 jogos de atirar em zumbis que já existem – mas como esse é seu primeiro jogo eu vou deixar essa passar.

Agora que temos algumas respostas está na hora de testá-las. Achou que ia ser fácil? Pois não é. Como um desenvolvedor, você não pode simplesmente ter a ideia de atirar em zumbis com armas de água e basear o jogo todo nisso, as novas mecânicas e tipos de zumbis, sem ao menos ver essa arma de água em ação e ter certeza que é divertida.

Outra coisa que deveríamos nos perguntar é como esse jogo é diferente dos 7.324.678.213 jogos de atirar em zumbis que já existem

Para testar isso, fazemos o que é chamado de protótipo, que é uma simulação da mecânica que vamos testar. O objetivo não é programar essa coisa e começar o jogo daí; o objetivo é fazer o trabalho mais porco possível para testar essa dúvida, ver se funciona e deletar o arquivo. Mais uma vez, consigo imaginar um semblante misto de confusão e surpresa na sua cara, leitor. "Mas por que sequer fazer o protótipo se ele é descartável?" Por que, meu querido leitor, o importante não é o protótipo, é o que você aprende com ele.

Eu posso te dar certeza absoluta que sua primeira tentativa de prototipação de uma mecânica vai resultar em algo horrível. Não é uma maldição, é só a realidade. A primeira versão de um protótipo é sempre a coisa que nos faz nos perguntar por que caralhinhos voadores estamos fazendo jogos. Em meio ao auto-ódio, então, procuramos quais são os maiores problemas e tentamos consertá-los. Aí, temos algo mais interessante que parece ter um futuro, mas ainda não tá legal. De volta para a programação e testes.

Eu posso te dar certeza absoluta que sua primeira tentativa de prototipação de uma mecânica vai resultar em algo horrível. Não é uma maldição, é só a realidade

Esse vai e volta, esse "isso ficou chato" e "isso tá melhor" é o que nos ajuda a definir o que realmente é legal nessa mecânica e o que não é. É também o que vai deixar o código absolutamente nojento e incapaz de ser utilizado em qualquer coisa minimamente estável. Saber exatamente qual a mecânica que é divertida, por que e como é para que serve o protótipo. Munido desse conhecimento, um bom programador consegue fazer um código que funcione bem exatamente para isso.

Não é incomum que a mecânica resultante de um processo de prototipação seja completamente diferente da mecânica proposta inicialmente. Isso é ótimo, isso mostra que a equipe soube trabalhar ao redor do que eles tinham e se comprometeram em fazer o melhor com o que tinham à disposição. Isso também nos lembra por que é importante que o protótipo seja descartável. Imagine um jogo puzzle inteiro construído em cima de uma engine base de um FPS, por que no meio do caminho os desenvolvedores perceberam que o puzzle seria mais interessante?

Eu estou focando em protótipos de game design pois essa é a minha área, mas na verdade todas as áreas de desenvolvimento estão fazendo seus próprios protótipos: a arte está testando os shaders e a aparência e comparando com a performance, a engenharia está testando tecnologia como engine ou servidores ou hardware, caso seja necessário.

Quando finalmente respondemos a maioria das perguntas que tínhamos e que finalmente temos uma ideia mais clara do jogo à nossa frente é quando devemos fechar a documentação. A documentação é tipo um plano de ataque, é uma descrição técnica do que o jogo vai ser e vai ter, em termos de funcionamento e conteúdo. Junto com a documentação, entra o planejamento, que é a estratégia de como, quando, e por quem cada parte do jogo vai ser feita. Então, no fim da pré-produção, idealmente todos os membros da equipe têm uma boa ideia de o quão longo o jogo vai ser (quantos níveis, episódios, etc), quanto tempo ele estará em produção (e quais áreas vão estar fazendo o quê) e o que realmente o jogo vai ser a respeito.  Daí, com a própria documentação ou com um pitch do jogo, apresentamos o conceito do jogo para o responsável em aceitar ou não  projeto, o que chamamos de greenlight. O responsável pela aprovação pode ser um executivo, poder ser um investidor, pode ser a equipe toda, depende muito da situação. Teoricamente, nada de grande vai mudar no jogo a partir da pré-produção; nenhum novo personagem jogável ou mecânica principal, só coisas menores que podem ser acomodadas na agenda geral.

Idealmente, não muda por que nem sempre é assim. E destes imprevistos vamos falar outro dia, assim como o que acontece assim que terminamos a pré-produção. Até lá!