agosto 21

10 Armadilhas do Desenvolvimento de Jogos (GameDesign)

É muito comum encontrarmos na web orientações de como fazer um bom Game Design. Os artigos variam de 10 à 100 dicas, mostrando o que deve ser feito no projeto de um bom jogo. Inclusive aqui mesmo no site, já li ótimos textos. Mas a criação de games envolve criatividade, arte e inspirarão. Fatores estes, difíceis de serem padronizados ou estarem contidos em uma fórmula mágica.

Por este motivo que o texto de Ian Fisch, Game Designer profissional de empresas como GameLoft e Pyro Studio, me chamou a atenção. Fisch, ao contrário da grande maioria, destaca o que Não deve ser feito. Portanto, inspirado em seu texto, o artigo deste final de semana traz para vocês uma lista das 10 Pitfall’s (Armadilhas) que podem ocorrer durante o desenvolvimento de jogos.

Antes de começar, gostaria de fazer um comentário sobre o termo Game Designer. É importante informar que o “Designer” aqui não faz referência alguma ao artista digital, a palavra refere-se a Projetista, portanto a melhor tradução para o termo seria, Projetista de Jogo e para Game Design, Projeto de Jogo. Para facilitar o entendimento do artigo, vou me referenciar aos termos em português.

1ª – Não Estruturar Tempo para Pesquisa de Jogabilidade

A primeira armadilha parece trivial, mas pode ter um grande impacto na qualidade e eficiência de seu projeto de jogo. O ideal seria que as produções incluissem em seu processo, um período para que todos da equipe jogassem games do mesmo gênero que estiverem produzindo.

Ian comenta que nunca viu isto ocorrer de forma estruturada. A “Hora de jogar” normalmente é mal vista por alguns produtores, e a idéia de agendar uma semana, ou mais, para “pesquisa” pode parecer dinheiro jogado fora.

Ao invés disto, presume-se que os projetistas já possuam um grande conhecimento do que existe no mercado. Infelizmente nem todos possuem tempo livre suficiente para jogar todos os jogos disponíveis. Normalmente, o Projetista mais antigo é o que menos tempo possui para este tipo de tarefa. E quando isto ocorre, dificilmente os jogos estão relacionados com seu trabalho. Muitos jogos, mesmo os medíocres, contém idéias interessantes e são valiosas ferramentas de aprendizagem.

Concordo com Fisch, inclusive citaria um game que joguei recentemente, Sonic Unleashed, que mesmo possuindo uma equipe dedicada ao personagem, o SONIC Team, consegue, a cada título, cometer novos erros. Este game é um objeto de estudo, de como não se deve fazer um jogo. Em breve, dedicarei um post inteiro para comentar esta pérola da SEGA.

Dedicar tempo para jogar outros jogos do mesmo gênero, pode levar a um melhor produto e poupar tempo. Ian, inclusive cita um projeto onde o responsável teve a iniciativa de jogar games do mesmo gênero em que trabalhava, e “descobriu” um ótimo sistema de navegação para o jogador. O curioso, é que a equipe já havia dedicado meses em cima da mecânica existente.

Em outro projeto, alguém também “descobriu” uma mecânica de terceira-pessoa, implementada em um jogo nem tão popular, exatamente igual a que eles estavam analisando para incluir no projeto. Semanas de debate poderiam ter sido poupadas se eles tivessem jogado este game antes, já que seria possível analisar se a mecânica era realmente divertida como parecia no papel.

Adquirir experiência jogando games, melhoram muito suas habilidades para expressar idéias aos membros da equipe. Um Projetista pode dizer para o outro “Nós precisamos implementar um sistema de mira semelhante ao do Metroid Prime”. Se o colega já conhece o game, entenderá imediatamente a idéia.

Implementar um período estruturado para jogar games pode exigir de persuasão. Um produtor pode ser mais receptível a isto se receber resultados mais concretos, como por exemplo, entregar relatórios ao final do dia para o líder analisar as jogabilidades experimentadas.

Aqui na empresa normalmente eu separo um tempo, durante o desenvolvimento do projeto de jogo, para estudar games com mecânicas, ou até mesmo visual, do mesmo gênero que estou imaginando implementar.

2ª – Dar Muita Importância ao Projeto no Papel

Ian compara games com o sistema meteorológico. Segundo ele, ambos são um tanto imprevisíveis, com muitas variáveis interferindo em seu processo. O projetista pode tentar imaginar como uma fase funcionará em sua cabeça, mas qualquer um dos vários elementos interativos (o ambiente, os controles, o mecanismo do jogo, a física ou AI), podem ter um grande impacto na diversão do todo. Este seria o primeiro motivo para o Projetista de Jogo não colocar tanto peso assim para os documentos de projeto.

Segundo Ian, a segunda razão seria que as melhores idéias são descobertas através de experiências e felizes acidentes. Por várias vezes, enquanto construía uma fase baseada nos documentos de projeto, percebia que a AI interagia com o ambiente de uma forma interessante, gerando experiências não previstas. Após este fato, ele normalmente modificava o projeto inicial para contemplar tal experiência.

Infelizmente, nem sempre os Projetistas possuem esta liberdade. Uma vez finalizado o projeto de jogo, ele é apresentado em uma grande reunião, é analisado e aprovado.

Se o Projetista de Jogo precisar efetuar uma grande mudança durante a etapa de implementação, isto é considerado como a correção de um erro que foi cometido durante o projeto. Nestes casos, a documentação é ajustada e uma nova aprovação é repassada aos líderes.

Compartilho com a visão do experiente projetista, porém não posso dar pouca importância a documentação no papel. É somente através dela que posso registrar minhas idéias e apresentá-las ao cliente. No ramo de Serious Games, ou até mesmo no modelo TailorMade (feito por encomenda), o produto deve ter seus requisitos muito claros durante a etapa de projeto. Uma alteração importante no meio do desenvolvimento, representa um alto custo. Claro que não posso exigir que o cliente aprove o game no papel, mas faço um grande esforço para que a maior quantidade de informações esteja ali.

3ª – Não Avaliar o Trabalho da Equipe

Se você trabalha em uma empresa de jogos provavelmente já ouviu a frase “mais pessoas precisam jogar este game“, comentado em uma, ou mais reuniões. Isto normalmente é falado por programadores e artistas. Ian confessa que dificilmente observa o trabalho do resto da equipe, e sabe que isto é uma grande armadilha.

Normalmente jogar fases criadas por outras pessoas levam a pulverização de idéias e garantem um bom jogo. Muitas vezes ele relata ter visto um projetista jogar uma fase criada por outro, encontrar elementos interessantes, e incluir em seu trabalho.

Uma competição sadia é criar na equipe o hábito de analisar o trabalho dos colegas à procura de idéias para o seu projeto. Ele inclusive sugere que se tenha um dia na agenda para esta tarefa, e que ela não seja próxima ao prazo de entrega, pois sempre surgirão novas idéias neste processo.

4ª – Confundir Projetista Líder com Produtor?

Existem muitos papéis diferentes em uma equipe de projeto, além de muitos tipos de projetistas. Em sua experiência, Ian comenta que os projetistas promovidos a líderes, seriam normalmente aqueles que estão rodeados de tarefas administrativas, tais como criar uma planilhas que indicam quais inimigos serão incluídos em determinada fase.

Já o tipo que envolve-se com criação de conteúdo, permanecem nesta área. Um Projetista que é excelente na criação de fases não será recompensado com uma promoção, portanto, não terá a oportunidade de tomar grandes decisões em um projeto de jogo. Embora ambos os tipos de projetistas, são igualmente importantes, esse desequilíbrio pode ser prejudicial para um projeto.

As razões para este desequilíbrio são um tanto óbvias, tornar-se um líder requer um senso de responsabilidade pelo trabalho das pessoas, além do seu próprio. Isto exige boa habilidade para tratar com pessoas. Uma tarefa bem difícil de demonstrar quando sua cabeça está as 8 horas do dia focada em um editor de níveis.

Encontrar um bom Projetista líder não é uma tarefa fácil, comenta Ian, uma equipe tem sorte se possuir uma liderança responsável e capaz de tomar boas decisões, que levem a desenvolver um bom conteúdo. Ele ainda acredita que estas habilidades, Liderança e Criação, são muito distintas, e recomenda que não sejam atribuidas a mesma pessoa.

O projetista líder deve dedicar seu tempo para o processo de criação, revisando o trabalho da equipe. Entretanto, as funções administrativas, como criar lista de tarefas e relatórios semanais, devem ficar a cargo do produtor que trabalha muito próximo ao departamento de projeto.

Apesar de concordar com Ian também neste item, destaco que a realidade de nosso país hoje é um pouco diferente. O desenvolvimento de jogos não permite ainda a contratação de uma equipe muito grande. Por este motivo, várias pessoas ainda acumulam mais de um função.

5ª – Não Tirar Vantagens dos PlaceHolders

PlaceHolders, apesar de ser um termo muito utilizado no desenvolvimento de jogos, pode ser pouco conhecido por nós aqui. Ele refere-se a um asset (animação, modelo 3D, mecânica de jogo) temporário de baixa qualidade ou funcionamento resumido, que será futuramente substituído por um melhor acabado, ou totalmente funcional.

Ian comenta que a utilização deste recurso é algo muito importante no desenvolvimento, o que é fácil de entender. Se um desenvolvedor está trabalhando para uma publisher (empresa encarregada da distribuição de um game, que normalmente demanda o projeto), é muito importante mostrar progresso. Porém isto não significa diretamente entregar botões de rolagem brilhantes e polidos, ou até prédios preenchidos com animações absurdas.

Membros da equipe, principalmente artistas e animadores, normalmente preferem trabalhar no asset final do que nos de baixa qualidade a serem substituídos mais tarde. Produtores normalmente preferem uma coisa finalizada que duas em desenvolvimento. Infelizmente o pouco uso de placeholders reduzem a qualidade final do game, além de tornar o projeto de jogo um processo mais demorado.

Um exemplo clássico, comentado por Ian, seria um projetista querendo ver um determinado asset do game, uma mecânica de jogabilidade. Ao invés de esperar algumas horas por um placeholder, ele precisa esperar uma semana pelo asset finalizado. Se por ventura, o asset não estiver com a diversão que ele imaginou, uma semana teria sido desperdiçada.

Esta dica de Ian é muito importante. Eu citaria um outra situação bem comum, durante a etapa de teste, onde o foco seria a jogabilidade, sem o uso destes assets temporários o testador pode distrair-se com fatores irrelevantes, ou até mesmo esperar a carga de arquivos que não possuem relação alguma com o seu foco, ou seja, testar se o game esta divertido de jogar.

6ª – 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 videogames 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 of 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 estímulos, são os fatores mais importantes. Se eles não estiveres sólidos, não haverá história que segure o tranco. Ian frisa 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 o 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.

7ª – 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 funcionalidade, seu ritmo de trabalho estará gravemente 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 equilíbrio saudável em relação ao que um projetista pode, e não pode fazer.

8ª – 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 possuía 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.

9ª – 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 desatualizados 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 conseqüê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.

10ª – 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 tornando 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és 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 artística 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 projetista de jogos, como 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.

Artigo Original: Ian Fisch

Matéria retirada do site: GameCultura


Tags:, , , , , , , , , , , , , , , , , , , , , ,

Posted 21 de agosto de 2010 by Vilela in category "GameDesign", "Texto

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Protected with IP Blacklist CloudIP Blacklist Cloud