UNIVERSIDADE FEDERAL DE SANTA CATARINA CENTRO TECNOLÓGICO DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA Desenvolvimento de um Framework de Jogos 3D para Celulares Fabricio Brasiliense Florianópolis 2006
Fabricio Brasiliense Desenvolvimento de um Framework de Jogos 3D para Celulares Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em Ciências da Computação Orientadora: Patrícia Vilain Co-orientador: Mario Dantas Universidade Federal De Santa Catarina Departamento De Informática E Estatística Curso De Ciências Da Computação Florianópolis Julho de 2006
Resumo Este trabalho tem como objetivo o estudo e criação de um framework de jogos 3D para plataforma móvel. Ele contem um estudo teórico sobre uso e desenvolvimento de frameworks, algumas das tecnologias para ambiente móvel e jogos. Foi utilizado a metodologia de desenvolvimento Envolving Frameworks para a criação do framework, que foi criado de forma evolutiva durante o desenvolvimento de três protótipos de jogos. Para cada jogo foi utilizado um rascunho de game design. A plataforma em que foi desenvolvida foi a Java Micro Edition e utilizado a API A Mobile 3D Graphics API for J2ME. No final do trabalho, foi produzido um framework com uma arquitetura definida e reusável.
Lista de Figuras 1 Aplicações e frameworks(1)......................... p. 15 2 Gráfico com os padrões pelo tempo.................... p. 19 3 Aquitetura Brew(2)............................. p. 27 4 Arquitetura do J2ME(3).......................... p. 28 5 Configurações, perfis e pacotes opcionais.................. p. 30 6 Screen shot do jogo Gor no emulador................... p. 45 7 Diagrama de classes após a implementação do projeto.......... p. 47 8 Screenshot do jogo Sky no emulador.................... p. 50 9 Rascunho de projeto do Sky sem o framework.............. p. 51 10 Diagrama de classes do framework..................... p. 54 11 Diagrama de classes do framework..................... p. 55 12 Diagrama com o jogos Sky utilizando o framework............ p. 56 13 Screenshot do jogo Tan no emulador.................... p. 58 14 Diagrama de classes resultante do terceiro protótipo........... p. 61 15 Diagrama de classes da segunda versão do framework........... p. 63 16 Gráfico de evolução do framework em linhas de código.......... p. 65 17 Rascunho inicial do diagrama de classes do jogo Gor........... p. 73 18 Diagrama de classes completo do jogo Gor................. p. 74 19 Diagrama de seqüência da inicialização do Gor.............. p. 75 20 Diagrama de seqüência para o fluxo de execução do Gor......... p. 76 21 Diagrama de classes da primeira versão do framework.......... p. 80 22 Classes na biblioteca de componentes na primeira versão do framework. p. 81
23 Diagrama de classes completo do jogo Sky................. p. 81 24 Diagrama de seqüência da inicialização do Sky............... p. 82 25 Diagrama de seqüência do fluxo de execução do Sky............ p. 83 26 Grafo de cenas para o desenho 3D do Sky................. p. 84 27 Diagrama de classes da segunda versão do framework........... p. 88 28 Classes na biblioteca de componentes na segunda versão do framework. p. 89 29 Diagrama de classes completo do jogo Tan................. p. 90 30 Diagrama de seqüência para inicialização do Tan............. p. 91 31 Diagrama de seqüência do fluxo de execução do Tan........... p. 92 32 Grafo de cenas para o desenho 3D para o Tan............... p. 92
Sumário 1 Introdução p. 10 1.1 Objetivos.................................. p. 11 1.2 Organização do Trabalho.......................... p. 12 2 Frameworks p. 13 2.1 Introdução.................................. p. 13 2.2 Definição................................... p. 14 2.3 Desenvolvimento de Frameworks...................... p. 16 2.4 Problemas com uso de Frameworks.................... p. 17 2.5 Metodologias de Desenvolvimento de Frameworks............ p. 18 2.5.1 Dirigido por exemplos....................... p. 18 2.5.2 Dirigido por pontos de flexão................... p. 18 2.5.3 Frameworks Evolutivos....................... p. 19 2.5.3.1 3 exemplos........................ p. 20 2.5.3.2 Frameworks de Caixa Branca.............. p. 20 2.5.3.3 Biblioteca de Componentes............... p. 21 2.5.3.4 Pontos de flexão..................... p. 21 2.5.3.5 Objetos Conectáveis................... p. 21 2.5.3.6 Objetos Refinados.................... p. 21 2.5.3.7 Framework de Caixa Preta............... p. 22 2.5.3.8 Construtor Visual.................... p. 22 2.5.3.9 Ferramentas de Linguagens............... p. 22
2.6 Documentação................................ p. 23 2.7 Testes.................................... p. 24 3 Plataforma Móvel p. 25 3.1 Introdução.................................. p. 25 3.2 Plataformas e Portabilidade........................ p. 26 3.2.1 Symbian OS............................. p. 27 3.2.2 Brew................................. p. 27 3.2.3 J2ME................................ p. 28 3.2.4 Exen................................. p. 30 3.3 Desenvolvimento de Jogos para Móveis.................. p. 31 3.3.1 Gráficos 3D............................. p. 32 3.3.1.1 OpenGL ES........................ p. 33 3.3.1.2 X-Forge 2......................... p. 33 3.3.1.3 M3G............................ p. 33 4 Jogos p. 35 4.1 Introdução.................................. p. 35 4.2 Tipos de Jogos............................... p. 36 4.3 Características no Desenvolvimento de Jogos............... p. 38 4.4 Game Design................................ p. 40 4.4.1 Primeiro Conceito.......................... p. 40 4.4.2 Core Design............................. p. 41 4.4.3 Jogabilidade............................. p. 41 4.4.4 Design Detalhado.......................... p. 42 4.4.5 Equilíbrio do Jogo......................... p. 42 4.4.6 Interfaces de Entrada e Saída................... p. 42
5 Projeto p. 43 5.1 Desenvolvimento do Primeiro Protótipo: Gor............... p. 44 5.1.1 Introdução.............................. p. 44 5.1.2 Implementação........................... p. 45 5.1.3 Resultados.............................. p. 49 5.2 Desenvolvimento do Segundo Protótipo: Sky............... p. 49 5.2.1 Introdução.............................. p. 49 5.2.2 Implementação........................... p. 50 5.2.2.1 Primeira Versão do Framework............. p. 52 5.2.2.2 Jogo e o Framework................... p. 54 5.2.3 Resultados.............................. p. 56 5.3 Desenvolvimento do Terceiro Protótipo: Tan............... p. 57 5.3.1 Introdução.............................. p. 57 5.3.2 Implementação........................... p. 57 5.3.3 Resultados.............................. p. 62 6 Conclusões p. 64 6.1 Trabalhos Futuros.............................. p. 66 Referências p. 67 Anexo A -- Game Design do Gor p. 69 A.1 Primeiro Conceito.............................. p. 69 A.2 Core Design................................. p. 69 A.2.1 Jogador............................... p. 69 A.2.2 Equipamentos............................ p. 69 A.2.3 Labirinto.............................. p. 70 A.2.4 Jogabilidade............................. p. 70
A.2.5 Evolução............................... p. 70 A.2.6 Monstros.............................. p. 71 A.2.7 Combate............................... p. 71 A.3 Protótipo - Design Detalhado....................... p. 71 A.3.1 Labirinto.............................. p. 71 A.3.2 Jogador............................... p. 72 A.3.3 Objetos............................... p. 72 A.3.4 Monstros.............................. p. 72 A.3.5 Ciclo de Vida do Jogo....................... p. 72 Anexo B -- Diagramas do Gor p. 73 Anexo C -- Game Design do Sky p. 77 C.1 Primeiro Conceito.............................. p. 77 C.2 Core Design................................. p. 77 C.2.1 Pista................................. p. 77 C.2.2 Obstáculos.............................. p. 77 C.2.3 Nave................................. p. 77 C.2.4 Jogabilidade............................. p. 78 C.3 Protótipo - Design Detalhado....................... p. 78 C.3.1 Pista................................. p. 78 C.3.2 Bloco................................. p. 78 C.3.3 Nave................................. p. 79 C.3.4 Ciclo de Vida do Jogo....................... p. 79 Anexo D -- Diagramas do Sky p. 80 Anexo E -- Game Design do Tan p. 85
E.1 Primeiro Conceito.............................. p. 85 E.2 Core Design................................. p. 85 E.2.1 Mapa................................ p. 85 E.2.2 Tanque Jogador........................... p. 85 E.2.3 Tanques inimigos.......................... p. 86 E.2.4 Base................................. p. 86 E.3 Protótipo - Design Detalhado....................... p. 86 E.3.1 Mapa................................ p. 86 E.3.2 Estrutura.............................. p. 86 E.3.3 Tanques............................... p. 87 E.3.4 Tiros................................. p. 87 Anexo F -- Diagramas do Tan p. 88
10 1 Introdução O mercado de jogos atualmente tem movimentado na ordem de bilhões de dólares em todo o mundo, sendo uma boa parte referente apenas aos jogos de celulares. No Brasil a venda de jogos, tanto para celulares, quanto para consoles, já atingiu a ordem de grandeza de centenas de milhões de reais. A tecnologia móvel é uma tecnologia interessante, pois possibilita a indústria de software brasileira alcançar um elevado grau de desenvolvimento devido a complexidade necessária para seu estabelecimento. Devido as suas restrições de recursos reduzidos (processamento, memória e energia) os dispositivos móveis dão suporte a um conjunto de aplicações de pequeno porte, o que permite as pequenas e médias empresas entrarem no mercado, o que seria inviável em relação ao o mercado tradicional de jogos, que já esta bastante estabelecida e tem os orçamentos das grandes produções na ordem milhões. Mesmo os jogos para celulares tendo um tamanho muito inferior aos jogos de desktop, é importante o uso de técnicas de reuso de código como orientação a objetos, componentes e frameworks para reduzir o tempo de desenvolvimento. Além de melhorar a qualidade do código, o tempo extra conseguido com o uso destas tecnologias pode ser utilizado para o refinamento ou adição de novas funcionalidades aos jogos, melhorando sua competitividade no mercado. O uso de frameworks pode não ser uma boa alternativa para plataformas com limitações de hardware, como os celulares, pois consumem preciosos ciclos de execução e memória que poderiam ser utilizados para os jogos. No entanto, a nova geração de aparelhos possui recursos de processamento e memória bem mais abundantes, o que permite o uso de frameworks e(ou) outras técnicas de reuso sem grandes impactos de performance. Assim como aconteceu com os jogos para desktop que já tem definido como padrão o uso de interface gráfica 3D, acredita-se que o mesmo irá ocorrer com os jogos para celulares na medida que os aparelhos tenham maior capacidade de processamento e sejam capazes de realizar o processamento gráfico em hardware.
11 Tendo em vista este contexto e o potencial da área de jogos para celulares, este trabalho tem o intuito de estudar o desenvolvimento de jogos para celulares através do desenvolvimento de um framework para jogos 3D. Para a criação do framework foi utilizada a metodologia de frameworks evolutivos propostos por Don Roberts e Ralph E. Johnson denominada Envolving Frameworks (4). Esta metodologia é um conjunto de padrões que devem ser seguidos para o desenvolvimento do framework. Desse modo o framework foi construído de forma evolutiva durante a criação de três protótipos de jogos, os jogos Gor, Sky e Tan. Estes três protótipos foram gerados especificamente para o desenvolvimento do framework, no entanto, são projetos de jogos reais, que potencialmente poderiam se tornar futuramente jogos comerciais. A plataforma de desenvolvimento para ambiente móvel escolhida para o framework foi a Java Micro Edition(3) utilizando a configuração CLDC 1.1 e perfil MIDP 2.0. Foi utilizado também o pacote Mobile 3D Graphics API for J2ME(3) para o desenho dos gráficos 3D. Esta plataforma foi escolhida por ser uma plataforma completamente livre e já bem aceita no meio acadêmico. 1.1 Objetivos O principal objetivo deste trabalho é desenvolver um framework que seja funcional, mas não necessariamente completo, para o domínio de jogos 3D para ambiente móveis, mais especificamente celulares. A escolha por não criar um framework completo é devido a natureza complexa dos frameworks e as restrições de tempo que torna esta tarefa inviável. A elaboração do trabalho também inclui os seguintes objetivos específicos: Estudar o uso de frameworks, sua vantagens, problemas e metodologias de desenvolvimento; Conhecer algumas das plataformas disponíveis para o ambiente móvel e suas limitações quanto ao desenvolvimento de software em relação ao desktop; Conhecer melhor o universo dos jogos eletrônicos, um pouco da teoria que os envolve e os desafios que podem ser encontrados durante os seus desenvolvimentos.
12 1.2 Organização do Trabalho Este trabalho foi organizado em duas partes, os três primeiros capítulos são dedicados a parte teórica, e o quarto capítulo ao desenvolvimento do framework. O capítulo 2 se refere ao uso e o desenvolvimento de frameworks, seus conceitos e metodologias de desenvolvimento. O capítulo 3 é dedicado ao estudo das plataformas móveis, como aparelhos de celulares e PDA, o desenvolvimento de jogos e o ambiente gráfico 3D para estas plataformas. Já o capítulo 4 aborda os jogos, aonde estão descritas algumas de suas características, desafios e uma descrição sobre Game Design, que é a tarefa de elaboração do jogo. No capítulo 5 o projeto é descrito, desde o desenvolvimento dos jogos até a evolução na construção do framework. Finalizando, este trabalho no capítulo 6 são mostrados as conclusões e os trabalhos futuros.
13 2 Frameworks A informática é uma das áreas que mais cresce mundialmente. O mercado necessita cada vez mais de produtos de software com requisitos cada vez mais complexos. Frameworks é uma das abordagens da Engenharia de Software utilizadas para reduzir o esforço no desenvolvimento e ainda com ganho na sua qualidade. Este capítulo é dedicado a um estudo teórico ao uso e desenvolvimento de frameworks, suas características, desafios, desvantagens e metodologias. 2.1 Introdução Utilizando a idéia básica de nunca refazer uma tarefa duas vezes, adaptando o que já foi produzido as novas necessidades, é que são utilizadas as técnicas de reuso de software(5). Na prática o processo de reuso é uma tarefa complexa, devem ser seguidos alguns princípios durante a construção do código original para que esse possa ser reutilizado posteriormente. Existem diversas formas de fazer um reuso entre diferentes softwares. Uma das primeiras técnicas utilizada foi o uso de bibliotecas de funções para reutilização de algoritmos para controle de estrutura de dados e cálculos matemáticos. Através das funções os códigos mais utilizados passaram a ser reaproveitados, mas ainda a grande maioria do código é necessária ser desenvolvida. Já a orientação a objetos com o conceito de objetos, classe, herança e polimorfismo, permite um novo paradigma de reuso, o reuso passa a ser integrada tanto dos algoritmos quanto das estruturas de dados, o que permite um maior reaproveitamento em relação as funções. Com a orientação a objeto além do reuso de uma classe como um todo através da composição, permite o reuso de forma personalizada através da especialização de uma classe e sobrescrita de seus métodos. Tanto as bibliotecas de funções quanto as de classes focam o reuso do código, no entanto a arquitetura ainda é deixada a cargo dos desenvolvedores. De acordo com (5), a arquitetura do software é a propriedade intelectual principal, e a parte mais difícil de
14 ser criada ou re-criada. Para suprir o reuso de arquiteturas é que são utilizado os padrões de projetos(6). Padrões de projetos são soluções propostas para problemas comuns de arquitetura inseridas em um determinado contexto. Através dos padrões, os programadores podem documentar e repassar suas decisões de projetos. (6) define que um arquiteto de software experiente não resolve cada problema do nada, ele reutiliza soluções que funcionaram no passado. Quando encontra uma boa solução, reutiliza novamente. E é isto o que o torna uma arquiteto experiente. Na busca de classes cada vez mais auto suficientes e com maior facilidade em sua reutilização, nasceu os componentes. Componentes de software seguem a idéia dos componentes eletrônicos(7), para realizar uma tarefa complexa você compra um conjunto de componentes fechados, conectando-os segundo o manual de entradas e saídas de cada componente. Não é necessário saber como um componente funciona, e sim o que ele é capaz de fazer. (8) define componentes de softwares como sendo Instâncias auto-contidas de objetos abstratos que podem ser conectados para formar uma aplicação completa. 2.2 Definição Entre diversas definições de o que é um framework na literatura, citaremos duas delas. De (4) Frameworks são o reuso total ou parcial de arquitetura de um sistema de software descrito por um conjunto de classes abstratas e o modo com que as instâncias destas classes colaboram., o foco desta definição é no reuso da arquitetura. Em (9) Framework é uma aplicação semi-completa reusável que pode ser especializada para a construção de aplicações personalizadas., o termo semicompleta passa a idéia da grande reuso ao utilizar frameworks. Frameworks é a tecnologia que tenta fazer o máximo de reuso possível. Faz o reuso da arquitetura através do controle do fluxo da aplicação, modelo de como as classes se inter-relacionam e a definição de como podem ser adaptadas pelos usuários para a geração de novas aplicações. O reuso de código é feito por suas classes e sua biblioteca de componentes. A fig. 1 ilustra o nível de reuso que pode ser alcançado através do uso de frameworks. A área pontilhada representa o framework, enquanto a área lisa representa as classes implementadas pelo usuário. É importante notar que as classes do framework tem relacionamentos internos, e as classes do usuário são uma pequena porção da aplicação, que foram criadas utilizando a herança.
15 Figura 1: Aplicações e frameworks(1) Além do reuso de código o uso de frameworks também proporciona uma série de outras vantagens. O aumento na qualidade do software desenvolvido, pois os frameworks geralmente são criado por engenheiros de software experientes e especialistas no domínio do problema. Cria também um padrão entre todas as aplicações desenvolvidas com ele. Através deste padrão, é mais fácil para um programador iniciar a manutenção de uma aplicação uma vez que ele já conheça a arquitetura do framework. O reuso de código do framework pela aplicação pode ser realizado basicamente de duas formas. Primeiro através da herança entre classes do framework e aplicação, conhecido como reuso do tipo caixa branca(white-box frameworks)(6). A segunda forma é feito pela composição entre as classes da aplicação e do framework, o reuso pela composição é chamada de reuso do tipo caixa preta(black-box frameworks)(6). Os frameworks que predomina o reuso caixa branca são caracterizados por ter geralmente disponível o código fonte para o usuário. O desenvolvimento da aplicação é feito pela especialização de classes do frameworks e sobrecarga de métodos, que muitas vezes já são pré-definidos pelos desenvolvedores do framework. Mesmo que exista uma documentação para o framework disponível, a maior fonte de informações para os programadores será o código fonte. Nos frameworks com predominância do reuso caixa preta, geralmente o código fonte não é disponibilizado ao usuário. A implementação é feita através da implementação de classes através da implementação de interfaces pré-definidas e pela composição entre componentes do framework. Neste tipo de framework como os desenvolvedores não tem acesso ao código fonte, portanto não podem vê-lo ou altera-lo, o framework deve estar
16 em nível elevado de maturidade e toda a fonte de informação deve ser fornecida via documentação. 2.3 Desenvolvimento de Frameworks Um framework não pode ser genérico o suficiente para gerar qualquer tipo de aplicação, ele deve estar inserido em um domínio específico como interface gráfica, simulação física ou persistência de dados. A abrangência de um domínio também deve ser considerada durante seu desenvolvimento, frameworks com abrangência muito grande tende a ter uma percentagem pequena de aproveitamento, já frameworks mais específicos tem menor possibilidade de serem utilizados. Uma das principais características dos frameworks é a inversão de controle(7), aonde o framework passa a controlar o fluxo de execução do domínio e o código da aplicação é chamado pelo framework. A inversão de controle também é chamada de Principio de Hollywood que significa Não nos procure, nós o procuraremos (8). Enquanto desenvolver softwares complexos já é difícil, desenvolver frameworks de alta qualidade, extensibilidade e reusabilidade para aplicações de domínios complexos é difícil ainda (8). Frameworks devem ser desenvolvidos para serem o mais flexíveis possíveis, pois devem ser capazes de se adaptarem aos mais diversos requisitos, portanto, a grande maioria das necessidades do domínio deverão ser previstas ainda durante seu desenvolvimento, e para as não previstas devem existir alternativas. Assim como desenvolver, a manutenção de frameworks é um processo trabalhoso. Além do próprio funcionamento do framework, devem ser consideradas as implicações que podem ocorrer nas aplicações já desenvolvidas e futuras. Caso a nova versão do framework não seja 100% compatível com as anteriores ou novos problemas tenham sido gerados, testes e correções serão necessários em todas as aplicações já desenvolvidas. No ponto de vista do modelo de negócios de uma empresa, o desenvolvimento de um framework pode não ser comercialmente favorável devido ao seu alto custo de desenvolvimento. O desenvolvimento só vale apena para uma empresa caso o framework seja utilizado em larga escala(10). Testar se um framework está correto e flexível suficiente é um processo difícil, e só pode ser realmente verificado com o desenvolvimento de aplicações finais, e mesmo assim nunca é possível testá-lo completamente(10).
17 2.4 Problemas com uso de Frameworks O uso de frameworks traz uma série de vantagens, mas também um conjunto grande de problemas. Dado um conjunto de frameworks candidatos para o desenvolvimento de uma aplicação, a decisão sobre qual framework melhor se adapta no contexto é um processo difícil, e custa tempo(10). Devido ao reuso resultante do uso de frameworks, pode causar expectativas falsas em relação ao tempo de desenvolvimento da aplicação(10), isso se deve principalmente ao fato de que o programador deve aprender a utilizar o framework antes de começar o desenvolvimento. Utilizar um framework de forma correta é tão essencial quanto desenvolver uma aplicação de forma correta. Em um framework bem feito todas as tarefas comuns em determinado domínio são previstas, a tarefa dos programadores é encontrar estes pontos pré-definidos. Outro problema relacionado com o uso de frameworks está relacionado com a identificação e depuração de erros. É muito mais difícil em aplicações que utilizam frameworks identificar se um determinado erro pertence ao framework ou à aplicação, principalmente quando não se tem acesso ao código fonte do framework. Neste caso, isto acontece devido à inversão de controle aonde o código do usuário é,geralmente, pequenos trechos dispersos em sobrecarga de operadores ou eventos(10). É comum, em frameworks bastante maduros, virem inseridas ferramentas para auxílio à identificação e depuração de código. A integração de diferentes frameworks pode causar muitos problemas. A grande maioria dos frameworks não está preparado para trabalhar de forma integrada. Um exemplo deste problema é a integração de dois frameworks que foram desenvolvidos para ter o total controle sobre o fluxo da aplicação.
2.5 Metodologias de Desenvolvimento de Frameworks 18 Na literatura existem algumas metodologias para o desenvolvimento de frameworks. Nesta seção será descritas as metodologias de desenvolvimento de framework dirigidas por exemplos (exemple-driven design)(11), dirigidas por pontos de flexão (hot spot driven design)(12) e os frameworks evolutivos (envolving frameworks)(4). 2.5.1 Dirigido por exemplos A metodologia de desenvolvimento dirigida por exemplos (11) busca o maior número possível de aplicações já desenvolvidas. Uma análise deve ser feita para identificar quais partes das aplicações são comuns e quais são específicas. As partes comuns devem ser generalizadas de modo que passam a constituir o framework. As partes específicas das aplicações devem ser desenvolvidas na forma de métodos de gatilho (hook). Os métodos de gatilho são um padrão utilizado por uma aplicação ou framework para fazer chamadas para partes de códigos não existentes no seu desenvolvimento. Para verificar se o framework foi bem desenvolvido, deve-se implementar novamente as aplicações exemplos, mas desta vez utilizando o framework desenvolvido como base. Este método é mais indicado quando já se tem as aplicações desenvolvidas (ou esteja disposto a desenvolvê-las). E quanto mais aplicações foram utilizadas como exemplos, mais genérico será o framework. 2.5.2 Dirigido por pontos de flexão Nesta metodologia (12) deve-se dar início ao desenvolvimento da arquitetura e implementação do framework para o domínio específico, e com o intuito de manter o framework flexível deve-se buscar os pontos de flexão (hot spots). Os pontos de flexão são regiões de código especificas de cada aplicação, como métodos de resposta a eventos que tem comportamento diferentes em cada aplicação. Nestes pontos são aplicados diversos padrões para manter o código flexível. Esta metodologia seria melhor utilizada em um contexto em que se deseja desenvolver as aplicações de um determinado domínio, mas antes é desenvolvido um framework para servir como base. Neste caso a implementação das aplicações é o melhor caso de teste.
19 2.5.3 Frameworks Evolutivos Frameworks evolutivos (4) é uma metodologia formada por uma linguagem de padrões que devem ser seguidos durante o desenvolvimento do framework. Os nove padrões propostos servem como um guia de alto nível, para o desenvolvimento de um framework de forma evolutiva. Nenhum destes padrões são obrigatórios ou devem ser seguidos de forma seqüencial. A fig. 2 contem um gráfico com todos os padrões. 1. 3 Exemplos 2. Framework de Caixa Branca 3. Framework de Caixa Preta 4. Biblioteca de Componentes 5. Pontos de Flexão 6. Objetos Conectáveis 7. Objetos Refinados 8. Construtor Visual 9. Ferramentas de Linguagem Figura 2: Gráfico com os padrões pelo tempo
20 2.5.3.1 3 exemplos Este primeiro padrão tenta resolver o problema de como começar o desenvolvimento do framework. Como um framework representa uma abstração de um determinado domínio de aplicação deve-se então buscar um meio de abstrair o domínio. Pessoas desenvolvem abstrações a partir da generalização de exemplos concretos (4). De modo a conseguir os exemplos concretos são desenvolvidas N aplicações exemplos de forma seqüencial, e durante o desenvolvimento de cada nova aplicação o framework é construído. Criado a primeira aplicação exemplo, ela será a base para início do framework e a primeira fonte de informações sobre o domínio. Deve-se planejar o segundo exemplo analisando o primeiro para identificar as partes comuns e distintas. Deve-se então dar início à construção do framework tentando sempre aproveitar o máximo possível do primeiro exemplo, seja criando abstrações das classes do primeiro de modo que faça sentido no segundo exemplo também, ou generalizando de modo que o segundo seja implementado sobre o ele. Tendo a primeira versão do framework e dois exemplos desenvolvidos, o segundo já utilizando o framework, deve-se iniciar um novo ciclo para os próximos exemplos. Mas agora sempre utilizando o framework já criado nas interações anteriores mas aproveitando sempre, na medida do possível as aplicações já desenvolvidas. Um ponto importante é que o framework não pode ser direcionado para a próxima aplicação, e sim generalizado para que dê suporte a outra aplicação. (4) recomenda que devem ser utilizados três exemplos para a criação da primeira versão do framework. Esta escolha se deve ao fato de que uma única aplicação não permite uma visão suficiente do domínio, e um número grande de aplicações exemplos pode causar um atraso muito grande na primeira versão do framework. 2.5.3.2 Frameworks de Caixa Branca Quando dá o início do desenvolvimento do framework, uma das decisões de projeto que deve ser escolhida é entre manter a flexibilidade através do uso de herança e polimorfismo ou via composição de componentes. Este padrão recomenda que inicialmente deve-se tentar apenas fazer o maior proveito possível de código, e provavelmente as informações adquiridas até o momento não são suficientes para decidir quais partes serão constantes, e quais variáveis. Portanto, deve-se construir o framework através do reuso do tipo caixa branca e conseguir a flexibilidade através da herança.
21 2.5.3.3 Biblioteca de Componentes Durante o desenvolvimento das aplicações a partir do framework é necessário as vezes implementar os mesmos componentes para problemas distintos, e de alguma forma esses componentes não participam do domínio do framework. Exemplos de componentes comuns são os utilitários ou repetição das mesmas implementações de certas super classes do framework. Para eliminar a reescrita destes componentes deve-se criar então uma biblioteca com componentes concretos e disponibiliza-lo junto com o framework, para o caso dela ser necessária. Deve-se iniciar apenas com os componentes mais óbvios e na medida em que for sendo necessário, adiciona novos componentes. E a medida que componentes da biblioteca deixem de ser utilizados, eles devem ser removidos. 2.5.3.4 Pontos de flexão Durante o desenvolvimento das aplicações é possível identificar que certos trechos são editados com muita freqüência. Estes trechos de código são identificados como os pontos de flexão (hot spots). Caso estes pontos estejam muito espalhados pela aplicação, a identificação destes pontos e sua manutenção se torna um processo muito trabalhosos. O padrão recomenda que os pontos de flexão devam ser separado do código, preferencialmente encapsulados por objetos. Separar o código que varia para um objetos além de facilitar o reuso, também facilita para o os usuários do framework saibam qual código deve ser alterado. 2.5.3.5 Objetos Conectáveis Algumas vezes é necessário estender classes do framework para realizar pequenas alterações de código ou no valores de variáveis. Deve-se então criar então uma sub classe especializada que seja capaz de ser configurada através de parâmetros. Esta nova classe é um perfeito candidato para sua biblioteca de componentes. 2.5.3.6 Objetos Refinados Durante a evolução do framework, diversos novos componentes serão inseridos na biblioteca. Para aumentar a quantidade de reuso da biblioteca de componentes e eliminar algumas redundâncias de implementações, deve ser realizada uma fatoração dos componentes. A fatoração deve dividir os componentes da biblioteca em componentes menores, que poderão ser reconstituídos através da composição. O padrão alerta que os
22 componentes devem ser fatorados até que uma outra fatoração resulte em um componente individualmente sem sentido. 2.5.3.7 Framework de Caixa Preta Após muito uso do framework, talvez os desenvolvedores queiram evoluir o framework para o tipo caixa preta. Este tipo de framework faz o uso intenso da composição, conectando componentes para a integração do framework com a aplicação. As vantagens da composição sobre a herança é que ela pode ser alterada durante o tempo de execução e necessita um menor entendimento dos usuários sobre classes do framework, já que para resolver o problema basta implementar um componentes especifico e agregar ao framework. Para a implementação deste padrão, recomenda-se utilizar a herança para organização interna do framework e da biblioteca de componentes, e usar a composição para integrar com aplicação. Para as classes do usuário a parte mutável deve ser removida do framework e deve ser colocada em classes ou interfaces que devem ser implementadas pelos usuários. 2.5.3.8 Construtor Visual Quando se tem um framework do tipo caixa preta já maduro, é possível construir aplicações simplesmente através da composição de componentes já pré-definidos na biblioteca, necessitando muito pouco código. A parte mais difícil do desenvolvimento passa a ser o entendimento dos componentes e como conectá-los. O padrão propõe a construção de um script responsável pela conexão e inicialização dos componentes. Uma aplicação gráfica seria responsável pela criação destes scripts para geração do código do framework. A criação visual é muito mais rápida e precisa de menos esforço no conhecimento do framework, além de que o usuário não precisa necessariamente ser um programador. 2.5.3.9 Ferramentas de Linguagens A construção visual através de uma aplicação gráfica traz uma série de vantagens por desassociar o framework da linguagem de programação em que foi desenvolvido. Em compensação devido a este mesmo motivo a verificação e depuração dos componentes altamente compostos e criados em tão alto nível é uma tarefa difícil. Devem ser desenvolvidas ferramentas com este objetivo pelo menos para as regiões mais complexas do framework.
23 2.6 Documentação É possível tirar todas as vantagens do reuso de um framework apenas quando os usuários tem pleno conhecimento sobre o funcionamento do mesmo. Portanto a documentação é essencial no processo de desenvolvimento do framework. (13) descreve o uso de padrões para a documentação de frameworks, e cita que uma documentação deve cobrir três objetivos básicos sobre o framework: seu propósito, como utilizá-lo e uma visão detalhada de sua arquitetura. O propósito do framework deve ser escrito de forma curta e clara, deve ser destinado aos usuários que ainda não tem conhecimento algum sobre o framework. Deve descrever os pontos fortes e fracos, e outras informações importantes para que o leitor possa ponderar em utilizar ou não o framework. Deve ser curto o suficiente para ser utilizado como resultado de uma busca ou em um catálogo. O documento que descreve como utilizar o framework se destina a usuários novos e antigos, que precisam resolver um determinado problema utilizando o framework. Geralmente são leitores com pressa e que querem apenas a solução, não importa o como. Este tipo de leitor se encaixa perfeitamente em documentos do tipo livros de receita (cookbook), e deve ser escrito desta forma. Livros de receitas são basicamente descrições de passos a serem seguidos para alcançar determinado objetivos, sem muita descrição do porquê e como de cada passo. Estes tipos de documentos podem ser escritos utilizando-se padrões, apenas invertendo o foco de um objetivo a ser alcançado, por um problema a ser resolvido. O detalhamento da arquitetura do framework é direcionado para os próprios desenvolvedores do framework ou para usuários avançados, que precisam resolver problemas não triviais não descritos no documento de uso do framework. Deve descrever suas classes e como suas instâncias interagem. Diagramas de classe e colaboração na medida do possível devem ser inseridos nestes documentos. Caso um framework tenha disponível seu código fonte, ele será parte desta documentação, mas de forma separada. (13) cita ainda que um importante auxílio na documentação de frameworks são os exemplos. Exemplos são a forma mais direta de se entender o problema e a solução de uma forma real, exemplos e podem ser usado pelos usuários como laboratório para realizar alterações de experiência. Devem ser utilizados na medida do possível no documento de como utilizar o framework. Exemplos de aplicações completas também são uma fonte de informações muito útil, além de servir de teste para o framework, permite aos novos usuários entenderem o framework como um todo.
24 2.7 Testes Implementar aplicações completas e com sucesso é a melhor forma de testar um framework, permite verificar tanto a corretude dos algoritmos quanto a flexibilidade para as novas funcionalidades da aplicação. A não ser que o framework seja vendido para terceiros, não serão necessários testes maiores que pequenos exemplos para testar as funcionalidades do sistema. Os testes reais serão realizados durante a utilização do framework, e continuamente ele deverá ser adaptado para se tornar mais flexível.
25 3 Plataforma Móvel Neste capítulo contem o estudo sobre os dispositivos móveis e suas plataformas. Na introdução é mostrado rapidamente o surgimento dos celulares e jogos, posteriormente é apresentada algumas das plataformas mais comuns no mercado, em seguida algumas das características e restrições no desenvolvimento para móvel. Fechando, algumas das tecnologias existentes para geração gráfica 3D também para móvel. 3.1 Introdução A primeira geração de celulares foi na década de 1980, estes aparelhos eram uma evolução dos telefones instalados nos automóveis de luxo. Eram aparelhos sem poder de processamento e com transmissão analógica. Já a segunda geração de celulares, conhecido como 2G, começou na década de 90. Foram diversos os padrões de comunicação digital criados, entre eles o GSM (Global System for Mobile Communications) que é o padrão mais utilizado mundialmente. Os aparelhos tem evoluído muito e a cada dia que passa se parecem mais com os microcomputadores. A capacidade de processamento dos aparelhos mais novos hoje produzidos é comparado aos microcomputadores no final da 90. Algumas das tecnologias hoje disponíveis nos celulares(14): Gravação/Leitura de áudio e vídeo; Bluetooth: comunicação de curta distância entre aparelhos de alta velocidade; WAP (Wireless Application Protocol): Navegação na internet; DRM (Digital Rights Management): Baixar arquivos para o aparelho através da rede; SMS (Short Message Service): Envio de mensagens;
26 MMS(Multimedia Messaging Service): Envio de arquivos multimídia como imagens e vídeos; Web Services: Padrão para comunicação entre aplicações de diferentes plataformas via rede; GPS (Global Positioning System): Localizar a posição física do aparelho no mundo; Java: Rodar aplicações em java. Quanto aos jogos para celulares a pioneira no ramo foi a empresa Nokia em 97 com o jogo Snake. O jogo foi inserido no aparelho como um passa tempo, devido a sua grande popularidade a empresa passou a comprar novos jogos para seus aparelhos. O explosão no mercado de jogos para celulares apenas aconteceu em 2001 quando os novos aparelhos passaram a ter a funcionalidade de fazer o downloads dos aplicativos direto da rede, entre eles os jogos. O que possibilitou aos usuários adquirirem novos aplicativos, diferentes daqueles já instalados pelos fabricantes. Este novo mercado foi uma grande oportunidade para os pequenos desenvolvedores de jogos. É difícil atualmente para uma empresa nova entrar no mercado de jogos, devido a complexidade e a grande quantidade de tecnologias envolvidas (ver capítulo 4.3). Entretanto, para os jogos em dispositivos móveis devido as limitações de hardware, os jogos das pequenas empresas podem competir com as grandes de maneira mais justa. 3.2 Plataformas e Portabilidade A explosão no mercado de celulares também trouxe um grande problema para os desenvolvedores. Com uma dezena de fabricantes e centenas de aparelhos disponíveis, criou-se uma heterogeneidade de ambientes de desenvolvimento. Existe uma grande diferença de recursos disponíveis, quantidade de memória e velocidade de processamento e linguagens suportadas. A implementação direta sobre o hardware dos aparelhos é uma tarefa com custos muito alto para aplicações genéricas. A solução adotada é inserir uma plataforma sobre o hardware para minimizar as diferenças. Destas plataformas as mais comuns são: Symbian OS; Brew;
27 J2ME; Exen. 3.2.1 Symbian OS O Symbian OS é um sistema operacional completo, sua versão para dispositivos móveis com contém bibliotecas, framework para interface com usuário e ferramentas de auxilio. Este sistema operacional tem suporte a multi tarefa preemptivas, multi-thread e proteção de memória. Uma das grandes qualidades deste sistema operacional é a gerência de memória que utiliza técnicas para reduzir o uso de memória e vazamentos. As aplicações são desenvolvidas em C++. 3.2.2 Brew Brew (Binary Runtime Environment for Wireless)(2) é uma plataforma desenvolvida pela Qualcomm que roda sobre o sistema operacional, tem como principal objetivo minimizar as diferenças entre aparelhos disponibilizando aos desenvolvedores uma API sólida e comum. O Brew suporta aplicações tanto em C como em C++ que rodam de forma nativa. Para disponibilizar os aplicativos nesta plataforma deve ser utilizado o modelo de negócios próprio da Qualcomm, que faz conexão direta entre os desenvolvedores e a operadora. Na fig. 3 pode ser visto a arquitetura da API BREW e os diversos tipos de aplicação e serviços que ela disponibiliza. Figura 3: Aquitetura Brew(2)
28 3.2.3 J2ME O J2ME (Java 2 Micro Edition)(3) é um conjunto de APIs simplificada da versão J2SE (Java 2 Standard Edition) para dispositivos com baixos recursos de hardware. Geralmente a máquina virtual é implementada pelos próprios fabricantes dos aparelhos utilizando as especificações da SUN. As aplicações escritas em java para a J2ME são chamadas de MIDlets. Figura 4: Arquitetura do J2ME(3) Como pode ser visto na fig. 4 a arquitetura do J2ME é dividida em três partes. A primeira mais inferior é o sistema operacional do próprio aparelho. A segunda parte, a configuração é composta pela maquina virtual, que tem a responsabilidade de encapsular o sistema operacional disponibilizando uma interface comum. A linguagem J2ME que é o código compilado a partir dos fontes Java. As bibliotecas são o conjunto de classes mínimas com as API disponível para as aplicações. A configuração pode ser diferente dependendo do aparelho, elas definem os requisitos mínimos, e estão divididas em duas categorias dependendo da quantidade de memória disponível, velocidade e tipo de processador. A máquina virtual e um conjunto de bibliotecas fazem parte da configuração. CLDC (Connected Limited Device Configuration): para processadores 16 e 32 bits com no mínimo de 160kb de memória. A versão 1.0 limita a maquina virtual, configuração, profile, pacotes opcionais e aplicação em até 512kb. Já na versão 1.1, o limite é a quantidade de memória disponível.
29 CDC (Connected Device Configuration): Para equipamentos mais rápidos que o CLDC com o mínimo de memória de 2Mb. Geralmente são processadores 32 bits. Já a parte mais superior da arquitetura estão os perfis, são um complemento às configurações para tornar o ambiente completo para a execução de aplicações, contem um conjunto de classes de apoio mas não essenciais para a execução das aplicações. O MIDP (Mobile Information Device Profile) é o perfil desenvolvida para os celulares e PDAs e roda sobre a configuração CLDC. Fornece em sua API para as aplicações com interface com usuário, acesso a rede e persistência e acesso a funções especificas dos aparelhos. O MIDP também existe em duas versões, 1.0 e 2.0. A segunda versão cumpre o seguinte escopo: Entrega e faturamento de aplicações; Ciclo de vida da aplicação; Modelo para certificar aplicações e privilégios; Transferência segura de fim-a-fim através do HTTPS; MIDlet push registration, inicializar aplicações sem interação do usuário; Acesso a rede; Persistência de dados; Som; Timers; Interface com usuários (inclusive um pacote para jogos). Este modelo de arquitetura permite ainda a alguns dispositivos agregarem em seu produto ainda outros pacotes opcionais que entendem as configurações CLDC e CDC. Estes pacotes trazem novas funcionalidades para as aplicações, e geralmente estão agregados a alguma funcionalidade especifica do hardware. Alguns exemplos de pacotes opcionais são os web services, arquivos de mídia, conexão com banco de dados, mensagens e gráficos 3d. A fig. 5 permite visualizar toda a plataforma J2ME como um todo, com suas configurações, perfis e pacotes opcionais
30 Figura 5: Configurações, perfis e pacotes opcionais. Apesar da proposta da Sun de desenvolver uma plataforma uniforme para o desenvolvimento, devido a má implementação das maquinas virtuais pelas empresas de fabricação dos aparelhos, é comum durante a migração para um aparelho diferente ocorrer uma série de problemas. Uma amostra deste problema é um estudo de caso realizado UFPE(15) de portar um jogo desenvolvido em J2ME no aparelho T720 da Motorola para os da série 60 da Nokia. Mesmo a linguagem java seguir o padrão Write once, run everywhere (escreva uma vez, rode em todo lugar) foram necessárias 79 alterações no código, com uma média de 2 linhas alteradas por modificação. 3.2.4 Exen Exen ou Execution Engine foi a primeira plataforma exclusiva para a execução de jogos. Esta plataforma roda aplicativos java e por ter sua API implementada em código nativo do aparelho sua máquina virtual é muito mais rápida. No entanto esta plataforma esta disponível em apenas para aparelhos de algumas operadoras na europa.
31 3.3 Desenvolvimento de Jogos para Móveis Para a implementação de aplicações, mais especificamente os jogos, tem um série de características e desafios quando desenvolvidas para dispositivos móveis. Nesta seção serão descritas algumas destas características. Em relação ao hardware temos os seguintes características: Baixo poder de processamento; Pouca quantidade de memória e com baixa velocidade de acesso; Pouco espaço em disco; Baixa velocidade de transmissão pela rede; Energia por tempo limitado; Diversos fatores relacionados a usuabilidade: tamanho da tela, resposta de botões, som... Ausência de ponto flutuantes. Em relação ao ao software, temos as seguintes características: APIs reduzidas; Limite no tamanho das aplicações; Número de aplicações em execução; Limitações no uso de ponto flutuante (implementado via software); Testes exaustivos para não danificar o software do aparelho; Uma série de eventos devem ser tratados como: falta de energia, número de arquivos abertos e chamadas telefônicas. Estas características estão relacionadas a todas as etapas do desenvolvimento do jogo, deste o game design4.4 do jogo até os testes. Durante o design do jogo, os designers tem que ter em mente que não existe memória e nem processamento de sobra, portanto apenas as funcionalidades essenciais devem estar presentes. Jogos de ação que exigem muitos
32 reflexos também não são apropriados, devido a baixa taxa de quadros dos aparelhos e má disposição e resposta do teclado. Durante a fase de desenvolvimento deve existir uma etapa de otimização de código aonde deve-se otimizar os pontos no programa com maior consumo de processamento e(ou) memória. A otimização é um processo muito importante pois além do o jogo ficar mais leve, o espaço liberado pode ser utilizado para adicionar novas funcionalidades do jogo. A fase de testes pode ser considerada a fase mais importante de todo o processo de desenvolvimento de jogos, pelo menos do ponto de vista das operadoras. O ciclo de vida comum de um jogo em celulares é o download, a instalação, a execução, a desinstalação e a deleção. Todas estas etapas devem funcionar corretamente em diferentes aparelhos e considerando uma série de eventos já citados anteriormente. Como o usuário não tem acesso direto ao sistema operacional, qualquer operação de manutenção em um aparelho destes é trabalhosa e caro. No modelo de negócios da Brew por exemplo, o jogo para poder ser disponibilizado para download deve passar pelos testes de empresas autorizadas pela Brew, que é pago por teste. Os testes são muito rigorosos e dependendo do caso pode atrasar o lançamento do jogo em vários meses. 3.3.1 Gráficos 3D A utilização de gráficos 3D nos jogos a muito tempo já se tornou um padrão para os jogos de PC e consoles. Para plataforma móvel os jogos 3D ainda são poucos em comparação com os 2D, no entanto, é certo que este cenário se inverta a medida que o processamento destes aparelho cresça. Como o framework será desenvolvido para jogos 3D, nesta seção são apresentados algumas das tecnologias 3D para dispositivos móveis. Basicamente existem dois modos diferentes de se desenhar objetos 3D, o primeiro é utilizando uma API de acesso hardware de aceleração 3D como OpenGL ES(16). A outra é realizando todas as transformações via software e desenhando em uma imagem 2D. Apesar da especificação de OpenGL ES já estar em sua versão 2.0 ainda são poucos os aparelhos celulares que tem esta funcionalidade, uma vez que é uma API para acesso a uma placa de vídeo em hardware. Por isto a grande maioria dos jogos e aplicativos 3D necessitam utilizar bibliotecas e frameworks que realizam todo o processamento via software. OpenGL ES(16) X-Forge 2(17)
33 M3G(3) 3.3.1.1 OpenGL ES OpenGL ES(16) é uma API inter plataforma, livre de royalty, com plena funcionalidade de aceleração 2D e 3D para dispositivos móveis. Ela foi desenvolvida a partir de um consórcio entre empresas de software e hardware. Algumas empresas participantes desde consórcio são: ARM, ATI, Nokia, Motorola, Intel, NVIDIA, Sony e Sun(16). Ela utiliza como base a já consagrada API OpenGL e sofreu uma série de alterações para poder dar suporte a aparelhos com baixos recursos de hardware. Foram removido funcionalidades computacionalmente caras, redundantes ou inúteis para ambiente móvel. A API utiliza a idéia de perfis e extensões que permitem a alguns aparelhos terem recursos a mais como shaders ou acessar otimizações dependentes de hardware. 3.3.1.2 X-Forge 2 X-Forge 2(17) é um motor para desenvolvimento de jogos 3D com um grande número de ferramentas. Os jogos são desenvolvidos em um ambiente próprio independente de plataforma e que engloba não apenas a programação, mas a parte artística do desenvolvimento. O motor foi desenvolvido de forma modular e permite a inserção e remoção de diversos pacotes, como por exemplo o pacote para gênero de jogos de corrida. O motor utiliza uma arquitetura de duas camadas, a primeira é responsável por criar a API indepedente de plataforma para a segunda. Já a segunda camada é composta pelo motor de jogos 3D. 3.3.1.3 M3G M3G(3) (A Mobile 3D Graphics API for J2ME é a versão de java 3D para dispositivos móveis é a especificação número 184 da JSR (Java Specification Requests) realizado pelo Java Community Process (JCP). O JCP é uma comunidade de empresas interessadas em decidir o futuro da linguagem java. No caso da 184, o Expert Group, como são chamados os envolvidos no desenvolvimento de uma JSR, contem dezenas de empresas e entre elas a Nokia, Motorola, ARM, Intel, Siemens, Sony e Sun. Assim como o OpenGL ES é um subconjunto de funcionalidades do OpenGL, o mesmo ocorre com M3G em relação ao J3D (Java 3D). M3G é um pacote do tipo opcional e foi
34 desenvolvido para J2ME/CLDC com perfil MIDP 1.0 ou 2.0. Para se ter uma idéia do funcionamento e das limitações abaixo esta listado os requisitos declarados na especificação do JSR 184: Suportar acesso via modo retained, deixando as tarefas de desenho para a API; Suportar acesso via modo immediate, o usuário deve fazer chamadas a API para que objetos sejam desenhados; Suportar uma mistura dos dois tipos de acessos, retained e immediate; Todos os métodos da especificação devem estar implementados; Deve importar meshes, texturas e grafos de cena; Deve ser capaz de ser implementada eficientemente sobre o OpenGL ES; Deve usar a variável float e introduzir novos tipos de variáveis básicas; Deve ser implementada de forma eficiente mesmo sem calculo de ponto flutuante em hardware; Recomenda-se que o consumo de memória deve ser inferior a 150kb; Deve estar estruturada de tal forma que coletor de lixo funcione de forma eficiente; Deve operar com outras APIs java. A API utiliza grafos de cena para a composição das imagens 3D. Para a criação do grafo de cena diferentes objetos como luzes, câmeras, modelos 3d, transformações geométricas, materiais, são conectados em forma de arvore. A API então utiliza este grafo para realizar otimizações e desenhar a na tela.
35 4 Jogos Como o domínio do framework desenvolvimento neste trabalho se trata de jogos, neste capítulo é apresentando alguns dos temas relacionados com os jogos. Primeiro é feito uma introdução sobre mercado de jogos, posteriormente é mostrado uma classificação informal quanto os tipos de jogos, em seguida algumas das características relacionadas ao desenvolvimento de jogos. Por fim, uma descrição das parte de um game design. 4.1 Introdução Os jogos eletrônicos são um meio de entretenimento muito difundido, estão disponíveis nos mais diversos aparelhos e nos mais diversos estilos. De acordo com uma pesquisa feita pela Entertainment Software Association nos Estados Unidos(18), 50% dos americanos jogam jogos eletrônicos. Destes apenas 35% são menores de 18 anos, a média de idade de 35 anos. Em média os jogadores gastam cerca de 1h por dia. Outro dado interessante é que os jogadores gastam mais que o triplo do tempo jogando do que praticando esportes, se dedicando a trabalhos voluntários, atividades religiosas, atividades culturais ou lendo. O mercado de jogos eletrônicos movimentou US$ 28 bilhões em todo o mundo em 2003(19), e que desde 2003 superou o mercado cinematográfico (18). Uma das principais características dos jogos é a interatividade. Ao contrário de um livro ou um filme, o jogador tem o poder de alterar o rumo da história, que muitas vezes depende do conhecimento do jogador sobre o jogo, e o assunto por ele tratado. Muitos passam muito mais do que as 7h médias semanais, algums mais criativos descobriram maneiras de ganhar dinheiro real sem sair do mundo virtual. Um caso famoso foi no jogo Project Entropia aonde uma estação espacial virtual foi comercializada entre dois usuário por 100 mil dólares(20).
36 4.2 Tipos de Jogos Jogos são lançados quase que diariamente, e graças ao avanço da internet os lançamentos são em escala mundial, sejam eles de grandes empresas, pequenas ou desenvolvedores independentes. A variedade de jogos hoje disponíveis no mercado é suficiente para todos os tipos e gostos. Para se entender melhor a vastidão dos jogos, abaixo serão descritos alguns tipos em relação a diferentes categorias. Quanto a tecnologia de interface gráfica utilizada: Textual: Estes jogos foram muito comuns até o lançamento das placas de vídeos e monitores gráficos. Alguns são como livros com pequenos problemas de lógica que precisam ser resolvidos para continuar, outro mais interativos e até com desenhos utilizando caracteres especiais. 2D: Estes jogos são formados por imagens retangulares sobrepostas, fazem grande uso de transparência. É a categoria que tem o maior número de jogos. Este tipo de interface para jogos em hardwares com abundância de memória e processamento já é considerada obsoleta, mas ainda é muito utilizada em jogos mais simples ou de baixo processamento. 3D: Utilizam modelos 3D e textura para composição das cenas, teve grande popularização graças às placas de vídeo 3D que existem no mercado. Quase sem exceção todas as grandes produções para microcomputadores são hoje desenvolvidas com esta tecnologia. Quanto ao modo de visualização do mundo pelo jogador: Primeira Pessoa: O jogador tem a visão como se fosse o personagem, e vê com seus próprios olhos. Este estilo é muito comum utilizando a tecnologia 3D, mas muitos bons jogos em primeira pessoa foram criados em 2D e mesmo em modo texto. Terceira Pessoa: Aqui a visão do jogador é como uma câmera flutuante que segue o personagem aonde ele for, geralmente mantendo uma certa distância. Visão de Deus: Este tipo o jogador tem uma visão do todo, ou aérea do mundo. É o tipo mais utilizado principalmente pelos jogos de interface 2D. Quanto ao estilo do jogo:
37 Ação: Talvez o mais genérico dos gêneros. Estes jogos tem como objetivo estimular os reflexos do jogador, muitos passam a sensação de perigo e fixam o jogador em não tirar os olhos sobre o monitor. Aventura: São jogos geralmente com uma história linear, aonde o personagem tem de cumprir objetivos e resolver quebra cabeças para tentar alcançar o final da história. Geralmente é o gênero que traz histórias mais criativas e elaboradas. Tiro: São jogos de ação em primeira pessoa, normalmente caracterizados por atirar em quem aparecer em sua frente. Salvo algumas exceções. Esporte: Estes jogos tentam simular partidas reais como de futebol ou basquete. Na grande maioria o jogador fica responsável por controlar os jogadores de um time, mas há também aqueles aonde o jogador controla apenas o técnico e que deve gerenciar uma equipe. Estratégia: São jogos em que bombardeiam o jogador com uma série de citações em que ele deve tomar decisões, a soma de suas escolhas é que resulta no sucesso ou fracasso no jogo. Simuladores: Jogos que fazem simulações de coisas reais, os mais comuns são os simuladores de carros ou de aviões. Muitos destes jogos implementam uma simulação físicas altamente realistas e são utilizados para treinamentos para uso real. RPG (Role Play Gaming): Seguindo os RPG tradicionais, o jogador assume o papel de personagem, ele deve tomar decisões através de uma história. Os personagens geralmente evoluem com o passar do tempo, adquirindo novos poderes e características. Luta: Muito popular nos arcades este tipo de jogos simula a briga entre dois ou mais personagens. São jogos geralmente violentos e competitivos, fazem grande uso dos reflexos. Educacional: São jogos desenvolvidos não apenas para entretenimento, mas como principal objetivo ensinar alguma coisa a seus jogadores. Jogos infantis para ensino da matemática e simuladores aéreos para treinamento de pilotos também entram nesta categoria. Puzzle: Puzzles são desafios lógicos, são muito usados como passatempo. Cartas: São jogos que simulam jogos de cartas reais como canastra ou poker.
38 Quanto ao número de jogadores podemos definir em 3 categorias: Um jogador: Apenas é possível um jogador por vez, todo o resto é controlado pelo computador. Alguns destes jogos são desenvolvidos com técnicas avançadas de inteligência artificial. Em grupo: Geralmente entre 2 a 100 jogadores, geralmente são dividos em grupos e competem entre si. Massivo: Estes jogos são caracterizados por mais de 500 jogadores simultâneos, gerenciado por grandes servidores. Estes jogos são geralmente persistentes e as escolhas dos jogadores em um partida podem ter conseqüências para os outros jogadores ou para o universo do jogo para sempre. Pode-se dividir ainda os jogos em outras duas grande categorias, os jogos em turnos e em tempo real. O primeiro é caracterizado por pouca ação, as respostas acontecem a eventos do usuário e a parte do processamento é deixada para uma tela de espera entre os turnos ou no final do turno dos jogadores. No segundo caso, os jogos em tempo real, o processamento do jogo é realizado em pequenas etapas várias vezes por segundo, durante cada processamento deve ser realizado a simulação física e colisões, inteligência artificial, e atualização da tela. 4.3 Características no Desenvolvimento de Jogos Jogos é um tópico interessante na área da computação por abordar o estudo em várias ciências, técnicas e não técnicas. Apesar de um jogo ser um software e depender das técnicas de desenvolvimento e programadores, o sucesso de um jogo está baseado muito em sua concepção Algumas das áreas utilizadas atualmente para o projeto e desenvolvimento dos jogos: Computação Gráfica: Objetos animados em 3D, sombras volumétricas e reflexos são algumas das tarefas responsáveis pela computação gráfica, e deve ser efetuada dezenas de vezes por segundo. Gráficos realistas e bonitos são os principais chamariz dos jogos, graças às novas gerações de placas de vídeo 3D. Inteligência Artificial: Em jogos de um único jogador, a interação se baseia completamente em ações tomadas pelo computador, e este deve atuar de forma inteligente que mostre realismo e desafie o jogador.
39 Arte: Imagens são utilizadas para texturas de modelos 3d e para a composição da interface de usuário. De modo mais indireto todo o trabalho de arte envolvido na concepção do jogo, arquitetura do ambiente de jogo, roupas e os próprios personagens são alguns exemplos. Comunicação de Dados: Certamente os jogos aonde a comunicação de dados é mais visível são os jogos MMO (Massive Multiplayer On-line) aonde seus servidores devem gerenciar um mundo completo com milhares de personagens, cada qual controlado por um jogador em um local físico distinto. O jogo World of Warcraft por exemplo tem mais de 1.5 milhões de usuários cadastrados. Simulação: Grande quantidade dos jogos desenvolvidos hoje são na verdades simuladores em tempo real. Bibliotecas físicas são capaz de simular em tempo real a dinâmica de corpos rígidos, roupas, líqüidos e partículas. Usabilidade: Muitos bons jogos se tornaram um completo fracasso devido a dificuldade de novos jogadores se adaptarem ao jogo. Navegar em ambientes 3D, gerenciar centenas de unidades ou controlar dezenas de cidades são algumas das tarefas realizadas pelos jogadores e deve ser da forma mais intuitiva possível. Som: Efeitos sonoros e músicas são fundamentais para a imersão dos jogadores no universo do jogo. Enquanto as músicas criam o clima necessário em cada ato, o efeitos sonoros criam maior realidade no que se vê na tela. Todas as áreas citadas anteriormente estão diretamente relacionadas ao desenvolvimento de parte do software. Mas outras áreas distantes da Ciências da Computação também são utilizadas durante o planejamento. Jogos devem ter um história interessante, personagens com personalidades e um universo realista. Para definir estes elementos é necessário utilizar outras áreas de pesquisa, por exemplo a psicologia, fotografia, história e estratégia. Outro grande desafio no desenvolvimento de jogos é que como todo o tipo de entretenimento ele deve ser acima de tudo divertido. Isso quer dizer que mesmo que façamos tudo corretamente, ainda corremos o risco de criar um jogo chato. Para evitar isso além do bom senso as empresas utilizam grandes equipes de testes, fórum para comunicação com os jogadores e lançamento de versões alphas e betas para grupos restritos de usuários. As equipes de desenvolvimento de jogos geralmente são bastante heterogêneas, os programadores devem trabalhar integrado com profissionais de outras áreas, e muitas
40 vezes são minoria. Para se ter uma idéia o StarCraft, jogo de grande sucesso da Blizzard Entertainment, teve 53 pessoas na gerência, atividades comerciais e design do jogo, 108 em arte, 51 nos testes e apenas 16 pessoas envolvidas na programação. 4.4 Game Design O game design 1 de um jogo é a etapa onde deve ser elaborado o jogo, sua histórica, contexto, regras, características, objetivos, personagens, etc. Deve ser realizado antes de qualquer tarefa relacionada com o desenvolvimento do software. O processo de concepção do jogo através do game design deve gerar uma série de documentos que serão utilizados posteriormente pela equipe de produção para o desenvolvimento do software, geração das imagens, modelos, sons e markenting. Já os Game Designers são as pessoas responsáveis pela elaboração do conceito do jogo e suas regras. São eles que ditam o que deve ser programado, modelado ou as imagens geradas pelas outras equipes. Os Game Designers também são responsável pela palavra final em aprovar o que é desenvolvido para o jogo, eles funcionam como uma espécie de diretor na indústria cinematográfica. Para detalhar melhor o game design e os produtos gerados será descrito de forma rápida as etapas descritas no livro (21). Primeiro Conceito Core Design Jogabilidade Design Detalhado Equilíbrio do Jogo Interfaces de Entrada e Saída 4.4.1 Primeiro Conceito Nesta etapa é que a primeira idéia deve ser trabalhada e documentada. Sem se preocupar com qualquer barreira que possa impedir o desenvolvimento do jogo, deve-se 1 Não se trata da fase de design de um ciclo de desenvolvimento de software, e sim da etapa de elaboração do jogo como conceito.
41 elaborar e documentar todas as características desejadas para o jogo. Descrever de forma rápida como seria as principais partes do jogo, quais as decisões que necessitariam ser tomadas pelos jogadores e as razões que tornariam o jogo legal. Este documento serve para vender a idéia a equipe, além de também ser muito útil para a equipe de marketing e conseguir investidores. Mesmo que este primeiro conceito não seja aprovado por não ser atrativo, financeiramente ou computacionalmente inviável, por se tratar de um documento escrito ele pode ser arquivado e não se perde na memória de seu criador. 4.4.2 Core Design Nesta fase será elaborado a primeira especificação do jogo, deve estar focada no jogo independente da plataforma que será desenvolvida, como: celular, computador ou mesmo em um tabuleiro. Aqui todos os componentes do jogo devem ser elaborados e devidamente documentos. Deve ser utilizado o documento gerado do primeiro conceito para selecionar quais as características desejadas serão utilizadas no jogo. Também pode ser interessante a geração de protótipos. Entre os componentes do jogo que serão elaborados nesta etapa são: O personagem; Contexto em que jogo estará inserido; História e seu desenrolar; Os objetivos; A interface de como o jogador interage com o jogo; A jogabilidade e as decisões que necessitarão ser tomadas pelo o jogador; As fases do jogo e como elas podem alterar a jogabilidade; 4.4.3 Jogabilidade Jogabilidade se refere basicamente às decisões que devem ser tomadas pelo jogador, as possibilidades devem ser interessantes e não triviais. Eles devem ter a possibilidade de tentar diferentes alternativas e tirar suas próprias conclusões sobre qual alternativa é
42 melhor em determinado contexto. As regras devem ser definidas de forma concreta, que já possam ser testas e equilibradas. 4.4.4 Design Detalhado Durante a etapa do Design Detalhado o Core Design será detalhado de forma que possa ser implementado em software. O documento resultante desta fase deve ser completo o suficiente para ser utilizado pelos programadores para a análise de requisitos. Este etapa é diferente da etapa de analise de um ciclo de desenvolvimento de software, aqui não pensamos em componentes de software como objetos, classes, estruturas ou algoritmos. Estes componentes apenas serão gerados posteriormente pela equipe de produção após uma analise sobre estes documentos. 4.4.5 Equilíbrio do Jogo Já durante o desenvolvimento das primeiras versões do jogo as regras devem ser novamente testadas com objetivo de verificar seu equilíbrio. O equilíbrio é fundamental para um jogo uma vez que descoberto uma falha que possibilite um jogador tomar vantagem sobre o outro, o jogo perde a capacidade do jogador explorar suas alternativas. Além dos testes manuais pode ser utilizado simulações que busquem exaustivamente falhas no equilíbrio do jogo. 4.4.6 Interfaces de Entrada e Saída Nesta etapa será realizado um polimento geral no jogo quanto o modo que o jogador interage com o jogo e como ele responde a suas ações. Um jogo somente pode ter seu potencial totalmente explorado pelos jogadores se tiver uma entrada bem feita, de modo que os jogadores possam acessar todas as possibilidades prevista para o jogo, e serem capaz de ver que suas ações causaram transformações no jogo.
43 5 Projeto O objetivo deste trabalho, como comentado anteriormente, é o desenvolvimento de um framework de jogos 3D para celulares, e este capítulo é dedicado à elaboração deste projeto, da implementação dos protótipos e a construção do framework. Do conjunto de metodologias apresentadas na seção 2.5 a escolhida para o desenvolvimento do framework foi a de frameworks evolutivos propostos por Don Roberts e Ralph E. Johnson denominada Envolving Frameworks(4). Obviamente nem todos os padrões propostos foram utilizados, uma vez que alguns são destinados a frameworks já bem maduros. Os padrões utilizados foram: 3 Exemplos, Framework de Caixa Branca e Biblioteca de Componentes. Uma descrição melhor sobre a utilização destes padrões pode ser visto nos capítulos referentes a implementação dos protótipos. Segundo o primeiro padrão da metodologia dos frameworks evolutivos, os 3 exemplos, foram desenvolvidos três protótipos de jogos em seqüencial. Realizar em forma seqüencial é para que um protótipo tente aproveitar o código do anterior e dessa forma, generalizando suas funcionalidades, construir o framework. O uso de protótipos em vez de de aplicações finais é devido ao esforço de desenvolvimento ser muito inferior, e como Roberts e Johnson comentam em seu artigo (4), com o uso de protótipos ainda é possível chegar muito próximo do que realizado com uma aplicação final. Antes da análise e implementação de cada protótipo foi desenvolvido o game design. O game design, descrito na seção 4.4, é responsável por documentar e formalizar as idéias de um jogo. Mas nem todas as suas partes foram criadas, apenas as primeiras referentes a concepção inicial do jogo, mais uma nova com o design detalhado para o protótipo em questão. As outras partes não foram elaboradas por tratarem de assuntos mais específicos para a versão final do jogo, e não seriam utilizados para os protótipos. O primeiro protótipo foi desenvolvido apenas para ser utilizado como fonte informação para o domínio do framework, portanto, não houve a preocupação de manter o código genérico e flexível. Já o segundo tem o propósito de criar o framework, através da com-
44 paração de seus requisitos com o que já foi desenvolvido no primeiro protótipo. Finalmente o terceiro protótipo tem o propósito de testar e refinar o framework desenvolvido. Informações mais detalhadas sobre a implementação de cada protótipo e sobre o desenvolvimento do framework pode ser visto nos capítulos 5.1, 5.2 e 5.3. A plataforma de desenvolvimento escolhida foi a Java Micro Edition(3) (item3.2.3) utilizando a configuração CLDC 1.1 e perfil 2.0. Ela se trata de uma plataforma livre tanto para uso como para distribuição dos jogos, o que permite uma melhor flexibilidade. Para o desenho 3D foi utilizado o Mobile 3D Graphics API for J2ME(3) (seção 3.3.1.3), que é um pacote opcional para a plataforma J2ME com uma API para geração de gráficos 3D para dispositivos móveis. Devido a falta de tempo para testes e depuração em um aparelho real, somado a dificuldade de encontrar um aparelho disponível para realização do projeto que possua o pacote JSR 184 com a API 3D M3G, não foi possível testar os softwares desenvolvidos em um aparelho real. No entanto com o uso de emuladores foi possível criar um ambiente de desenvolvimento para a elaboração do framework. 5.1 Desenvolvimento do Primeiro Protótipo: Gor 5.1.1 Introdução O primeiro protótipo desenvolvido foi o Gor. Ele teve como principal influência o jogo Mines of Gorr, um clássico das BBS (Bulletin Board System) desenvolvido pela Jibben Software em 1995. O Gor consiste em um pequeno RPG(Role-playing game) em que o jogador deve explorar labirintos escuros infestados de monstros em busca de um tesouro escondido. No jogo o jogador vê através da visão do personagem, que inicia sua jornada em um ponto qualquer de um labirinto. O labirinto é escuro, permitindo apenas alguns metros de visibilidade, formado por diversos corredores e intersecções. Não é um jogo de ação, portanto o deslocamento pelo labirinto é feito de forma lenta. Na busca pelo tesouro existem alguns monstros que ficam fixos em determinadas partes do labirinto, e quando avistados pelo jogador, ele deve tomar a decisão de enfrentá-los, ou tentar encontrar o tesouro por outro caminho. Na versão final do jogo o jogador deve evoluir com o tempo e diferentes equipamentos, como armas e itens mágicos poderão ser utilizados. No protótipo foi implementado o básico para o jogo, que é a geração do labirinto
45 gráfico 3D, visto em primeira pessoa, o posicionamento de objetos representados por uma imagem, resposta aos comandos de usuário para movimentação do personagem e interação com os objetos. No game design desenvolvido com uma descrição mais detalhada de cada elemento do jogo pode ser visto no anexo A A fig. 6 é mostra uma tela do jogo visto no emulador, aonde no fundo do corredor está o tesouro. Como não foi aplicado efeito de transparência, está aparecendo o fundo branco da imagem. Figura 6: Screen shot do jogo Gor no emulador. 5.1.2 Implementação O game design para o jogo Gor(anexo A) foi analisado para identificação dos requisitos para o protótipo. Os requisitos identificados foram: O labirinto deve ser em forma de uma grade, aonde as linhas representam as paredes ou sua ausência. Sendo que são obrigatórias as paredes que delimitam o labirinto; O labirinto 3D deve permitir diferentes texturas, sendo que ela pode ser definidas por parede;