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)
Universidade Presbiteriana Mackenzie
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).
VII Jornada de Iniciação Científica - 2011
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)
Universidade Presbiteriana Mackenzie
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.
VII Jornada de Iniciação Científica - 2011
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
Universidade Presbiteriana Mackenzie
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;
VII Jornada de Iniciação Científica - 2011
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.
Universidade Presbiteriana Mackenzie
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.
VII Jornada de Iniciação Científica - 2011
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.
Universidade Presbiteriana Mackenzie
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.
VII Jornada de Iniciação Científica - 2011
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
Universidade Presbiteriana Mackenzie
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.
VII Jornada de Iniciação Científica - 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
Universidade Presbiteriana Mackenzie
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
VII Jornada de Iniciação Científica - 2011
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
Universidade Presbiteriana Mackenzie
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)
VII Jornada de Iniciação Científica - 2011
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.
Universidade Presbiteriana Mackenzie
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]
Top Related