8 Diagramas de Progresso

Criar um fluxograma para mostrar o progresso do jogador no game. Este tipo de diagrama serve como um mapa não linear para uma narrativa. A imagem abaixo apresenta o mapa do game Ultima VII (1992 Origin Systems), é possivel perceber as diferentes decisões a serem tomadas pelo jogador durante sua jornada.
O grafico de progresso também pode ser aplicado para jogos em turnos, descrevendo detalhadamente as atividades de cada fase.

Storyboards

Para jogos com cutscenes e cinematics, identifique estas cenas no diagrama e insira material adicional na forma de storybords e scripts que descrevam a cena. Uma ótima referencia seria o livro Don Bluth’s The Art of Storyboard [Bluth and Goldman 04].http://www.amazon.com/Don-Bluths-Art-Storyboard-Bluth/dp/1595820078

9 Direção de Arte

A seção de direção de arte é a combinação de texto descritivo e imagens que transmitem o estilo gráfico do jogo. Ela normalmente inclui concepções (como da figura abaixo), referencia de artes de livros para inspirar o estilo, instruções de uso da luz em jogos 3D, exemplo de fonts e até limitações definidas pela tecnologia atual.

http://cache.kotaku.com/assets/resources/2007/07/gypsies_900.jpg

10 Storyboards de Interface do Usuário

Para um jogo de computador, a interface do usuário é o instaldor, a tela de título, menus, diálogos, HUD (Head Up Display) e qualquer outro controle ou texto. Cada um destes deve ser devidamente projetado através de uma storyboard gráfico e de conteúdo, apesar do conteúdo ser o foco desta seção. Storyboards podem ser simples esboços que mostram os elementos da GUI (Graphic User Interface), com rótulos indicando a funcionalidade de cada elemento. Fluxogramas são necessários para descrever cada interação do jogador e a resposta do jogo para esta ação.

11 Arquitetura de Software

Video games necessitam de um projeto de software complexo. Os documentos de arquitetura descrevem as funcionalidade de cada módulo de programação. Isto inclui o uso de APIS, algoritmos que serão usados para implementá-los, além dos padrões de projetos envolvidos na produção. Esta seção contará com vários diagramas, entre eles:diagramas de classes, diagrama de sequência, de fluxo e o já conhecido diagrama de módulos de sistema. Observe abaixo um exemplo de cada um deles.

Obviamente este post não destina-se a explicar como funciona cada um dos diagramas, porém outros post virão com esta finalidade.

12 Controles

Video games dependem de seus esquemas de controle. Um grande jogo pode ser um fracasso se a mecanica de entrada estiver inadequada ou destinada a um público-alvo que não é o mesmo de seu projeto. A seção Controles detalha ambos, o mapeamento dos botões para as funções do jogo e o mapeamento dos algoritmos de entrada para as ações.

Figure 5.6: Controls for Roadkill on the PlayStation 2 by Red Octane. (Image courtesy of Red Octane/Activision)

13 Projeto de Níveis (Level Design)

A maioria dos games são divididos em níveis que representam uma discreta mudança na dificuldade, como diferente ondas de aliens em Space Invaders. Estes níveis também podem ser representados por novos mapas ou cenários. Em jogos clássicos, como Xadrez, níveis são um tanto vagos (embora podemos considerar a abertura, meio e fim como níveis distintos)

Em jogos com uma forte progreção linear, níveis são normalmente areas em grandes mundos. A progressão nestas áreas deve ser descrita pelo gráfico de progresso da seção anterior. Já para jogos com niveis baseados em locações, você deve criar um mapa para mostrar o layout e conectividade do nível. Indicando encontros, locais com itens e objetivos.

Esta seção em resumo deve preocupar-se em deixar o jogo equilibrado e desafiante. Atualmente é bastante comum encontrarmos editores específicos para esta finalidade, permitindo que um profissional focado nesta área, com pouco conhecimento de programação, possa ter total autonomia para definir cada nível do game. Na verdade podemos pensar ainda um pouco mais longe, existem jogos que deixam o jogador assumir este papel.

Little Big Planet.8 Diagramas de Progresso

Criar um fluxograma para mostrar o progresso do jogador no game. Este tipo de diagrama serve como um mapa não linear para uma narrativa. A imagem abaixo apresenta o mapa do game Ultima VII (1992 Origin Systems), é possivel perceber as diferentes decisões a serem tomadas pelo jogador durante sua jornada.

O grafico de progresso também pode ser aplicado para jogos em turnos, descrevendo detalhadamente as atividades de cada fase.

Storyboards

Para jogos com cutscenes e cinematics, identifique estas cenas no diagrama e insira material adicional na forma de storybords e scripts que descrevam a cena. Uma ótima referencia seria o livro Don Bluth’s The Art of Storyboard [Bluth and Goldman 04].http://www.amazon.com/Don-Bluths-Art-Storyboard-Bluth/dp/1595820078

9 Direção de Arte

A seção de direção de arte é a combinação de texto descritivo e imagens que transmitem o estilo gráfico do jogo. Ela normalmente inclui concepções (como da figura abaixo), referencia de artes de livros para inspirar o estilo, instruções de uso da luz em jogos 3D, exemplo de fonts e até limitações definidas pela tecnologia atual.

http://cache.kotaku.com/assets/resources/2007/07/gypsies_900.jpg

10 Storyboards de Interface do Usuário

Para um jogo de computador, a interface do usuário é o instaldor, a tela de título, menus, diálogos, HUD (Head Up Display) e qualquer outro controle ou texto. Cada um destes deve ser devidamente projetado através de uma storyboard gráfico e de conteúdo, apesar do conteúdo ser o foco desta seção. Storyboards podem ser simples esboços que mostram os elementos da GUI (Graphic User Interface), com rótulos indicando a funcionalidade de cada elemento. Fluxogramas são necessários para descrever cada interação do jogador e a resposta do jogo para esta ação.

11 Arquitetura de Software

Video games necessitam de um projeto de software complexo. Os documentos de arquitetura descrevem as funcionalidade de cada módulo de programação. Isto inclui o uso de APIS, algoritmos que serão usados para implementá-los, além dos padrões de projetos envolvidos na produção. Esta seção contará com vários diagramas, entre eles:diagramas de classes, diagrama de sequência, de fluxo e o já conhecido diagrama de módulos de sistema. Observe abaixo um exemplo de cada um deles.

Obviamente este post não destina-se a explicar como funciona cada um dos diagramas, porém outros post virão com esta finalidade.

12 Controles

Video games dependem de seus esquemas de controle. Um grande jogo pode ser um fracasso se a mecanica de entrada estiver inadequada ou destinada a um público-alvo que não é o mesmo de seu projeto. A seção Controles detalha ambos, o mapeamento dos botões para as funções do jogo e o mapeamento dos algoritmos de entrada para as ações.

Figure 5.6: Controls for Roadkill on the PlayStation 2 by Red Octane. (Image courtesy of Red Octane/Activision)

13 Projeto de Níveis (Level Design)

A maioria dos games são divididos em níveis que representam uma discreta mudança na dificuldade, como diferente ondas de aliens em Space Invaders. Estes níveis também podem ser representados por novos mapas ou cenários. Em jogos clássicos, como Xadrez, níveis são um tanto vagos (embora podemos considerar a abertura, meio e fim como níveis distintos)

Em jogos com uma forte progreção linear, níveis são normalmente areas em grandes mundos. A progressão nestas áreas deve ser descrita pelo gráfico de progresso da seção anterior. Já para jogos com niveis baseados em locações, você deve criar um mapa para mostrar o layout e conectividade do nível. Indicando encontros, locais com itens e objetivos.

Esta seção em resumo deve preocupar-se em deixar o jogo equilibrado e desafiante. Atualmente é bastante comum encontrarmos editores específicos para esta finalidade, permitindo que um profissional focado nesta área, com pouco conhecimento de programação, possa ter total autonomia para definir cada nível do game. Na verdade podemos pensar ainda um pouco mais longe, existem jogos que deixam o jogador assumir este papel.

Little Big Planet.

1 Title Page

O título está na página um. Ele é graficamente simples, como um frontispício de um livro. Ainda assim contendo informação vital. A página de título deve conter:

1. Uma imagem(screenshot ou box art);
2. O título do jogo, e opcionalmente, a versão;
3. O nome do desenvolvedor
4. A data e numero da versão do documento

Grandes companhias ou aqueles que trabalham com publishers requerem questões legais como por exemplo, informações sobre copyrigth, instruições de confidencialidade e contato.

5.2 Executive Summary

This one-page section describes the entire game in three sentences: [1]

1. a sentence about the basic setting;
2. a sentence that describes what makes the game interesting;
3. a sentence that will convince a publisher to approve or fund the game.

A game might be interesting and engaging because it contains a new technology, has an interesting story, contains a new mechanic, or can be marketed at a low price. There are many reasons a publisher might want to approve a game. These tend to focus on either novelty, e.g., “never before have RPG and puzzle games been combined” or “the first real-time Scrabble game,” or (ironically) the complete absence of novelty, e.g., “this is a James Bond game, and all James Bond games sell 1M units.” Often the text for the executive summary can be entirely drawn from other sections of the design document.

2 Sumário Executivo

Esta primeira página descreve o jogo interio em três frases.

1. Uma frase sobre a configuração básica;
2. Uma frase que descreve oque torna o jogo interessante;
3. Uma frase que convencerá um punlisher a aprovar ou financiar o jogo.

Um jogo pode ser interessante e atraente por conter um nova tecnologia, por uma história interessante, conter uma nova mecânica, ou até por ser oferecido a um baixo preço. Há várias razões para uma publisher querer aprovar um game, entre elas alguma novidade, por exemplo: Um RPG combinado com Puzzle nunca antes visto, ou exatamente o contrário, mais um jogo de futebol, por que normalmente eles vendem muito.

5.3 Overview

The overview consists of two or three pages that compactly describe the major qualities of the game. It follows the overview worksheet format from the previous chapter. It must pitch the core concept, review related games, and present the reader with a mental image of the game as a whole. It is essentially a distilled version of the entire design document.

The overview is the first part of the design document that is written. Once accepted by an internal team, the proposal/overview then evolves into a proposal from the team to the company. The ideas from the overview are finally expanded into a full design document.

3 Visão Geral

Esta sessão é composta por duas ou três páginas que resumidamente descrevem a maior qualidade do game. Ela precisa fixar o conceito principal, revisar jogos relacionados, e apresentar ao leitor uma imagem mental do game como um todo. Esta sessão seria como uma versão da essencia do documento todo. A Visão Geral é a primeira parte que é escrita no documento de projeto de jogo. Uma vez aceita pela equipe, as idéias finalmente se disseminam para todo o documento.

5.4 Related Games

This section reviews related games and serves as background research for both marketing and design purposes. Experience with previous work is important. You should extend the successes of previous games while avoiding their pitfalls. Rarely do truly original ideas emerge; usually someone has already come up with your great idea. So research previous work and then leverage it.

The related games section should devote about one page to each related game. The specific games chosen should be a superset of those described in the overview section.

Discuss existing games that resemble yours in any way (e.g., setting, mechanics, business model). Why do you feel that you can repeat the success of a previous game or avoid its failure?

Some previous work may be your competition. You need to address this head-on. Judge your own potential and account for competition in your design. Why will your game succeed if it is competing with an already established game?

Figure 5.1: Library of related work games at Iron Lore Entertainment.

A wise designer draws heavily from previous games. Most games companies have large libraries of games available for close study and reverse engineering during production (see Figure 5.1). Build such a library and plan on spending many hours perusing everything from menus to data files in other games.

—

[1] An academic would call this the abstract for the document.

4 Jogos Relacionados

Este seção relata os jogos relacionados ao seu, isto serve como pesquisa para embasamento de marketing e projeto. Experiência com trabalhos anteriores é importante. Você pode extender o sucesso já lançado arrumando o que não considerou adequado. Dificilmente idéias totalmente originais surgem, você, mesmo que inconscientemente, apropria-se de conhecimentos e experiências prévias com outros jogos. Por este motivo, pesquisa é muito importante.
Esta seção deve dedicar uma página para cada jogo relacionado a seu projeto. Os escolhidos devem complementar o que foi descrito na seção “Visão Geral”.
Esta é uma parte do documento onde você deve desmonstrar bastante maturidade e profissionalismo, porque ao relacionar o seu projeto a outro, e já vimos que isto é importante, você deve destacar claramente onde estes games erraram e onde eles acertaram. Em seguida deve provar onde você, como jogador, e agora como projetista, vai contornar os pontos falhos e criar um produto ainda melhor em relação aos que inspiram seu trabalho.

Imagem

Uma boa dica para as pesquisas seria jogar muito videogame, isto até pode parecer fácil, mas para muita gente falta tempo. Ter uma boa coleção de jogos em casa facilita bastante. Caso você não se “identifique” com a ilustração acima, há bons sites na web que podem ser utilizados como biblioteca. Ao final do artigo estarei separando alguns links que utilizo no trabalho.

5.5 Player Composites

This section creates a marketing model of the players who will purchase and play your game. These aren’t the in-game characters but the real people who will playing the game. The characteristics of this group will help you create intuition for design decisions, as well as serve as a job description for the playtesters you will recruit.

Creating a player composite takes the player from being an ambiguous presence in the design (or, even more dangerous, a carbon copy of you!) and makes him or her into a concrete person you want to make happy. For example, you may create the following profile:

“John Brooke, 27, accountant. Single. Graduate of Loyola College. Plays games alone about once a week, and with male friends on a next-generation console plugged into an HDTV in his living room on weekend afternoons. Focuses on competitive, action games like Gears of War and Madden. Watches football one day a week. Favorite TV shows are Lost and Sopranos reruns. Drives an Audi A4. Drinks imported beer.”

The profile answers the following questions about this target player.

1. When and where does this person play games?
2. Who buys the games this person uses?
3. What platforms does this player use?
4. How much time does this person spend in each session, and how frequent are gaming sessions?
5. Who does he or she play with?
6. What does the player like about games?
7. What (non-game) brand images appeal to this player?
8. How much disposable income does this player have?
9. What licensed content would appeal to this player?
10. What competes with gaming time for this player?

Most games have both a primary market and a secondary market; for example, an Asteroids remake might target both preteens and nostalgic 40-somethings. Make a composite for each demographic you hope to target. When available, the composites can be based on actual market research. But even without such research, it is better to invent the composite than to have none at all. With a composite, the entire development team will explicitly agree, which is far better than having everyone independently make different personal assumptions.

5 Perfil do Jogador

Esta seção cria um modelo de marketing do jogador que irá comprar e jogar nosso game. As característica deste grupo de pessoas ajudará você nas decisões de projeto, além de definir o perfil ideal para um grupo de playtesters.
Criando um perfil de jogador, você não corre o risco de “confundir-se” com o público-alvo, fato bastante comum atualmente na indústria, ou esquecer para quem esta desenvolvendo. Para isto lista abaixo um exemplo:
João Paulo, 29 anos. Casado, Ensino Superior. Joga games de estratégia sozinho uma vez na semana. Com seus amigos, prefere jogos casuais em modo cooperativo.
A listagem abaixo aborda algumas perguntas que ajudarão a definir o perfíl do público-alvo.

1. Quando e onde esta pessoa joga?
2. Quem compra os jogos desta pessoa?
3. Que plataforma esta pessoa utiliza?
4. Quanto tempo esta pessoa dedica em cada sessão de jogo, e qual seria a frequencia destas sessões?
5. Quem ele ou ela joga?
6. Oque faz o jogador gostar de games?
7. Qual é a renda disponível deste jogador?
8. O que compete com o tempo de jogo deste jogador?

Ainda podemos ter um grupo de jogadores bem heterogeneo, mas mesmo assim será um grupo que você deve ter bem claro seu perfil. Várias empresas hoje cometem o erro de esquecer o que seu público está pedindo. Uma prova viva disto, seria a SEGA com seus infindáveis jogos 3D para SONIC. O público desde o inicio da geração DreamCast clama por um game em 2D dinâmico e rápido, bem nos moldes dos três primeiros. Mas felizmente ela parece ter ouvido as preces, não cometam este erro.

5.6 World

For all but abstract games, like Yinsh and go, the setting and narrative are significant aspects of production. Most players never create a mental model more sophisticated than the fiction they are told and depend on a consistent virtual world for enjoyment.

In the world section, give the background. This may be the history of an entire civilization or just the conditions surrounding the main character. Record information about areas and events to keep the decisions made by various team members consistent. The Halo series is based on hundreds of pages of documents detailing several alien races, the main character, the rough geography of the universe, and the detailed geography of the ring world in which the game takes place. The amount of detail needed for your game depends on the scope of the setting and on the player’s exploration ability. The only limiting factor is the time you can invest creating and maintaining this information.

Some of the world information will be revealed to players in the game manual or throughout the course of the game. Other aspects will never be revealed, but their consistency will be felt. Sequels and expansion packs are a great opportunity for revealing aspects that were kept secret in the initial game. Chapter 11 describes methods for building out your world.

6 Mundo

Com exceção de jogos mais abstratos, como dama e xadrez, todo game precisa de um contexto, de uma ambientação. Caso contrário o jogador não se sentirá engajado e motivado a jogá-lo.
Na seção Mundo, você dará uma fundamentação a seu jogo. Isto pode ser uma história complexa, com detalhes de uma civilização inteira, ou apenas condições em torno do personagem principal, como space invaders. A série Halo, por outro lado, é baseada em centenas de paginas de documentos detalhando várias raças de alienígenas, o personagem principal e toda a geografia do universo. Não há muito claro uma definição do tempo que você deva dedicar para esta seção, o ideal seria usar o bom sendo, analisando o custo benefício. Muitos detalhes do mundo acabam servindo apenas para a base criativa da equipe, não podendo ser observado explicitamente no game.

5.7 Characters

Describe each character’s background and motivation. This is especially important for the main character in a narrative-driven game, whose motivations will become the player’s own. Include concept and in-game art for each character. List aspects including their:

1. motivation
2. physical description
3. likes and dislikes
4. family
5. friends and enemies
6. vital statistics
7. education
8. occupation
9. transportation
10. tools/weapons
11. clothing

For nonhuman characters, make sure their origins and race are well developed.

7 Personagens

Descreve a base e moticação de cada personagem. Isto é muito importante para o protagonista em um jogo que narrativa dirigida, onde a motivação virá do proprio jogador. Observe uma sugestão para lista de características básicas:

1. motivação
2. descrição física
3. preferências
4. famíia
5. amigos e inimigos
6. estatisticas vitais
7. educação
8. ocupação
9. locomoção
10. armas/ferramentas
11. roupa

1 Title Page

O título está na página um. Ele é graficamente simples, como um frontispício de um livro. Ainda assim contendo informação vital. A página de título deve conter:

1. Uma imagem(screenshot ou box art);

2. O título do jogo, e opcionalmente, a versão;

3. O nome do desenvolvedor

4. A data e numero da versão do documento

Grandes companhias ou aqueles que trabalham com publishers requerem questões legais como por exemplo, informações sobre copyrigth, instruições de confidencialidade e contato.

5.2 Executive Summary

This one-page section describes the entire game in three sentences: [1]

1. a sentence about the basic setting;

2. a sentence that describes what makes the game interesting;

3. a sentence that will convince a publisher to approve or fund the game.

A game might be interesting and engaging because it contains a new technology, has an interesting story, contains a new mechanic, or can be marketed at a low price. There are many reasons a publisher might want to approve a game. These tend to focus on either novelty, e.g., “never before have RPG and puzzle games been combined” or “the first real-time Scrabble game,” or (ironically) the complete absence of novelty, e.g., “this is a James Bond game, and all James Bond games sell 1M units.” Often the text for the executive summary can be entirely drawn from other sections of the design document.

2 Sumário Executivo

Esta primeira página descreve o jogo interio em três frases.

1. Uma frase sobre a configuração básica;

2. Uma frase que descreve oque torna o jogo interessante;

3. Uma frase que convencerá um punlisher a aprovar ou financiar o jogo.

Um jogo pode ser interessante e atraente por conter um nova tecnologia, por uma história interessante, conter uma nova mecânica, ou até por ser oferecido a um baixo preço. Há várias razões para uma publisher querer aprovar um game, entre elas alguma novidade, por exemplo: Um RPG combinado com Puzzle nunca antes visto, ou exatamente o contrário, mais um jogo de futebol, por que normalmente eles vendem muito.

5.3 Overview

The overview consists of two or three pages that compactly describe the major qualities of the game. It follows the overview worksheet format from the previous chapter. It must pitch the core concept, review related games, and present the reader with a mental image of the game as a whole. It is essentially a distilled version of the entire design document.

The overview is the first part of the design document that is written. Once accepted by an internal team, the proposal/overview then evolves into a proposal from the team to the company. The ideas from the overview are finally expanded into a full design document.

3 Visão Geral

Esta sessão é composta por duas ou três páginas que resumidamente descrevem a maior qualidade do game. Ela precisa fixar o conceito principal, revisar jogos relacionados, e apresentar ao leitor uma imagem mental do game como um todo. Esta sessão seria como uma versão da essencia do documento todo. A Visão Geral é a primeira parte que é escrita no documento de projeto de jogo. Uma vez aceita pela equipe, as idéias finalmente se disseminam para todo o documento.

5.4 Related Games

This section reviews related games and serves as background research for both marketing and design purposes. Experience with previous work is important. You should extend the successes of previous games while avoiding their pitfalls. Rarely do truly original ideas emerge; usually someone has already come up with your great idea. So research previous work and then leverage it.

The related games section should devote about one page to each related game. The specific games chosen should be a superset of those described in the overview section.

Discuss existing games that resemble yours in any way (e.g., setting, mechanics, business model). Why do you feel that you can repeat the success of a previous game or avoid its failure?

Some previous work may be your competition. You need to address this head-on. Judge your own potential and account for competition in your design. Why will your game succeed if it is competing with an already established game?

Figure 5.1: Library of related work games at Iron Lore Entertainment.

A wise designer draws heavily from previous games. Most games companies have large libraries of games available for close study and reverse engineering during production (see Figure 5.1). Build such a library and plan on spending many hours perusing everything from menus to data files in other games.

—

[1] An academic would call this the abstract for the document.

4 Jogos Relacionados

Este seção relata os jogos relacionados ao seu, isto serve como pesquisa para embasamento de marketing e projeto. Experiência com trabalhos anteriores é importante. Você pode extender o sucesso já lançado arrumando o que não considerou adequado. Dificilmente idéias totalmente originais surgem, você, mesmo que inconscientemente, apropria-se de conhecimentos e experiências prévias com outros jogos. Por este motivo, pesquisa é muito importante.

Esta seção deve dedicar uma página para cada jogo relacionado a seu projeto. Os escolhidos devem complementar o que foi descrito na seção “Visão Geral”.

Esta é uma parte do documento onde você deve desmonstrar bastante maturidade e profissionalismo, porque ao relacionar o seu projeto a outro, e já vimos que isto é importante, você deve destacar claramente onde estes games erraram e onde eles acertaram. Em seguida deve provar onde você, como jogador, e agora como projetista, vai contornar os pontos falhos e criar um produto ainda melhor em relação aos que inspiram seu trabalho.

Imagem

Uma boa dica para as pesquisas seria jogar muito videogame, isto até pode parecer fácil, mas para muita gente falta tempo. Ter uma boa coleção de jogos em casa facilita bastante. Caso você não se “identifique” com a ilustração acima, há bons sites na web que podem ser utilizados como biblioteca. Ao final do artigo estarei separando alguns links que utilizo no trabalho.

5.5 Player Composites

This section creates a marketing model of the players who will purchase and play your game. These aren’t the in-game characters but the real people who will playing the game. The characteristics of this group will help you create intuition for design decisions, as well as serve as a job description for the playtesters you will recruit.

Creating a player composite takes the player from being an ambiguous presence in the design (or, even more dangerous, a carbon copy of you!) and makes him or her into a concrete person you want to make happy. For example, you may create the following profile:

“John Brooke, 27, accountant. Single. Graduate of Loyola College. Plays games alone about once a week, and with male friends on a next-generation console plugged into an HDTV in his living room on weekend afternoons. Focuses on competitive, action games like Gears of War and Madden. Watches football one day a week. Favorite TV shows are Lost and Sopranos reruns. Drives an Audi A4. Drinks imported beer.”

The profile answers the following questions about this target player.

1. When and where does this person play games?

2. Who buys the games this person uses?

3. What platforms does this player use?

4. How much time does this person spend in each session, and how frequent are gaming sessions?

5. Who does he or she play with?

6. What does the player like about games?

7. What (non-game) brand images appeal to this player?

8. How much disposable income does this player have?

9. What licensed content would appeal to this player?

10. What competes with gaming time for this player?

Most games have both a primary market and a secondary market; for example, an Asteroids remake might target both preteens and nostalgic 40-somethings. Make a composite for each demographic you hope to target. When available, the composites can be based on actual market research. But even without such research, it is better to invent the composite than to have none at all. With a composite, the entire development team will explicitly agree, which is far better than having everyone independently make different personal assumptions.

5 Perfil do Jogador

Esta seção cria um modelo de marketing do jogador que irá comprar e jogar nosso game. As característica deste grupo de pessoas ajudará você nas decisões de projeto, além de definir o perfil ideal para um grupo de playtesters.

Criando um perfil de jogador, você não corre o risco de “confundir-se” com o público-alvo, fato bastante comum atualmente na indústria, ou esquecer para quem esta desenvolvendo. Para isto lista abaixo um exemplo:

João Paulo, 29 anos. Casado, Ensino Superior. Joga games de estratégia sozinho uma vez na semana. Com seus amigos, prefere jogos casuais em modo cooperativo.

A listagem abaixo aborda algumas perguntas que ajudarão a definir o perfíl do público-alvo.

1. Quando e onde esta pessoa joga?

2. Quem compra os jogos desta pessoa?

3. Que plataforma esta pessoa utiliza?

4. Quanto tempo esta pessoa dedica em cada sessão de jogo, e qual seria a frequencia destas sessões?

5. Quem ele ou ela joga?

6. Oque faz o jogador gostar de games?

7. Qual é a renda disponível deste jogador?

8. O que compete com o tempo de jogo deste jogador?

Ainda podemos ter um grupo de jogadores bem heterogeneo, mas mesmo assim será um grupo que você deve ter bem claro seu perfil. Várias empresas hoje cometem o erro de esquecer o que seu público está pedindo. Uma prova viva disto, seria a SEGA com seus infindáveis jogos 3D para SONIC. O público desde o inicio da geração DreamCast clama por um game em 2D dinâmico e rápido, bem nos moldes dos três primeiros. Mas felizmente ela parece ter ouvido as preces, não cometam este erro.

5.6 World

For all but abstract games, like Yinsh and go, the setting and narrative are significant aspects of production. Most players never create a mental model more sophisticated than the fiction they are told and depend on a consistent virtual world for enjoyment.

In the world section, give the background. This may be the history of an entire civilization or just the conditions surrounding the main character. Record information about areas and events to keep the decisions made by various team members consistent. The Halo series is based on hundreds of pages of documents detailing several alien races, the main character, the rough geography of the universe, and the detailed geography of the ring world in which the game takes place. The amount of detail needed for your game depends on the scope of the setting and on the player’s exploration ability. The only limiting factor is the time you can invest creating and maintaining this information.

Some of the world information will be revealed to players in the game manual or throughout the course of the game. Other aspects will never be revealed, but their consistency will be felt. Sequels and expansion packs are a great opportunity for revealing aspects that were kept secret in the initial game. Chapter 11 describes methods for building out your world.

6 Mundo

Com exceção de jogos mais abstratos, como dama e xadrez, todo game precisa de um contexto, de uma ambientação. Caso contrário o jogador não se sentirá engajado e motivado a jogá-lo.

Na seção Mundo, você dará uma fundamentação a seu jogo. Isto pode ser uma história complexa, com detalhes de uma civilização inteira, ou apenas condições em torno do personagem principal, como space invaders. A série Halo, por outro lado, é baseada em centenas de paginas de documentos detalhando várias raças de alienígenas, o personagem principal e toda a geografia do universo. Não há muito claro uma definição do tempo que você deva dedicar para esta seção, o ideal seria usar o bom sendo, analisando o custo benefício. Muitos detalhes do mundo acabam servindo apenas para a base criativa da equipe, não podendo ser observado explicitamente no game.

5.7 Characters

Describe each character’s background and motivation. This is especially important for the main character in a narrative-driven game, whose motivations will become the player’s own. Include concept and in-game art for each character. List aspects including their:

1. motivation

2. physical description

3. likes and dislikes

4. family

5. friends and enemies

6. vital statistics

7. education

8. occupation

9. transportation

10. tools/weapons

11. clothing

For nonhuman characters, make sure their origins and race are well developed.

7 Personagens

Descreve a base e moticação de cada personagem. Isto é muito importante para o protagonista em um jogo que narrativa dirigida, onde a motivação virá do proprio jogador. Observe uma sugestão para lista de características básicas:

1. motivação

2. descrição física

3. preferências

4. famíia

5. amigos e inimigos

6. estatisticas vitais

7. educação

8. ocupação

9. locomoção

10. armas/ferramentas

11. roupas

1. s

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.