Desenvolvimento de Framework de Jogos 3d para Celulares

CENTRO TECNOL ´

OGICO

DEPARTAMENTO DE INFORM ´

ATICA E ESTAT´ISTICA

Desenvolvimento de um Framework

de Jogos 3D para Celulares

Fabricio Brasiliense

Florian´

opolis

2006

Desenvolvimento de um Framework de

Jogos 3D para Celulares

Trabalho de conclus˜ao de curso apresentado como parte dos requisitos para obten¸c˜ao do grau de Bacharel em Ciˆencias da Com-puta¸c˜ao

Orientadora:

Patr´ıcia Vilain

Co-orientador:

Mario Dantas

Universidade Federal De Santa Catarina Departamento De Inform´atica E Estat´ıstica

Curso De Ciˆencias Da Computac¸˜ao

Florian´opolis Julho de 2006

Este trabalho tem como objetivo o estudo e cria¸c˜ao de um framework de jogos 3D para plataforma m´ovel. Ele contem um estudo te´orico sobre uso e desenvolvimento de frame-works, algumas das tecnologias para ambiente m´ovel e jogos. Foi utilizado a metodologia de desenvolvimento Envolving Frameworks para a cria¸c˜ao do framework, que foi criado de forma evolutiva durante o desenvolvimento de trˆes prot´otipos 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´avel.

1 Aplica¸c˜oes e frameworks(1) . . . p. 15 2 Gr´afico com os padr˜oes pelo tempo . . . p. 19 3 Aquitetura Brew(2) . . . p. 27 4 Arquitetura do J2ME(3) . . . p. 28 5 Configura¸c˜oes, perfis e pacotes opcionais. . . p. 30 6 Screen shot do jogo Gor no emulador. . . p. 45 7 Diagrama de classes ap´os a implementa¸c˜ao 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´otipo. . . p. 61 15 Diagrama de classes da segunda vers˜ao do framework. . . p. 63 16 Gr´afico de evolu¸c˜ao do framework em linhas de c´odigo. . . 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¨uˆencia da inicializa¸c˜ao do Gor. . . p. 75 20 Diagrama de seq¨uˆencia para o fluxo de execu¸c˜ao do Gor. . . p. 76 21 Diagrama de classes da primeira vers˜ao do framework. . . p. 80 22 Classes na biblioteca de componentes na primeira vers˜ao do framework. p. 81

24 Diagrama de seq¨uˆencia da inicializa¸c˜ao do Sky. . . p. 82 25 Diagrama de seq¨uˆencia do fluxo de execu¸c˜ao do Sky. . . p. 83 26 Grafo de cenas para o desenho 3D do Sky. . . p. 84 27 Diagrama de classes da segunda vers˜ao do framework. . . p. 88 28 Classes na biblioteca de componentes na segunda vers˜ao do framework. p. 89 29 Diagrama de classes completo do jogo Tan. . . p. 90 30 Diagrama de seq¨uˆencia para inicializa¸c˜ao do Tan. . . p. 91 31 Diagrama de seq¨uˆencia do fluxo de execu¸c˜ao do Tan. . . p. 92 32 Grafo de cenas para o desenho 3D para o Tan. . . p. 92

1 Introdu¸c˜ao p. 10 1.1 Objetivos . . . p. 11 1.2 Organiza¸c˜ao do Trabalho . . . p. 12 2 Frameworks p. 13 2.1 Introdu¸c˜ao . . . p. 13 2.2 Defini¸c˜ao . . . 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˜ao . . . 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˜ao . . . p. 21 2.5.3.5 Objetos Conect´aveis . . . 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.7 Testes . . . p. 24 3 Plataforma M´ovel p. 25 3.1 Introdu¸c˜ao . . . 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´oveis . . . p. 31 3.3.1 Gr´aficos 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¸c˜ao . . . 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.1 Desenvolvimento do Primeiro Prot´otipo: Gor . . . p. 44 5.1.1 Introdu¸c˜ao . . . p. 44 5.1.2 Implementa¸c˜ao . . . p. 45 5.1.3 Resultados . . . p. 49 5.2 Desenvolvimento do Segundo Prot´otipo: Sky . . . p. 49 5.2.1 Introdu¸c˜ao . . . p. 49 5.2.2 Implementa¸c˜ao . . . p. 50 5.2.2.1 Primeira Vers˜ao 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´otipo: Tan . . . p. 57 5.3.1 Introdu¸c˜ao . . . p. 57 5.3.2 Implementa¸c˜ao . . . p. 57 5.3.3 Resultados . . . p. 62 6 Conclus˜oes p. 64 6.1 Trabalhos Futuros . . . p. 66 Referˆencias 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.6 Monstros . . . p. 71 A.2.7 Combate . . . p. 71 A.3 Prot´otipo - 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´aculos . . . p. 77 C.2.3 Nave . . . p. 77 C.2.4 Jogabilidade . . . p. 78 C.3 Prot´otipo - 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.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´otipo - 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

1

Introdu¸

c˜

ao

O mercado de jogos atualmente tem movimentado na ordem de bilh˜oes de d´olares 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´a atingiu a ordem de grandeza de centenas de milh˜oes de reais. A tecnologia m´ovel ´e uma tecnologia interessante, pois possibilita a ind´ustria de software brasileira alcan¸car um elevado grau de desenvolvimento devido a complexidade necess´aria para seu estabelecimento. Devido as suas restri¸c˜oes de recursos reduzidos (processamento, mem´oria e energia) os dispositivos m´oveis d˜ao suporte a um conjunto de aplica¸c˜oes de pequeno porte, o que permite as pequenas e m´edias empresas entrarem no mercado, o que seria invi´avel em rela¸c˜ao ao o mercado tradicional de jogos, que j´a esta bastante estabelecida e tem os or¸camentos das grandes produ¸c˜oes na ordem milh˜oes.

Mesmo os jogos para celulares tendo um tamanho muito inferior aos jogos de desktop, ´e importante o uso de t´ecnicas de reuso de c´odigo como orienta¸c˜ao a objetos, componentes e frameworks para reduzir o tempo de desenvolvimento. Al´em de melhorar a qualidade do c´odigo, o tempo extra conseguido com o uso destas tecnologias pode ser utilizado para o refinamento ou adi¸c˜ao de novas funcionalidades aos jogos, melhorando sua com-petitividade no mercado. O uso de frameworks pode n˜ao ser uma boa alternativa para plataformas com limita¸c˜oes de hardware, como os celulares, pois consumem preciosos cic-los de execu¸c˜ao e mem´oria que poderiam ser utilizados para os jogos. No entanto, a nova gera¸c˜ao de aparelhos possui recursos de processamento e mem´oria bem mais abundantes, o que permite o uso de frameworks e(ou) outras t´ecnicas de reuso sem grandes impactos de performance.

Assim como aconteceu com os jogos para desktop que j´a tem definido como padr˜ao o uso de interface gr´afica 3D, acredita-se que o mesmo ir´a ocorrer com os jogos para celulares na medida que os aparelhos tenham maior capacidade de processamento e sejam capazes de realizar o processamento gr´afico em hardware.

Tendo em vista este contexto e o potencial da ´area de jogos para celulares, este tra-balho tem o intuito de estudar o desenvolvimento de jogos para celulares atrav´es do de-senvolvimento de um framework para jogos 3D. Para a cria¸c˜ao do framework foi utilizada a metodologia de frameworks evolutivos propostos por Don Roberts e Ralph E. Johnson denominada Envolving Frameworks (4). Esta metodologia ´e um conjunto de padr˜oes que devem ser seguidos para o desenvolvimento do framework. Desse modo o framework foi constru´ıdo de forma evolutiva durante a cria¸c˜ao de trˆes prot´otipos de jogos, os jogos Gor, Sky e Tan. Estes trˆes prot´otipos foram gerados especificamente para o desenvolvimento do framework, no entanto, s˜ao projetos de jogos reais, que potencialmente poderiam se tornar futuramente jogos comerciais.

A plataforma de desenvolvimento para ambiente m´ovel escolhida para o framework foi a Java Micro Edition(3) utilizando a configura¸c˜ao CLDC 1.1 e perfil MIDP 2.0. Foi utilizado tamb´em o pacote Mobile 3D Graphics API for J2ME (3) para o desenho dos gr´aficos 3D. Esta plataforma foi escolhida por ser uma plataforma completamente livre e j´a bem aceita no meio acadˆemico.

1.1

Objetivos

O principal objetivo deste trabalho ´e desenvolver um framework que seja funcional, mas n˜ao necessariamente completo, para o dom´ınio de jogos 3D para ambiente m´oveis, mais especificamente celulares. A escolha por n˜ao criar um framework completo ´e devido a natureza complexa dos frameworks e as restri¸c˜oes de tempo que torna esta tarefa invi´avel.

A elabora¸c˜ao do trabalho tamb´em inclui os seguintes objetivos espec´ıficos:

• Estudar o uso de frameworks, sua vantagens, problemas e metodologias de desen-volvimento;

• Conhecer algumas das plataformas dispon´ıveis para o ambiente m´ovel e suas li-mita¸c˜oes quanto ao desenvolvimento de software em rela¸c˜ao ao desktop;

• Conhecer melhor o universo dos jogos eletrˆonicos, um pouco da teoria que os envolve e os desafios que podem ser encontrados durante os seus desenvolvimentos.

1.2

Organiza¸

c˜

ao do Trabalho

Este trabalho foi organizado em duas partes, os trˆes primeiros cap´ıtulos s˜ao dedica-dos a parte te´orica, 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 ´e dedicado ao estudo das plataformas m´oveis, como apa-relhos de celulares e PDA, o desenvolvimento de jogos e o ambiente gr´afico 3D para estas plataformas. J´a o cap´ıtulo 4 aborda os jogos, aonde est˜ao descritas algumas de suas ca-racter´ısticas, desafios e uma descri¸c˜ao sobre Game Design, que ´e a tarefa de elabora¸c˜ao do jogo. No cap´ıtulo 5 o projeto ´e descrito, desde o desenvolvimento dos jogos at´e a evolu¸c˜ao na constru¸c˜ao do framework. Finalizando, este trabalho no cap´ıtulo 6 s˜ao mostrados as conclus˜oes e os trabalhos futuros.

2

Frameworks

A inform´atica ´e uma das ´areas que mais cresce mundialmente. O mercado necessita cada vez mais de produtos de software com requisitos cada vez mais complexos. Frame-works ´e uma das abordagens da Engenharia de Software utilizadas para reduzir o esfor¸co no desenvolvimento e ainda com ganho na sua qualidade. Este cap´ıtulo ´e dedicado a um estudo te´orico ao uso e desenvolvimento de frameworks, suas caracter´ısticas, desafios, desvantagens e metodologias.

2.1

Introdu¸

c˜

ao

Utilizando a id´eia b´asica de nunca refazer uma tarefa duas vezes, adaptando o que j´a foi produzido as novas necessidades, ´e que s˜ao utilizadas as t´ecnicas de reuso de soft-ware(5). Na pr´atica o processo de reuso ´e uma tarefa complexa, devem ser seguidos alguns princ´ıpios durante a constru¸c˜ao do c´odigo original para que esse possa ser reutilizado pos-teriormente.

Existem diversas formas de fazer um reuso entre diferentes softwares. Uma das primei-ras t´ecnicas utilizada foi o uso de bibliotecas de fun¸c˜oes para reutiliza¸c˜ao de algoritmos para controle de estrutura de dados e c´alculos matem´aticos. Atrav´es das fun¸c˜oes os c´odigos mais utilizados passaram a ser reaproveitados, mas ainda a grande maioria do c´odigo ´e necess´aria ser desenvolvida. J´a a orienta¸c˜ao a objetos com o conceito de objetos, classe, heran¸ca 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¸c˜ao as fun¸c˜oes. Com a orienta¸c˜ao a objeto al´em do reuso de uma classe como um todo atrav´es da composi¸c˜ao, permite o reuso de forma personalizada atrav´es da especializa¸c˜ao de uma classe e sobrescrita de seus m´etodos.

Tanto as bibliotecas de fun¸c˜oes quanto as de classes focam o reuso do c´odigo, no entanto a arquitetura ainda ´e deixada a cargo dos desenvolvedores. De acordo com (5), a arquitetura do software ´e a propriedade intelectual principal, e a parte mais dif´ıcil de

ser criada ou re-criada. Para suprir o reuso de arquiteturas ´e que s˜ao utilizado os padr˜oes de projetos(6). Padr˜oes de projetos s˜ao solu¸c˜oes propostas para problemas comuns de ar-quitetura inseridas em um determinado contexto. Atrav´es dos padr˜oes, os programadores podem documentar e repassar suas decis˜oes de projetos. (6) define que um arquiteto de software experiente n˜ao resolve cada problema do nada, ele reutiliza solu¸c˜oes que funcio-naram no passado. Quando encontra uma boa solu¸c˜ao, reutiliza novamente. E ´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¸c˜ao, nasceu os componentes. Componentes de software seguem a id´eia dos com-ponentes eletrˆonicos(7), para realizar uma tarefa complexa vocˆe compra um conjunto de componentes fechados, conectando-os segundo o manual de entradas e sa´ıdas de cada componente. N˜ao ´e necess´ario saber como um componente funciona, e sim o que ele ´e capaz de fazer. (8) define componentes de softwares como sendo “Instˆancias auto-contidas de objetos abstratos que podem ser conectados para formar uma aplica¸c˜ao completa”.

2.2

Defini¸

c˜

ao

Entre diversas defini¸c˜oes de o que ´e um framework na literatura, citaremos duas delas. De (4) “Frameworks s˜ao 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ˆancias destas classes colaboram.”, o foco desta defini¸c˜ao ´e no reuso da arquitetura. Em (9) “Framework ´e uma aplica¸c˜ao “semi-completa” reus´avel que pode ser especializada para a constru¸c˜ao de aplica¸c˜oes personalizadas.”, o termo “semicompleta” passa a id´eia da grande reuso ao utilizar frameworks.

Frameworks ´e a tecnologia que tenta fazer o m´aximo de reuso poss´ıvel. Faz o reuso da arquitetura atrav´es do controle do fluxo da aplica¸c˜ao, modelo de como as classes se inter-relacionam e a defini¸c˜ao de como podem ser adaptadas pelos usu´arios para a gera¸c˜ao de novas aplica¸c˜oes. O reuso de c´odigo ´e feito por suas classes e sua biblioteca de componentes.

A fig. 1 ilustra o n´ıvel de reuso que pode ser alcan¸cado atrav´es do uso de frame-works. A ´area pontilhada representa o framework, enquanto a ´area lisa representa as classes implementadas pelo usu´ario. ´E importante notar que as classes do framework tem relacionamentos internos, e as classes do usu´ario s˜ao uma pequena por¸c˜ao da aplica¸c˜ao, que foram criadas utilizando a heran¸ca.

Figura 1: Aplica¸c˜oes e frameworks(1)

Al´em do reuso de c´odigo o uso de frameworks tamb´em proporciona uma s´erie de outras vantagens. O aumento na qualidade do software desenvolvido, pois os frameworks geralmente s˜ao criado por engenheiros de software experientes e especialistas no dom´ınio do problema. Cria tamb´em um padr˜ao entre todas as aplica¸c˜oes desenvolvidas com ele. Atrav´es deste padr˜ao, ´e mais f´acil para um programador iniciar a manuten¸c˜ao de uma aplica¸c˜ao uma vez que ele j´a conhe¸ca a arquitetura do framework.

O reuso de c´odigo do framework pela aplica¸c˜ao pode ser realizado basicamente de duas formas. Primeiro atrav´es da heran¸ca entre classes do framework e aplica¸c˜ao, conhecido como reuso do tipo caixa branca(white-box frameworks)(6). A segunda forma ´e feito pela composi¸c˜ao entre as classes da aplica¸c˜ao e do framework, o reuso pela composi¸c˜ao ´e chamada de reuso do tipo caixa preta(black-box frameworks)(6).

Os frameworks que predomina o reuso caixa branca s˜ao caracterizados por ter ge-ralmente dispon´ıvel o c´odigo fonte para o usu´ario. O desenvolvimento da aplica¸c˜ao ´e feito pela especializa¸c˜ao de classes do frameworks e sobrecarga de m´etodos, que muitas vezes j´a s˜ao pr´e-definidos pelos desenvolvedores do framework. Mesmo que exista uma documenta¸c˜ao para o framework dispon´ıvel, a maior fonte de informa¸c˜oes para os pro-gramadores ser´a o c´odigo fonte.

Nos frameworks com predominˆancia do reuso caixa preta, geralmente o c´odigo fonte n˜ao ´e disponibilizado ao usu´ario. A implementa¸c˜ao ´e feita atrav´es da implementa¸c˜ao de classes atrav´es da implementa¸c˜ao de interfaces pr´e-definidas e pela composi¸c˜ao entre componentes do framework. Neste tipo de framework como os desenvolvedores n˜ao tem acesso ao c´odigo fonte, portanto n˜ao podem vˆe-lo ou altera-lo, o framework deve estar

em n´ıvel elevado de maturidade e toda a fonte de informa¸c˜ao deve ser fornecida via documenta¸c˜ao.

2.3

Desenvolvimento de Frameworks

Um framework n˜ao pode ser gen´erico o suficiente para gerar qualquer tipo de aplica¸c˜ao, ele deve estar inserido em um dom´ınio espec´ıfico como interface gr´afica, simula¸c˜ao f´ısica ou persistˆencia de dados. A abrangˆencia de um dom´ınio tamb´em deve ser considerada durante seu desenvolvimento, frameworks com abrangˆencia muito grande tende a ter uma percentagem pequena de aproveitamento, j´a frameworks mais espec´ıficos tem menor possibilidade de serem utilizados.

Uma das principais caracter´ısticas dos frameworks ´e a invers˜ao de controle(7), aonde o framework passa a controlar o fluxo de execu¸c˜ao do dom´ınio e o c´odigo da aplica¸c˜ao ´e chamado pelo framework. A invers˜ao de controle tamb´em ´e chamada de “Principio de Hollywood” que significa “N˜ao nos procure, n´os o procuraremos”(8).

“Enquanto desenvolver softwares complexos j´a ´e dif´ıcil, desenvolver frameworks de alta qualidade, extensibilidade e reusabilidade para aplica¸c˜oes de dom´ınios complexos ´e 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˜ao ser previstas ainda durante seu desenvolvimento, e para as n˜ao previstas devem existir alternativas.

Assim como desenvolver, a manuten¸c˜ao de frameworks ´e um processo trabalhoso. Al´em do pr´oprio funcionamento do framework, devem ser consideradas as implica¸c˜oes que podem ocorrer nas aplica¸c˜oes j´a desenvolvidas e futuras. Caso a nova vers˜ao do framework n˜ao seja 100% compat´ıvel com as anteriores ou novos problemas tenham sido gerados, testes e corre¸c˜oes ser˜ao necess´arios em todas as aplica¸c˜oes j´a desenvolvidas.

No ponto de vista do modelo de neg´ocios de uma empresa, o desenvolvimento de um framework pode n˜ao ser comercialmente favor´avel devido ao seu alto custo de desen-volvimento. O desenvolvimento s´o vale apena para uma empresa caso o framework seja utilizado em larga escala(10).

Testar se um framework est´a correto e flex´ıvel suficiente ´e um processo dif´ıcil, e s´o pode ser realmente verificado com o desenvolvimento de aplica¸c˜oes finais, e mesmo assim nunca ´e poss´ıvel test´a-lo completamente(10).

2.4

Problemas com uso de Frameworks

O uso de frameworks traz uma s´erie de vantagens, mas tamb´em um conjunto grande de problemas.

Dado um conjunto de frameworks candidatos para o desenvolvimento de uma ap-lica¸c˜ao, a decis˜ao sobre qual framework melhor se adapta no contexto ´e um processo dif´ıcil, e custa tempo(10).

Devido ao reuso resultante do uso de frameworks, pode causar expectativas falsas em rela¸c˜ao ao tempo de desenvolvimento da aplica¸c˜ao(10), isso se deve principalmente ao fato de que o programador deve aprender a utilizar o framework antes de come¸car o desen-volvimento. Utilizar um framework de forma correta ´e t˜ao essencial quanto desenvolver uma aplica¸c˜ao de forma correta. Em um framework bem feito todas as tarefas comuns em determinado dom´ınio s˜ao previstas, a tarefa dos programadores ´e encontrar estes pontos pr´e-definidos.

Outro problema relacionado com o uso de frameworks est´a relacionado com a identi-fica¸c˜ao e depura¸c˜ao de erros. ´E muito mais dif´ıcil em aplica¸c˜oes que utilizam frameworks identificar se um determinado erro pertence ao framework ou `a aplica¸c˜ao, principalmente quando n˜ao se tem acesso ao c´odigo fonte do framework. Neste caso, isto acontece devido `

a invers˜ao de controle aonde o c´odigo do usu´ario ´e ,geralmente, pequenos trechos disper-sos em sobrecarga de operadores ou eventos(10). E comum, em frameworks bastante´ maduros, virem inseridas ferramentas para aux´ılio `a identifica¸c˜ao e depura¸c˜ao de c´odigo. A integra¸c˜ao de diferentes frameworks pode causar muitos problemas. A grande maioria dos frameworks n˜ao est´a preparado para trabalhar de forma integrada. Um exemplo deste problema ´e a integra¸c˜ao de dois frameworks que foram desenvolvidos para ter o total controle sobre o fluxo da aplica¸c˜ao.

2.5

Metodologias de Desenvolvimento de Frameworks

Na literatura existem algumas metodologias para o desenvolvimento de frameworks. Nesta se¸c˜ao ser´a descritas as metodologias de desenvolvimento de framework dirigidas por exemplos (exemple-driven design)(11), dirigidas por pontos de flex˜ao (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´umero poss´ıvel de aplica¸c˜oes j´a desenvolvidas. Uma an´alise deve ser feita para identificar quais partes das aplica¸c˜oes s˜ao comuns e quais s˜ao espec´ıficas. As partes comuns devem ser generalizadas de modo que passam a constituir o framework. As partes espec´ıficas das aplica¸c˜oes devem ser desenvolvidas na forma de m´etodos de gatilho (hook ). Os m´etodos de gatilho s˜ao um padr˜ao utilizado por uma aplica¸c˜ao ou framework para fazer chamadas para partes de c´odigos n˜ao existentes no seu desenvolvimento.

Para verificar se o framework foi bem desenvolvido, deve-se implementar novamente as aplica¸c˜oes exemplos, mas desta vez utilizando o framework desenvolvido como base. Este m´etodo ´e mais indicado quando j´a se tem as aplica¸c˜oes desenvolvidas (ou esteja disposto a desenvolvˆe-las). E quanto mais aplica¸c˜oes foram utilizadas como exemplos, mais gen´erico ser´a o framework.

2.5.2

Dirigido por pontos de flex˜

ao

Nesta metodologia (12) deve-se dar in´ıcio ao desenvolvimento da arquitetura e imple-menta¸c˜ao 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˜ao (hot spots). Os pontos de flex˜ao s˜ao regi˜oes de c´odigo especificas de cada aplica¸c˜ao, como m´etodos de resposta a eventos que tem com-portamento diferentes em cada aplica¸c˜ao. Nestes pontos s˜ao aplicados diversos padr˜oes para manter o c´odigo flex´ıvel.

Esta metodologia seria melhor utilizada em um contexto em que se deseja desenvolver as aplica¸c˜oes de um determinado dom´ınio, mas antes ´e desenvolvido um framework para servir como base. Neste caso a implementa¸c˜ao das aplica¸c˜oes ´e o melhor caso de teste.

2.5.3

Frameworks Evolutivos

Frameworks evolutivos (4) ´e uma metodologia formada por uma linguagem de padr˜oes que devem ser seguidos durante o desenvolvimento do framework. Os nove padr˜oes pro-postos servem como um guia de alto n´ıvel, para o desenvolvimento de um framework de forma evolutiva. Nenhum destes padr˜oes s˜ao obrigat´orios ou devem ser seguidos de forma seq¨uencial. A fig. 2 contem um gr´afico com todos os padr˜oes.

1. 3 Exemplos

2. Framework de Caixa Branca 3. Framework de Caixa Preta 4. Biblioteca de Componentes 5. Pontos de Flex˜ao

6. Objetos Conect´aveis 7. Objetos Refinados 8. Construtor Visual

9. Ferramentas de Linguagem

2.5.3.1 3 exemplos

Este primeiro padr˜ao tenta resolver o problema de como come¸car o desenvolvimento do framework. Como um framework representa uma abstra¸c˜ao de um determinado dom´ınio de aplica¸c˜ao deve-se ent˜ao buscar um meio de abstrair o dom´ınio.“Pessoas desenvolvem abstra¸c˜oes a partir da generaliza¸c˜ao de exemplos concretos”(4). De modo a conseguir os exemplos concretos s˜ao desenvolvidas N aplica¸c˜oes exemplos de forma seq¨uencial, e durante o desenvolvimento de cada nova aplica¸c˜ao o framework ´e constru´ıdo.

Criado a primeira aplica¸c˜ao exemplo, ela ser´a a base para in´ıcio do framework e a primeira fonte de informa¸c˜oes sobre o dom´ınio. Deve-se planejar o segundo exemplo ana-lisando o primeiro para identificar as partes comuns e distintas. Deve-se ent˜ao dar in´ıcio `

a constru¸c˜ao do framework tentando sempre aproveitar o m´aximo poss´ıvel do primeiro exemplo, seja criando abstra¸c˜oes das classes do primeiro de modo que fa¸ca sentido no segundo exemplo tamb´em, ou generalizando de modo que o segundo seja implementado sobre o ele.

Tendo a primeira vers˜ao do framework e dois exemplos desenvolvidos, o segundo j´a utilizando o framework, deve-se iniciar um novo ciclo para os pr´oximos exemplos. Mas agora sempre utilizando o framework j´a criado nas intera¸c˜oes anteriores mas aproveitando sempre, na medida do poss´ıvel as aplica¸c˜oes j´a desenvolvidas. Um ponto importante ´e que o framework n˜ao pode ser direcionado para a pr´oxima aplica¸c˜ao, e sim generalizado para que dˆe suporte a outra aplica¸c˜ao.

(4) recomenda que devem ser utilizados trˆes exemplos para a cria¸c˜ao da primeira vers˜ao do framework. Esta escolha se deve ao fato de que uma ´unica aplica¸c˜ao n˜ao permite uma vis˜ao suficiente do dom´ınio, e um n´umero grande de aplica¸c˜oes exemplos pode causar um atraso muito grande na primeira vers˜ao do framework.

2.5.3.2 Frameworks de Caixa Branca

Quando d´a o in´ıcio do desenvolvimento do framework, uma das decis˜oes de projeto que deve ser escolhida ´e entre manter a flexibilidade atrav´es do uso de heran¸ca e polimorfismo ou via composi¸c˜ao de componentes. Este padr˜ao recomenda que inicialmente deve-se tentar apenas fazer o maior proveito poss´ıvel de c´odigo, e provavelmente as informa¸c˜oes adquiridas at´e o momento n˜ao s˜ao suficientes para decidir quais partes ser˜ao constantes, e quais vari´aveis. Portanto, deve-se construir o framework atrav´es do reuso do tipo caixa branca e conseguir a flexibilidade atrav´es da heran¸ca.

2.5.3.3 Biblioteca de Componentes

Durante o desenvolvimento das aplica¸c˜oes a partir do framework ´e necess´ario as vezes implementar os mesmos componentes para problemas distintos, e de alguma forma esses componentes n˜ao participam do dom´ınio do framework. Exemplos de componentes co-muns s˜ao os utilit´arios ou repeti¸c˜ao das mesmas implementa¸c˜oes de certas super classes do framework. Para eliminar a reescrita destes componentes deve-se criar ent˜ao uma bi-blioteca com componentes concretos e disponibiliza-lo junto com o framework, para o caso dela ser necess´aria. Deve-se iniciar apenas com os componentes mais ´obvios e na medida em que for sendo necess´ario, 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˜ao

Durante o desenvolvimento das aplica¸c˜oes ´e poss´ıvel identificar que certos trechos s˜ao editados com muita freq¨uˆencia. Estes trechos de c´odigo s˜ao identificados como os pon-tos de flex˜ao (hot spots). Caso estes pontos estejam muito espalhados pela aplica¸c˜ao, a identifica¸c˜ao destes pontos e sua manuten¸c˜ao se torna um processo muito trabalhosos. O padr˜ao recomenda que os pontos de flex˜ao devam ser separado do c´odigo, preferencial-mente encapsulados por objetos. Separar o c´odigo que varia para um objetos al´em de facilitar o reuso, tamb´em facilita para o os usu´arios do framework saibam qual c´odigo deve ser alterado.

2.5.3.5 Objetos Conect´aveis

Algumas vezes ´e necess´ario estender classes do framework para realizar pequenas altera¸c˜oes de c´odigo ou no valores de vari´aveis. Deve-se ent˜ao criar ent˜ao uma sub classe especializada que seja capaz de ser configurada atrav´es de parˆametros. Esta nova classe ´e um perfeito candidato para sua biblioteca de componentes.

2.5.3.6 Objetos Refinados

Durante a evolu¸c˜ao do framework, diversos novos componentes ser˜ao inseridos na biblioteca. Para aumentar a quantidade de reuso da biblioteca de componentes e eli-minar algumas redundˆancias de implementa¸c˜oes, deve ser realizada uma fatora¸c˜ao dos componentes. A fatora¸c˜ao deve dividir os componentes da biblioteca em componentes menores, que poder˜ao ser reconstitu´ıdos atrav´es da composi¸c˜ao. O padr˜ao alerta que os

componentes devem ser fatorados at´e que uma outra fatora¸c˜ao resulte em um componente individualmente sem sentido.

2.5.3.7 Framework de Caixa Preta

Ap´os 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¸c˜ao, conec-tando componentes para a integra¸c˜ao do framework com a aplica¸c˜ao. As vantagens da composi¸c˜ao sobre a heran¸ca ´e que ela pode ser alterada durante o tempo de execu¸c˜ao e necessita um menor entendimento dos usu´arios sobre classes do framework, j´a que para resolver o problema basta implementar um componentes especifico e agregar ao frame-work.

Para a implementa¸c˜ao deste padr˜ao, recomenda-se utilizar a heran¸ca para organiza¸c˜ao interna do framework e da biblioteca de componentes, e usar a composi¸c˜ao para integrar com aplica¸c˜ao. Para as classes do usu´ario a parte mut´avel deve ser removida do framework e deve ser colocada em classes ou interfaces que devem ser implementadas pelos usu´arios. 2.5.3.8 Construtor Visual

Quando se tem um framework do tipo caixa preta j´a maduro, ´e poss´ıvel construir aplica¸c˜oes simplesmente atrav´es da composi¸c˜ao de componentes j´a pr´e-definidos na bi-blioteca, necessitando muito pouco c´odigo. A parte mais dif´ıcil do desenvolvimento passa a ser o entendimento dos componentes e como conect´a-los.

O padr˜ao prop˜oe a constru¸c˜ao de um script respons´avel pela conex˜ao e inicializa¸c˜ao dos componentes. Uma aplica¸c˜ao gr´afica seria respons´avel pela cria¸c˜ao destes scripts para gera¸c˜ao do c´odigo do framework. A cria¸c˜ao visual ´e muito mais r´apida e precisa de menos esfor¸co no conhecimento do framework, al´em de que o usu´ario n˜ao precisa necessariamente ser um programador.

2.5.3.9 Ferramentas de Linguagens

A constru¸c˜ao visual atrav´es de uma aplica¸c˜ao gr´afica traz uma s´erie de vantagens por desassociar o framework da linguagem de programa¸c˜ao em que foi desenvolvido. Em compensa¸c˜ao devido a este mesmo motivo a verifica¸c˜ao e depura¸c˜ao dos componentes alta-mente compostos e criados em t˜ao alto n´ıvel ´e uma tarefa dif´ıcil. Devem ser desenvolvidas ferramentas com este objetivo pelo menos para as regi˜oes mais complexas do framework.

2.6

Documenta¸

c˜

ao

´

E poss´ıvel tirar todas as vantagens do reuso de um framework apenas quando os usu´arios tem pleno conhecimento sobre o funcionamento do mesmo. Portanto a docu-menta¸c˜ao ´e essencial no processo de desenvolvimento do framework.

(13) descreve o uso de padr˜oes para a documenta¸c˜ao de frameworks, e cita que uma documenta¸c˜ao deve cobrir trˆes objetivos b´asicos sobre o framework: seu prop´osito, como utiliz´a-lo e uma vis˜ao detalhada de sua arquitetura.

O prop´osito do framework deve ser escrito de forma curta e clara, deve ser des-tinado aos usu´arios que ainda n˜ao tem conhecimento algum sobre o framework. Deve descrever os pontos fortes e fracos, e outras informa¸c˜oes importantes para que o leitor possa ponderar em utilizar ou n˜ao o framework. Deve ser curto o suficiente para ser utilizado como resultado de uma busca ou em um cat´alogo.

O documento que descreve como utilizar o framework se destina a usu´arios novos e antigos, que precisam resolver um determinado problema utilizando o framework. Geral-mente s˜ao leitores com pressa e que querem apenas a solu¸c˜ao, n˜ao 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˜ao basicamente descri¸c˜oes de passos a serem seguidos para alcan¸car determinado objetivos, sem muita descri¸c˜ao do porquˆe e como de cada passo. Estes tipos de documentos podem ser escritos utilizando-se padr˜oes, apenas invertendo o foco de um objetivo a ser alcan¸cado, por um problema a ser resolvido. O detalhamento da arquitetura do framework ´e direcionado para os pr´oprios desenvolvedores do framework ou para usu´arios avan¸cados, que precisam resolver proble-mas n˜ao triviais n˜ao descritos no documento de uso do framework. Deve descrever suas classes e como suas instˆancias interagem. Diagramas de classe e colabora¸c˜ao na medida do poss´ıvel devem ser inseridos nestes documentos. Caso um framework tenha dispon´ıvel seu c´odigo fonte, ele ser´a parte desta documenta¸c˜ao, mas de forma separada.

(13) cita ainda que um importante aux´ılio na documenta¸c˜ao de frameworks s˜ao os exemplos. Exemplos s˜ao a forma mais direta de se entender o problema e a solu¸c˜ao de uma forma real, exemplos e podem ser usado pelos usu´arios como laborat´orio para realizar altera¸c˜oes de experiˆencia. Devem ser utilizados na medida do poss´ıvel no documento de como utilizar o framework. Exemplos de aplica¸c˜oes completas tamb´em s˜ao uma fonte de informa¸c˜oes muito ´util, al´em de servir de teste para o framework, permite aos novos usu´arios entenderem o framework como um todo.

2.7

Testes

Implementar aplica¸c˜oes completas e com sucesso ´e a melhor forma de testar um fra-mework, permite verificar tanto a corretude dos algoritmos quanto a flexibilidade para as novas funcionalidades da aplica¸c˜ao. A n˜ao ser que o framework seja vendido para terceiros, n˜ao ser˜ao necess´arios testes maiores que pequenos exemplos para testar as funcionalida-des do sistema. Os testes reais ser˜ao realizados durante a utiliza¸c˜ao do framework, e continuamente ele dever´a ser adaptado para se tornar mais flex´ıvel.

3

Plataforma M´

ovel

Neste cap´ıtulo contem o estudo sobre os dispositivos m´oveis e suas plataformas. Na introdu¸c˜ao ´e mostrado rapidamente o surgimento dos celulares e jogos, posteriormente ´e apresentada algumas das plataformas mais comuns no mercado, em seguida algumas das caracter´ısticas e restri¸c˜oes no desenvolvimento para m´ovel. Fechando, algumas das tecnologias existentes para gera¸c˜ao gr´afica 3D tamb´em para m´ovel.

3.1

Introdu¸

c˜

ao

A primeira gera¸c˜ao de celulares foi na d´ecada de 1980, estes aparelhos eram uma evolu¸c˜ao dos telefones instalados nos autom´oveis de luxo. Eram aparelhos sem poder de processamento e com transmiss˜ao anal´ogica. J´a a segunda gera¸c˜ao de celulares, conhecido como 2G, come¸cou na d´ecada de 90. Foram diversos os padr˜oes de comunica¸c˜ao digital criados, entre eles o GSM (Global System for Mobile Communications) que ´e o padr˜ao mais utilizado mundialmente.

Os aparelhos tem evolu´ıdo muito e a cada dia que passa se parecem mais com os micro-computadores. A capacidade de processamento dos aparelhos mais novos hoje produzidos ´e comparado aos microcomputadores no final da 90.

Algumas das tecnologias hoje dispon´ıveis nos celulares(14): • Grava¸c˜ao/Leitura de ´audio e v´ıdeo;

• Bluetooth: comunica¸c˜ao de curta distˆancia entre aparelhos de alta velocidade; • WAP (Wireless Application Protocol ): Navega¸c˜ao na internet;

• DRM (Digital Rights Management ): Baixar arquivos para o aparelho atrav´es da rede;

• MMS(Multimedia Messaging Service): Envio de arquivos multim´ıdia como imagens e v´ıdeos;

• Web Services: Padr˜ao para comunica¸c˜ao entre aplica¸c˜oes de diferentes plataformas via rede;

• GPS (Global Positioning System): Localizar a posi¸c˜ao f´ısica do aparelho no mundo; • Java: Rodar aplica¸c˜oes 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˜ao 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´arios adquirirem novos aplicativos, diferentes daqueles j´a instalados pelos fabricantes.

Este novo mercado foi uma grande oportunidade para os pequenos desenvolvedores de jogos. ´E 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). Ent-retanto, para os jogos em dispositivos m´oveis devido as limita¸c˜oes de hardware, os jogos das pequenas empresas podem competir com as grandes de maneira mais justa.

3.2

Plataformas e Portabilidade

A explos˜ao no mercado de celulares tamb´em 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 di-feren¸ca de recursos dispon´ıveis, quantidade de mem´oria e velocidade de processamento e linguagens suportadas. A implementa¸c˜ao direta sobre o hardware dos aparelhos ´e uma tarefa com custos muito alto para aplica¸c˜oes gen´ericas. A solu¸c˜ao adotada ´e inserir uma plataforma sobre o hardware para minimizar as diferen¸cas. Destas plataformas as mais comuns s˜ao:

• Symbian OS; • Brew;

• J2ME; • Exen.

3.2.1

Symbian OS

O Symbian OS ´e um sistema operacional completo, sua vers˜ao para dispositivos m´oveis com cont´em bibliotecas, framework para interface com usu´ario e ferramentas de auxilio. Este sistema operacional tem suporte a multi tarefa preemptivas, multi-thread e prote¸c˜ao de mem´oria. Uma das grandes qualidades deste sistema operacional ´e a gerˆencia de mem´oria que utiliza t´ecnicas para reduzir o uso de mem´oria e vazamentos. As aplica¸c˜oes s˜ao desenvolvidas em C++.

3.2.2

Brew

Brew (Binary Runtime Environment for Wireless)(2) ´e uma plataforma desenvolvida pela Qualcomm que roda sobre o sistema operacional, tem como principal objetivo mini-mizar as diferen¸cas entre aparelhos disponibilizando aos desenvolvedores uma API s´olida e comum. O Brew suporta aplica¸c˜oes tanto em C como em C++ que rodam de forma nativa. Para disponibilizar os aplicativos nesta plataforma deve ser utilizado o modelo de neg´ocios pr´oprio da Qualcomm, que faz conex˜ao direta entre os desenvolvedores e a operadora. Na fig. 3 pode ser visto a arquitetura da API BREW e os diversos tipos de aplica¸c˜ao e servi¸cos que ela disponibiliza.

3.2.3

J2ME

O J2ME (Java 2 Micro Edition)(3) ´e um conjunto de APIs simplificada da vers˜ao J2SE (Java 2 Standard Edition) para dispositivos com baixos recursos de hardware. Geralmente a m´aquina virtual ´e implementada pelos pr´oprios fabricantes dos aparelhos utilizando as especifica¸c˜oes da SUN. As aplica¸c˜oes escritas em java para a J2ME s˜ao chamadas de MIDlets.

Figura 4: Arquitetura do J2ME(3)

Como pode ser visto na fig. 4 a arquitetura do J2ME ´e dividida em trˆes partes. A primeira mais inferior ´e o sistema operacional do pr´oprio aparelho.

A segunda parte, a configura¸c˜ao ´e composta pela maquina virtual, que tem a responsa-bilidade de encapsular o sistema operacional disponibilizando uma interface comum. A linguagem J2ME que ´e o c´odigo compilado a partir dos fontes Java. As bibliotecas s˜ao o conjunto de classes m´ınimas com as API dispon´ıvel para as aplica¸c˜oes. A configura¸c˜ao pode ser diferente dependendo do aparelho, elas definem os requisitos m´ınimos, e est˜ao divididas em duas categorias dependendo da quantidade de mem´oria dispon´ıvel, veloci-dade e tipo de processador. A m´aquina virtual e um conjunto de bibliotecas fazem parte da configura¸c˜ao.

• CLDC (Connected Limited Device Configuration): para processadores 16 e 32 bits com no m´ınimo de 160kb de mem´oria. A vers˜ao 1.0 limita a maquina virtual, configura¸c˜ao, profile, pacotes opcionais e aplica¸c˜ao em at´e 512kb. J´a na vers˜ao 1.1, o limite ´e a quantidade de mem´oria dispon´ıvel.

• CDC (Connected Device Configuration): Para equipamentos mais r´apidos que o CLDC com o m´ınimo de mem´oria de 2Mb. Geralmente s˜ao processadores 32 bits. J´a a parte mais superior da arquitetura est˜ao os perfis, s˜ao um complemento `as con-figura¸c˜oes para tornar o ambiente completo para a execu¸c˜ao de aplica¸c˜oes, contem um conjunto de classes de apoio mas n˜ao essenciais para a execu¸c˜ao das aplica¸c˜oes. O MIDP (Mobile Information Device Profile) ´e o perfil desenvolvida para os celulares e PDAs e roda sobre a configura¸c˜ao CLDC. Fornece em sua API para as aplica¸c˜oes com interface com usu´ario, acesso a rede e persistˆencia e acesso a fun¸c˜oes especificas dos aparelhos. O MIDP tamb´em existe em duas vers˜oes, 1.0 e 2.0. A segunda vers˜ao cumpre o seguinte escopo:

• Entrega e faturamento de aplica¸c˜oes; • Ciclo de vida da aplica¸c˜ao;

• Modelo para certificar aplica¸c˜oes e privil´egios;

• Transferˆencia segura de fim-a-fim atrav´es do HTTPS;

• MIDlet push registration, inicializar aplica¸c˜oes sem intera¸c˜ao do usu´ario; • Acesso a rede;

• Persistˆencia de dados; • Som;

• Timers;

• Interface com usu´arios (inclusive um pacote para jogos).

Este modelo de arquitetura permite ainda a alguns dispositivos agregarem em seu pro-duto ainda outros pacotes opcionais que entendem as configura¸c˜oes CLDC e CDC. Estes pacotes trazem novas funcionalidades para as aplica¸c˜oes, e geralmente est˜ao agregados a alguma funcionalidade especifica do hardware. Alguns exemplos de pacotes opcionais s˜ao os web services, arquivos de m´ıdia, conex˜ao com banco de dados, mensagens e gr´aficos 3d. A fig. 5 permite visualizar toda a plataforma J2ME como um todo, com suas confi-gura¸c˜oes, perfis e pacotes opcionais

Figura 5: Configura¸c˜oes, perfis e pacotes opcionais.

Apesar da proposta da Sun de desenvolver uma plataforma uniforme para o desenvol-vimento, devido a m´a implementa¸c˜ao das maquinas virtuais pelas empresas de fabrica¸c˜ao dos aparelhos, ´e comum durante a migra¸c˜ao para um aparelho diferente ocorrer uma s´erie de problemas. Uma amostra deste problema ´e um estudo de caso realizado UFPE(15) de portar um jogo desenvolvido em J2ME no aparelho T720 da Motorola para os da s´erie 60 da Nokia. Mesmo a linguagem java seguir o padr˜ao Write once, run everywhere (escreva uma vez, rode em todo lugar) foram necess´arias 79 altera¸c˜oes no c´odigo, com uma m´edia de 2 linhas alteradas por modifica¸c˜ao.

3.2.4

Exen

Exen ou Execution Engine foi a primeira plataforma exclusiva para a execu¸c˜ao de jogos. Esta plataforma roda aplicativos java e por ter sua API implementada em c´odigo nativo do aparelho sua m´aquina virtual ´e muito mais r´apida. No entanto esta plataforma esta dispon´ıvel em apenas para aparelhos de algumas operadoras na europa.

3.3

Desenvolvimento de Jogos para M´

oveis

Para a implementa¸c˜ao de aplica¸c˜oes, mais especificamente os jogos, tem um s´erie de caracter´ısticas e desafios quando desenvolvidas para dispositivos m´oveis. Nesta se¸c˜ao ser˜ao descritas algumas destas caracter´ısticas.

Em rela¸c˜ao ao hardware temos os seguintes caracter´ısticas: • Baixo poder de processamento;

• Pouca quantidade de mem´oria e com baixa velocidade de acesso; • Pouco espa¸co em disco;

• Baixa velocidade de transmiss˜ao pela rede; • Energia por tempo limitado;

• Diversos fatores relacionados a usuabilidade: tamanho da tela, resposta de bot˜oes, som...

• Ausˆencia de ponto flutuantes.

Em rela¸c˜ao ao ao software, temos as seguintes caracter´ısticas: • APIs reduzidas;

• Limite no tamanho das aplica¸c˜oes; • N´umero de aplica¸c˜oes em execu¸c˜ao;

• Limita¸c˜oes no uso de ponto flutuante (implementado via software); • Testes exaustivos para n˜ao danificar o software do aparelho;

• Uma s´erie de eventos devem ser tratados como: falta de energia, n´umero de arquivos abertos e chamadas telefˆonicas.

Estas caracter´ısticas est˜ao relacionadas a todas as etapas do desenvolvimento do jogo, deste o game design4.4 do jogo at´e os testes. Durante o design do jogo, os designers tem que ter em mente que n˜ao existe mem´oria e nem processamento de sobra, portanto apenas as funcionalidades essenciais devem estar presentes. Jogos de a¸c˜ao que exigem muitos

reflexos tamb´em n˜ao s˜ao apropriados, devido a baixa taxa de quadros dos aparelhos e m´a disposi¸c˜ao e resposta do teclado. Durante a fase de desenvolvimento deve existir uma etapa de otimiza¸c˜ao de c´odigo aonde deve-se otimizar os pontos no programa com maior consumo de processamento e(ou) mem´oria. A otimiza¸c˜ao ´e um processo muito importante pois al´em do o jogo ficar mais leve, o espa¸co 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 ´e o download, a instala¸c˜ao, a execu¸c˜ao, a desinstala¸c˜ao e a dele¸c˜ao. Todas estas etapas devem funcionar corretamente em diferentes aparelhos e considerando uma s´erie de eventos j´a citados anteriormente. Como o usu´ario n˜ao tem acesso direto ao sistema operacional, qualquer opera¸c˜ao de manuten¸c˜ao em um aparelho destes ´e trabalhosa e caro. No modelo de neg´ocios da Brew por exemplo, o jogo para poder ser disponibilizado para download deve passar pelos testes de empresas autorizadas pela Brew, que ´e pago por teste. Os testes s˜ao muito rigorosos e dependendo do caso pode atrasar o lan¸camento do jogo em v´arios meses.

3.3.1

Gr´

aficos 3D

A utiliza¸c˜ao de gr´aficos 3D nos jogos a muito tempo j´a se tornou um padr˜ao para os jogos de PC e consoles. Para plataforma m´ovel os jogos 3D ainda s˜ao poucos em compara¸c˜ao com os 2D, no entanto, ´e certo que este cen´ario se inverta a medida que o processamento destes aparelho cres¸ca. Como o framework ser´a desenvolvido para jogos 3D, nesta se¸c˜ao s˜ao apresentados algumas das tecnologias 3D para dispositivos m´oveis.

Basicamente existem dois modos diferentes de se desenhar objetos 3D, o primeiro ´e utilizando uma API de acesso hardware de acelera¸c˜ao 3D como OpenGL ES(16). A outra ´e realizando todas as transforma¸c˜oes via software e desenhando em uma imagem 2D.

Apesar da especifica¸c˜ao de OpenGL ES j´a estar em sua vers˜ao 2.0 ainda s˜ao poucos os aparelhos celulares que tem esta funcionalidade, uma vez que ´e 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)

• M3G(3)

3.3.1.1 OpenGL ES

OpenGL ES(16) ´e uma API inter plataforma, livre de royalty, com plena funcionali-dade de acelera¸c˜ao 2D e 3D para dispositivos m´oveis. Ela foi desenvolvida a partir de um cons´orcio entre empresas de software e hardware. Algumas empresas participantes desde cons´orcio s˜ao: ARM, ATI, Nokia, Motorola, Intel, NVIDIA, Sony e Sun(16).

Ela utiliza como base a j´a consagrada API OpenGL e sofreu uma s´erie de altera¸c˜oes para poder dar suporte a aparelhos com baixos recursos de hardware. Foram removido funcionalidades computacionalmente caras, redundantes ou in´uteis para ambiente m´ovel. A API utiliza a id´eia de perfis e extens˜oes que permitem a alguns aparelhos terem recursos a mais como shaders ou acessar otimiza¸c˜oes dependentes de hardware.

3.3.1.2 X-Forge 2

X-Forge 2(17) ´e um motor para desenvolvimento de jogos 3D com um grande n´umero de ferramentas. Os jogos s˜ao desenvolvidos em um ambiente pr´oprio independente de plataforma e que engloba n˜ao apenas a programa¸c˜ao, mas a parte art´ıstica do desenvol-vimento. O motor foi desenvolvido de forma modular e permite a inser¸c˜ao e remo¸c˜ao de diversos pacotes, como por exemplo o pacote para gˆenero de jogos de corrida.

O motor utiliza uma arquitetura de duas camadas, a primeira ´e respons´avel por criar a API indepedente de plataforma para a segunda. J´a a segunda camada ´e composta pelo motor de jogos 3D.

3.3.1.3 M3G

M3G(3) (A Mobile 3D Graphics API for J2ME ´e a vers˜ao de java 3D para dispositivos m´oveis ´e a especifica¸c˜ao n´umero 184 da JSR (Java Specification Requests) realizado pelo Java Community Process (JCP). O JCP ´e uma comunidade de empresas interessadas em decidir o futuro da linguagem java. No caso da 184, o Expert Group, como s˜ao 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 ´e um subconjunto de funcionalidades do OpenGL, o mesmo ocorre com M3G em rela¸c˜ao ao J3D (Java 3D). M3G ´e um pacote do tipo opcional e foi

desenvolvido para J2ME/CLDC com perfil MIDP 1.0 ou 2.0. Para se ter uma id´eia do funcionamento e das limita¸c˜oes abaixo esta listado os requisitos declarados na especifica¸c˜ao do JSR 184:

• Suportar acesso via modo retained, deixando as tarefas de desenho para a API; • Suportar acesso via modo immediate, o usu´ario deve fazer chamadas a API para

que objetos sejam desenhados;

• Suportar uma mistura dos dois tipos de acessos, retained e immediate; • Todos os m´etodos da especifica¸c˜ao 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´avel float e introduzir novos tipos de vari´aveis b´asicas;

• Deve ser implementada de forma eficiente mesmo sem calculo de ponto flutuante em hardware;

• Recomenda-se que o consumo de mem´oria 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¸c˜ao das imagens 3D. Para a cria¸c˜ao do grafo de cena diferentes objetos como luzes, cˆameras, modelos 3d, transforma¸c˜oes geom´etricas, materiais, s˜ao conectados em forma de arvore. A API ent˜ao utiliza este grafo para realizar otimiza¸c˜oes e desenhar a na tela.

4

Jogos

Como o dom´ınio do framework desenvolvimento neste trabalho se trata de jogos, neste cap´ıtulo ´e apresentando alguns dos temas relacionados com os jogos. Primeiro ´e feito uma introdu¸c˜ao sobre mercado de jogos, posteriormente ´e mostrado uma classifica¸c˜ao informal quanto os tipos de jogos, em seguida algumas das caracter´ısticas relacionadas ao desenvolvimento de jogos. Por fim, uma descri¸c˜ao das parte de um game design.

4.1

Introdu¸

c˜

ao

Os jogos eletrˆonicos s˜ao um meio de entretenimento muito difundido, est˜ao 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ˆonicos. Destes apenas 35% s˜ao menores de 18 anos, a m´edia de idade de 35 anos. Em m´edia os jogadores gastam cerca de 1h por dia. Outro dado interessante ´e que os jogadores gastam mais que o triplo do tempo jogando do que praticando esportes, se dedicando a trabalhos volunt´arios, atividades religiosas, atividades culturais ou lendo. O mercado de jogos eletrˆonicos movimentou US$ 28 bilh˜oes em todo o mundo em 2003(19), e que desde 2003 superou o mercado cinematogr´afico (18).

Uma das principais caracter´ısticas dos jogos ´e a interatividade. Ao contr´ario de um livro ou um filme, o jogador tem o poder de alterar o rumo da hist´oria, 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´edias 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¸c˜ao espacial virtual foi comercializada entre dois usu´ario por 100 mil d´olares(20).

4.2

Tipos de Jogos

Jogos s˜ao lan¸cados quase que diariamente, e gra¸cas ao avan¸co da internet os lan¸camentos s˜ao em escala mundial, sejam eles de grandes empresas, pequenas ou desenvolvedores in-dependentes. A variedade de jogos hoje dispon´ıveis no mercado ´e suficiente para todos os tipos e gostos. Para se entender melhor a vastid˜ao dos jogos, abaixo ser˜ao descritos alguns tipos em rela¸c˜ao a diferentes categorias.

Quanto a tecnologia de interface gr´afica utilizada:

• Textual: Estes jogos foram muito comuns at´e o lan¸camento das placas de v´ıdeos e monitores gr´aficos. Alguns s˜ao como livros com pequenos problemas de l´ogica que precisam ser resolvidos para continuar, outro mais interativos e at´e com desenhos utilizando caracteres especiais.

• 2D: Estes jogos s˜ao formados por imagens retangulares sobrepostas, fazem grande uso de transparˆencia. ´E a categoria que tem o maior n´umero de jogos. Este tipo de interface para jogos em hardwares com abundˆancia de mem´oria e processamento j´a ´e considerada obsoleta, mas ainda ´e muito utilizada em jogos mais simples ou de baixo processamento.

• 3D: Utilizam modelos 3D e textura para composi¸c˜ao das cenas, teve grande popu-lariza¸c˜ao gra¸cas `as placas de v´ıdeo 3D que existem no mercado. Quase sem exce¸c˜ao todas as grandes produ¸c˜oes para microcomputadores s˜ao hoje desenvolvidas com esta tecnologia.

Quanto ao modo de visualiza¸c˜ao do mundo pelo jogador:

• Primeira Pessoa: O jogador tem a vis˜ao como se fosse o personagem, e vˆe com seus pr´oprios olhos. Este estilo ´e 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˜ao do jogador ´e como uma cˆamera flutuante que segue o

personagem aonde ele for, geralmente mantendo uma certa distˆancia.

• Vis˜ao de Deus: Este tipo o jogador tem uma vis˜ao do todo, ou a´erea do mundo. ´E o tipo mais utilizado principalmente pelos jogos de interface 2D.

• A¸c˜ao: Talvez o mais gen´erico dos gˆeneros. Estes jogos tem como objetivo estimular os reflexos do jogador, muitos passam a sensa¸c˜ao de perigo e fixam o jogador em n˜ao tirar os olhos sobre o monitor.

• Aventura: S˜ao jogos geralmente com uma hist´oria linear, aonde o personagem tem de cumprir objetivos e resolver quebra cabe¸cas para tentar alcan¸car o final da hist´oria. Geralmente ´e o gˆenero que traz hist´orias mais criativas e elaboradas.

• Tiro: S˜ao jogos de a¸c˜ao em primeira pessoa, normalmente caracterizados por atirar em quem aparecer em sua frente. Salvo algumas exce¸c˜oes.

• Esporte: Estes jogos tentam simular partidas reais como de futebol ou basquete. Na grande maioria o jogador fica respons´avel por controlar os jogadores de um time, mas h´a tamb´em aqueles aonde o jogador controla apenas o t´ecnico e que deve gerenciar uma equipe.

• Estrat´egia: S˜ao jogos em que bombardeiam o jogador com uma s´erie de cita¸c˜oes em que ele deve tomar decis˜oes, a soma de suas escolhas ´e que resulta no sucesso ou fracasso no jogo.

• Simuladores: Jogos que fazem simula¸c˜oes de coisas reais, os mais comuns s˜ao os simuladores de carros ou de avi˜oes. Muitos destes jogos implementam uma simula¸c˜ao f´ısicas altamente realistas e s˜ao 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˜oes atrav´es de uma hist´oria. Os personagens geralmente evoluem com o passar do tempo, adquirindo novos poderes e carac-ter´ısticas.

• Luta: Muito popular nos arcades este tipo de jogos simula a briga entre dois ou mais personagens. S˜ao jogos geralmente violentos e competitivos, fazem grande uso dos reflexos.

• Educacional: S˜ao jogos desenvolvidos n˜ao apenas para entretenimento, mas como principal objetivo ensinar alguma coisa a seus jogadores. Jogos infantis para ensino da matem´atica e simuladores a´ereos para treinamento de pilotos tamb´em entram nesta categoria.

• Puzzle: Puzzles s˜ao desafios l´ogicos, s˜ao muito usados como passatempo. • Cartas: S˜ao jogos que simulam jogos de cartas reais como canastra ou poker.

Quanto ao n´umero de jogadores podemos definir em 3 categorias:

• Um jogador: Apenas ´e poss´ıvel um jogador por vez, todo o resto ´e controlado pelo computador. Alguns destes jogos s˜ao desenvolvidos com t´ecnicas avan¸cadas de inteligˆencia artificial.

• Em grupo: Geralmente entre 2 a 100 jogadores, geralmente s˜ao dividos em grupos e competem entre si.

• Massivo: Estes jogos s˜ao caracterizados por mais de 500 jogadores simultˆaneos, ge-renciado por grandes servidores. Estes jogos s˜ao geralmente persistentes e as escol-has dos jogadores em um partida podem ter conseq¨uˆencias 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 ´e caracterizado por pouca a¸c˜ao, as respostas acontecem a eventos do usu´ario e a parte do processamento ´e 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 ´e realizado em pequenas etapas v´arias vezes por segundo, durante cada processamento deve ser realizado a simula¸c˜ao f´ısica e colis˜oes, inteligˆencia artificial, e atualiza¸c˜ao da tela.

4.3

Caracter´ısticas no Desenvolvimento de Jogos

Jogos ´e um t´opico interessante na ´area da computa¸c˜ao por abordar o estudo em v´arias ciˆencias, t´ecnicas e n˜ao t´ecnicas. Apesar de um jogo ser um software e depender das t´ecnicas de desenvolvimento e programadores, o sucesso de um jogo est´a baseado muito em sua concep¸c˜ao Algumas das ´areas utilizadas atualmente para o projeto e desenvolvimento dos jogos:

• Computa¸c˜ao Gr´afica: Objetos animados em 3D, sombras volum´etricas e reflexos s˜ao algumas das tarefas respons´aveis pela computa¸c˜ao gr´afica, e deve ser efetuada dezenas de vezes por segundo. Gr´aficos realistas e bonitos s˜ao os principais chamariz dos jogos, gra¸cas `as novas gera¸c˜oes de placas de v´ıdeo 3D.

• Inteligˆencia Artificial: Em jogos de um ´unico jogador, a intera¸c˜ao se baseia comple-tamente em a¸c˜oes tomadas pelo computador, e este deve atuar de forma inteligente que mostre realismo e desafie o jogador.

• Arte: Imagens s˜ao utilizadas para texturas de modelos 3d e para a composi¸c˜ao da interface de usu´ario. De modo mais indireto todo o trabalho de arte envolvido na concep¸c˜ao do jogo, arquitetura do ambiente de jogo, roupas e os pr´oprios persona-gens s˜ao alguns exemplos.

• Comunica¸c˜ao de Dados: Certamente os jogos aonde a comunica¸c˜ao de dados ´e mais vis´ıvel s˜ao os jogos MMO (Massive Multiplayer On-line) aonde seus servido-res devem gerenciar um mundo completo com milhaservido-res 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˜oes de usu´arios cadastrados.

• Simula¸c˜ao: Grande quantidade dos jogos desenvolvidos hoje s˜ao na verdades simu-ladores em tempo real. Bibliotecas f´ısicas s˜ao capaz de simular em tempo real a dinˆamica de corpos r´ıgidos, roupas, l´ıq¨uidos e part´ıculas.

• Usabilidade: Muitos bons jogos se tornaram um completo fracasso devido a di-ficuldade de novos jogadores se adaptarem ao jogo. Navegar em ambientes 3D, gerenciar centenas de unidades ou controlar dezenas de cidades s˜ao algumas das tarefas realizadas pelos jogadores e deve ser da forma mais intuitiva poss´ıvel. • Som: Efeitos sonoros e m´usicas s˜ao fundamentais para a imers˜ao dos jogadores no

universo do jogo. Enquanto as m´usicas criam o clima necess´ario em cada ato, o efeitos sonoros criam maior realidade no que se vˆe na tela.

Todas as ´areas citadas anteriormente est˜ao diretamente relacionadas ao desenvol-vimento de parte do software. Mas outras ´areas distantes da Ciˆencias da Computa¸c˜ao tamb´em s˜ao utilizadas durante o planejamento. Jogos devem ter um hist´oria interessante, personagens com personalidades e um universo realista. Para definir estes elementos ´e necess´ario utilizar outras ´areas de pesquisa, por exemplo a psicologia, fotografia, hist´oria e estrat´egia.

Outro grande desafio no desenvolvimento de jogos ´e que como todo o tipo de entre-tenimento ele deve ser acima de tudo divertido. Isso quer dizer que mesmo que fa¸camos tudo corretamente, ainda corremos o risco de criar um jogo chato. Para evitar isso al´em do bom senso as empresas utilizam grandes equipes de testes, f´orum para comunica¸c˜ao com os jogadores e lan¸camento de vers˜oes alphas e betas para grupos restritos de usu´arios. As equipes de desenvolvimento de jogos geralmente s˜ao bastante heterogˆeneas, os programadores devem trabalhar integrado com profissionais de outras ´areas, e muitas

vezes s˜ao minoria. Para se ter uma id´eia o StarCraft, jogo de grande sucesso da Blizzard Entertainment, teve 53 pessoas na gerˆencia, atividades comerciais e design do jogo, 108 em arte, 51 nos testes e apenas 16 pessoas envolvidas na programa¸c˜ao.

4.4

Game Design

O game design1 de um jogo ´e a etapa onde deve ser elaborado o jogo, sua hist´orica, contexto, regras, caracter´ısticas, objetivos, personagens, etc. Deve ser realizado antes de qualquer tarefa relacionada com o desenvolvimento do software. O processo de concep¸c˜ao do jogo atrav´es do game design deve gerar uma s´erie de documentos que ser˜ao utilizados posteriormente pela equipe de produ¸c˜ao para o desenvolvimento do software, gera¸c˜ao das imagens, modelos, sons e markenting.

J´a os Game Designers s˜ao as pessoas respons´aveis pela elabora¸c˜ao do conceito do jogo e suas regras. S˜ao eles que ditam o que deve ser programado, modelado ou as imagens geradas pelas outras equipes. Os Game Designers tamb´em s˜ao respons´avel pela palavra final em aprovar o que ´e desenvolvido para o jogo, eles funcionam como uma esp´ecie de diretor na ind´ustria cinematogr´afica.

Para detalhar melhor o game design e os produtos gerados ser´a descrito de forma r´apida 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 ´e que a primeira id´eia deve ser trabalhada e documentada. Sem se preocupar com qualquer barreira que possa impedir o desenvolvimento do jogo, deve-se

1_{N˜ao se trata da fase de design de um ciclo de desenvolvimento de software, e sim da etapa de} elabora¸c˜ao do jogo como conceito.

elaborar e documentar todas as caracter´ısticas desejadas para o jogo. Descrever de forma r´apida como seria as principais partes do jogo, quais as decis˜oes que necessitariam ser tomadas pelos jogadores e as raz˜oes que tornariam o jogo legal. Este documento serve para vender a id´eia a equipe, al´em de tamb´em ser muito ´util para a equipe de marketing e conseguir investidores.

Mesmo que este primeiro conceito n˜ao seja aprovado por n˜ao ser atrativo, financeira-mente ou computacionalfinanceira-mente invi´avel, por se tratar de um documento escrito ele pode ser arquivado e n˜ao se perde na mem´oria de seu criador.

4.4.2

Core Design

Nesta fase ser´a elaborado a primeira especifica¸c˜ao do jogo, deve estar focada no jogo independente da plataforma que ser´a 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˜ao utilizadas no jogo. Tamb´em pode ser interessante a gera¸c˜ao de prot´otipos.

Entre os componentes do jogo que ser˜ao elaborados nesta etapa s˜ao: • O personagem;

• Contexto em que jogo estar´a inserido; • Hist´oria e seu desenrolar;

• Os objetivos;

• A interface de como o jogador interage com o jogo;

• A jogabilidade e as decis˜oes que necessitar˜ao ser tomadas pelo o jogador; • As fases do jogo e como elas podem alterar a jogabilidade;

4.4.3

Jogabilidade

Jogabilidade se refere basicamente `as decis˜oes que devem ser tomadas pelo jogador, as possibilidades devem ser interessantes e n˜ao triviais. Eles devem ter a possibilidade de tentar diferentes alternativas e tirar suas pr´oprias conclus˜oes sobre qual alternativa ´e

melhor em determinado contexto. As regras devem ser definidas de forma concreta, que j´a possam ser testas e equilibradas.

4.4.4

Design Detalhado

Durante a etapa do Design Detalhado o Core Design ser´a 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´alise de requisitos. Este etapa ´e diferente da etapa de analise de um ciclo de desenvolvimento de soft-ware, aqui n˜ao pensamos em componentes de software como objetos, classes, estruturas ou algoritmos. Estes componentes apenas ser˜ao gerados posteriormente pela equipe de produ¸c˜ao ap´os uma analise sobre estes documentos.

4.4.5

Equil´ıbrio do Jogo

J´a durante o desenvolvimento das primeiras vers˜oes do jogo as regras devem ser nova-mente testadas com objetivo de verificar seu equil´ıbrio. O equil´ıbrio ´e 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´em dos testes manuais pode ser utilizado simula¸c˜oes que busquem exaustivamente falhas no equil´ıbrio do jogo.

4.4.6

Interfaces de Entrada e Sa´ıda

Nesta etapa ser´a realizado um polimento geral no jogo quanto o modo que o jogador interage com o jogo e como ele responde a suas a¸c˜oes. 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¸c˜oes causaram transforma¸c˜oes no jogo.

5

Projeto

O objetivo deste trabalho, como comentado anteriormente, ´e o desenvolvimento de um framework de jogos 3D para celulares, e este cap´ıtulo ´e dedicado `a elabora¸c˜ao deste projeto, da implementa¸c˜ao dos prot´otipos e a constru¸c˜ao do framework. Do conjunto de metodologias apresentadas na se¸c˜ao 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˜oes propostos foram utilizados, uma vez que alguns s˜ao destinados a frameworks j´a bem maduros. Os padr˜oes utilizados foram: 3 Exemplos, Framework de Caixa Branca e Biblioteca de Componentes. Uma descri¸c˜ao melhor sobre a utiliza¸c˜ao destes padr˜oes pode ser visto nos cap´ıtulos referentes a implementa¸c˜ao dos prot´otipos.

Segundo o primeiro padr˜ao da metodologia dos frameworks evolutivos, os 3 exemplos, foram desenvolvidos trˆes prot´otipos de jogos em seq¨uencial. Realizar em forma seq¨uencial ´e para que um prot´otipo tente aproveitar o c´odigo do anterior e dessa forma, generalizando suas funcionalidades, construir o framework. O uso de prot´otipos em vez de de aplica¸c˜oes finais ´e devido ao esfor¸co de desenvolvimento ser muito inferior, e como Roberts e Johnson comentam em seu artigo (4), com o uso de prot´otipos ainda ´e poss´ıvel chegar muito pr´oximo do que realizado com uma aplica¸c˜ao final.

Antes da an´alise e implementa¸c˜ao de cada prot´otipo foi desenvolvido o game design. O game design, descrito na se¸c˜ao 4.4, ´e respons´avel por documentar e formalizar as id´eias de um jogo. Mas nem todas as suas partes foram criadas, apenas as primeiras referentes a concep¸c˜ao inicial do jogo, mais uma nova com o design detalhado para o prot´otipo em quest˜ao. As outras partes n˜ao foram elaboradas por tratarem de assuntos mais espec´ıficos para a vers˜ao final do jogo, e n˜ao seriam utilizados para os prot´otipos.

O primeiro prot´otipo foi desenvolvido apenas para ser utilizado como fonte informa¸c˜ao para o dom´ınio do framework, portanto, n˜ao houve a preocupa¸c˜ao de manter o c´odigo gen´erico e flex´ıvel. J´a o segundo tem o prop´osito de criar o framework, atrav´es da