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

Transcrição

1 Proposta de Modelos de Documentação de Design para Jogos 2D Frederico Boussada Alves 1, Márlon Oliveira da Silva 2 Faculdade de Ciências Exatas e Comunicação (FACEC) Universidade Presidente Antônio Carlos (UNIPAC) Barbacena - MG 1 fredbr.pro@gmail.com, 2 marlonos.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 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

2 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

3 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.

4 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 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 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,

5 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 Mecânica Interatividade Narrativa Seções Complementares Arte e Animação 2D Músicas e Efeitos Sonoros Fases do 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 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 Geral da Jogabilidade Estabelecer Regras e Física do Jogo Elementos da Jogabilidade Inteligência 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;

6 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 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 Visão Geral da Interface Estabelecer Ordem de Navegação Desenvolver Esboços das Telas de Navegação Elaborar Interface do Jogo Principal 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 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;

7 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 Visão Geral da História Elaborar Roteiro Estabelecer Disposição do Conteúdo Narrativo Desenvolver Esboços das Telas com Conteúdo Narrativo Figura 7. Diagrama de Atividades demonstrando a divisão da seção de Narrativa dentro do documento de design 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. Plano de Fundo (Background) Arte e Animação 2D Sprites Descrever Menus e Telas de Transição Interface do Jogo Principal Mostrar Detalhes Visuais de Personagens Mostrar Detalhes Visuais dos Ambientes Efeitos 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

8 principal, e a última subseção detalha os efeitos aplicados aos personagens e ambientes do jogo. Essa divisão é mostrada na Figura 9. Músicas Música e Efeitos Sonoros Efeitos Sonoros Conteúdo da Telas de Navegação e Transição Músicas no Jogo Principal Efeitos Sonoros das Telas de Navegação e Transição Efeitos da Interface do Jogo Principal Descrever Efeitos dos Personagens, 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 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 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;

9 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 Estabelecer Plataforma Ferramentas Externas Componentes de Jogo Explicar Regras e Física Comportamento da IA Explicar Controle de Dados Interface Figura 10. Diagrama de Atividades demonstrando a divisão do tópico Mecânica. 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) 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 Som

10 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 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.

11 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. Main 1 contém 1..* Sprite 1 1 utiliza 1..* GameComponent 0..* reúne 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

12 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 Alteração gráfica das naves do jogador e dos inimigos, bem como dos tiros de ambos. Decisões Funcionais Utilização da classe List, do C, para criação de uma lista para os tiros do jogador.

13 Inserção de parte do roteiro (narração) dos fatos do jogo nas telas de transição (antes e depois de cada 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. Inserção de um chefe de fase no final de cada uma delas. Inserção de uma barra na área inferior da tela do jogo, exibindo ao jogador informações sobre pontos de vida, pontos por inimigo abatido e número de bombas durante o jogo. Inicialização dos jogadores em posições aleatórias do cenário (utilizando a função srand() do C). 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. Utilização de uma subpasta para armazenar arquivos de som e imagem utilizados no jogo. Utilização de métodos mais eficientes para cálculo de colisão de objetos na tela (por exemplo, quando uma nave inimiga encosta na nave ou em algum 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.

14 Tabela 2. Comparativo entre os modelos de de Ryan e os modelos propostos. Aspectos Modelo de Tim Ryan Modelo Proposto Análise de Mercado Nível de Abordagem da Documentação de Design Abordagem Técnica Possui um modelo de documentação direcionado a investidores e setor financeiro e administrativo da(s) empresa(s) envolvida(s). É necessário certo grau de adequação do modelo de acordo com o projeto, por se tratar apenas de diretrizes para abordagem de design. Dependendo do projeto, haverá mudanças drásticas no escopo do documento de design. Propõe a abordagem e detalhamento de componentes funcionais do jogo (DLLs, EXEs, etc) e funcionamento de códigos-fonte. Não possui análise de mercado, pois foi focado no desenvolvimento do produto do ponto de vista do designer e do líder técnico. O escopo das seções atende perfeitamente ao nível de projeto proposto (jogos 2D de pequena/média complexidade), e permite, através de poucas alterações, atender a projetos bem distintos entre si Propõe maior utilização de uma linguagem de modelagem (UML, etc) para facilitar o entendimento acerca 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.

15 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 Acessado em junho de HARGREAVES, Shawn. (2007) Allegro A Game Programming Library v Disponível em Acessado em junho de JOHNSON, Richard. (2007) Capture de Dude Game Design Document. Disponível em Acessado em junho de 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 Acessado em julho de 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 Acessado em agosto de 2007.