Topo

Histórico

Criando games, parte 2: Produção é quando as coisas realmente acontecem

Thais Weiller

06/08/2019 04h00

No post anterior, falamos do processo de desenvolvimento de um jogo e de suas três principais fases, e discutimos em mais profundidade a primeira delas, a pré-produção. Hoje, do que será que vamos falar? Os Xeroque Roms já devem ter previsto, isso mesmo, vamos falar da Produção.

Agora que arregaçamos as mangas – mas antes de sujarmos as mãos – vamos lembrar o que devemos ter pronto ao fim da pré-produção: documentação descrevendo as partes e o escopo do jogo, o planejamento do trabalho baseado nessa documentação, e, frequentemente, um pitch tocando os principais pontos de ambos na forma de uma apresentação. Esses documentos são essenciais para aprovar o projeto e permitir que ele entre oficialmente em produção.

Mas isso não quer dizer que ele será feito tal qual proposto ao fim da pré-produção. Não, senhores: a aprovação geralmente é condicionada a algumas mudanças requeridas pelo grupo que dá o sinal verde. Coisas maiores vêm à cabeça, como orçamento ou tamanho da equipe disponíveis ao projeto, ambos capazes de cancelar o projeto por si só caso estejam em falta. Mas não é só por grandes motivos como esses que projetos são alterados, adiados ou até cancelados. Às vezes, o estúdio já tem um lançamento previsto para a mesma época em que o novo projeto ficaria pronto, o que requer adiantar ou atrasar o lançamento, o que implica cortes ou mudanças ao jogo principal. Outras, um título de outra empresa foi anunciado e é terrivelmente semelhante ao projeto proposto, o que obriga todos a voltarem a prancheta.

Mesmo com tanto trabalho colocado na pré-produção, a proposta de projeto ainda não é uma certeza absoluta e pode facilmente ser descartada por razões como as exemplificadas acima ou inúmeras outras. Por isso, raríssimos são os casos de jogos anunciados ou tornados públicos antes dessa fase em empresas grandes. Vocês sabem como são fanbases, elas não precisam de mais combustível para atear fogo em si mesmas.

Todos os números batem e tá todo mundo animado? Começamos a produção. Bom momento para rever aquele gráfico (que, novamente, não é um plano preciso de projeto para todos jogos, mas sim uma aproximação bem por cima de como em geral projetos são conduzidos).

As etapas que, em geral, fazem parte do desenvolvimento de um jogo

E, eu sei, vai soar muito mais chato do que você esperava, leitor, mas basicamente na produção fazemos o que planejamos na pré-produção. Quando temos uma pré-produção excepcionalmente boa, até as ferramentas específicas para criar o jogo foram desenvolvidas nela, antes da produção em si, de forma que todos os desenvolvedores já estão familiarizados com as mesmas. Ferramentas para construção de level ou para edição de terrenos ou inimigos, por exemplo, são inestimáveis, e assim que começamos a construir o jogo em si o ideal é já estar com todas funcionando e suas habilidades tinindo para usá-las.

O negócio é que, na maioria das vezes, a pré-produção não é tão efetiva ou tão bem resolvida assim, e muitas coisas acabam tendo que ser resolvidas, envisionadas ou totalmente repensadas e implementadas durante a produção. Uma mecânica que não é tão divertida assim, uma parte da história que se saiu mal nos play-testes, uma parte do orçamento que parecia garantida mas que foi cancelada de última hora. Essa é a parte mais estressante do projeto e, ao mesmo tempo, a mais recompensadora. Quando imprevistos acontecem é quando a criatividade e resolução de problemas dos desenvolvedores têm realmente o espaço para brilhar.

Gambiarra de Fallout 3 para resolver o deslocamento dos trens.

É nesses momentos que vemos soluções como a de "Fallout 3" para os trens. O mapa ficou muito grande e vamos precisar de uma forma de o jogador se movimentar por ele mais rapidamente, como um metrô. Temos tempo para fazer um sistema de deslocamento baseado em trilhos? Não, mas realmente precisamos disso. Bora modelar o trem e colocá-lo como o braço de um NPC e botar o NPC pra fazer o deslocamento. Perfeito. O pessoal lá de fora chama essas soluções de workaround, eu chamo de gambiarra mesmo – não para desmerecer o rolê, mas porque gambiarra faz parte do nosso cotidiano, né? Em desenvolvimento, evitamos resolver as coisas com gambiarra, mas caso estejamos com pouco tempo ou haja um imprevisto e que não terá implicações piores no futuro, gambiarra rainha, hora extra nadinha.

O senso para pesar o que muda, quando e onde e o que cortar e botar fogo é algo que só vem com o tempo, de sentir o que fazer nesse caso específico e seguir o baile, mas é uma situação que encaramos desde que começamos na indústria. Eu já escrevi sobre isso no passado mais de uma vez, mas nem todas as dicas do mundo fazem uma única pessoa infalível dessas decisões. A equipe deve ponderar junta e assumir uma decisão unida, mesmo que nem todos estejam felizes com ela. Afinal, ninguém é clarividente para saber com certeza todas as implicações e resultados de cada decisão e só no longo prazo que vamos saber se foi uma decisão acertada ou zoadaça. E sobre esses resultados, assim como as finalizações, é o que falaremos na próxima coluna.

Sobre a autora

Thais Weiller é mestre pela ECA-USP pesquisando game design, com uma dissertação que virou um livro e um blog. Ela trabalhou em games como “Oniken”, “Odallus”, “Finding Monsters”, “Rainy Day” entre outros, e também fundou, junto com Danilo Dias, a desenvolvedora JoyMasher. Atualmente, Thais dá aulas de design de jogos na PUC do Paraná.

Sobre o Blog

Quais os mitos e fantasias que influenciam nosso comportamento e afetam nossa paixão pelos games? Neste espaço, Thais vai trazer a perspectiva dos pesquisadores e desenvolvedores de jogos para nos ajudar a entender os games de uma maneira diferente.