ANÁLISE DE MODELOS DE DOCUMENTOS DE GAME DESIGN E PROPOSTA DE …€¦ · · 2012-10-04Um...

Universidade Presbiteriana Mackenzie

1

ANÁLISE DE MODELOS DE DOCUMENTOS DE GAME DESIGN E PROPOSTA DE PADRÃO UNIFICADO

Steven David Feuerstein Mariasch (IC) e Luciano Silva (Orientador)

Apoio: PIVIC Mackenzie

Resumo

A documentação de Game Design é fruto da descentralização de tarefas do processo de

desenvolvimento e publicação de jogos digitais, como também do número elevado de pessoas em algumas equipes de desenvolvimento. Alguns autores apontam que não há um padrão industrial para o formato da documentação, diferentemente do que acontece em outras indústrias, como a de cinema. Com o objetivo de apresentar uma proposta de padrão de Documento de Game Design, este

artigo pretende ajudar iniciantes na área e a indústria de jogos digitais. Para identificar interesses comuns nos documentos, alguns formatos existentes foram analisados. Em seguida, um novo formato foi criado, fazendo uso da linguagem de programação literada CWEB para se obter um novo documento. Finalmente, é proposto que o modelo seja apresentado em eventos das áreas abordadas para que seja dado início às discussões sobre seu uso como padrão.

Palavras-chave: Padrões de Documentação de Jogos, Game Design Document, Game Design,

Engenharia de Software

Abstract

Game Design documentation exists due to the decentralization of the game development process and

game publishing tasks, and also due to the high number of members in some development teams. Some authors indicate that there are no standard formats for documenting designs, differently from what happens in other industries, like the film industry. Aiming to propose a standard format for Game

Design Documents, this article intends to help people that are starting to learn about Game Design

and its industry as well. In order to identify common interests between different documents of this type, some of the existing formats were analyzed. After that, a new format was created, making use of the CWEB literate programming language in order to obtain a new document. Finally, it is proposed that this new model be presented in some events of the related areas so the conversations for using it as a standard could be started.

Keywords: Game Documentation Patterns, Game Design Document, Game Design, Software

Engineering

VII Jornada de Iniciação Científica - 2011

2

1. Introdução

Para pessoas que desejam se tornar game designers ou mesmo pessoas que desejam

desenvolver um jogo, é normal que se questionem como se estrutura um documento de

game design, o que ele deve conter e o porquê disso, assim poderão num estágio mais

avançado de desenvolvimento, por exemplo, satisfazer às exigências de uma publicadora

que tenha estabelecido a necessidade de se apresentar uma documentação (ROUSE, 2005,

p. 307). O mais correto seria ir em busca do padrão da indústria. Fullerton, Swain e Hoffman

(2008, p. 395, tradução nossa) são bem diretos sobre este suposto padrão: “A indústria de

jogos digitais não tem um formato padrão para documentação de designs. Seria legal se

existisse uma fórmula definida ou estilo para se seguir, [...] mas isso simplesmente não

existe”1. Um exemplo de pessoa que foi em busca de um formato padrão quando era

aspirante à game designer, é Rouse (2005, p. 356). Ele sabia que os roteiros de Hollywood

tinham um formato preciso, e acreditava que deveria ter algo semelhante para documentos

de design. Entretanto, descobriu que não havia um formato e que cada um que escreve um

documento de design cria o próprio formato.

A “engenharia de jogos digitais” é uma herança ainda não padronizada, na área de

documentação, da Engenharia de Software. É interessante mencionar que o escopo deste

projeto não foca padrões em Game Design, já descritos na obra de Björk e Holopainen

(2005). A obra demonstra uma série de possibilidades de design em diversos tipos de jogos

digitais. O grupo conhecido como Gang of Four (GAMMA; et al., 2000), ou apenas GoF,

descreveu uma série de padrões de projeto orientados a objeto. Eles também descreveram

quais são os elementos essenciais de um padrão (Ibid., 2000, p. 19): o nome do padrão, o

problema (em que situação aplicar o padrão), a solução e as consequências. Muito

embora o GoF estivesse descrevendo padrões de projeto, sua descrição de padrão é

completamente aplicável à padrões de documentação.

Este artigo apresenta uma proposta de padrão de documentação para Game Design,

caracterizando os elementos essenciais que um Documento de Game Design deve possuir,

utilizando a linguagem literada CWEB para aumentar as funcionalidades deste tipo de

documento com a adição de trechos de código ao mesmo.

Este artigo está organizado da seguinte forma:

● a Seção 2 apresenta o referencial teórico;

● a Seção 3 apresenta o método;

1Texto original: “The game industry has no standard format for documenting designs. It would be nice

if there were a set formula or style to follow, […], but this simply does not exist.” (FULLERTON; SWAIN; HOFFMAN, 2008, p. 395)


3

● a Seção 4 apresenta os resultados e discussão;

● finalmente, a Seção 5 apresenta as conclusões.

2. Referencial Teórico

2.1 Processos de Projeto de Jogos

2.1.1 Introdução

A indústria de jogos digitais contemporânea apresenta um modelo de divisão de tarefas por

especialização. Há dois tipos principais de tarefas nessa indústria: desenvolver e publicar os

jogos. O desenvolvimento dos jogos é responsabilidade das empresas chamadas

“desenvolvedoras”, e a publicação é responsabilidade das empresas chamadas

“publicadoras” ou, em inglês, “publishers”. Algumas empresas publicam seus próprios jogos,

e são chamadas por muitos de “desenvolvedoras independentes”.

Quando uma desenvolvedora necessita recursos financeiros para desenvolver, ou quando

deseja que uma publicadora veicule um de seus jogos, ela deve primeiro apresentar para

uma publicadora um documento chamado e descrito por Pedersen (2009, p. 73, tradução

nossa) como One Pager, que “explica e vende o conceito de seu game para publicadoras e

desenvolvedoras e coloca suas ideias e visão em um documento conciso. Um One Pager

pode ter uma ou duas páginas […]”2. A partir do momento em que a publicadora aprova o

projeto, ou mesmo quando ela fornece um projeto próprio para uma dada desenvolvedora,

ela financia todos os custos do projeto.

Dado o grau de complexidade dos grandes projetos de jogos atualmente, são necessárias

diversas pessoas trabalhando nestes projetos para cumprir os prazos estabelecidos. Por

exemplo, segundo uma reportagem de Reynolds (2009), a equipe que estava

desenvolvendo o jogo Assassin’s Creed II (Ubisoft Montreal, 2009) contava com

aproximadamente 450 pessoas. Estas pessoas são especializadas em diversos segmentos

necessários para se desenvolver jogos, como arte (desde desenhos conceituais até

modelagem e texturização dos personagens e cenários), programação (como da Inteligência

Artificial e da Física) e design (Game Design, Character Design e Level Design).

Antigamente, os jogos digitais não eram apenas desenvolvidos na forma de software, eram

também desenvolvidos na forma de hardware, como relata Wozniak (______; SMITH, 2007,

2Texto original: “The one pager explains and sells your game’s concept to publishers and developers

and puts your ideas and vision into a concise document. A one pager can be one or two pages […]” (PEDERSEN, 2009, p. 79).


4

p. 139-147, tradução nossa) sobre sua experiência ao desenvolver o jogo Breakout (Atari,

1978):

Eu comecei na verdade desenhando os esquemas de uma forma que uma

TV mostraria luz na tela – linha por linha. Eu não dormi por quatro dias e

noites durante este projeto. Durante o dia, eu desenhei o design em papel,

desenhando-o claramente o suficiente para que um técnico pudesse pegar

o design e ligar os chips.3

Wozniak foi um dos pioneiros na área de design de jogos, apesar de que atualmente esta

área possui mais responsabilidades e dificilmente acarrete no desenho de hardware.

Segundo Andrade (2008, p. 36),

Os designers são os profissionais que “pensam” como o jogo deve ser. [...]

Os designers têm que pensar, descrever e documentar cada detalhe do

jogo. O game designer deve pensar no funcionamento geral do jogo, nas

regras, nos desafios e, principalmente, em como deve manter o jogador

interessado.

Apesar de Wozniak também ter usado, sem muito valor, uma técnica de documentação de

design, atualmente ela é muito comum e importante nas empresas de desenvolvimento de

jogos. Alguns documentos são usados, sendo o mais importante o de Game Design que

[...] é o coração e a alma de todos os documentos que giram em torno de

um game em desenvolvimento. É o verdadeiro documento de planta baixa,

e seu objetivo é ilustrar como se deve jogá-lo e apresentar uma descrição

abrangente de todos os aspectos, para que a equipe de desenvolvimento

possa, de fato, criar o game (SCHUYTEMA, 2008, p. 100).

Por meio deste documento, do game designer - responsável pelo documento -, e de

reuniões constantes que as equipes se guiam e resolvem dúvidas durante o projeto. As

próximas seções descrevem algumas das etapas do processo de desenvolvimento de jogos.

2.1.2 Game Design

Em sua essência, o desenvolvimento de jogos depende do Game Design. Não há o que

desenvolver se não há uma ideia pré-elaborada. As atividades de Game Design se situam

na criação de um contexto que dá rumo à todas as outras atividades relacionadas ao 3Texto original: “I began by actually drawing the schematics so a TV would display light on the screen

– line by line. I didn’t sleep for four days and nights during this project. During the day, I drew the

design on paper, drawing it out clearly enough so that a technician could take the design and wire

chips together” (WOZNIAK; SMITH, 2007, p. 144-145)


5

desenvolvimento de jogos, como também garantem que a equipe de desenvolvimento

compreendeu este contexto e a execução do trabalho corresponde ao esperado. O cargo do

principal responsável da equipe por elaborar o design corresponde ao Game Designer. Este

profissional pode ter como formação acadêmica diversas origens, devido à dimensão

extensa de possibilidades de design, entre outros.

Uma das etapas que nem sempre está presente em um jogo, devido ao estilo a que este

pertence, é a de Level Design. Esta etapa é descrita na seção a seguir.

2.1.3 Level Design

Chamado por alguns autores como “Design do ambiente” (SCHUYTEMA, 2008, p. 277),

geralmente, apenas jogos que são organizados em fases ou em um mundo específico

possuem atividades relacionadas com Level Design. Tanto Schuytema (Ibid., p. 278) quanto

Fullerton, Swain e Hoffman (2008, p. 361-362) concordam que se uma equipe e/ou projeto

forem pequenos, cabe ao game designer a execução desta tarefa, e caso a equipe e/ou o

projeto forem grandes, esta tarefa pode ser atribuída à um profissional do tipo level

designer. Cabe ao responsável desta tarefa responsabilidades como as seguintes:

implementar os designs das fases, elaborar conceitos para fases, testar as fases e trabalhar

junto ao designer para melhorar o gameplay em geral (Ibid., p. 362). Estas

responsabilidades estão diretamente ligadas à documentação, seja consultando-a ou

adicionando rascunhos dos mapas das fases ao documento.

A tarefa de implementação é descrita na próxima seção.

2.1.4 Implementação

A implementação corresponde a tornar a visão do jogo digital uma realidade em termos de

produto digital. Em equipes numerosas, os profissionais envolvidos são: programadores,

artistas visuais, engenheiros de garantia de qualidade (QA engineers), profissionais de mídia

especializada, e os próprios level designers (FULLERTON; SWAIN; HOFFMAN, 2008, p.

356-362, tradução nossa).

A próxima seção descreve como são realizados os testes de um jogo, que é diferente dos

testes realizados na programação.


6

2.1.5 Testes

A atividade de testes de um jogo, conhecida em inglês como atividade de playtesting,

acontece durante todo o processo de design e fornece uma introspecção sobre o jogo

alcançar ou não as metas de “experiência” estabelecidas para o jogador. Basicamente, esta

atividade corresponde ao designer observar “à distância” uma ou várias pessoas

(playtesters) jogando, sem interferir ou ajudar nesta experiência. Idealmente, os playtesters

não devem conhecer o conteúdo do GDD, sendo que apenas a análise de seu ato de jogar

deve indicar ao designer aspectos a serem alterados ou mantidos no design (Ibid., p. 248).

Na próxima seção, há uma avaliação de diferentes propostas de modelos de Documentos

de Game Design, como também a análise de um metamodelo.

2.2 Documentos de Jogos

2.2.1 O Modelo de Rouse

Rouse (2005) propõe uma documentação de Game Design dividida nas seguintes seções:

● sumário,

● introdução/visão geral,

● mecânica do jogo,

● Inteligência Artificial (IA),

● elementos do jogo,

● visão geral da história,

● progressão do jogo e

● menus do sistema.

É importante ressaltar que nem todos os jogos necessitarão de todas estas seções e,

portanto, não há como definir uma ordem específica para o modelo.

2.2.2 O Modelo de Schuytema

Schuytema (2008, p. 100) afirma que a complexidade do sumário do Documento de Game

Design necessária para cada game designer depende da escala e do escopo do projeto em

desenvolvimento e que não há modelo que sirva para todas as opções. O modelo do autor é

composto pelo seguinte sumário (Ibid. p. 101):

I. Visão geral essencial


7

a. Resumo

b. Aspectos fundamentais

c. Golden nuggets

II. Contexto do jogo

a. História do jogo

b. Eventos anteriores

c. Principais jogadores

III. Objetos essenciais do jogo

a. Personagens

b. Armas

c. Estruturas

d. Objetos

IV. Conflitos e soluções

V. Inteligência Artificial

VI. Fluxo do jogo

VII. Controles

VIII. Variações de jogo

IX. Definições

X. Referências

2.2.3 O Modelo de Fullerton, Swain e Hoffman

Em nenhum momento os autores mencionam o uso de um sumário em seu modelo. Ao

invés disso, mencionam que documentos eficientes comunicam a informação principal de 50

a 100 páginas. A visão de Rouse (2005), já mencionada anteriormente e que incluí um

sumário em seu modelo, parece ser mais eficiente, já que leva o interessado em alguma

parte específica do documento direto ao seu ponto de interesse.

Em geral, os conteúdos de um GDD podem ser divididos nas seguintes áreas:

● Visão Geral e Vision Statement;

● Público, Plataforma e Marketing;


8

● Gameplay;

● Personagens (se tiver);

● História (se tiver);

● Mundo (se tiver);

● Lista de Mídias

O GDD também pode incluir detalhes técnicos, caso não for adotado o uso do Documento

de Especificação Técnica. Os autores ainda quiseram deixar claro que o modelo deles não é

um padrão que funcionaria para qualquer jogo, mas fornece ideias sobre os tipos de seções

a incluir.

2.2.4 O Metamodelo de Björk e Holopainen

Björk e Holopainen (2005, cap. 2) definem um framework para descrição de jogos baseado

em atividades que o jogador realiza nos jogos. Este framework não tem como intenção

descrever um GDD, mas um jogo. Por esse motivo e por não se basear em seções que o

Game Designer tem que documentar, este framework, ou “metamodelo” de GDD, é bem

diferente dos modelos de GDD apresentados pelos outros autores.

O metamodelo fornece conceitos para se discutir que os autores chamam de Primeira

Ordem do Game Design, os componentes de um jogo que fazem do gameplay ser possível.

Esses componentes básicos de jogos podem então ser usados para descrever o que os

autores chamam de Conceitos de Segunda Ordem do Game Design, que seriam os padrões

de Game Design. É importante ressaltar que o metamodelo não tem como intenção definir o

que é um jogo digital ou o ato de jogar, pelo contrário, ele é indiferente à definição do que é

ou deveria ser um jogo digital.

Os componentes do jogo são divididos em quatro categorias no framework: Holística,

Fronteira, Temporal e Estrutural. Essas categorias seriam uma reflexão de quatro possíveis

maneiras de se ver a atividade de jogar um jogo. Os componentes holísticos descrevem

como essa atividade é separada de outras atividades; os componentes fronteiriços limitam

as possíveis ações do jogador no/durante o jogo; os componentes temporais descrevem o

fluxo do jogo; e os componentes estruturais definem os elementos físicos e lógicos

necessários para conter e manipular o estado do jogo.


9

3. Método

3.1 Proposta de Documentação Unificada para Game Design, Implementação e Testes

3.1.1 Introdução

Apesar dos três modelos analisados e do metamodelo serem diferentes entre si, é possível

identificar pontos em comum, apenas dispostos de maneira diferente. Também foi

identificado que nenhum dos modelos visa uma aproximação do processo de

desenvolvimento de código para o jogo, algo que distancia o software de sua

documentação, o que pode prejudicar o interesse de programadores na leitura de

documentos - justamente algo que é contrário a ideia de comunicar a visão geral do jogo

para a equipe já mencionado anteriormente (FULLERTON; SWAIN; HOFFMAN, 2009, p.

394).

A proposta de padrão a ser apresentada nesta seção leva em consideração as ideias dos

autores, os pontos em comum dos modelos analisados e o objetivo de criar um modelo

independente de gênero. Considerando essencial a transmissão para a equipe da ideia

geral do jogo através do GDD, é interessante adicionar ao padrão de GDD um processo de

transmissão contínua desta ideia, adicionando elementos de código diretamente no texto

através de programação literada em CWEB com a intenção de aumentar as funções do

próprio documento e as consultas ao mesmo realizadas pela equipe.

3.1.2 Modelo de Desenvolvimento em Espiral

Considerando que o GDD está sempre em crescimento (por muitas vezes chamado de

documento vivo) durante o desenvolvimento do jogo, dado que o desenvolvimento de jogos

digitais é um meio inerentemente colaborativo em que a visão geral do jogo deve ser

transmitida com clareza a toda equipe de desenvolvimento (FULLERTON; SWAIN;

HOFFMAN, 2008, p. 394), é sensato o uso de um processo de desenvolvimento em espiral,

que representa um processo sempre em crescimento. Entretanto, é importante ressaltar que

a criação de um GDD pertence, principalmente, à etapa de pré-produção de um jogo digital,

e que a segunda etapa, a de produção, depende da aprovação da primeira (VAN SLYKE,

2009). Sendo assim, grande parte do conteúdo criado no processo a ser descrito na Seção

3.3, corresponde a um protótipo de jogo digital, e não ao próprio jogo, e será determinante

na aprovação de um projeto. Porventura, durante a etapa de produção, pode ocorrer alguma

mudança no escopo do projeto que faça com que haja uma atualização no GDD, dando

continuidade ao conceito de documento vivo e à espiral.


10

O modelo tradicional do processo de desenvolvimento de software em espiral, conforme a

Figura 1, é dividido em quatro setores (SOMMERVILLE, 2003, p. 44-45). No primeiro,

definição de objetivos, são definidos os objetivos específicos para essa fase do projeto,

representada por um loop na espiral. No segundo, avaliação e redução de riscos, para cada

um dos riscos de projeto identificados, é realizada uma análise detalhada e são tomadas

providências para reduzir esses riscos. Em seguida, em desenvolvimento e validação, um

modelo de desenvolvimento (como prototipação evolucionária ou modelo em cascata) é

escolhido para o sistema. Finalmente, em planejamento, o projeto é revisto e toma-se uma

decisão sobre a necessidade de continuar a espiral.

Figura 1 - Modelo do Processo de Desenvolvimento de Software em Espiral (SOMMERVILLE, 2003).

Entretanto, para o GDD, foram definidas três fases gerais para este processo, conforme a

Figura 2: Design, Implementação e Testes.


11

Figura 2 - O Modelo de Desenvolvimento do GDD em uma Espiral de Três Fases.

Além da descrição do processo relacionado com a espiral na Seção 4.2, a Seção 4.3

apresenta seções elementares de qualquer GDD, seguida do fluxo que o documento deve

seguir, com um exemplo no final da Seção 4.

3.1.3 Processo

A primeira fase, Design, é uma atividade independente da programação do jogo, produzindo

mídia a partir de um documento inicial de design. Já a segunda fase, Implementação, vem

da equipe de programação que associa a primeira fase, ou seja, toda a mídia produzida ao

código. Finalmente, uma equipe de testes do documento analisa, na fase Testes, os

documentos obtidos após a compilação em CWEB nesta iteração da espiral. A Figura 3

representa o diagrama de atividades em UML referente a este processo.


12

Figura 3: Diagrama de Atividades UML do Processo de Desenvolvimento Relacionado ao Padrão

A próxima seção, Documento de Game Design Unificado e Independente de Gênero, indica

quais são as seções elementares que um GDD independente de gênero deve possuir, além

de seções e subseções complementares que podem fornecer mais informações para os

interessados em sua leitura.

4 Resultados e Discussão

4.1 Documento de Game Design Unificado e Independente de Gênero

Após o estudo comparativo realizado anteriormente entre os modelos de GDD que usam o

formato de seções, foram definidas seções elementares presentes em qualquer GDD

moderno para fazer parte do padrão, dispostas a seguir:

1 Histórico do Design

2 Sumário

3 Gameplay

3.1 Visão Geral

3.2 Elementos do Jogo

3.3 Controles


13

4 Mecânica

5 Menus do Sistema

Estas seções são descritas nos modelos apresentados anteriormente, e podem ter variação

de nome e localização, dependendo do autor. Pode-se dizer que elas são elementares de

qualquer GDD por estarem presentes nos modelos analisados, como também não são

dependentes de gênero e por isso foram escolhidas para compor um modelo unificado.

Outras seções analisadas não são essencialmente independentes de gêneros e dificultam a

criação de um modelo unificado independente de gênero. As duas primeiras seções

representam elementos pré-textuais, e são escritas e atualizadas ao fim de cada nova

iteração da espiral, não havendo uma necessidade de serem implementadas no jogo em si.

Conforme o gênero e estilo do jogo a ser documentado, outras seções ou subseções podem

ser acrescentadas, como: Inteligência Artificial, Progressão do Jogo/Level Design, Contexto

do Jogo, Conflitos e Soluções, Variações de Jogo, História, Mundo, e Personagens.

4.2 Fluxo do Documento

Partindo da fase de Design, após todo o processo criativo inicial, deve-se documentar em

um arquivo com a extensão “.w” o que foi obtido. O Histórico do Design deve registrar a

versão inicial, incrementando o número da versão na medida em que ocorrem novas

iterações da espiral e indicando as mudanças ocorridas. Com esta primeira documentação,

no formato de texto - definindo seções como a Visão Geral e a Mecânica do Jogo, por

exemplo -, o documento segue para a fase de Implementação, no qual é desenvolvido o

código correspondente em CWEB e disposto logo em seguida ao respectivo trecho

implementado. Feito isso, os programas CTANGLE e CWEAVE (KNUTH; LEVY, 2002) são

executados, tendo como entrada o arquivo com a extensão “.w”. O primeiro programa gera

como produto um código fonte em C baseado no código em CWEB, e o segundo programa

gera como produto um arquivo de texto do tipo “.tex”, conforme a Figura 4.

Figura 4: Adaptação de figura do site literateprogramming.com, de um exemplo de entrada e de saídas dos programas CTANGLE e CWEAVE4

4Fonte: <http://www.literateprogramming.com/cweave.jpg>. Acesso em: 12 Maio 2011.


14

A espiral segue para a fase de testes, na qual o arquivo executável obtido da compilação do

código fonte em C e a documentação obtida do arquivo de extensão “.tex” são validados. Ao

término desta fase, avalia-se a necessidade de continuar a espiral, retomando todo o

processo ou finalizando o procedimento. Na seção a seguir, há um exemplo do uso de

CWEB integrado à Documentação de Game Design.

4.3 Exemplo de Construção de Documento

Knuth (2010) adaptou como exemplo para CWEB o jogo de texto Adventure (CROWTHER;

WOODS, 1975), originalmente escrito em FORTRAN. Na época em que o jogo original foi

desenvolvido, não existia o conceito de GDD, como também não foi desenvolvido por uma

equipe numerosa. A adaptação feita por Knuth consiste basicamente na tradução direta do

código em FORTRAN para CWEB, usando, inclusive, os comentários originais como

documentação do código (WOODS; KNUTH, 2002). É de se esperar, portanto, que esta

versão em CWEB não apresente o formato de um GDD, mas sim de um programa

documentado. Esta versão apresenta a seguinte divisão de seções, na respectiva ordem

(Ibid., tradução nossa): Introdução, Vocabulário, Dados da Caverna, Conexões da Caverna,

Estruturas de Dados para Objetos, Dados de Objetos, Entrada em Baixo Nível, Loop de

Controle Principal, Verbos Simples, Ativos Líquidos, Outras Ações, Movimentos, Números

Aleatórios, Elementos de Duendes, Fechando a Caverna, Morte e Ressurreição, Pontuação,

Executando o Programa, Índice Remissivo e um Sumário automático.

Para fins de demonstração do processo em espiral, foi criada uma simulação na qual o

programa documentado de Knuth, “adventure.w” (KNUTH, 2010), representa o protótipo de

um jogo mais elaborado no setor de arte e jogabilidade, e foi concebido nas primeiras duas

fases deste processo. A fase de Testes valida o arquivo executável obtido após a execução

do CTANGLE, entretanto, identifica que o documento gerado após a execução do CWEAVE

não possuí as seções elementares de um GDD, ou não está organizado com a

nomenclatura correta das seções, e informa a equipe de Design que a avaliação da validade

das seções depende disto. Começa uma nova fase de Design, na qual a equipe reorganiza

as seções antigas em seções do GDD unificado apresentado neste artigo. As seguintes

alterações foram feitas: foi adicionada no início a seção de Histórico do Design, já

descrevendo as alterações; o Sumário foi reposicionado logo após o Histórico do Design; a

seção de Introdução se torna uma subseção de Visão Geral, antecedendo uma nova

descrição da ideia geral do jogo; Gameplay abriga tanto a subseção Elementos do Jogo,

que passa a representar as antigas “Estruturas de Dados para Objetos”, “Dados de

Objetos”, e “Ativos Líquidos”, quanto abriga a subseção Controles, que representa as


15

antigas “Vocabulário”, “Entrada em Baixo Nível”, “Verbos Simples”, “Outras Ações”, e

“Movimentos”, como também abriga “Pontuação”; a nova seção Mecânica recebe as

subseções “Loop de Controle Principal”, “Números Aleatórios”, “Morte e Ressurreição”, e

“Executando o Programa”; a seção Level Design é adicionada e apresenta o conteúdo de

“Dados da Caverna”, “Conexões da Caverna”, e “Fechando a Caverna”; Personagens passa

a ser a nova seção de “Elementos de Duendes”; e parte da seção “Vocabulário” representa

comandos que desencadeiam a abertura de algum tipo de Menu, como o de ajuda, e estes

comandos devem ser indicados na nova seção Menus do Sistema; finalmente, o Índice

Remissivo permanece no mesmo lugar. A nova ordem corresponde ao seguinte:

1 Histórico do Design

1.1 Versão 0.1

1.2 Versão 0.2

2 Sumário

3 Gameplay

3.1 Visão Geral

3.1.1 Introdução

3.1.2 Conceito do Jogo

3.2 Elementos do Jogo

3.2.1 Estruturas de Dados para Objetos

3.2.2 Dados de Objetos

3.2.3 Ativos Líquidos

3.3 Controles

3.3.1 Vocabulário

3.3.2 Entrada em Baixo Nível

3.3.3 Verbos Simples

3.3.4 Outras Ações

3.3.5 Movimentos

3.4 Pontuação


16

4 Mecânica

4.1 Loop de Controle Principal

4.2 Números Aleatórios

4.3 Morte e Ressurreição

4.4 Executando o Programa

5 Level Design

5.1 Dados da Caverna

5.2 Conexões da Caverna

5.3 Fechando a Caverna

6 Personagens

6.1 Elementos de Duendes

7 Menus do Sistema

7.1 Vocabulário

8 Índice Remissivo

Em CWEB, diferentemente de subseções, que são definidas pelo prefixo composto pelo

símbolo “@” e um espaço em branco, uma seção principal tem seu título definido pelo

prefixo “@*”, um texto e um ponto (.). Todo o conteúdo escrito até o próximo título deste

estilo corresponde a uma seção. O programa CWEAVE foi programado de uma maneira

para identificar estes símbolos de seção ao ser executado e determinar sua posição e

número correspondente, para então criar o Sumário automaticamente (KNUTH; LEVY,

2002).

Em termos de alterações no arquivo “adventure.w”, isto corresponde, usando como exemplo

o momento em que algumas alterações já foram feitas e a nova seção Mecânica vai ser

criada, ao seguinte: Loop de Controle Principal, Números Aleatórios, Morte e Ressurreição,

e Executando o Programa, que são definidas como seções principais (começam com o

prefixo “@*”, seguido de texto e um ponto), são recortados individualmente e colocados um

em seguida do outro, a partir do fim da seção anterior - Gameplay. Os prefixos de seção

principal são substituídos por prefixos de subseção. Finalmente, no princípio da seção

(antes da primeira subseção), o prefixo de seção principal é adicionado, seguido pelo texto

“Mecânica” sem aspas e um ponto. Estas alterações não afetam o funcionamento do


17

programa gerado pelo CTANGLE, tendo como explicação a própria origem do nome deste

programa (Ibid., tradução nossa):

O programa CTANGLE tem este nome porque ele recebe uma certa “teia” e

remaneja as seções de sua estrutura em forma de “teia” em uma ordem

exigida pela linguagem C; a vantagem de se programar em CWEB é de que

os algoritmos podem ser expressos em uma forma “desemaranhada”, com

cada seção explicada separadamente.5

Já na fase de Implementação, eventuais atualizações são feitas no código para refletir as

mudanças feitas na fase anterior. Novamente, a fase de Testes valida o arquivo executável

e verifica por alguma falha no documento de texto. Este processo todo é continuado caso

tenha sido identificado a necessidade de alguma mudança ou atualização.

5. Conclusão

É certo que para o GDD e o processo de desenvolvimento associado criados neste trabalho

passarem a ser de conhecimento da indústria e serem usados, é necessário que eles sejam

aprimorados e apresentados de alguma maneira, como em um evento da área, por exemplo.

Futuramente, o padrão pode ser testado com uma equipe desenvolvendo um jogo, enquanto

outra equipe desenvolve o mesmo jogo sem o uso do padrão, para que haja uma avaliação

do desempenho do padrão. Outra sugestão é adaptar o metamodelo para que ele possa

descrever um jogo de uma maneira independente de seu gênero, a fim de fornecer uma

alternativa aos modelos baseados em gênero. Também é importante consultar membros

estabelecidos da indústria internacional de jogos em relação ao formato criado, tanto para

analisar novas propostas quanto divulgar o formato. Mesmo que o padrão criado neste

trabalho não seja aplicado na indústria, seja com um documento dependente ou não de

gênero, é interessante divulgar que um padrão de documentação para Game Design é

possível.

Além dessas possibilidades, outras questões surgiram durante o decorrer da pesquisa que

podem ser temas para novas pesquisas. Ao analisar os processos de desenvolvimento de

jogos digitais, foi constatado que certos pontos são muito semelhantes à Engenharia de

Software, ou mesmo idênticos. Aparentemente, devido à descentralização de tarefas - onde

profissionais de outras áreas que não são da Tecnologia da Informação (TI) - como artistas -

se juntaram ao desenvolvimento de jogos, houve a criação de processos de

5Texto original: “The CTANGLE program is so named because it takes a given web and moves the

sections from their web structure into the order required by C; the advantage of programming in

CWEB is that the algorithms can be expressed in “untangled” form, with each section explained

separately” (KNUTH; LEVY, 2002)


18

desenvolvimento em paralelo à Engenharia de Software, onde havia mais profissionais

específicos de TI. Um trabalho futuro pode, por exemplo, determinar se a suposição anterior

é válida, como também determinar se um GDD corresponde ao documento de especificação

de software (SRS, do inglês Software Requirements Specification) e se o cargo de Game

Designer equivale ao cargo de Arquiteto de Software, e outras comparações entre Game

Design e Engenharia de Software.

Referências

ANDRADE, P. M. F. D. As Carreiras no Mercado de Games. In: BOBANY, A. Videogame

Arte. Teresópolis: Novas Idéias, 2008. p. 36.

BJÖRK, S.; HOLOPAINEN, J. An Activity-Based Framework for Describing Games. In:

______. Patterns in Game Design. Boston: Charles River Media, 2005. Cap. 2.

FULLERTON, T.; SWAIN, C.; HOFFMAN, S. Playtesting In: ______. Game Design

Workshop. 2nd. ed. Burlington: Elsevier Inc, 2008. Cap. 9.

______. Team Structures. In: ______. Game Design Workshop. 2nd. ed. Burlington:

Elsevier Inc, 2008. Cap. 12.

______. The Design Document. In: ______. Game Design Workshop. 2nd. ed. Burlington:

Elsevier Inc, 2008. Cap. 14.

GAMMA, E. et al. Introdução. In: ______. Padrões de Projeto: soluções reutilizáveis de

software orientado a objetos. Porto Alegre: Bookman, 2000. Cap. 1.

KNUTH, D. E. ADVENT, 2010. Disponível em: <http://www-cs-

staff.stanford.edu/~uno/programs/advent.w.gz>. Acesso em: 05 Maio 2011.

______.; LEVY, S. The CWEB System of Structured Documentation, 2002. Disponível

em: <http://www.literateprogramming.com/cweb.pdf>. Acesso em: 05 Maio 2011.

PEDERSEN, R. E. The Game Design Process. In: ______. Game Design Foundations.

2nd. ed. Plano: Wordware Publishing, 2009. Cap 5.

REYNOLDS, C. Assassin's Creed II dev team triples in size. NowGamer, 2009. Disponível

em: <http://www.nowgamer.com/news/513/assassins-creed-ii-triples-size-of-dev-team>.

Acesso em: 03 Maio 2010.

ROUSE, R. The Design Document. In: ______. Game design: theory & practice. 2nd. ed.

Plano: Wordware Publishing, Inc, 2005. Cap. 19.


19

SCHUYTEMA, P. O documento de design. In: ______. Design de Games: Uma Abordagem

Prática. São Paulo: Cengage Learning, 2008. Cap. 5.

______. Design do ambiente In: ______. Design de Games: Uma Abordagem Prática. São

Paulo: Cengage Learning, 2008. Cap. 12.

SOMMERVILLE, I. Processos de software. In: ______. Engenharia de Software. 6. ed. São

Paulo: Pearson Addison Weasley, 2003. Cap. 3.

VAN SLYKE, B. How a Game Gets Made: A Game's Journey from Concept to Store

Shelves. GameCareerGuide.com, 2009. Disponível em:

<http://www.gamecareerguide.com/features/745/how_a_game_gets_made_a_games_.php>.

Acesso em: 16 Abr. 2011.

WOODS, D.; KNUTH, D. E. ADVENTURE, 2002. Disponível em:

<http://www.literateprogramming.com/adventure.pdf>. Acesso em: 05 Maio 2011.

WOZNIAK, S.; SMITH, G. iWoz. New York: W. W. Norton & Company, 2007.

Jogos Digitais Citados

Adventure. Will Crowther; Don Woods, 1976.

Assassin’s Creed II. Ubisoft. Ubisoft Montreal, 2009.

Breakout. Atari, 1978.

Contato: [email protected] e [email protected]

ANÁLISE DE MODELOS DE DOCUMENTOS DE GAME DESIGN E PROPOSTA DE …€¦ · · 2012-10-04Um...

Documents

Transcript of ANÁLISE DE MODELOS DE DOCUMENTOS DE GAME DESIGN E PROPOSTA DE …€¦ · · 2012-10-04Um...