Proposta de Modelos de Documentação de Design para Jogos

2D
Frederico Boussada Alves1, Márlon Oliveira da Silva2

Faculdade de Ciências Exatas e Comunicação (FACEC)

Universidade Presidente Antônio Carlos (UNIPAC) – Barbacena - MG
1
fredbr.pro@gmail.com, 2marlonos.br@gmail.com

Resumo. No cenário do desenvolvimento de jogos atual, empresas são

responsáveis por projetos que envolvem grande complexidade técnica e de
conteúdo, exigindo um processo de análise, ou design, minucioso e profundo
acerca desses projetos. Este trabalho tem como objetivo apresentar propostas
de documentação de design, que venham a auxiliar na análise de conteúdo
técnico e artístico em jogos 2D, com base nas três fases de desenvolvimento
de um jogo eletrônico.
Palavras-chave: game design, processo de desenvolvimento, documentação de
design, modelos de documentação.

1. Introdução
Até o início dos anos 80, os jogos eletrônicos eram criados por times pequenos (FORTE
e GARRETT, 2007), na maioria das vezes por apenas uma pessoa. A codificação
envolvia apenas um programador (e às vezes um artista); os projetos contavam com um
baixo orçamento e prazo de entrega do produto final bem flexível (FREEMAN, 1997).
Um grande exemplo de um jogo desenvolvido com essa metodologia é o jogo Pitfall,
lançado em 1982 para Atari 2600, mostrado na Figura 1.

Figura 1. Pitfall, lançado em 1982, para Atari 2600.

Pelos motivos descritos acima, processos de documentação e design eram

praticamente inexistentes, já que, com o pequeno número de pessoas envolvidas em um
projeto, era muito mais fácil realizar alterações, não sendo necessário informar a mais
ninguém (ou a apenas a poucas pessoas) sobre elas. Conseqüentemente, o
desenvolvimento era focado na implementação do jogo em si.
Atualmente, com a utilização de ferramentas de alta tecnologia, com o
envolvimento de dezenas de pessoas em projetos milionários e com a pressão cada vez
maior da indústria e da mídia, a fase anterior à codificação é uma etapa essencial para
evitar transtornos futuros no desenvolvimento de um jogo eletrônico, auxiliando a
equipe envolvida a se direcionar em relação aos objetivos a serem alcançados com o
projeto, com o objetivo de promover a produção de um trabalho atrativo ao jogador
final. Uma das versões mais recentes de Pitfall, mostrado na Figura 2, não poderia ser
concebido sem um processo de análise de conteúdo e técnico, em função de sua
complexidade técnica.

Figura 2. Pitfall: The Lost Expedition, lançado em 2004, para videogames e PC.

É fato, portanto, que a aplicação de documentações relacionadas à fase de

análise do projeto pode ser a diferença entre um projeto fadado ao fracasso e um projeto
que tende a alcançar a perfeição técnica e artística (FREEMAN, 1997).
Este artigo tem como objetivo apresentar três modelos de documentação para o
processo de análise de um jogo, baseando-se nas três fases de desenvolvimento: fase
conceitual, fase de design e fase de produção (FREEMAN, 1997). A Seção 2 apresenta
alguns modelos ou abordagens de documentação encontradas na literatura. A Seção 3
detalha os modelos propostos, explicando todas as seções abordadas em cada um deles.
A Seção 4 faz uma análise dos modelos propostos através do desenvolvimento de um
protótipo de jogo de nave em 2D. A Seção 5 apresenta as conclusões sobre a utilização
de documentação para o desenvolvimento de um jogo, além de propor alguns temas
para extensão do trabalho.

2. Trabalhos Relacionados
Existem diversos trabalhos e artigos relacionados ao processo de desenvolvimento e
game design. Os portais Gamedev.net e Gamasutra abrigam diversos artigos sobre
design e desenvolvimento de jogos, escritos por profissionais da área. François
Laramee, em seu artigo na Gamedev.net (LARAMEE, 1999), propõe a utilização de até
seis documentos de design diferentes. Tzvi Freeman, em seu artigo disponível no
Gamasutra (FREEMAN, 1997), divide o processo de desenvolvimento de games em
três partes, cada uma resultando em um ou mais documentos relacionados.
Também são disponibilizadas na Internet diversas documentações de design de
jogos com abordagens totalmente distintas. A documentação de design do jogo Capture
the Dude (JOHNSON, 2000), criado por alunos da escola de jogos Digipen (EUA)
apresenta uma análise pouco profunda em relação ao documento de design de
Stampede, jogo de ação projetado para o console Xbox 360 (da Microsoft). Nesse
último, é disponibilizada uma análise mais detalhada sobre o funcionamento do jogo, o
estilo visual, a interface com o usuário e outras características inerentes ao projeto a
nível de conteúdo.
Na literatura, encontram-se livros que abordam o processo de design de modo
teórico e prático. Na obra de Richard Rousse III (ROUSSE III, 2005), são apresentados
documentos de design de dois jogos distintos, um de ação e outro de terror, porém
ambos em 3D. Através desses exemplos, é demonstrada de modo claro a falta de
padronização no processo de documentação de um jogo, que varia conforme o projeto e
abordagem por parte do designer.
Tim Ryan disponibiliza, no portal Gamasutra, modelos de quatro níveis de
documentação diferentes (RYAN, 1999): documento de proposta do jogo, documento
conceitual, documento de design e documentação técnica, sendo que os três últimos
serviram de base para a criação dos modelos deste trabalho. Através de linhas gerais,
são explicados os pontos em que o desenvolvedor ou designer deve se preocupar para
desenvolver um jogo de qualquer gênero ou nível de complexidade. O autor deixa claro
que o detalhamento de alguns tópicos (ou até a exclusão de alguns tópicos
desnecessários) fica a cargo do designer, responsável por documentar todo o conteúdo.

3. Criação de Modelos de Documentação de Game Design

Através dos estudos realizados, constatou-se que é muito difícil adotar um modelo para
as documentações de design de um game, visto que os tópicos abordados podem variar
dependendo do projeto. Como exemplo, documentações de design de jogos 3D abordam
tópicos que documentações de jogos 2D geralmente não precisam, como controle de
câmera pelo jogador, variação do campo de visão do personagem do jogador e
detalhamento de técnicas de modelagem 3D, para citar alguns. Isso reforça a idéia de
que, em função da subjetividade de alguns componentes dos jogos, a adoção de métodos
rígidos é geralmente descartada.
Porém, quando se compara documentos de design de jogos com alguma
semelhança, seja de conteúdo, gênero (tipo de jogo) ou grau de complexidade de
projeto, os documentos referentes a esses projetos possuem vários pontos em comum.
Entre jogos 2D, similaridades foram encontradas durante a leitura das documentações
de design de diferentes jogos, abordando quase sempre os mesmos tópicos. Este
trabalho apresenta três modelos de documentação para as três fases de desenvolvimento
de um jogo 2D:
• Um modelo de documentação conceitual, elaborado na fase conceitual;
• Um modelo de documentação de design, criado na fase homônima; e
• Um modelo de documentação técnica, elaborado durante a fase de produção
(implementação e testes) do jogo.

3.1. O Modelo de Documentação Conceitual

A documentação conceitual é formada por seções básicas, abordando de modo sucinto a
idéia inicial proposta pelo designer. Dependendo da complexidade do projeto, pode
possuir de uma a quatro páginas, e deve abordar as seções ilustradas na Figura 3:

Documentação Conceitual
Introdução Descrição Elementos-Chave Gênero Plataforma Arte Conceitual

Figura 3. Diagrama de Atividades demonstrando as seções que formam o

modelo para o documento conceitual de um game.

Em ordem, as seções são abordadas da seguinte maneira:

1. Introdução: deve conter um texto breve descrevendo a idéia principal do jogo;
2. Descrição: é recomendável conter um leve aprofundamento da idéia principal do
jogo, abordando suas características principais;
3. Elementos-chave: contém frases que expressam os atrativos principais do jogo;
4. Gênero: especifica o estilo do jogo (como ação, corrida, plataforma);
5. Plataforma: informa se o jogo será destinado a algum console (videogame),
computador, celular ou portáteis (como Gameboy Advance e Nintendo DS);
6. Arte Conceitual: seção que contém alguma ilustração de personagens e cenários do
jogo. É opcional, visto que nem sempre há um profissional que possa atuar como artista
em um estágio tão prematuro de desenvolvimento. Apesar disso, essa seção é de
extrema importância, pois a presença de ilustrações enriquecem muito o documento e
atraem o leitor.

3.2. O Modelo de Documentação de Design

Na segunda fase de desenvolvimento, uma documentação de design deve ser criada para
abrigar as idéias válidas para a futura implementação do game.
O modelo proposto foi dividido basicamente em três tópicos principais:
mecânica, interatividade e enredo (ROLLINGS e ADAMS, 2005). Além disso,
verificou-se a importância de se detalhar os aspectos artísticos referentes a som e arte
gráfica do jogo em seções complementares, devido à sua aplicabilidade em todos os
projetos. Outra seção aplicável à maioria dos jogos refere-se ao detalhamento das fases
do jogo, abordando o conteúdo lógico, gráfico e sonoro de cada uma delas
separadamente. A Figura 4 mostra a organização e divisão dos tópicos do documento de
design:

Documento de
Design

Seções
Mecânica Interatividade Narrativa Complementares

Arte e Músicas e Fases do

Animação 2D Efeitos Sonoros Jogo

Figura 4. Organograma mostrando o primeiro particionamento do documento

de design, em três tópicos principais e seções complementares.

Cada um dos tópicos, em função do nível de abordagem exigido para um

documento de design, é composto de alguns subtópicos, detalhados nas seções a seguir.

3.2.1 Seção “Mecânica”

A seção de Mecânica deve expressar claramente o funcionamento do jogo, detalhando
sua jogablidade principal, funcionamento de regras e cálculos internos referentes à
jogabilidade, elementos que compõem o jogo principal e o comportamento dos
elementos que interagem com o jogador.
Quatro tópicos compõem a análise da mecânica do jogo, como mostrado na
Figura 5.

Mecânica

Descrever Visão Estabelecer Detalhar Detalhar

Geral da Regras e Física do Elementos da Inteligência
Jogabilidade Jogo Jogabilidade Artificial

Figura 5. Diagrama de Atividades mostrando a composição da seção de

Mecânica no documento de design.

De forma resumida, as seções abordam os seguintes aspectos:

1. Visão Geral da Jogabilidade: uma descrição sobre a base do funcionamento do jogo.
Todo o trabalho de design é desenvolvido com base na descrição contida nessa seção;
2. Regras e Física do Jogo: aborda, de modo mais prático, detalhes sobre
movimentação, combate e demais aspectos de jogabilidade, assim como informações
básicas sobre os cálculos envolvidos no processo;
3. Elementos da Jogabilidade: descrição sobre os elementos com os quais o jogador irá
interagir no jogo (como itens, armas, habilidades especiais, por exemplo);
4. Inteligência Artificial: explicação prática sobre o comportamento (através de textos
ou diagramas) de inimigos e personagens não-jogáveis que compõem o jogo.

3.2.2 Seção “Interatividade”

Esta seção aborda seções relativas à navegação e interação do jogo, contendo uma visão
do funcionamento geral da interatividade, esboço de telas de menu e de transição e
detalhamento da interface do jogo principal, como mostrados na Figura 6:
Interatividade

Detalhar Visão Estabelecer Desenvolver Esboços

Elaborar Interface
Geral da Ordem de das Telas de
Interface do Jogo Principal
Navegação Navegação

Figura 6. Diagrama de Atividades mostrando o processo de composição da

seção de Interatividade dentro do documento de design.

Pela ordem, uma descrição sucinta sobre as quatro seções:

1. Visão Geral da Interface: deve conter uma explicação detalhada sobre o
funcionamento da interação do usuário com o jogo (através de teclado, mouse, controle
remoto, etc) e especificação de comandos relacionados às ações do jogador;
2. Navegação: contém um ou mais diagramas de sequência detalhando o fluxo de
navegação do conteúdo do jogo pelo usuário, com explicação sobre telas de transição,
menus e jogo principal;
3. Esboço de Telas de Navegação: seção composta por desenhos demonstrando o
conteúdo visual das telas de telas de transição, de carregamento e de menu, bem como
uma breve descrição sobre os elementos componentes dessas telas;
4. Interface do Jogo Principal: contém um detalhamento dos componentes da interface
de jogo principal (como a GUI – Graphics User Interface, Interface Gráfica do
Usuário), com descrições e esboços de cada um deles.

3.2.3. Seção “Narrativa”

Detalhes sobre a história do jogo devem ser descritas nesta seção. Ela deve conter todos
os textos narrativos e de diálogos que serão utilizados, além da disposição do conteúdo
relacionado nos componentes de interface do jogo. Como complemento, o designer
pode adicionar esboços de algumas telas de transição que contenham conteúdo
narrativo. Optou-se por dividir este tópico em quatro partes principais, descritas a seguir
e demonstradas na Figura 7:
1. Visão Geral da História: aborda de modo sucinto a história do jogo, abordando os
aspectos que venham a motivar o jogador a participar dela através do jogo;
2. Roteiro: deve conter os textos, tanto em forma de narração quanto em forma de
diálogo, que serão inseridos no jogo. Optou-se pela divisão em dois tópicos (“Narração”
e “Diálogos”), abordando os dois tipos de texto;
3. Disposição do Conteúdo Narrativo: contém detalhes sobre a disposição dos textos
descritos na seção de roteiro, através da especificação acerca das telas e eventos do jogo
onde eles estarão presentes;
4. Esboço das Telas com Conteúdo Narrativo: como o título já diz, deve conter
representações gráficas das telas que contém os textos que compõem o roteiro do jogo.
Narrativa

Estabelecer Desenvolver Esboços das

Detalhar Visão Elaborar
Disposição do Telas com Conteúdo
Geral da História Roteiro Conteúdo Narrativo Narrativo

Figura 7. Diagrama de Atividades demonstrando a divisão da seção de

Narrativa dentro do documento de design.

3.2.4. Seções Complementares

As seções complementares abordam aspectos artísticos, como os tópicos “Arte 2D e
Animação” e “Música e Efeitos Sonoros”, além de um tópico extra contendo as fichas
relacionadas às fases a serem implementadas no jogo.
Em “Arte 2D e Animação”, esboços e arte relacionados a cenários, sprites
(animações de personagens, inimigos, elementos do cenário e efeitos especiais), planos
de fundo e elementos de interface (como itens de menu e de interface do jogo principal)
são descritos e documentados. A divisão deste tópico é demonstrada na Figura 8.
Arte e Animação 2D
Plano de Fundo (Background) Sprites

Descrever Detalhar Mostrar Detalhes Mostrar Detalhar

Menus e Telas Interface do Visuais de Detalhes Visuais Efeitos
de Transição Jogo Principal Personagens dos Ambientes Especiais

Figura 8. Diagrama de Atividades demonstrando a composição da seção “Arte

2D e Animação” dentro do documento de design.

Na abordagem relacionada à parte sonora do jogo, optou-se por dividir o tópico

em dois pontos principais: “Músicas” e “Efeitos Sonoros”.
Em “Musicas”, define-se, basicamente, os nomes dos arquivos que serão
adotados, e uma breve descrição sobre as composições (inspirações, estilo de música e
duração) presentes na telas de navegação e no jogo principal.
Em “Efeitos Sonoros”, deve-se detalhar os sons utilizados durante o jogo. Esta
seção foi dividida em três subseções, onde a primeira trata dos sons utilizados nas telas
de navegação e nos menus, outra trata dos efeitos utilizados na interface de jogo
principal, e a última subseção detalha os efeitos aplicados aos personagens e ambientes
do jogo. Essa divisão é mostrada na Figura 9.
Música e Efeitos Sonoros
Músicas Efeitos Sonoros

Detalhar Detalhar Efeitos Descrever

Detalhar
Sonoros das Telas Detalhar Efeitos Efeitos dos
Conteúdo da Telas
de Navegação e
Músicas no
de Navegação e da Interface do Personagens,
Transição
Jogo Principal
Transição Jogo Principal Inimigos e
Outros Agentes

Figura 9. Diagrama de Atividades demonstrando a sequência na composição

da seção “Música e Efeitos Sonoros” na documentação de design.

A última seção do documento de design consiste na abordagem e detalhamento

das fases do jogo em dois tópicos, descritos a seguir:
Diagrama de Sequência: tem como objetivo conter um diagrama ou
organograma reesponsável por demonstrar a ordem das fases no jogo;
Descrição do Conteúdo das Fases: seção composta de subtópicos, cada um
destes correspondente a uma fase do jogo, e contém informações sobre número e
descrição dos inimigos, ocorrência e localização de itens, poderes especiais, além de
uma descrição sobre o visual (com direito a esboços) e componentes sonoros.

3.3. O Modelo de Documentação Técnica

A documentação técnica contém o modelo lógico do game, uma análise do jogo a nível
de software. Como os tópicos principais detalhados no documento de design se utilizam
de componentes de programação para funcionar, a documentação técnica foi dividida
em cinco tópicos principais, alguns semelhantes aos da documentação de design:
mecânica, interface, gráficos, som e fases. Estes tópicos são detalhados a seguir.

3.3.1. Mecânica
A seção de mecânica refere-se basicamente aos requisitos, componentes de
funcionamento interno e descrição de elementos e ferramentas externas utilizadas no
jogo. Por ser a seção mais importante e, consequentemente, a que deve conter mais
detalhes, foi subdividida em seis seções:
1. Plataforma: descrição sobre a plataforma-alvo e requisitos para funcionamento do
jogo;
2. Ferramentas externas: descrição de aplicativos e programas utilizados no
desenvolvimento (programação, modelagem, etc);
3. Componentes do jogo: detalhamento sobre classes, bibliotecas e arquivos que
compõem a estrutura do jogo. É viável a aplicação de diagramas (como o de classes)
nesta seção, demonstrando a aplicabilidade desses componentes no conteúdo do
jogo;
4. Regras e Física: consiste no detalhamento dos cálculos responsáveis pela formação
das regras do jogo, presentes em movimentações, combates, colisões de personagens
e outros elementos;
5. Comportamento da IA (Inteligência Artificial): descrição mais aprofundada (através
de texto e fluxogramas) sobre o comportamento das unidades não controladas pelo
jogador;
6. Controle dos dados: explicação dos mecanismos de processamento (consulta,
salvamento, carregamento) de dados no jogo.
Mecânica

Detalhar Detalhar Explicar Detalhar Explicar

Estabelecer
Plataforma
Ferramentas Componentes Regras e Comportamento Controle de
Externas de Jogo Física da IA Dados

Figura 10. Diagrama de Atividades demonstrando a divisão do tópico

“Mecânica”.

3.3.2. Interface
A seção de interface compreende na descrição do funciomento dos componentes com os
quais o usuário irá interagir. Botões, opções de menu, componentes da interface do jogo
principal (por exemplo, medidores de energia ou de pontos de experiência) devem ser
detalhados nesta seção.
Optou-se por uma divisão em apenas dois tópicos, uma tratando da interface fora
do jogo principal (menus, etc) e a outra tratando do jogo em si (tela do jogo principal),
descritas a seguir:
1. Telas de navegação: descrição sobre as telas que não correspondam à tela do jogo
principal. Deve-se listar os componentes das telas, bem como variáveis e funções
envolvidas nos eventos correspondentes a esses componentes;
2. Tela do Jogo Principal: deve conter informações detalhadas sobre os componentes
que promovem a exibição do conteúdo da tela do jogo e da interface com o usuário
(GUI).

3.3.3. Gráficos
Esta seção deve incluir informações sobre como as imagens são tratadas no jogo,
incluindo detalhes do sistema de exibição e animação 2D.
1. Informações Gerais: detalhes sobre modo de exibição, resolução, paletas de cores e
formatos de arquivo utilizados devem ser descritos nesta subseção;
2. Motor Gráfico: deve conter detalhes sobre métodos de animação de sprites,
renderização, efeitos especiais, dentre outras características intrínsecas ao projeto.

3.3.4. Som
A seção relacionada à parte sonora deve conter detalhes sobre o carregamento e
execução do som, como informações sobre formatos de som e drivers utilizados. Além
disso, é importante uma descrição sobre cada música e efeito sonoro utilizado, seu nome
de arquivo e caminho dentro do sistema, e os mecanismos utilizados para manipulação
desse arquivo no código.

3.3.5. Níveis
Cada nível deve ser tratado em uma subseção, como na seção homônima na
documentação de design. Neste documento, o foco deve ser dado ao código responsável
pela execução do nível e as particularidades de cada um deles.

4. Análise dos Modelos de Documentação

Para avaliação prática dos modelos de documentação propostos no trabalho, foi iniciado
o processo de design e desenvolvimento de um protótipo de um jogo de nave em 2D.
Foram criados os documentos referentes às etapas: conceitual, de design e de produção.
Na documentação conceitual, os tópicos foram abordados em apenas uma
página, o suficiente para apresentar a idéia inicial e a principal característica do jogo.
Já na documentação de design, o nível de detalhamento das idéias principais e
dos componentes do jogo foi grande. Apesar disso, percebeu-se que, por se tratar de um
jogo com uma abordagem mais simples, não houve necessidade de grande detalhamento
em todos os tópicos ou subtópicos da documentação. Nessa fase, além do documento de
design, foi criado um protótipo para avaliação da jogabilidade do jogo final,
demonstrado na Figura 11. Protótipos são adotados por grande parte das empresas de
jogos para fins de testes em torno da Mecânica e Interatividade, além de aplicação de
componentes gráficos e de som, com o objetivo de avaliar o andamento das decisões já
tomadas até então.

Figura 11. Protótipo desenvolvido com base na documentação de design.

 Alguns sprites do jogo foram apresentados na seção de Arte e Animação 2D. Na
seção de interface, foi exibido um mapeamento dos comandos utilizados pelo jogador,
bem como um fluxograma demonstrando o processo típico de navegação pelo jogo, com
esboços de telas de navegação. Além disso, os tópicos propostos na seção de Mecânica
permitiram um detalhamento muito grande nesse aspecto, onde foram descritos o
funcionamento da jogabilidade principal, detalhes de estatísticas (ganho de pontos,
vidas e itens) e comportamento das naves inimigas.
Logo depois de elaborada a documentação de design, iniciou-se a confecção da
documentação funcional. Nesta última etapa, verificou-se a importância da
documentação de design, pois foram necessárias várias consultas ao documento para
direcionar o desenvolvimento do jogo de acordo com as especificações definidas na fase
de design.
A documentação funcional do protótipo, assim como qualquer documentação de
análise de software, contém detalhes de modelagem do projeto físico através de
diagramas da UML (Unified Modelling Language – Linguagem de Modelagem
Unificada, que contém diagramas de representação de componentes e comportamentos
de sistemas). Para a versão final do jogo, foi gerado um diagrama de classes,
demonstrado na Figura 12.

1 utiliza
Main
1..*
1
contém GameComponent

1..* 0..*
1 reúne
Sprite

Figura 12. Diagrama de classes do protótipo, presente na documentação

funcional.

A classe Main é composta pelas rotinas e atributos principais do protótipo, como

funções de inicialização, processamento e finalização do jogo, cálculo da lógica e do
loop do jogo.
Foi criada a classe GameComponent para representar os elementos visíveis na
tela, como itens de menu, ícone de seleção de menu e logotipo da tela de título. O objeto
Tiro é instanciado através dessa classe, e irá abrigar características como bitmap
(imagem exibida na tela), posição na tela e valor de deslocamento.
A classe Sprite, subclasse da classe GameComponent foi criada para
representação dos elementos visíveis que possuam atributos importantes para o processo
lógico do jogo. Objetos Jogador (representação da nave e atributos do jogador) e
Inimigo (representação das naves dos inimigos no jogo) foram instanciados a partir
dessa classe, pois, além de possuir representação gráfica na tela, têm atributos como
número de vidas, bombas e pontos ganhos (este último, no caso do Jogador).
Cada objeto terá um vetor de Tiros (representando os tiros das naves), onde cada
um deles é uma instância da classe GameComponent. Por isso, há uma agregação de
instâncias da classe GameComponent em cada objeto da classe Sprite.
Além disso, informações detalhadas sobre funcionamento das classes e dos
componentes visuais e de som foram incluídos no documento.
Poucos detalhes presentes na documentação de design e no protótipo foram
implementados no produto final, em função do pouco tempo disponível para maior
aprendizado da linguagem proposta, C++, e de familiarização com a biblioteca gráfica
Allegro (HARGREAVES, 2007), direcionada a jogos 2D e 3D.
Com grande parte da documentação do protótipo já realizada, observou-se que o
modelo atendeu a todos os aspectos presentes no jogo. Isso ocorreu pois o projeto se
trata de um jogo 2D de complexidade pequena/média, de acordo com a classificação
abaixo.
• Complexidade pequena: jogos que possuem o mínimo de interação com o jogador,
aplicação de técnicas simples na exibição de imagens e pouca ou nenhuma presença de
componente narrativo no jogo. Exemplos: jogo-da-velha, forca.
• Complexidade média: jogos que possuem uma interação maior com o jogador
(utilização de vários botões, por exemplo), utilização de técnicas conhecidas e muito
utilizadas por desenvolvedores de jogos, aplicação de algum aspecto narrativo (textos
descritivos, por exemplo) para complementar a experiência de jogo e presença mais
expressiva de conteúdo artístico. Exemplo: Pitfall (mostrado no início do artigo).
• Complexidade alta: jogos que possuem grande interação com o jogador, possuem
vários módulos dentro do jogo, onde cada um deles possui modos de interação
(controles e exibição) distintos entre si; aplicação de técnicas complexas no
processamento de componentes visuais, além de grande riqueza artística e de conteúdo
narrativo. Exemplos: jogos da série Mario e Sonic.
Além disso, através da análise realizada, percebeu-se que tanto a documentação
de design quanto a funcional serviram para documentar as decisões referentes ao
protótipo, descritas na Tabela 1.

Tabela 1. Principais decisões de design e funcionais tomadas com base no protótipo

desenvolvido.

Decisões de Design Decisões Funcionais

Alteração gráfica das naves do jogador e dos Utilização da classe List, do C, para criação de
inimigos, bem como dos tiros de ambos. uma lista para os tiros do jogador.
Inserção de parte do roteiro (narração) dos fatos do Inicialização dos jogadores em posições aleatórias
jogo nas telas de transição (antes e depois de cada do cenário (utilizando a função srand() do C).
fase).

O jogador, ao invés de três vidas, terá três pontos
de vida, onde, na perda de cada um deles, a nave
sofrerá danos (visuais). Caso os três pontos de vida
sejam perdidos, o jogador deverá recomeçar o jogo
desde a primeira fase.
Enquanto, no protótipo, utilizou-se structs para
criação das estruturas dos componentes (jogador,
inimigo e tiro), pretende-se utilizar classes no
produto final, promovendo maior modularização
das estruturas utilizadas.

Inserção de um chefe de fase no final de cada uma Utilização de uma subpasta para armazenar
delas. arquivos de som e imagem utilizados no jogo.

Inserção de uma barra na área inferior da tela do Utilização de métodos mais eficientes para cálculo
jogo, exibindo ao jogador informações sobre de colisão de objetos na tela (por exemplo, quando
pontos de vida, pontos por inimigo abatido e uma nave inimiga “encosta” na nave ou em algum
número de bombas durante o jogo. tiro do jogador).

Visto que o desenvolvimento de um jogo compreende aspectos muito subjetivos

e varia conforme a complexidade técnica e abordagem de conteúdo, projetos de jogos
2D que envolvam características mais complexas em um ou mais componentes de
design (mecânica, interatividade e enredo) provavelmente requerem uma abordagem
mais detalhada desses aspectos. Isso influi diretamente na extensão da documentação de
design e da documentação funcional (quando há maior complexidade técnica). Quando
isso ocorre, uma alternativa é transferir uma seção mais extensa para outra
documentação em separado. Freeman, ao propor os documentos “bíblia gráfica”
(graphic bible, que contém detalhes visuais – através de esboços e ilustrações – de
personagens, cenários, mapas do jogo, etc.) e “cenas interativas” (interactive
screenplay, que contém todo o roteiro do jogo), deixa claro que o enredo é um fator
determinante para a variação no número de documentos que compõem o design. Essa
separação da seção de enredo do documento de design é possível no modelo proposto,
já que há um tópico em separado para tratar exclusivamente desse aspecto do jogo.
O modelo de documentação de design em (RYAN, 1999), que serviu de base
para a criação dos modelos deste trabalho, é mais abrangente, e pode ser utilizado
também para jogos 3D e projetos de maior complexidade, visto que trata de outros
aspectos (como funcionamento de jogabilidade via internet ou rede, por exemplo)
existentes em títulos mais expressivos. Porém, deixa a cargo do desenvolvedor ou
designer a tarefa de acrescentar tópicos de acordo com a necessidade de projeto, não
abordando de forma mais específica os aspectos inerentes a grande parte dos jogos
atuais. Foi elaborada uma tabela demonstrando algumas diferenças de abordagem entre
os modelos em (RYAN, 1999) e os modelos deste trabalho.
 Tabela 2. Comparativo entre os modelos de de Ryan e os modelos propostos.

Aspectos Modelo de Tim Ryan Modelo Proposto

Análise de Mercado Possui um modelo de documentação Não possui análise de mercado, pois
direcionado a investidores e setor foi focado no desenvolvimento do
financeiro e administrativo da(s) produto do ponto de vista do designer
empresa(s) envolvida(s). e do líder técnico.

Nível de Abordagem É necessário certo grau de adequação O escopo das seções atende
da Documentação de do modelo de acordo com o projeto, perfeitamente ao nível de projeto
Design por se tratar apenas de diretrizes para proposto (jogos 2D de pequena/média
abordagem de design. Dependendo complexidade), e permite, através de
do projeto, haverá mudanças poucas alterações, atender a projetos
drásticas no escopo do documento de bem distintos entre si
design.

Abordagem Técnica Propõe a abordagem e detalhamento Propõe maior utilização de uma

de componentes funcionais do jogo linguagem de modelagem (UML, etc)
(DLLs, EXEs, etc) e funcionamento para facilitar o entendimento acerca
de códigos-fonte. dos componentes funcionais do jogo.

5. Conclusão e Trabalhos Futuros

Os documentos conceitual, de design e funcional servem de ferramenta para análise do
projeto de um jogo eletrônico, do ponto de vista artístico (documento de design),
técnico (documentação funcional) e de abordagem de conteúdo (englobando os três
documentos). Esses artefatos são de grande ajuda para desenvolvimento de aplicações
que grande conteúdo a ser abordado e desenvolvido.
Os modelos propostos, como demonstrado na seção de análise, funcionam
perfeitamente para projetos de jogos 2D de complexidade pequena/média. Porém, para
um projeto de grande complexidade e envolvendo uma grande número de profissionais
qualificados, pode vir a ser necessário um número maior de documentos, ou apenas a
abordagem mais detalhada de um ou mais tópicos presentes nos modelos.
Como dito anteriormente, o volume de documentação varia conforme a
complexidade do projeto. Contudo, através da análise realizada, a documentação
auxiliou em decisões já expostas na seção de Análise. Isso só reforça a idéia de que,
apesar de consumir um certo tempo no processo de desenvolvimento, a documentação
de um projeto, seja ele da área de jogos eletrônicos ou não, é muito importante,
permitindo uma análise mais profunda sobre o sistema a ser desenvolvido e uma
previsão sobre os componentes e ferramentas reutilizáveis em projetos futuros. Aliás,
essa prática é muito comum em empresas de jogos de grande porte (JUNIOR et. al.,
2002).
Como proposta para trabalhos futuros, pode-se realizar o estudo de caso de dois
jogos 2D de períodos distintos (por exemplo, um jogo de 1995 e outro de 2005) para
verificar se houve mudanças drásticas no processo de design entre esses dois períodos.
 Outra sugestão é adaptar os modelos existentes para projetos de jogos em 3D,
através da inserção de tópicos inerentes a esses jogos.

6. Referências Bibliográficas
FORTE, André e GARRETT, Marcus. (2007) “Designer à moda antiga” em EGM
Brasil nº63, abril. Futuro Comunicação.

FREEMAN, Tzvi. (1997) “Creating a Design Document”. Disponível em

www.gamasutra.com. Acessado em junho de 2007.

HARGREAVES, Shawn. (2007) “Allegro – A Game Programming Library – v.4.2.2”.

Disponível em http://www.talula.demon.co.uk/allegro/. Acessado em junho de 2007.

JOHNSON, Richard. (2007) “Capture de Dude Game Design Document”. Disponível

em www.ihfsoft.com/designdocuments.html. Acessado em junho de 2007.

JUNIOR, Ademar de Souza; NASSU, Bogdan T. e JONACK, Marco Antonio. (2002)

“Um Estudo Sobre os Processos de Desenvolvimento de Jogos”. Departamento de
Informática da UFPR, Curitiba. Setembro.

LARAMEE, Francois Dominic. (1999) “The Game Design Process”. Disponível em

www.gamedev.net. Acessado em julho de 2007.

ROLLINGS, Andrew e ADAMS, Ernest. (2005) On Game Design. New Riders

Publishing. 1ª edição.

ROUSSE III, Richard. (2005) Game Design Theory and Practice. Wordware
Publishing. 2ª edição.

RYAN, Tim. (1999) “The Anatomy of a Design Document”. Disponível em

www.gamasutra.com/features/19991019/ryan_01.htm. Acessado em agosto de 2007.