Quando dá tudo errado na criação de um game

Nas colunas passadas, falamos das etapas de desenvolvimento de um jogo. Em cada um dos textos, eu reforcei que aquilo era uma projeção, uma média genérica que não se encaixa em nenhum tipo particular de jogo e que não estava regulada para erros. Mas, como muito bem sabemos, somos humanos e erramos muito.

Então, hoje vamos falar de algumas formas em que tudo pode dar errado. (Esse tema foi escolhido em uma votação no twitter por vocês, leitores!)

As coisas podem dar errado em qualquer momento do desenvolvimento, do começo ao fim, e podem ter diferentes impactos no processo. No texto de pós produção, discutimos um pouco sobre o caso do filme do Sonic e como a falta de aceitação do público do design do mascote da Sega significaria praticamente refazer metade do filme do zero.

Muitos dos desvios de planejamento, de fato, ocorrem na pós-produção e tendem a ser os mais catastróficos de todos, mas catástrofes podem acontecer a qualquer momento e alguns problemas que poderiam, sim, resultar em catástrofes na pós-produção às vezes são transformados em bênçãos por soluções engenhosas de equipes espertinhas.

Vamos relembrar as etapas que, em geral, fazem parte do desenvolvimento de um jogo e sua ordem.

Pré-produção

Esse é o momento em que é planejado, bom, o jogo inteiro. Esse planejamento requer investigar e traçar possíveis softwares, histórias personagens, etc. antes de, de fato, usá-los para concretizar o que deve ser feito. Então, qualquer suposição aqui (por exemplo, planejar usar ferramenta x e y para fazer tal parte do jogo) que se provar errada durante o desenvolvimento (os programadores simplesmente não conseguem fazer esse uso das ferramentas no tempo estipulado) vai impactar lá. Mas isso é um caso de um problema criado na pré-produção que explode em outro momento, vamos falar de problemas que nascem e criam dentro dela.

Nesse momento, a não ser que a equipe já tenha trabalho em outros projetos junta, as pessoas ainda estão se conhecendo e se adaptando às suas posições. Mesmos que já tenham trabalho juntas, muitas vezes promoções e mudanças de cargo acontecem e as pessoas tem que se acostumar a novas responsabilidades e trabalhos. E essa dinâmica pode causar atritos.

Vamos supor que um novo diretor criativo está no cargo, não importa se veio de fora ou se é uma pessoa da equipe que ascendeu ao cargo. A responsabilidade de um diretor criativo é guiar a equipe de design à visão do jogo completo, a entender qual é a essência desse jogo e como ela vai se materializar em levels, mecânicas, personagens, etc.

Entretanto, o que acontece se o diretor criativo não sabe qual é essa essência e fica fica guiando a equipe em círculos sem nunca saber exatamente o que é e o que não é pertinente ao jogo? Pior ainda, o que acontece quando esse diretor criativo não quer reconhecer que não sabe o que quer e, na visão da equipe, fica randomicamente dizendo que uma coisa está boa ou péssima?

A falta de visão sobre o leitmotiv do projeto em uma pessoa tão alto na hierarquia é catastrófica para todo o processo de pré-produção, que é justamente quando os alicerces em que o jogo vai ser construído devem ser definidos. Se a pessoas responsável por estruturar, selecionar e inspecionar a posição e planejamento desses alicerces não sabe o que está fazendo e, pior, não permite que a equipe tome a posição para ela mesma fazer esse trabalho, o jogo nunca vai ter uma cara. É como se tivéssemos uma palavra ou uma idéia para seguir, mas nenhum plano de como de fato chegar lá. A equipe gasta a pré-produção inteira caçando fantasmas.

Esse é o padroeiro do desenvolvimento de jogos.

Produção

Tudo, absolutamente tudo, pode dar errado durante a produção. O que importa é como a equipe lida com esses imprevistos. Sim, tem os planos da pré-produção que podem não se concretizar conforme planejado, mas esse é só o início dos problemas.

Às vezes, tudo sai exatamente conforme o planejado. A arte demora o tempo certo, a programação também e o design idem. Mas quando vamos jogar essa parte do jogo, tá chato. Ou muito longo. Ou muito parado. Ou muito rápido. Características que não dá para se planejar, você estima, por meio de protótipos e testes, que vai funcionar, mas as vezes não funciona. O que fazer? Passar "x" tempo tentando arrumar problema ou passar "y" tempo cortando essa parte e realocando as coisas importantes de história, gameplay e fluxo para outras partes do jogo? Decisão chata, que pode impactar o projeto inteiro, mas que tem que ser feita.

E quando está tudo indo nos conformes e a engine, que é o software que a gente usa para fazer o jogo, atualiza? O procedimento padrão no começo do projeto é atualizar, mas isso geralmente quebra bastante coisa no jogo que tem que ser consertada. Consertos que não estavam planejados e vão impactar na agenda. Por isso, o procedimento padrão no fim do desenvolvimento é não atualizar, mas e se a nova versão corrige um problema que os programadores tão peleando pra consertar há meses? E se a nova versão melhora a performance? Outra decisão chata que impacta tudo.

O caso Duke Nukem Forever

Outra coisa chata da produção é quando coisas externas ao jogo interferem no que ele vai ser, mudando completamente seu escopo. Por exemplo, um título anunciado é muito parecido com o nosso ou o dinheiro diminuiu ou os objetivos com esse jogo mudaram e agora vamos ter que mudar muitas coisas. Isso nos obriga a rever o projeto todo e decidir o que pode ser cortado, diminuído ou repensado.

Outros problemas podem parecer boas notícias, mas nem sempre são: temos mais dinheiro/mais tempo, logo, precisamos por mais coisas no jogo. O jogo já foi planejado para ser desse jeito, como por essas coisas sem elas parecerem só cosméticas ou não relacionadas com o jogo principal?

"Duke Nukem Forever" sofreu de algo semelhante à esse último problema: toda vez que via algo inovador em FPS, seu diretor decidia que o jogo ficaria antiquado se não tivesse essa mesma coisa. Então, meses de trabalho eram jogados fora para mudar de engine ou colocar um novo tipo de luz ou para melhorar a qualidade dos modelos. É por isso que o jogo passou mais de uma década em desenvolvimento e se tornou o Frankenstein que é, mas esse é só o exemplo mais extremo do que a mudança de escopo pode ocasionar. Pequenas mudanças podem ser igualmente catastróficas.

Outro problema assustador que pode acontecer aqui é o fechamento do jogo. Geralmente, durante a produção, o jogo é dividido em partes em que diferentes equipes trabalharam separadamente. Em mega-corporações, algumas equipes ficam inclusive em outros países, muitas vezes são terceirizadas. Então, quando chega a hora de costurar tudo junto e fazer um jogo só é comum as partes não se harmonizam tão bem.Com tempo e trabalho, geralmente resolvemos isso e temos um jogo coeso no final para lançar, mas nem sempre esse é o caso.

Problemas de comunicação durante o processo de desenvolvimento podem ocasionar em partes que simplesmente nunca vão funcionar juntas e que devem ser refeitas do zero. Novamente, daí temos outra decisão difícil: vale a pena ou temos tempo e orçamento para refazer ou é melhor cortar e re-distribuir os pontos importantes nas partes que já funcionam? Isso não parece um grande problema quando pensamos em um level ou um personagem só, mas não se esqueça que "partes" pode ser qualquer parte do jogo, inclusive uma mecânica essencial. Já jogou um jogo que parece que tem algo faltando? Bom, talvez foi isso que aconteceu.

Pós produção

Falamos de algumas das catástrofes que podem ocorrer nessa fase no texto sobre ela, mas hey, tanta coisa pode dar errado aqui que ainda temos assunto para mais um mês inteiro de colunas. O querido leitor pode pensar: "mas o jogo tá pronto, o que mais pode dar errado?" ahhh, meu anjo, o bolo tá pronto, o que mais pode dar errado? Bom, ele pode ter um gosto horrível. Ou pode cair no chão. Ou pode estar queimado. Mas vamos falar de jogos que eu já estou ficando com fome.

Na pós produção, o jogo está sim quase pronto. Ele está, no mínimo, com o conteúdo completo. Conteúdo aqui se refere à história, assets, as mecânicas e features, mas conteúdo completo não significa sem bugs, né? Aliás, uma coisa que você aprende trabalhando com jogo é que nada, absolutamente nada, não tem bugs: o melhor que temos é sem bugs críticos.

Bugs críticos são os que estragam a experiência do jogador, são bugs que, se encontrados, ou o jogo fica ruim ou não dá para terminar o jogo. Eles não precisam ter 100% de reprodutibilidade (acontecer todas as vezes em que o jogo é jogado), mas também não podem ser tão raros a ponto de acontecerem só se uma ordem muito específica de ações forem realizadas. O que acontece se encontramos um bug crítico na pós produção que os programadores simplesmente não conseguem resolver? Isso mesmo, a gente chora.

Às vezes, você tem sorte de achar uma gambiarra que resolve um bug crítico. "Donkey Kong 64", quando pronto, tinha um problema ridículo de memory leak que ninguém conseguia resolver. Mas, se o jogador estivesse usando a expansão de memória do N64 o problema não quebrava o jogo. Por isso, o jogo exige a expansão de memória para rodar mesmo que, em uma situação ideal, ele não usa essa memória. Ele só exige a memória por que se não a tiver o jogo crasha.

Não é incomum de mudanças drásticas aparecerem nessa fase, mesmo o jogo estando content complete. Geralmente, essas mudanças são arbitrárias e vem de cima, do pessoal com a grana ou os executivos. É por isso a odiamos o pessoal de cima, sempre.

Em decorrência de problemas como esses ou outros, nessa fase também é quando é mais comum ocorrerem crunches, que são péssimos para a saúde da equipe e na real podem resultar em ainda mais problemas.

Bom, estamos falando de problemas já faz algum tempo, não tocamos nem 10% dos problemas possíveis e tá batendo uma bad então vou encerrar por aqui. Nos encontramos novamente semana que vem com um tema mais good vibes.