As 10 Armadilhas no Game Design – parte 1

PitfallLogoOlá pessoal, vocês já pararam para pensar quais seriam os fatores responsáveis por um game de sucesso? Poderíamos dizer que uma boa mecânica e idéias inovadoras garantem um blockbuster?

É 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. Mas a criação de games envolve criatividade, arte e inspiraçã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.

Não Estruturar Tempo para Pesquisa de Jogabilidade

Pitfall01A 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éz 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 (ou Sonic UmLisho :P), 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 aqui no blog para comentar esta pérola da SEGA.

Sonic Unleashed 01

Sonic Unleashed – Um exemplo de como desperdiçar o potencial de um ótimo personagem

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.

Dar Muita Importância ao Projeto no Papel

Pitfall02Ian 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 construia 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 possuiem 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.

Não Avaliar o Trabalho da Equipe

Pitfall03Se 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 coelgas à 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.

Confundir Projetista Líder com Produtor?

Pitfall04Existem 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 admistrativas, 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.

Não Tirar Vantagens dos PlaceHolders

Pitfall05PlaceHolders, apesar de ser um termo muito utilizado no desenvolvimento de jogos, pode ser pouco conehcido 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 substituido por um melhor acabado, ou totalmente funcional.

Ian comenta que a utilização deste recurso é algo muito importante no desenvolvimento, o que é facil 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 substituidos 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éz 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.

Bom pessoal, o que vocês estão achando até agora destas dicas? Eu me identifiquei muito com praticamente todas elas. Dentro de alguns dias estarei postando a segunda parte e a conclusão desta interessante abordagem sobre o projetos de jogos, até lá.

Confira a segunda parte >>

Ilustrações: Inara Cavichioli

1. Not Structuring Time For Game PlayingThis first pitfall seems trivial, but can actually have a large impact on the quality and efficiency of the design process. Ideally pre-production would include a set amount of time for everyone on the design team to play games in the genre they are about to take a shot at.

I’ve never seen this happen in a structured way. “Play time” can be hard for some producers to wrap their heads around, and the idea of scheduling a week or more of “research” for a five-person team can seem like a rather expensive play session.

Instead, designers are expected to already have a strong knowledge of what’s out there. Unfortunately not all game designers have enough free time to play every game out there. Generally, the older the game designer is, the less free time he’ll have. Furthermore, the games a designer chooses to play in his free time may not line up with the games he should play for development purposes. Many mediocre games, for example, contain interesting ideas and are valuable as learning tools.

Devoting time to playing other games in your genre can lead to a better product and save a tremendous amount of time. I worked on a project where a designer happened to play a game in the genre we were working in and “discovered” a better player navigation system than the one we had already spent months on.

On another project, someone “discovered” a third-person cover mechanic implemented in an unpopular game that was exactly like the one we argued about including. Weeks of debate could have been saved had we played this game and had known that the mechanic wasn’t as fun as it seemed on paper.

1- Não Estruturar Tempo para a jogabilidade

A primeira armadilha parece trivial, mas pode atualmente ter um grande impacto na qualidade e eficiência do processo de Design. O ideal seria que pre-produções incluissem no processo um período para que todos do time jogassem jogos do mesmo genero do que eles estarão produzindo.

Eu nunca vi isto ocorrer de forma estruturada. A “Hora de jogar” pode ser mal vista por alguns produtores, e a idéia de agendar uma semana ou mais de “pesquisa” pode parecer dinheiro jogado fora.

Ao invéz disto, presume-se que os designers já possuem um grande conhecimento do que existe no mercado. Infelizmente nem todos possuem tempo livre suficiente para jogar todos os jogos disponíveis. Normalmente, o GD 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 medíocres, por exemplo, contém ideias interessantes e são valiosas ferramentas de aprendizagem.

SONIC UNLEASHED

Eu inclusive citaria Sonic Unleashed (ou seria Sonic UmLisho?), que mesmo possuindo um time dedicado ao personagem, o SONIC Team, consegue a cada titulo cometer os mesmos erros. Este título na verdade é um objeto de estudo, de como não se deve fazer um jogo (farei logo logo um post comentado todos os pontos desta pérola).

Dedicar tempo para jogar outros jogos do seu genero pode levar a um melhor produto e poupar um grande período de tempo. Ele trabalhou em um projeto onde o desginer começou a jogar um game do mesmo genero que trabalhavam e “descobriu” um melhor sistema de navegação para o jogador do que eles haviam dedicado meses em cima.

Em outro projeto, algué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, pois já seria possivel analisar se a mecanica é divertida como parecia no papel.

Adquirir experiencia jogando games relevantes para o processo, melhoram muito suas habilidades para expressar idéias para os outros do time. Um Designer pode dizer para o outro “Nós precisamos implementar um sistema de Lock-on 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 necessitar de alguma persuasão. Um produtor pode ser mais receptivel 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.

2. Placing Too Much Importance On Paper Designs

Students of mathematics may know that one of the fundamental ideas of Chaos Theory is that some systems, such as the weather, are so complex that it is impossible to make accurate predictions of their behavior. There are too many interacting variables, any one of which could lead to a major change. I feel that games are the same way.

A designer can try to imagine how a level is going to play in his head, but any of the hundreds of interacting elements — the environment, the controls, the game mechanics, the physics, or the AI can each make a huge impact on the overall fun. This is one reason that I don’t put too much weight on paper designs.

The second reason is that, in my experience, the best ideas are discovered through experiments and happy accidents. I’ll often be building a level based on a paper design when I notice that when the AI interacts with the environment in a certain way, I get a really cool little experience.

I will then modify the level to make this something that most players will encounter. This form of discovering fun through interacting with the game’s systems only works when the designer has the freedom to modify his level from the original paper design.

Unfortunately, designers don’t always have this freedom. I’ve worked on teams where designers were given equal time to create a level on paper as to create it in 3D. Once a paper design was finished, it was presented at a big meeting, analyzed and approved.

If a designer wanted to make a large change during the 3D phase, this was treated as correcting an error he had made in the paper process. The paper design had to be reedited and another approval was needed from the department leads.

Designers were expected to get it right the first time. The end result of this process was environments that didn’t fit with the game. For example, some environments featured enemies that the player could see and pick off from a mile away. Others featured enemies that the player couldn’t see until they were two feet from his face.

2- Dar muita importância ao projeto no papel

Ian faz um relação dos games com o sistema de previsão do tempo. Segundo ele, ambos são um tanto imprevisiveis, com muitas variáveis interferindo em seu processo. O projetista pod tentar imaginar como uma fase funcionará em sua cabeça, mas qualquer um das centenas de elementos interativos – o ambiente, os controles, o mecanismo do jogo, a física ou  a AI, podem ter um grande impacto na diversão do todo. Este seria o primeiro motivo para o Game Designer 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 construia uma fase baseado nos documentos de projeto, percebia que a AI interagia com o ambiente de uma certa forma, gerando experiências interessantes e não previstas. Após este fato, ele normalmente modificava o projeto inicial para contemplar tal experiência.

Infelizmente ele comenta que nem sempre os Designers tem esta liberdade. Ele relata ter trabalhado em equipes onde tinha o mesmo tempo para criar uma fase no papel e também em 3D (aqui presumindo que o projetista tenha a função de também criar o nível através de um editor). Uma vez finalizado o projeto de jogo, ele é apresentado em um grande reunião, é analisado e aprovado.

Se o Game Designer 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 do projeto.

3. Peer Review Not Taken Seriously

If you’ve worked at a game company you’ve probably heard the phrase “more people need to play the game” tossed about at a meeting or two.

These calls are generally made to the artists and programmers, yet I notice that designers have a habit of not playing each other’s work. I’ve definitely fallen into the trap of being so focused on my own work that I neglect to play the work of others.

Regularly playing other designers’ levels leads to cross-pollination of ideas and generally makes a better game. Often I’ve seen one designer play another’s level, think an element is cool and then include it in his own level with improvements.

A healthy sense of competition is created in the team where each tries to take another’s idea and one-up them. By playing levels other than their own, designers also gain a better feel for how the game will play as a whole rather than just seeing it through the perspective of his personal chunk.

Peer review is something that will fall apart unless it is strictly enforced by a lead. I recommend that a team have weekly scheduled peer review sessions where all designers are told to put down their own work and spend the afternoon reviewing the work of his teammates.

The peer review day shouldn’t be too close to a deadline. For instance if milestones are usually on Fridays, schedule your peer reviews for Tuesday afternoon.

3. Não avaliar o trabalho da equipe

Se você trabalha em uma compania de jogos provavelmente já ouviu a frase “mais pessoas precisam jogar este game” comentado em um, ou mais reuniões. Isto normalmente é feito por programadores e artistas. Ian confessa que dificilmente observa o trabalho do resto da equipe, e sabe que isto é uma 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 designer 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 outros a procura de idéias para o seu projeto. Ele inclusive sugere que se tenha um dia na agenda para esta tarefa, e que ela seja próxima ao prazo de entrega.

4. Decision-Maker Picked For His Producer Skills

There are many different roles on a design team and many different types of designers. It’s been my experience that the designers promoted to the role of lead have been almost exclusively the types that gravitate toward the administrative tasks — such as creating the spreadsheet that dictates which enemy type will be included in which levels.

Those that gravitate toward content creation usually stay there. A designer who excels at making levels will not be rewarded with a promotion — and thus will not have the opportunity to make the big game design decisions. While both types of designers are equally important, this imbalance can be harmful to a project.

The reasons for this imbalance are obvious. Being a lead requires a sense of responsibility for people’s work other than your own. It requires good people skills. It is difficult to demonstrate either when your head is in an editor eight hours a day.

It is easy to demonstrate these, on the other hand, when you are handling tasks that involve the entire team — for example if you are responsible for making sure design requests find their way to programming in a timely and organized manner.

Unfortunately, it can be bad for a project if the person making the design decisions has never made compelling content himself. He is less likely to choose wisely when it comes time to deciding what ideas get included in the game and what get left on the floor.

Worse, having spent little time in the trenches, he will not have first-hand knowledge of what processes lead to good content creation. For instance he may not place importance on peer review since he’s never benefited from it in his own work.

Picking a good lead is difficult, and a team is lucky if it has a lead who is a responsible leader and has a good sense of what makes good content. Since these are two different skill sets, I recommend that they not necessarily fall on the same person.

The lead designer could devote his time to maintaining design processes, reviewing the other designers’ work, and hopefully getting some hands-on time with the tool set. Meanwhile the administrative tasks, such as creating task lists and weekly reports, would be handled by a producer that works closely with the design department.

4. Projetista Líder igual a produtor?

Existem muito 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 aqueles que estão rodeados de tarefas administrativas, tais como criar uma planilha que indica quais inimigos serão incluídos em determinada fase.

Já 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 rasões para este desequilibrio são um tanto óbvias, tornar-se um líder reqyer um senso de responsabilidade pelo trabalho das pessoas além do seu próprio. Isto exige boa habilidade para tratar com pessoas. Isto é dificil de demonstrar quando sua cabeça esta 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, um time tem sorte se possuir uma liderança responsável e capaz de tomar boas decisões para desenvolver um bom conteúdo. Ele ainda acredita que estas habilidades são muito distintas e recomenda não necessáriamente caiam sobre a mesma pessoa.

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

5. Not Taking Advantage Of Placeholders

Placeholder assets and code are used a lot in this industry, yet placeholder use often greatly diminishes once production starts. It is understandable. If a developer is working for a publisher, it’s very important to show progress. Going from a nice shiny vertical slice to builds filled with jerky animations and flat-shaded backgrounds can look like a step backward.

Internally, team members, particularly artists and animators, generally prefer working on final assets than low-quality ones that will have to be replaced later. Producers generally prefer something done once rather than twice. Unfortunately under-use of placeholders reduces final game quality and slows down the design process.

The basic scenario goes like this: a designer wants to see an asset in game — be it a 3D model, an animation, a gameplay mechanic, etc. Rather than wait a few hours for a placeholder, he must wait a week for the finished asset. If what he receives isn’t as fun as he had imagined, that will be a week of work wasted.

To avoid this from happening, long approval processes are often implemented with the intention of weeding out all but the best ideas. In practice the approval process can shear off all but the least risky elements of the idea until it’s lost its originality.

So now instead of trying out an idea with a placeholder and moving on, the designer must wait a week to receive a final asset that is often far less interesting than what he would have discovered through experimentation with placeholders.

Working without placeholders wastes time in many ways. Levels made up of hundreds of 3D meshes take longer to load and test than those that are made of simple BSPs. They take much longer to modify because they’re made of 100’s of pieces instead of a few simple shapes.

Finally less experienced mission designers will waste time showing off their interior decoration and lighting skills when they should be focusing on making fun gameplay. Some flat-shaded textures, a pool of placeholder 3D objects, and a watchful eye of an artist to make sure things are architecturally sound should be all a mission designer needs to make fun environments.

A placeholder-heavy game design process requires a lot from a lot of people. It requires a studio that can shuffle artists to other duties while the design team settles on what they want for the “final” level.

It requires faith that the higher-ups (be they an external publisher or an internal studio head) are not as superficial and can appreciate the value of a fun, if ugly, level filled with placeholders. If you don’t have this faith, outside playtesting can be used to quantify the “fun” in lieu of showing polished graphics.

5. Não tirar vantagens dos PlaceHolders

PlaceHolders apesar de ser um termo muito utilizado no desenvolvimento de jogos, pode ser pouco conehcido por 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 substituido por um melhor acabado, ou totalmente funcional.

Ian comenta que a utilização deste recurso é algo muito importante no desenvolvimento, o que é facil 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. Passando de boas e brilhantes botões de rolagem a prédios preenchidos com animações absurdas podem parecer um passo atrás.

Membros da equipe, principalmente artistas e animadores, normalmente preferem trabalhar no asset final do que nos de baixa qualidade a serem substituidos mais tarde. Produtores normalmente preferem uma coisa terminada do 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 Yan, seria um projetista quer ver um determinado asset no game, uma mecânica de jogabilidade. Ao invéz de esperar algumas horas por um placeholder, ele precisa esperar uma semana pelo asset finalizado. Se por ventura, isto não estiver com a diversão que ele imaginou, foi uma semana desperdiçada.

Outra situação bem comum seria na etapa de teste, onde o foco seria a jogabilidade, sem o uso destes assets temporários o testador pode distrair-se 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.

Autor: Everton Vieira Ver todos os posts de
Sou Bacharel em Análise de Sistemas pela Universidade Católica de Pelotas (UCPel) no ano de 1999. Minha paixão por games é de longa data. Porém, em 2003 tornei essa paixão uma profissão. Durante oito anos atuei como Game Designer e Arquiteto de Software em mais de 30 projetos de Serious Games (simuladores) para grandes empresas do país. Atualmente sou sócio-fundador da Izyplay Game Studio, onde exerço o cargo de Diretor de Criação. Além do envolvimento corporativo, também participei da organização da Pós Graduação em Arquitetura e Desenvolvimento de Jogos Digitais na FATEC SENAC Pelotas. Minha área de interesse e especialização é Game Design e Inteligência Artificial.

8 Comentários em "As 10 Armadilhas no Game Design – parte 1"

  1. Luis Otavio 15/06/2009 at 21:48 - Reply

    Eu gostei apesar de não achar nada muito inovador, parece com muita coisa que ja li escrita de maneira ao crontrário, que pode ser bom, porque se todos os designers de games leram as mesmas coisas que li, e continuam fazendo jogos sem inovação nenhuma como os jogos que vemos hoje, repetindo os mesmos erros, provavelmente eles não estejam entendendo. Quem sabe explicando de forma diferente, entre na cabeça de pelo menos alguns deles. Estou curioso para ver o resto do post, vê se não demora muito para postar, até.

  2. Everton 15/06/2009 at 22:35 - Reply

    Olá Otávio, concordo com você em parte. Achei bem interessante, e posso dizer até inovador, a abordagem de Ian Fisch. Como no próprio post é comentado, existem artigos com 100 Dicas de como fazer um bom game, porém existem várias formas de se fazer isto. Se pegarmos 10 sucessos da indústria, provavelmente cada um teria a sua “fórmula mágica”. Acredito que isto é devido a natureza desta mídia, que envolve muita criatividade e arte. Exatamente foi neste ponto que o texto de Fisch me chamou atenção. Ele destaca as armadilhas neste processo, o que sem sombra de dúvida é mais fácil de elencar do que as boas práticas. 🙂
    Mas não perca a segunda parte, asseguro que será ainda mais interessante!

  3. Janie Moss 29/05/2010 at 17:42 - Reply

    Hah am I honestly the only reply to this amazing post.

  4. Alex 05/01/2011 at 13:22 - Reply

    Uma dúvida: jogar games pré-existes tem seus beneficios, como citou no caso da jogabilidade. Mas isto tb não lmita a criatividade? Pois os integrantes da equipe podems implesmente copiar algo existente ao inves de tentar algo novo.

    • everton.vieira 10/01/2011 at 14:45 - Reply

      Olá Alex,
      Na minha opinião, de forma alguma.
      Eu gosto da definição de criatividade que descreve ela como a capacidade de fazer novas ligações entre as “memórias” já existentes. Partindo disso, quanto mais games, jogabilidades, experiências, desafios você conhecer, mais criativo você será 😉

    • Bárbara 29/10/2011 at 22:06 - Reply

      Não sou da área, mas minha experiência como alguém que adora escrever histórias diz o inverso. Ver boas ideias e aplicá-las instiga sua criatividade quando sua intenção é usar a ideia sem que ela seja uma cópia.
      Se você reaproveitar uma ideia mudando tudo que a identificaria como sendo a velha ideia, você cria algo novo e as vezes muito melhor, porque você não partiu do zero, mas de um bom alicerce.
      É claro que para isto tem que ter bom senso para não estragar algo que foi muito bem concebido. Aquela história de “Se melhorar estraga”.

      Quer um bom exemplo? Não precisa ler o livro, assista a adaptação da Disney de “Alice no país das maravilhas” e depois assista ao primeiro filme da série “Matrix” e você vai descobrir muitos elementos de uma história na outra. E os dois sequer são parecidos.

  5. Bárbara 29/10/2011 at 22:09 - Reply

    Eu quero ler a segunda parte, mas a Worpress.com está me dizendo que o autor deletou o blog…

    • everton.vieira 30/10/2011 at 01:57 - Reply

      Olá Bárbara,

      Havia um erro no link, já corrigimos. 😉

Deixar um Comentário