Conforme prometido, apesar de levar mais tempo do que o esperado , completo com a segunda parte este interessante artigo baseado nos relatos de Ian Ficsh.

Me identifiquei bastante com as últimas cinco armadilhas, os problemas levantados pelo experiente Game Designer, em sua grande parte, foram os mesmos que enfrentei, e ainda enfrento, nos games que desenvolvo.

Vamos então conhecer quais são as outras Pitfalls que devem ser evitadas no Game Design.

Permitir a História Controlar o Projeto de Jogo

Na televisão e cinema um escritor escreve um roteiro e entrega a um produtor. A equipe então, usa o roteiro como um guia para contar a história ao telespectador. Este processo pode funcionar também para video games já que o propósito é o mesmo, contar uma história ao jogador.

Jogos como a série Final Fantasy, assim como muitos jogos de aventura, podem obter sucesso pela história por si só. Porém, se o principal propósito do game é colocar o jogador dentro de uma experiência altamente interativa, este método pode ser inapropriado.

Se o jogo for Halo, Call o Duty ou God of War, o roteiro deveria moldar-se a jogabilidade, e não o inverso. Questões como Projeto de Níveis (Level Design), mecânicas de jogo e estimulos, são os fatores mais importantes. Se eles não estiveres sólidos, não haverá história que segure o tranco. Ian friza que isto não significa que a história em um game não seja importante, mas o roteirista deve ser fleíivel o suficiente para mudá-la, baseando-se nas reações do jogador durante sua experiência interativa.

Dar mais atenção a história em relação ao demais elemento do projeto de jogo, podem causar outros problemas. Um exemplo citado por Fisch, é o título de 2003, Enter the Matrix.

Enter The Matrix - Jogo fez pouco sucesso devido a fraca jogabilidade.

O enredo do jogo, e suas CutScenes em live-Action (animação com atores reais), foram feitas para relacionar o game ao filme Matrix Reloaded. Os criadores do filmes, os irmãos Wachowski, estavam fortemente envolvidos na produção. O resultado foram fases que faziam sentido na perspectiva da história, mas sem propísito algum para jogabilidade. Além disto, a equipe de desenvolvimento foi persuadida a criar três tipos de jogos diferentes, com o personagem em carros, a pé e na água. Tudo demandado pela história.

Fisch comenta que uma vez trabalhou em um projeto de um game de ação em terceira pessoa (onde o jogador enxerga o personagem) com um roteiro que lhes foi entregue por um escritor de Hollywood. Apesar da história ser ótima , ela conflitava com vários elementos da jogabilidade que já haviam sido projetados. O roteiro contava sobre quatro níveis em lugares fechados com um punhado de inimigos, enquanto a mecânica do game era baseada totalmente em locais abertos.

Outro exemplo, seria o fato do jogo ter sido projetado para o jogador possuir um parceiro no campo de batalha, ao qual poderia dar ordens. Porém, o roteiro demandava que o protagonista agisse sozinho, em mais da metade do jogo. O cancelamento do projeto esteve diretamente relacionado ao fato da equipe de projeto ser forçada a seguir o roteiro de Hollywood, lamenta Fisch.

A história em um jogo de ação deveria ser responsabilidade de um Game Writer. Um roteirista especializado em jogos, pois antes de ser um escritor, ele era um gamer. Um Game Writer fica junto da equipe o tempo inteiro, entendendo porque sua história precisa ser reescrita continuamente.

Não dar as Ferramentas Necessárias ao Projetista

Há vários argumentos para limitar o que um projetista é capaz de fazer com ferramentas de desenvolvimento. Porém, quando mais funções e variáveis o Projetista tiver acesso, mais ele pode errar.

Não há nada que um programador goste mais do que concertar códigos desorganizados de um projetista. Além do mais, projetistas não são treinandos para programar. Eles desperdiçam tempo tentando fazer o que um programador foi treinado para executar.

Estes argumentos fazem sentido, mas o problema deve também ser analisado da ótica da produtividade do projetista. Se ele pode trabalhar em uma fase ininterruptamente, estará mais focado e produtivo. Se precisar requisitar a um programador toda vez que precisar de uma nova fucionalidade, seu ritmo de trabalho estará gravimente comprometido.

Ian diz que pode falar por experiência própria. Quando trabalhava como Projetista de Níveis, ocorreram situações que dependia de outras pessoas para executar seu trabalho, nestas ocasiões, normalmente frequentava mais a máquina de doces da empresa, desperdiçando mais tempo conversando com colegas e olhando para o relógio. Nos dias que podia trabalhar de forma ininterrupta, ele nem conseguia levantar da cadeira.

Ele acha que é fundamental encontrar um equilibrio saudável em relação ao que um projetista pode, e não pode fazer.

Nada de Divertido em Todo o Projeto

Durante o desenvolvimento de Mario 64, os criadores dedicaram meses trabalhando no movimento de Mario sobre um simples jardim. Eles queriam ter certeza que esta ação básica, seria divertida suficiente para manter o jogador envolvido e ajustado ao conceito 3D do game.

Mesmo o combate que utiliza um único botão do mouse, como Diablo, é divertido suficiente para engajar novos jogadores, depois que eles descobrem os elementos de RPG mais profundos do game. Infelizmente, muitos projetos são desenvolvidos sem ter algo realmente divertido.

Ter uma release (protótipo ou trecho de um jogo) registrando o que é divertido, pode ser um grande trunfo. Ela pode funcionar como uma luz que indica o caminho correto. Quando um game atinge meses de produção, a equipe esta tão acostumada que mais nada nele parece divertido. Neste momento, os projetistas podem pegar este protótipo para lembrar a experiência que tiveram quando jogaram pela primeira vez.

Ian comenta ter participado de um projeto onde não haviam releases registrando que o game possuia algo divertido. A equipe trabalhava com a esperança de que ao final, elementos inseridos garantissem uma boa diversão. Meses se passaram, idéias foram acrescentadas, e o game não conseguiu ganhar diversão alguma. Muitas pessoas fora do projeto não tinham uma idéia clara do que eles estavam fazendo, por outro lado pessoas dentro da equipe não conseguiam ter uma visão clara do caminho traçado pelo diretor do jogo.

Interessante  como muitos projetos independentes, como World of Goo e Braid, criados com uma verba muito pequena são mais divertidos do que produções com orçamentos astronômicos. Isto prova que diversão não necessariamente custa caro, e o quanto é importante garantir fatores divertidos logo no início de seu projeto.

Não Manter a Documentação do Projeto Atualizada

Quantas vezes você já ouviu alguem dizer, “Não leia estes documentos. Eles não estão atualizados”? Se a resposta for nenhuma, você não trabalha com jogos, ou teve muita sorte até agora. Documentos destualizados são muito comuns em equipes de desenvolvimento.

Isto pode parecer uma falha inevitável, afinal funcionalidades quase sempre se mostram diferentes de como foram projetadas no papel. Além disto, elas mudam muitas vezes após sua implementação original. Manter a documentação atualizada pode consumir muito tempo. Porém, se isto não for feito, as consequências podem ser bem sérias.

Quando a documentação de um projeto está desatualizada, a equipe perde a credibilidade nela. Eles assumem que o seu conteúdo não é válido, não utilizando os documentos como referência quando surgir uma dúvida. E, na maioria das vezes, acabam questionando diretamente o projetista. Fato este, muito preocupante, já que conversas sobre o projeto normalmente é fragmentada e focada em uma dúvida específica. Normalmente o programador vai acabar  implementando com base apenas no que lembrar das tais conversas.

Fisch comenta que estava trabalhando na fase de produção, quando precisou saber quais seriam a ordem dos níveis do jogo. O único modo de obter esta informação foi enviar um e-mail pra o projetista líder. Após um tempo, uma planilha  com as informações retornou, porém se comparada a documentação atual, estava totalmente incompatível.

Manter os documentos atualizados não é fácil, mas a tecnologia pode ajudar. Ian diz ter trabalhado para uma empresa que utilizava um sistema para controlar a atualização. Ele acusava documentos desatualizados, se duas semanas se passassem sem que eles sofressem alguma alteração. Tais documentos, nem poderiam ser abertos neste estado, apenas se o projetista confirmasse sua validade.

Não Prever Testes Externos

Mais e mais companhias estão percebendo o valor de fazer regularmente testes de jogabilidade (PlayTests) durante o processo de desenvolvimento. Valve, por exemplo, é conhecida por seus testes rigorosos de jogabilidade, utilizados na criação de Half Life 2 e Portal. Ubisoft também é conhecida por dar muito importância aos testes.

Infelizmente esta prática não é tão difundida quanto deveria.Vários desenvolvedores ainda vêem isto como algo não tão importante. Um Projetista experiente verá os testes de jogabilidade como a sua principal ferramenta em seu cinto de utilidades.

Se o foco dos testes não for o jogador hardcore (assíduo),  ma sim jogadores casuais ou crianças, os testes serão ainda mais importantes. Tentar ver através dos olhos de um jogador casual, exige mais de 15 anos de conhecimento acumulado em jogabilidade. Em outras palavras, é impossível.

Mesmo que você pense em desenvolver uma interface muito simples, ficará impressionado quando entregar pela primeira vez um controle nas mãos de uma mãe de 40 anos.

Se o foco for jogos para crianças, então prepare-se para um desafio ainda maior, uma criança de seis anos terá dificuldade com qualquer coisa além do mais simples conceito.

Mesmo que o foco seja o hardcore, os testes ainda são incrivelmente importantes. Com o andar do projeto, todo o projetista acaba se tornarndo um mestre no jogo que esta desenvolvendo. Questões que serão um desafio para o jogador alvo, se tornam facilmente entediantes para a equipe.

Se testes externos forem parte do desenvolvimento, a equipe de projeto pode refinar a dificuldade do game na medida certa, baseando-se nos resultados dos testes, ao invéz de utilizar suas percepções,  contaminadas pelo grande envolvimento com os elementos do jogo.

Fisch trabalhou com projetistas que preferiam não executar testes durante o desenvolvimento porque, segundo eles, confiar muito na visão de um grupo (neste caso a equipe de teste) pode interferir na visão artistica do projeto. Este argumento faz sentido, porém somente considera o fator diversão, ignorando o lado da jogabilidade.

Se a decisão for, não se importar com o fator diversão nos testes, bastaria não questionar os testadores sobre isto.  Porém se os testes indicarem que existe uma grande dificuldade já na primeira fase, devido a problemas com os comandos, isto deve ser identificado, e o mais rápido possível.

Conclusão

Se você trabalha como um projetista de jogos, eu imagino que tenha passado por várias destas armadilhas. Fisch comenta que mesmo com uma boa verba e uma ótima equipe, o sucesso não estará garantido. Muito ainda depende de como o Projeto de Jogo será conduzido.

Várias das armadilhas citadas neste artigo, agora que conhecidas, são fáceis de serem evitadas. Porém outras devem receber uma atenção especial, tais como Revisar o Trabalho da Equipe e Dar Muita Importância ao Projeto no Papel, pois exigem um esforço continuo e dedicação.

Um abraço, e até o próximo post!

Referências : Artigo original de Ian Fisch

Ilustrações: Inara Cavichioli

One Response to “As 10 Armadilhas no Game Design – parte 2”