Fabricio Brasiliense - Coordenação de Projetos · Java Micro Edition e utilizado a API A Mobile...

UNIVERSIDADE FEDERAL DE SANTA CATARINA

CENTRO TECNOLOGICO

DEPARTAMENTO DE INFORMATICA E ESTATISTICA

Desenvolvimento de um Framework

de Jogos 3D para Celulares

Fabricio Brasiliense

Florianopolis

2006

Fabricio Brasiliense

Desenvolvimento de um Framework de

Jogos 3D para Celulares

Trabalho de conclusao de curso apresentadocomo parte dos requisitos para obtencaodo grau de Bacharel em Ciencias da Com-putacao

Orientadora:

Patrıcia Vilain

Co-orientador:

Mario Dantas

Universidade Federal De Santa CatarinaDepartamento De Informatica E Estatıstica

Curso De Ciencias Da Computacao

Florianopolis

Julho de 2006

Resumo

Este trabalho tem como objetivo o estudo e criacao de um framework de jogos 3D paraplataforma movel. Ele contem um estudo teorico sobre uso e desenvolvimento de frame-works, algumas das tecnologias para ambiente movel e jogos. Foi utilizado a metodologiade desenvolvimento Envolving Frameworks para a criacao do framework, que foi criadode forma evolutiva durante o desenvolvimento de tres prototipos de jogos. Para cada jogofoi utilizado um rascunho de game design. A plataforma em que foi desenvolvida foi aJava Micro Edition e utilizado a API A Mobile 3D Graphics API for J2ME. No final dotrabalho, foi produzido um framework com uma arquitetura definida e reusavel.

Lista de Figuras

1 Aplicacoes e frameworks(1) . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

2 Grafico com os padroes pelo tempo . . . . . . . . . . . . . . . . . . . . p. 19

3 Aquitetura Brew(2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

4 Arquitetura do J2ME(3) . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28

5 Configuracoes, perfis e pacotes opcionais. . . . . . . . . . . . . . . . . . p. 30

6 Screen shot do jogo Gor no emulador. . . . . . . . . . . . . . . . . . . p. 45

7 Diagrama de classes apos a implementacao 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 prototipo. . . . . . . . . . . p. 61

15 Diagrama de classes da segunda versao do framework. . . . . . . . . . . p. 63

16 Grafico de evolucao do framework em linhas de codigo. . . . . . . . . . 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 sequencia da inicializacao do Gor. . . . . . . . . . . . . . p. 75

20 Diagrama de sequencia para o fluxo de execucao do Gor. . . . . . . . . p. 76

21 Diagrama de classes da primeira versao do framework. . . . . . . . . . p. 80

22 Classes na biblioteca de componentes na primeira versao do framework. p. 81

23 Diagrama de classes completo do jogo Sky. . . . . . . . . . . . . . . . . p. 81

24 Diagrama de sequencia da inicializacao do Sky. . . . . . . . . . . . . . . p. 82

25 Diagrama de sequencia do fluxo de execucao do Sky. . . . . . . . . . . . p. 83

26 Grafo de cenas para o desenho 3D do Sky. . . . . . . . . . . . . . . . . p. 84

27 Diagrama de classes da segunda versao do framework. . . . . . . . . . . p. 88

28 Classes na biblioteca de componentes na segunda versao do framework. p. 89

29 Diagrama de classes completo do jogo Tan. . . . . . . . . . . . . . . . . p. 90

30 Diagrama de sequencia para inicializacao do Tan. . . . . . . . . . . . . p. 91

31 Diagrama de sequencia do fluxo de execucao do Tan. . . . . . . . . . . p. 92

32 Grafo de cenas para o desenho 3D para o Tan. . . . . . . . . . . . . . . p. 92

Sumario

1 Introducao p. 10

1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 11

1.2 Organizacao do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12

2 Frameworks p. 13

2.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13

2.2 Definicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 flexao . . . . . . . . . . . . . . . . . . . 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 flexao . . . . . . . . . . . . . . . . . . . . . p. 21

2.5.3.5 Objetos Conectaveis . . . . . . . . . . . . . . . . . . . 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 Documentacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23

2.7 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24

3 Plataforma Movel p. 25

3.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Moveis . . . . . . . . . . . . . . . . . . p. 31

3.3.1 Graficos 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 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Prototipo: Gor . . . . . . . . . . . . . . . p. 44

5.1.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 44

5.1.2 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45

5.1.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 49

5.2 Desenvolvimento do Segundo Prototipo: Sky . . . . . . . . . . . . . . . p. 49

5.2.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 49

5.2.2 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 50

5.2.2.1 Primeira Versao 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 Prototipo: Tan . . . . . . . . . . . . . . . p. 57

5.3.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 57

5.3.2 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 57

5.3.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 62

6 Conclusoes p. 64

6.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66

Referencias 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 Evolucao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 70

A.2.6 Monstros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 71

A.2.7 Combate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 71

A.3 Prototipo - 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 Obstaculos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 77

C.2.3 Nave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 77

C.2.4 Jogabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 78

C.3 Prototipo - 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 Prototipo - 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 Introducao

O mercado de jogos atualmente tem movimentado na ordem de bilhoes de dolares 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, ja atingiu a ordem de grandeza

de centenas de milhoes de reais. A tecnologia movel e uma tecnologia interessante, pois

possibilita a industria de software brasileira alcancar um elevado grau de desenvolvimento

devido a complexidade necessaria para seu estabelecimento. Devido as suas restricoes de

recursos reduzidos (processamento, memoria e energia) os dispositivos moveis dao suporte

a um conjunto de aplicacoes de pequeno porte, o que permite as pequenas e medias

empresas entrarem no mercado, o que seria inviavel em relacao ao o mercado tradicional

de jogos, que ja esta bastante estabelecida e tem os orcamentos das grandes producoes na

ordem milhoes.

Mesmo os jogos para celulares tendo um tamanho muito inferior aos jogos de desktop,

e importante o uso de tecnicas de reuso de codigo como orientacao a objetos, componentes

e frameworks para reduzir o tempo de desenvolvimento. Alem de melhorar a qualidade

do codigo, o tempo extra conseguido com o uso destas tecnologias pode ser utilizado

para o refinamento ou adicao de novas funcionalidades aos jogos, melhorando sua com-

petitividade no mercado. O uso de frameworks pode nao ser uma boa alternativa para

plataformas com limitacoes de hardware, como os celulares, pois consumem preciosos cic-

los de execucao e memoria que poderiam ser utilizados para os jogos. No entanto, a nova

geracao de aparelhos possui recursos de processamento e memoria bem mais abundantes,

o que permite o uso de frameworks e(ou) outras tecnicas de reuso sem grandes impactos

de performance.

Assim como aconteceu com os jogos para desktop que ja tem definido como padrao

o uso de interface grafica 3D, acredita-se que o mesmo ira ocorrer com os jogos para

celulares na medida que os aparelhos tenham maior capacidade de processamento e sejam

capazes de realizar o processamento grafico em hardware.

11

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 atraves do de-

senvolvimento de um framework para jogos 3D. Para a criacao 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 padroes que

devem ser seguidos para o desenvolvimento do framework. Desse modo o framework foi

construıdo de forma evolutiva durante a criacao de tres prototipos de jogos, os jogos Gor,

Sky e Tan. Estes tres prototipos foram gerados especificamente para o desenvolvimento

do framework, no entanto, sao projetos de jogos reais, que potencialmente poderiam se

tornar futuramente jogos comerciais.

A plataforma de desenvolvimento para ambiente movel escolhida para o framework

foi a Java Micro Edition(3) utilizando a configuracao CLDC 1.1 e perfil MIDP 2.0. Foi

utilizado tambem o pacote Mobile 3D Graphics API for J2ME (3) para o desenho dos

graficos 3D. Esta plataforma foi escolhida por ser uma plataforma completamente livre e

ja bem aceita no meio academico.

1.1 Objetivos

O principal objetivo deste trabalho e desenvolver um framework que seja funcional,

mas nao necessariamente completo, para o domınio de jogos 3D para ambiente moveis,

mais especificamente celulares. A escolha por nao criar um framework completo e devido a

natureza complexa dos frameworks e as restricoes de tempo que torna esta tarefa inviavel.

A elaboracao do trabalho tambem 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 movel e suas li-

mitacoes quanto ao desenvolvimento de software em relacao ao desktop;

• Conhecer melhor o universo dos jogos eletronicos, um pouco da teoria que os envolve

e os desafios que podem ser encontrados durante os seus desenvolvimentos.

12

1.2 Organizacao do Trabalho

Este trabalho foi organizado em duas partes, os tres primeiros capıtulos sao dedica-

dos a parte teorica, 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 moveis, como apa-

relhos de celulares e PDA, o desenvolvimento de jogos e o ambiente grafico 3D para estas

plataformas. Ja o capıtulo 4 aborda os jogos, aonde estao descritas algumas de suas ca-

racterısticas, desafios e uma descricao sobre Game Design, que e a tarefa de elaboracao do

jogo. No capıtulo 5 o projeto e descrito, desde o desenvolvimento dos jogos ate a evolucao

na construcao do framework. Finalizando, este trabalho no capıtulo 6 sao mostrados as

conclusoes e os trabalhos futuros.

13

2 Frameworks

A informatica 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 esforco

no desenvolvimento e ainda com ganho na sua qualidade. Este capıtulo e dedicado a

um estudo teorico ao uso e desenvolvimento de frameworks, suas caracterısticas, desafios,

desvantagens e metodologias.

2.1 Introducao

Utilizando a ideia basica de nunca refazer uma tarefa duas vezes, adaptando o que

ja foi produzido as novas necessidades, e que sao utilizadas as tecnicas de reuso de soft-

ware(5). Na pratica o processo de reuso e uma tarefa complexa, devem ser seguidos alguns

princıpios durante a construcao do codigo original para que esse possa ser reutilizado pos-

teriormente.

Existem diversas formas de fazer um reuso entre diferentes softwares. Uma das primei-

ras tecnicas utilizada foi o uso de bibliotecas de funcoes para reutilizacao de algoritmos

para controle de estrutura de dados e calculos matematicos. Atraves das funcoes os

codigos mais utilizados passaram a ser reaproveitados, mas ainda a grande maioria do

codigo e necessaria ser desenvolvida. Ja a orientacao a objetos com o conceito de objetos,

classe, heranca 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 relacao as funcoes. Com a orientacao a objeto alem do reuso de

uma classe como um todo atraves da composicao, permite o reuso de forma personalizada

atraves da especializacao de uma classe e sobrescrita de seus metodos.

Tanto as bibliotecas de funcoes quanto as de classes focam o reuso do codigo, 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

14

ser criada ou re-criada. Para suprir o reuso de arquiteturas e que sao utilizado os padroes

de projetos(6). Padroes de projetos sao solucoes propostas para problemas comuns de ar-

quitetura inseridas em um determinado contexto. Atraves dos padroes, os programadores

podem documentar e repassar suas decisoes de projetos. (6) define que um arquiteto de

software experiente nao resolve cada problema do nada, ele reutiliza solucoes que funcio-

naram no passado. Quando encontra uma boa solucao, 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

reutilizacao, nasceu os componentes. Componentes de software seguem a ideia dos com-

ponentes eletronicos(7), para realizar uma tarefa complexa voce compra um conjunto de

componentes fechados, conectando-os segundo o manual de entradas e saıdas de cada

componente. Nao e necessario saber como um componente funciona, e sim o que ele e

capaz de fazer. (8) define componentes de softwares como sendo “Instancias auto-contidas

de objetos abstratos que podem ser conectados para formar uma aplicacao completa”.

2.2 Definicao

Entre diversas definicoes de o que e um framework na literatura, citaremos duas

delas. De (4) “Frameworks sao 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 instancias

destas classes colaboram.”, o foco desta definicao e no reuso da arquitetura. Em (9)

“Framework e uma aplicacao “semi-completa” reusavel que pode ser especializada para

a construcao de aplicacoes personalizadas.”, o termo “semicompleta” passa a ideia da

grande reuso ao utilizar frameworks.

Frameworks e a tecnologia que tenta fazer o maximo de reuso possıvel. Faz o reuso

da arquitetura atraves do controle do fluxo da aplicacao, modelo de como as classes

se inter-relacionam e a definicao de como podem ser adaptadas pelos usuarios para a

geracao de novas aplicacoes. O reuso de codigo e feito por suas classes e sua biblioteca de

componentes.

A fig. 1 ilustra o nıvel de reuso que pode ser alcancado atraves do uso de frame-

works. A area pontilhada representa o framework, enquanto a area lisa representa as

classes implementadas pelo usuario. E importante notar que as classes do framework tem

relacionamentos internos, e as classes do usuario sao uma pequena porcao da aplicacao,

que foram criadas utilizando a heranca.

15

Figura 1: Aplicacoes e frameworks(1)

Alem do reuso de codigo o uso de frameworks tambem proporciona uma serie de

outras vantagens. O aumento na qualidade do software desenvolvido, pois os frameworks

geralmente sao criado por engenheiros de software experientes e especialistas no domınio

do problema. Cria tambem um padrao entre todas as aplicacoes desenvolvidas com ele.

Atraves deste padrao, e mais facil para um programador iniciar a manutencao de uma

aplicacao uma vez que ele ja conheca a arquitetura do framework.

O reuso de codigo do framework pela aplicacao pode ser realizado basicamente de duas

formas. Primeiro atraves da heranca entre classes do framework e aplicacao, conhecido

como reuso do tipo caixa branca(white-box frameworks)(6). A segunda forma e feito

pela composicao entre as classes da aplicacao e do framework, o reuso pela composicao e

chamada de reuso do tipo caixa preta(black-box frameworks)(6).

Os frameworks que predomina o reuso caixa branca sao caracterizados por ter ge-

ralmente disponıvel o codigo fonte para o usuario. O desenvolvimento da aplicacao e

feito pela especializacao de classes do frameworks e sobrecarga de metodos, que muitas

vezes ja sao pre-definidos pelos desenvolvedores do framework. Mesmo que exista uma

documentacao para o framework disponıvel, a maior fonte de informacoes para os pro-

gramadores sera o codigo fonte.

Nos frameworks com predominancia do reuso caixa preta, geralmente o codigo fonte

nao e disponibilizado ao usuario. A implementacao e feita atraves da implementacao

de classes atraves da implementacao de interfaces pre-definidas e pela composicao entre

componentes do framework. Neste tipo de framework como os desenvolvedores nao tem

acesso ao codigo fonte, portanto nao podem ve-lo ou altera-lo, o framework deve estar

16

em nıvel elevado de maturidade e toda a fonte de informacao deve ser fornecida via

documentacao.

2.3 Desenvolvimento de Frameworks

Um framework nao pode ser generico o suficiente para gerar qualquer tipo de aplicacao,

ele deve estar inserido em um domınio especıfico como interface grafica, simulacao fısica

ou persistencia de dados. A abrangencia de um domınio tambem deve ser considerada

durante seu desenvolvimento, frameworks com abrangencia muito grande tende a ter

uma percentagem pequena de aproveitamento, ja frameworks mais especıficos tem menor

possibilidade de serem utilizados.

Uma das principais caracterısticas dos frameworks e a inversao de controle(7), aonde

o framework passa a controlar o fluxo de execucao do domınio e o codigo da aplicacao

e chamado pelo framework. A inversao de controle tambem e chamada de “Principio de

Hollywood” que significa “Nao nos procure, nos o procuraremos”(8).

“Enquanto desenvolver softwares complexos ja e difıcil, desenvolver frameworks de

alta qualidade, extensibilidade e reusabilidade para aplicacoes 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 deverao ser previstas ainda durante seu

desenvolvimento, e para as nao previstas devem existir alternativas.

Assim como desenvolver, a manutencao de frameworks e um processo trabalhoso.

Alem do proprio funcionamento do framework, devem ser consideradas as implicacoes

que podem ocorrer nas aplicacoes ja desenvolvidas e futuras. Caso a nova versao do

framework nao seja 100% compatıvel com as anteriores ou novos problemas tenham sido

gerados, testes e correcoes serao necessarios em todas as aplicacoes ja desenvolvidas.

No ponto de vista do modelo de negocios de uma empresa, o desenvolvimento de

um framework pode nao ser comercialmente favoravel devido ao seu alto custo de desen-

volvimento. O desenvolvimento so vale apena para uma empresa caso o framework seja

utilizado em larga escala(10).

Testar se um framework esta correto e flexıvel suficiente e um processo difıcil, e so

pode ser realmente verificado com o desenvolvimento de aplicacoes finais, e mesmo assim

nunca e possıvel testa-lo completamente(10).

17

2.4 Problemas com uso de Frameworks

O uso de frameworks traz uma serie de vantagens, mas tambem um conjunto grande

de problemas.

Dado um conjunto de frameworks candidatos para o desenvolvimento de uma ap-

licacao, a decisao 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

relacao ao tempo de desenvolvimento da aplicacao(10), isso se deve principalmente ao fato

de que o programador deve aprender a utilizar o framework antes de comecar o desen-

volvimento. Utilizar um framework de forma correta e tao essencial quanto desenvolver

uma aplicacao de forma correta. Em um framework bem feito todas as tarefas comuns em

determinado domınio sao previstas, a tarefa dos programadores e encontrar estes pontos

pre-definidos.

Outro problema relacionado com o uso de frameworks esta relacionado com a identi-

ficacao e depuracao de erros. E muito mais difıcil em aplicacoes que utilizam frameworks

identificar se um determinado erro pertence ao framework ou a aplicacao, principalmente

quando nao se tem acesso ao codigo fonte do framework. Neste caso, isto acontece devido

a inversao de controle aonde o codigo do usuario 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 identificacao e depuracao de codigo.

A integracao de diferentes frameworks pode causar muitos problemas. A grande

maioria dos frameworks nao esta preparado para trabalhar de forma integrada. Um

exemplo deste problema e a integracao de dois frameworks que foram desenvolvidos para

ter o total controle sobre o fluxo da aplicacao.

18

2.5 Metodologias de Desenvolvimento de Frameworks

Na literatura existem algumas metodologias para o desenvolvimento de frameworks.

Nesta secao sera descritas as metodologias de desenvolvimento de framework dirigidas

por exemplos (exemple-driven design)(11), dirigidas por pontos de flexao (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 numero

possıvel de aplicacoes ja desenvolvidas. Uma analise deve ser feita para identificar quais

partes das aplicacoes sao comuns e quais sao especıficas. As partes comuns devem ser

generalizadas de modo que passam a constituir o framework. As partes especıficas das

aplicacoes devem ser desenvolvidas na forma de metodos de gatilho (hook). Os metodos

de gatilho sao um padrao utilizado por uma aplicacao ou framework para fazer chamadas

para partes de codigos nao existentes no seu desenvolvimento.

Para verificar se o framework foi bem desenvolvido, deve-se implementar novamente

as aplicacoes exemplos, mas desta vez utilizando o framework desenvolvido como base.

Este metodo e mais indicado quando ja se tem as aplicacoes desenvolvidas (ou esteja

disposto a desenvolve-las). E quanto mais aplicacoes foram utilizadas como exemplos,

mais generico sera o framework.

2.5.2 Dirigido por pontos de flexao

Nesta metodologia (12) deve-se dar inıcio ao desenvolvimento da arquitetura e imple-

mentacao do framework para o domınio especıfico, e com o intuito de manter o framework

flexıvel deve-se buscar os pontos de flexao (hot spots). Os pontos de flexao sao regioes de

codigo especificas de cada aplicacao, como metodos de resposta a eventos que tem com-

portamento diferentes em cada aplicacao. Nestes pontos sao aplicados diversos padroes

para manter o codigo flexıvel.

Esta metodologia seria melhor utilizada em um contexto em que se deseja desenvolver

as aplicacoes de um determinado domınio, mas antes e desenvolvido um framework para

servir como base. Neste caso a implementacao das aplicacoes e o melhor caso de teste.

19

2.5.3 Frameworks Evolutivos

Frameworks evolutivos (4) e uma metodologia formada por uma linguagem de padroes

que devem ser seguidos durante o desenvolvimento do framework. Os nove padroes pro-

postos servem como um guia de alto nıvel, para o desenvolvimento de um framework de

forma evolutiva. Nenhum destes padroes sao obrigatorios ou devem ser seguidos de forma

sequencial. A fig. 2 contem um grafico com todos os padroes.

1. 3 Exemplos

2. Framework de Caixa Branca

3. Framework de Caixa Preta

4. Biblioteca de Componentes

5. Pontos de Flexao

6. Objetos Conectaveis

7. Objetos Refinados

8. Construtor Visual

9. Ferramentas de Linguagem

Figura 2: Grafico com os padroes pelo tempo

20

2.5.3.1 3 exemplos

Este primeiro padrao tenta resolver o problema de como comecar o desenvolvimento do

framework. Como um framework representa uma abstracao de um determinado domınio

de aplicacao deve-se entao buscar um meio de abstrair o domınio.“Pessoas desenvolvem

abstracoes a partir da generalizacao de exemplos concretos”(4). De modo a conseguir

os exemplos concretos sao desenvolvidas N aplicacoes exemplos de forma sequencial, e

durante o desenvolvimento de cada nova aplicacao o framework e construıdo.

Criado a primeira aplicacao exemplo, ela sera a base para inıcio do framework e a

primeira fonte de informacoes sobre o domınio. Deve-se planejar o segundo exemplo ana-

lisando o primeiro para identificar as partes comuns e distintas. Deve-se entao dar inıcio

a construcao do framework tentando sempre aproveitar o maximo possıvel do primeiro

exemplo, seja criando abstracoes das classes do primeiro de modo que faca sentido no

segundo exemplo tambem, ou generalizando de modo que o segundo seja implementado

sobre o ele.

Tendo a primeira versao do framework e dois exemplos desenvolvidos, o segundo ja

utilizando o framework, deve-se iniciar um novo ciclo para os proximos exemplos. Mas

agora sempre utilizando o framework ja criado nas interacoes anteriores mas aproveitando

sempre, na medida do possıvel as aplicacoes ja desenvolvidas. Um ponto importante e

que o framework nao pode ser direcionado para a proxima aplicacao, e sim generalizado

para que de suporte a outra aplicacao.

(4) recomenda que devem ser utilizados tres exemplos para a criacao da primeira

versao do framework. Esta escolha se deve ao fato de que uma unica aplicacao nao

permite uma visao suficiente do domınio, e um numero grande de aplicacoes exemplos

pode causar um atraso muito grande na primeira versao do framework.

2.5.3.2 Frameworks de Caixa Branca

Quando da o inıcio do desenvolvimento do framework, uma das decisoes de projeto que

deve ser escolhida e entre manter a flexibilidade atraves do uso de heranca e polimorfismo

ou via composicao de componentes. Este padrao recomenda que inicialmente deve-se

tentar apenas fazer o maior proveito possıvel de codigo, e provavelmente as informacoes

adquiridas ate o momento nao sao suficientes para decidir quais partes serao constantes,

e quais variaveis. Portanto, deve-se construir o framework atraves do reuso do tipo caixa

branca e conseguir a flexibilidade atraves da heranca.

21

2.5.3.3 Biblioteca de Componentes

Durante o desenvolvimento das aplicacoes a partir do framework e necessario as vezes

implementar os mesmos componentes para problemas distintos, e de alguma forma esses

componentes nao participam do domınio do framework. Exemplos de componentes co-

muns sao os utilitarios ou repeticao das mesmas implementacoes de certas super classes

do framework. Para eliminar a reescrita destes componentes deve-se criar entao uma bi-

blioteca com componentes concretos e disponibiliza-lo junto com o framework, para o caso

dela ser necessaria. Deve-se iniciar apenas com os componentes mais obvios e na medida

em que for sendo necessario, adiciona novos componentes. E a medida que componentes

da biblioteca deixem de ser utilizados, eles devem ser removidos.

2.5.3.4 Pontos de flexao

Durante o desenvolvimento das aplicacoes e possıvel identificar que certos trechos sao

editados com muita frequencia. Estes trechos de codigo sao identificados como os pon-

tos de flexao (hot spots). Caso estes pontos estejam muito espalhados pela aplicacao, a

identificacao destes pontos e sua manutencao se torna um processo muito trabalhosos. O

padrao recomenda que os pontos de flexao devam ser separado do codigo, preferencial-

mente encapsulados por objetos. Separar o codigo que varia para um objetos alem de

facilitar o reuso, tambem facilita para o os usuarios do framework saibam qual codigo

deve ser alterado.

2.5.3.5 Objetos Conectaveis

Algumas vezes e necessario estender classes do framework para realizar pequenas

alteracoes de codigo ou no valores de variaveis. Deve-se entao criar entao uma sub classe

especializada que seja capaz de ser configurada atraves de parametros. Esta nova classe

e um perfeito candidato para sua biblioteca de componentes.

2.5.3.6 Objetos Refinados

Durante a evolucao do framework, diversos novos componentes serao inseridos na

biblioteca. Para aumentar a quantidade de reuso da biblioteca de componentes e eli-

minar algumas redundancias de implementacoes, deve ser realizada uma fatoracao dos

componentes. A fatoracao deve dividir os componentes da biblioteca em componentes

menores, que poderao ser reconstituıdos atraves da composicao. O padrao alerta que os

22

componentes devem ser fatorados ate que uma outra fatoracao resulte em um componente

individualmente sem sentido.

2.5.3.7 Framework de Caixa Preta

Apos 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 composicao, conec-

tando componentes para a integracao do framework com a aplicacao. As vantagens da

composicao sobre a heranca e que ela pode ser alterada durante o tempo de execucao e

necessita um menor entendimento dos usuarios sobre classes do framework, ja que para

resolver o problema basta implementar um componentes especifico e agregar ao frame-

work.

Para a implementacao deste padrao, recomenda-se utilizar a heranca para organizacao

interna do framework e da biblioteca de componentes, e usar a composicao para integrar

com aplicacao. Para as classes do usuario a parte mutavel deve ser removida do framework

e deve ser colocada em classes ou interfaces que devem ser implementadas pelos usuarios.

2.5.3.8 Construtor Visual

Quando se tem um framework do tipo caixa preta ja maduro, e possıvel construir

aplicacoes simplesmente atraves da composicao de componentes ja pre-definidos na bi-

blioteca, necessitando muito pouco codigo. A parte mais difıcil do desenvolvimento passa

a ser o entendimento dos componentes e como conecta-los.

O padrao propoe a construcao de um script responsavel pela conexao e inicializacao

dos componentes. Uma aplicacao grafica seria responsavel pela criacao destes scripts para

geracao do codigo do framework. A criacao visual e muito mais rapida e precisa de menos

esforco no conhecimento do framework, alem de que o usuario nao precisa necessariamente

ser um programador.

2.5.3.9 Ferramentas de Linguagens

A construcao visual atraves de uma aplicacao grafica traz uma serie de vantagens

por desassociar o framework da linguagem de programacao em que foi desenvolvido. Em

compensacao devido a este mesmo motivo a verificacao e depuracao dos componentes alta-

mente compostos e criados em tao alto nıvel e uma tarefa difıcil. Devem ser desenvolvidas

ferramentas com este objetivo pelo menos para as regioes mais complexas do framework.

23

2.6 Documentacao

E possıvel tirar todas as vantagens do reuso de um framework apenas quando os

usuarios tem pleno conhecimento sobre o funcionamento do mesmo. Portanto a docu-

mentacao e essencial no processo de desenvolvimento do framework.

(13) descreve o uso de padroes para a documentacao de frameworks, e cita que uma

documentacao deve cobrir tres objetivos basicos sobre o framework: seu proposito, como

utiliza-lo e uma visao detalhada de sua arquitetura.

O proposito do framework deve ser escrito de forma curta e clara, deve ser des-

tinado aos usuarios que ainda nao tem conhecimento algum sobre o framework. Deve

descrever os pontos fortes e fracos, e outras informacoes importantes para que o leitor

possa ponderar em utilizar ou nao o framework. Deve ser curto o suficiente para ser

utilizado como resultado de uma busca ou em um catalogo.

O documento que descreve como utilizar o framework se destina a usuarios novos e

antigos, que precisam resolver um determinado problema utilizando o framework. Geral-

mente sao leitores com pressa e que querem apenas a solucao, nao 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 sao basicamente descricoes de passos

a serem seguidos para alcancar determinado objetivos, sem muita descricao do porque e

como de cada passo. Estes tipos de documentos podem ser escritos utilizando-se padroes,

apenas invertendo o foco de um objetivo a ser alcancado, por um problema a ser resolvido.

O detalhamento da arquitetura do framework e direcionado para os proprios

desenvolvedores do framework ou para usuarios avancados, que precisam resolver proble-

mas nao triviais nao descritos no documento de uso do framework. Deve descrever suas

classes e como suas instancias interagem. Diagramas de classe e colaboracao na medida

do possıvel devem ser inseridos nestes documentos. Caso um framework tenha disponıvel

seu codigo fonte, ele sera parte desta documentacao, mas de forma separada.

(13) cita ainda que um importante auxılio na documentacao de frameworks sao os

exemplos. Exemplos sao a forma mais direta de se entender o problema e a solucao de

uma forma real, exemplos e podem ser usado pelos usuarios como laboratorio para realizar

alteracoes de experiencia. Devem ser utilizados na medida do possıvel no documento de

como utilizar o framework. Exemplos de aplicacoes completas tambem sao uma fonte

de informacoes muito util, alem de servir de teste para o framework, permite aos novos

usuarios entenderem o framework como um todo.

24

2.7 Testes

Implementar aplicacoes 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 aplicacao. A nao ser que o framework seja vendido para terceiros,

nao serao necessarios testes maiores que pequenos exemplos para testar as funcionalida-

des do sistema. Os testes reais serao realizados durante a utilizacao do framework, e

continuamente ele devera ser adaptado para se tornar mais flexıvel.

25

3 Plataforma Movel

Neste capıtulo contem o estudo sobre os dispositivos moveis e suas plataformas. Na

introducao 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 restricoes no desenvolvimento para movel. Fechando, algumas das

tecnologias existentes para geracao grafica 3D tambem para movel.

3.1 Introducao

A primeira geracao de celulares foi na decada de 1980, estes aparelhos eram uma

evolucao dos telefones instalados nos automoveis de luxo. Eram aparelhos sem poder de

processamento e com transmissao analogica. Ja a segunda geracao de celulares, conhecido

como 2G, comecou na decada de 90. Foram diversos os padroes de comunicacao digital

criados, entre eles o GSM (Global System for Mobile Communications) que e o padrao

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):

• Gravacao/Leitura de audio e vıdeo;

• Bluetooth: comunicacao de curta distancia entre aparelhos de alta velocidade;

• WAP (Wireless Application Protocol): Navegacao na internet;

• DRM (Digital Rights Management): Baixar arquivos para o aparelho atraves 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: Padrao para comunicacao entre aplicacoes de diferentes plataformas

via rede;

• GPS (Global Positioning System): Localizar a posicao fısica do aparelho no mundo;

• Java: Rodar aplicacoes 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 explosao

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 usuarios adquirirem novos aplicativos, diferentes

daqueles ja 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 moveis devido as limitacoes de hardware, os jogos

das pequenas empresas podem competir com as grandes de maneira mais justa.

3.2 Plataformas e Portabilidade

A explosao no mercado de celulares tambem 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-

ferenca de recursos disponıveis, quantidade de memoria e velocidade de processamento e

linguagens suportadas. A implementacao direta sobre o hardware dos aparelhos e uma

tarefa com custos muito alto para aplicacoes genericas. A solucao adotada e inserir uma

plataforma sobre o hardware para minimizar as diferencas. Destas plataformas as mais

comuns sao:

• Symbian OS;

• Brew;

27

• J2ME;

• Exen.

3.2.1 Symbian OS

O Symbian OS e um sistema operacional completo, sua versao para dispositivos moveis

com contem bibliotecas, framework para interface com usuario e ferramentas de auxilio.

Este sistema operacional tem suporte a multi tarefa preemptivas, multi-thread e protecao

de memoria. Uma das grandes qualidades deste sistema operacional e a gerencia de

memoria que utiliza tecnicas para reduzir o uso de memoria e vazamentos. As aplicacoes

sao 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 diferencas entre aparelhos disponibilizando aos desenvolvedores uma API solida

e comum. O Brew suporta aplicacoes tanto em C como em C++ que rodam de forma

nativa. Para disponibilizar os aplicativos nesta plataforma deve ser utilizado o modelo

de negocios proprio da Qualcomm, que faz conexao direta entre os desenvolvedores e a

operadora. Na fig. 3 pode ser visto a arquitetura da API BREW e os diversos tipos de

aplicacao e servicos que ela disponibiliza.

Figura 3: Aquitetura Brew(2)

28

3.2.3 J2ME

O J2ME (Java 2 Micro Edition)(3) e um conjunto de APIs simplificada da versao J2SE

(Java 2 Standard Edition) para dispositivos com baixos recursos de hardware. Geralmente

a maquina virtual e implementada pelos proprios fabricantes dos aparelhos utilizando as

especificacoes da SUN. As aplicacoes escritas em java para a J2ME sao chamadas de

MIDlets.

Figura 4: Arquitetura do J2ME(3)

Como pode ser visto na fig. 4 a arquitetura do J2ME e dividida em tres partes. A

primeira mais inferior e o sistema operacional do proprio aparelho.

A segunda parte, a configuracao 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 codigo compilado a partir dos fontes Java. As bibliotecas sao

o conjunto de classes mınimas com as API disponıvel para as aplicacoes. A configuracao

pode ser diferente dependendo do aparelho, elas definem os requisitos mınimos, e estao

divididas em duas categorias dependendo da quantidade de memoria disponıvel, veloci-

dade e tipo de processador. A maquina virtual e um conjunto de bibliotecas fazem parte

da configuracao.

• CLDC (Connected Limited Device Configuration): para processadores 16 e 32 bits

com no mınimo de 160kb de memoria. A versao 1.0 limita a maquina virtual,

configuracao, profile, pacotes opcionais e aplicacao em ate 512kb. Ja na versao 1.1,

o limite e a quantidade de memoria disponıvel.

29

• CDC (Connected Device Configuration): Para equipamentos mais rapidos que o

CLDC com o mınimo de memoria de 2Mb. Geralmente sao processadores 32 bits.

Ja a parte mais superior da arquitetura estao os perfis, sao um complemento as con-

figuracoes para tornar o ambiente completo para a execucao de aplicacoes, contem um

conjunto de classes de apoio mas nao essenciais para a execucao das aplicacoes. O MIDP

(Mobile Information Device Profile) e o perfil desenvolvida para os celulares e PDAs e

roda sobre a configuracao CLDC. Fornece em sua API para as aplicacoes com interface

com usuario, acesso a rede e persistencia e acesso a funcoes especificas dos aparelhos. O

MIDP tambem existe em duas versoes, 1.0 e 2.0. A segunda versao cumpre o seguinte

escopo:

• Entrega e faturamento de aplicacoes;

• Ciclo de vida da aplicacao;

• Modelo para certificar aplicacoes e privilegios;

• Transferencia segura de fim-a-fim atraves do HTTPS;

• MIDlet push registration, inicializar aplicacoes sem interacao do usuario;

• Acesso a rede;

• Persistencia de dados;

• Som;

• Timers ;

• Interface com usuarios (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 configuracoes CLDC e CDC. Estes

pacotes trazem novas funcionalidades para as aplicacoes, e geralmente estao agregados a

alguma funcionalidade especifica do hardware. Alguns exemplos de pacotes opcionais sao

os web services, arquivos de mıdia, conexao com banco de dados, mensagens e graficos

3d. A fig. 5 permite visualizar toda a plataforma J2ME como um todo, com suas confi-

guracoes, perfis e pacotes opcionais

30

Figura 5: Configuracoes, perfis e pacotes opcionais.

Apesar da proposta da Sun de desenvolver uma plataforma uniforme para o desenvol-

vimento, devido a ma implementacao das maquinas virtuais pelas empresas de fabricacao

dos aparelhos, e comum durante a migracao para um aparelho diferente ocorrer uma serie

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 serie 60

da Nokia. Mesmo a linguagem java seguir o padrao Write once, run everywhere (escreva

uma vez, rode em todo lugar) foram necessarias 79 alteracoes no codigo, com uma media

de 2 linhas alteradas por modificacao.

3.2.4 Exen

Exen ou Execution Engine foi a primeira plataforma exclusiva para a execucao de

jogos. Esta plataforma roda aplicativos java e por ter sua API implementada em codigo

nativo do aparelho sua maquina virtual e muito mais rapida. No entanto esta plataforma

esta disponıvel em apenas para aparelhos de algumas operadoras na europa.

31

3.3 Desenvolvimento de Jogos para Moveis

Para a implementacao de aplicacoes, mais especificamente os jogos, tem um serie

de caracterısticas e desafios quando desenvolvidas para dispositivos moveis. Nesta secao

serao descritas algumas destas caracterısticas.

Em relacao ao hardware temos os seguintes caracterısticas:

• Baixo poder de processamento;

• Pouca quantidade de memoria e com baixa velocidade de acesso;

• Pouco espaco em disco;

• Baixa velocidade de transmissao pela rede;

• Energia por tempo limitado;

• Diversos fatores relacionados a usuabilidade: tamanho da tela, resposta de botoes,

som...

• Ausencia de ponto flutuantes.

Em relacao ao ao software, temos as seguintes caracterısticas:

• APIs reduzidas;

• Limite no tamanho das aplicacoes;

• Numero de aplicacoes em execucao;

• Limitacoes no uso de ponto flutuante (implementado via software);

• Testes exaustivos para nao danificar o software do aparelho;

• Uma serie de eventos devem ser tratados como: falta de energia, numero de arquivos

abertos e chamadas telefonicas.

Estas caracterısticas estao relacionadas a todas as etapas do desenvolvimento do jogo,

deste o game design4.4 do jogo ate os testes. Durante o design do jogo, os designers tem

que ter em mente que nao existe memoria e nem processamento de sobra, portanto apenas

as funcionalidades essenciais devem estar presentes. Jogos de acao que exigem muitos

32

reflexos tambem nao sao apropriados, devido a baixa taxa de quadros dos aparelhos e

ma disposicao e resposta do teclado. Durante a fase de desenvolvimento deve existir uma

etapa de otimizacao de codigo aonde deve-se otimizar os pontos no programa com maior

consumo de processamento e(ou) memoria. A otimizacao e um processo muito importante

pois alem do o jogo ficar mais leve, o espaco 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 instalacao, a execucao, a desinstalacao

e a delecao. Todas estas etapas devem funcionar corretamente em diferentes aparelhos

e considerando uma serie de eventos ja citados anteriormente. Como o usuario nao tem

acesso direto ao sistema operacional, qualquer operacao de manutencao em um aparelho

destes e trabalhosa e caro. No modelo de negocios 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 sao muito rigorosos e dependendo do caso

pode atrasar o lancamento do jogo em varios meses.

3.3.1 Graficos 3D

A utilizacao de graficos 3D nos jogos a muito tempo ja se tornou um padrao para

os jogos de PC e consoles. Para plataforma movel os jogos 3D ainda sao poucos em

comparacao com os 2D, no entanto, e certo que este cenario se inverta a medida que o

processamento destes aparelho cresca. Como o framework sera desenvolvido para jogos

3D, nesta secao sao apresentados algumas das tecnologias 3D para dispositivos moveis.

Basicamente existem dois modos diferentes de se desenhar objetos 3D, o primeiro e

utilizando uma API de acesso hardware de aceleracao 3D como OpenGL ES(16). A outra

e realizando todas as transformacoes via software e desenhando em uma imagem 2D.

Apesar da especificacao de OpenGL ES ja estar em sua versao 2.0 ainda sao 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)

33

• M3G(3)

3.3.1.1 OpenGL ES

OpenGL ES(16) e uma API inter plataforma, livre de royalty, com plena funcionali-

dade de aceleracao 2D e 3D para dispositivos moveis. Ela foi desenvolvida a partir de um

consorcio entre empresas de software e hardware. Algumas empresas participantes desde

consorcio sao: ARM, ATI, Nokia, Motorola, Intel, NVIDIA, Sony e Sun(16).

Ela utiliza como base a ja consagrada API OpenGL e sofreu uma serie de alteracoes

para poder dar suporte a aparelhos com baixos recursos de hardware. Foram removido

funcionalidades computacionalmente caras, redundantes ou inuteis para ambiente movel.

A API utiliza a ideia de perfis e extensoes que permitem a alguns aparelhos terem

recursos a mais como shaders ou acessar otimizacoes 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 numero

de ferramentas. Os jogos sao desenvolvidos em um ambiente proprio independente de

plataforma e que engloba nao apenas a programacao, mas a parte artıstica do desenvol-

vimento. O motor foi desenvolvido de forma modular e permite a insercao e remocao de

diversos pacotes, como por exemplo o pacote para genero de jogos de corrida.

O motor utiliza uma arquitetura de duas camadas, a primeira e responsavel por criar

a API indepedente de plataforma para a segunda. Ja 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 versao de java 3D para dispositivos

moveis e a especificacao numero 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 sao 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 relacao ao J3D (Java 3D). M3G e um pacote do tipo opcional e foi

34

desenvolvido para J2ME/CLDC com perfil MIDP 1.0 ou 2.0. Para se ter uma ideia do

funcionamento e das limitacoes abaixo esta listado os requisitos declarados na especificacao

do JSR 184:

• Suportar acesso via modo retained, deixando as tarefas de desenho para a API;

• Suportar acesso via modo immediate, o usuario deve fazer chamadas a API para

que objetos sejam desenhados;

• Suportar uma mistura dos dois tipos de acessos, retained e immediate;

• Todos os metodos da especificacao 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 variavel float e introduzir novos tipos de variaveis basicas;

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

em hardware;

• Recomenda-se que o consumo de memoria 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 composicao das imagens 3D. Para a criacao

do grafo de cena diferentes objetos como luzes, cameras, modelos 3d, transformacoes

geometricas, materiais, sao conectados em forma de arvore. A API entao utiliza este

grafo para realizar otimizacoes e desenhar a na tela.

35

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 introducao sobre mercado de jogos, posteriormente e mostrado uma classificacao

informal quanto os tipos de jogos, em seguida algumas das caracterısticas relacionadas ao

desenvolvimento de jogos. Por fim, uma descricao das parte de um game design.

4.1 Introducao

Os jogos eletronicos sao um meio de entretenimento muito difundido, estao 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 eletronicos. Destes apenas 35% sao menores de 18 anos, a media de idade de

35 anos. Em media 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 voluntarios, atividades religiosas, atividades culturais ou lendo. O

mercado de jogos eletronicos movimentou US$ 28 bilhoes em todo o mundo em 2003(19),

e que desde 2003 superou o mercado cinematografico (18).

Uma das principais caracterısticas dos jogos e a interatividade. Ao contrario de um

livro ou um filme, o jogador tem o poder de alterar o rumo da historia, 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 medias 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 estacao espacial virtual foi comercializada entre

dois usuario por 100 mil dolares(20).

36

4.2 Tipos de Jogos

Jogos sao lancados quase que diariamente, e gracas ao avanco da internet os lancamentos

sao 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 vastidao dos jogos, abaixo serao descritos

alguns tipos em relacao a diferentes categorias.

Quanto a tecnologia de interface grafica utilizada:

• Textual: Estes jogos foram muito comuns ate o lancamento das placas de vıdeos e

monitores graficos. Alguns sao como livros com pequenos problemas de logica que

precisam ser resolvidos para continuar, outro mais interativos e ate com desenhos

utilizando caracteres especiais.

• 2D: Estes jogos sao formados por imagens retangulares sobrepostas, fazem grande

uso de transparencia. E a categoria que tem o maior numero de jogos. Este tipo

de interface para jogos em hardwares com abundancia de memoria e processamento

ja e considerada obsoleta, mas ainda e muito utilizada em jogos mais simples ou de

baixo processamento.

• 3D: Utilizam modelos 3D e textura para composicao das cenas, teve grande popu-

larizacao gracas as placas de vıdeo 3D que existem no mercado. Quase sem excecao

todas as grandes producoes para microcomputadores sao hoje desenvolvidas com

esta tecnologia.

Quanto ao modo de visualizacao do mundo pelo jogador:

• Primeira Pessoa: O jogador tem a visao como se fosse o personagem, e ve com seus

proprios 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 visao do jogador e como uma camera flutuante que segue o

personagem aonde ele for, geralmente mantendo uma certa distancia.

• Visao de Deus: Este tipo o jogador tem uma visao do todo, ou aerea do mundo. E

o tipo mais utilizado principalmente pelos jogos de interface 2D.

Quanto ao estilo do jogo:

37

• Acao: Talvez o mais generico dos generos. Estes jogos tem como objetivo estimular

os reflexos do jogador, muitos passam a sensacao de perigo e fixam o jogador em

nao tirar os olhos sobre o monitor.

• Aventura: Sao jogos geralmente com uma historia linear, aonde o personagem tem de

cumprir objetivos e resolver quebra cabecas para tentar alcancar o final da historia.

Geralmente e o genero que traz historias mais criativas e elaboradas.

• Tiro: Sao jogos de acao em primeira pessoa, normalmente caracterizados por atirar

em quem aparecer em sua frente. Salvo algumas excecoes.

• Esporte: Estes jogos tentam simular partidas reais como de futebol ou basquete.

Na grande maioria o jogador fica responsavel por controlar os jogadores de um

time, mas ha tambem aqueles aonde o jogador controla apenas o tecnico e que deve

gerenciar uma equipe.

• Estrategia: Sao jogos em que bombardeiam o jogador com uma serie de citacoes em

que ele deve tomar decisoes, a soma de suas escolhas e que resulta no sucesso ou

fracasso no jogo.

• Simuladores: Jogos que fazem simulacoes de coisas reais, os mais comuns sao os

simuladores de carros ou de avioes. Muitos destes jogos implementam uma simulacao

fısicas altamente realistas e sao utilizados para treinamentos para uso real.

• RPG (Role Play Gaming): Seguindo os RPG tradicionais, o jogador assume o papel

de personagem, ele deve tomar decisoes atraves de uma historia. 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. Sao jogos geralmente violentos e competitivos, fazem grande uso

dos reflexos.

• Educacional: Sao jogos desenvolvidos nao apenas para entretenimento, mas como

principal objetivo ensinar alguma coisa a seus jogadores. Jogos infantis para ensino

da matematica e simuladores aereos para treinamento de pilotos tambem entram

nesta categoria.

• Puzzle: Puzzles sao desafios logicos, sao muito usados como passatempo.

• Cartas: Sao jogos que simulam jogos de cartas reais como canastra ou poker.

38

Quanto ao numero 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 sao desenvolvidos com tecnicas avancadas de

inteligencia artificial.

• Em grupo: Geralmente entre 2 a 100 jogadores, geralmente sao dividos em grupos

e competem entre si.

• Massivo: Estes jogos sao caracterizados por mais de 500 jogadores simultaneos, ge-

renciado por grandes servidores. Estes jogos sao geralmente persistentes e as escol-

has dos jogadores em um partida podem ter consequencias 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 acao, as respostas acontecem a

eventos do usuario 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 varias vezes por segundo, durante

cada processamento deve ser realizado a simulacao fısica e colisoes, inteligencia artificial,

e atualizacao da tela.

4.3 Caracterısticas no Desenvolvimento de Jogos

Jogos e um topico interessante na area da computacao por abordar o estudo em

varias ciencias, tecnicas e nao tecnicas. Apesar de um jogo ser um software e depender das

tecnicas de desenvolvimento e programadores, o sucesso de um jogo esta baseado muito em

sua concepcao Algumas das areas utilizadas atualmente para o projeto e desenvolvimento

dos jogos:

• Computacao Grafica: Objetos animados em 3D, sombras volumetricas e reflexos

sao algumas das tarefas responsaveis pela computacao grafica, e deve ser efetuada

dezenas de vezes por segundo. Graficos realistas e bonitos sao os principais chamariz

dos jogos, gracas as novas geracoes de placas de vıdeo 3D.

• Inteligencia Artificial: Em jogos de um unico jogador, a interacao se baseia comple-

tamente em acoes tomadas pelo computador, e este deve atuar de forma inteligente

que mostre realismo e desafie o jogador.

39

• Arte: Imagens sao utilizadas para texturas de modelos 3d e para a composicao da

interface de usuario. De modo mais indireto todo o trabalho de arte envolvido na

concepcao do jogo, arquitetura do ambiente de jogo, roupas e os proprios persona-

gens sao alguns exemplos.

• Comunicacao de Dados: Certamente os jogos aonde a comunicacao de dados e

mais visıvel sao os jogos MMO (Massive Multiplayer On-line) aonde seus servido-

res 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 milhoes de usuarios cadastrados.

• Simulacao: Grande quantidade dos jogos desenvolvidos hoje sao na verdades simu-

ladores em tempo real. Bibliotecas fısicas sao capaz de simular em tempo real a

dinamica de corpos rıgidos, roupas, lıquidos 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 sao algumas das

tarefas realizadas pelos jogadores e deve ser da forma mais intuitiva possıvel.

• Som: Efeitos sonoros e musicas sao fundamentais para a imersao dos jogadores no

universo do jogo. Enquanto as musicas criam o clima necessario em cada ato, o

efeitos sonoros criam maior realidade no que se ve na tela.

Todas as areas citadas anteriormente estao diretamente relacionadas ao desenvol-

vimento de parte do software. Mas outras areas distantes da Ciencias da Computacao

tambem sao utilizadas durante o planejamento. Jogos devem ter um historia interessante,

personagens com personalidades e um universo realista. Para definir estes elementos e

necessario utilizar outras areas de pesquisa, por exemplo a psicologia, fotografia, historia

e estrategia.

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 facamos

tudo corretamente, ainda corremos o risco de criar um jogo chato. Para evitar isso alem

do bom senso as empresas utilizam grandes equipes de testes, forum para comunicacao

com os jogadores e lancamento de versoes alphas e betas para grupos restritos de usuarios.

As equipes de desenvolvimento de jogos geralmente sao bastante heterogeneas, os

programadores devem trabalhar integrado com profissionais de outras areas, e muitas

40

vezes sao minoria. Para se ter uma ideia o StarCraft, jogo de grande sucesso da Blizzard

Entertainment, teve 53 pessoas na gerencia, atividades comerciais e design do jogo, 108

em arte, 51 nos testes e apenas 16 pessoas envolvidas na programacao.

4.4 Game Design

O game design1 de um jogo e a etapa onde deve ser elaborado o jogo, sua historica,

contexto, regras, caracterısticas, objetivos, personagens, etc. Deve ser realizado antes de

qualquer tarefa relacionada com o desenvolvimento do software. O processo de concepcao

do jogo atraves do game design deve gerar uma serie de documentos que serao utilizados

posteriormente pela equipe de producao para o desenvolvimento do software, geracao das

imagens, modelos, sons e markenting.

Ja os Game Designers sao as pessoas responsaveis pela elaboracao do conceito do jogo

e suas regras. Sao eles que ditam o que deve ser programado, modelado ou as imagens

geradas pelas outras equipes. Os Game Designers tambem sao responsavel pela palavra

final em aprovar o que e desenvolvido para o jogo, eles funcionam como uma especie de

diretor na industria cinematografica.

Para detalhar melhor o game design e os produtos gerados sera descrito de forma

rapida 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 ideia deve ser trabalhada e documentada. Sem se

preocupar com qualquer barreira que possa impedir o desenvolvimento do jogo, deve-se

1Nao se trata da fase de design de um ciclo de desenvolvimento de software, e sim da etapa deelaboracao do jogo como conceito.

41

elaborar e documentar todas as caracterısticas desejadas para o jogo. Descrever de forma

rapida como seria as principais partes do jogo, quais as decisoes que necessitariam ser

tomadas pelos jogadores e as razoes que tornariam o jogo legal. Este documento serve

para vender a ideia a equipe, alem de tambem ser muito util para a equipe de marketing

e conseguir investidores.

Mesmo que este primeiro conceito nao seja aprovado por nao ser atrativo, financeira-

mente ou computacionalmente inviavel, por se tratar de um documento escrito ele pode

ser arquivado e nao se perde na memoria de seu criador.

4.4.2 Core Design

Nesta fase sera elaborado a primeira especificacao do jogo, deve estar focada no jogo

independente da plataforma que sera 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 serao utilizadas no jogo. Tambem pode ser interessante

a geracao de prototipos.

Entre os componentes do jogo que serao elaborados nesta etapa sao:

• O personagem;

• Contexto em que jogo estara inserido;

• Historia e seu desenrolar;

• Os objetivos;

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

• A jogabilidade e as decisoes que necessitarao 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 decisoes que devem ser tomadas pelo jogador,

as possibilidades devem ser interessantes e nao triviais. Eles devem ter a possibilidade

de tentar diferentes alternativas e tirar suas proprias conclusoes sobre qual alternativa e

42

melhor em determinado contexto. As regras devem ser definidas de forma concreta, que

ja possam ser testas e equilibradas.

4.4.4 Design Detalhado

Durante a etapa do Design Detalhado o Core Design sera 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 analise de requisitos.

Este etapa e diferente da etapa de analise de um ciclo de desenvolvimento de soft-

ware, aqui nao pensamos em componentes de software como objetos, classes, estruturas

ou algoritmos. Estes componentes apenas serao gerados posteriormente pela equipe de

producao apos uma analise sobre estes documentos.

4.4.5 Equilıbrio do Jogo

Ja durante o desenvolvimento das primeiras versoes 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. Alem

dos testes manuais pode ser utilizado simulacoes que busquem exaustivamente falhas no

equilıbrio do jogo.

4.4.6 Interfaces de Entrada e Saıda

Nesta etapa sera realizado um polimento geral no jogo quanto o modo que o jogador

interage com o jogo e como ele responde a suas acoes. 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 acoes causaram transformacoes no jogo.

43

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 elaboracao deste

projeto, da implementacao dos prototipos e a construcao do framework. Do conjunto de

metodologias apresentadas na secao 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 padroes propostos foram utilizados,

uma vez que alguns sao destinados a frameworks ja bem maduros. Os padroes utilizados

foram: 3 Exemplos, Framework de Caixa Branca e Biblioteca de Componentes. Uma

descricao melhor sobre a utilizacao destes padroes pode ser visto nos capıtulos referentes

a implementacao dos prototipos.

Segundo o primeiro padrao da metodologia dos frameworks evolutivos, os 3 exemplos,

foram desenvolvidos tres prototipos de jogos em sequencial. Realizar em forma sequencial

e para que um prototipo tente aproveitar o codigo do anterior e dessa forma, generalizando

suas funcionalidades, construir o framework. O uso de prototipos em vez de de aplicacoes

finais e devido ao esforco de desenvolvimento ser muito inferior, e como Roberts e Johnson

comentam em seu artigo (4), com o uso de prototipos ainda e possıvel chegar muito

proximo do que realizado com uma aplicacao final.

Antes da analise e implementacao de cada prototipo foi desenvolvido o game design.

O game design, descrito na secao 4.4, e responsavel por documentar e formalizar as ideias

de um jogo. Mas nem todas as suas partes foram criadas, apenas as primeiras referentes

a concepcao inicial do jogo, mais uma nova com o design detalhado para o prototipo em

questao. As outras partes nao foram elaboradas por tratarem de assuntos mais especıficos

para a versao final do jogo, e nao seriam utilizados para os prototipos.

O primeiro prototipo foi desenvolvido apenas para ser utilizado como fonte informacao

para o domınio do framework, portanto, nao houve a preocupacao de manter o codigo

generico e flexıvel. Ja o segundo tem o proposito de criar o framework, atraves da com-

44

paracao de seus requisitos com o que ja foi desenvolvido no primeiro prototipo. Final-

mente o terceiro prototipo tem o proposito de testar e refinar o framework desenvolvido.

Informacoes mais detalhadas sobre a implementacao de cada prototipo e sobre o desen-

volvimento 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 configuracao CLDC 1.1 e perfil 2.0. Ela se trata de uma plataforma livre

tanto para uso como para distribuicao dos jogos, o que permite uma melhor flexibilidade.

Para o desenho 3D foi utilizado o Mobile 3D Graphics API for J2ME (3) (secao 3.3.1.3),

que e um pacote opcional para a plataforma J2ME com uma API para geracao de graficos

3D para dispositivos moveis.

Devido a falta de tempo para testes e depuracao em um aparelho real, somado a

dificuldade de encontrar um aparelho disponıvel para realizacao do projeto que possua o

pacote JSR 184 com a API 3D M3G, nao 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 elaboracao do framework.

5.1 Desenvolvimento do Primeiro Prototipo: Gor

5.1.1 Introducao

O primeiro prototipo desenvolvido foi o Gor. Ele teve como principal influencia o jogo

Mines of Gorr, um classico 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 ve atraves da visao do personagem, que inicia sua jornada em um

ponto qualquer de um labirinto. O labirinto e escuro, permitindo apenas alguns metros

de visibilidade, formado por diversos corredores e interseccoes. Nao e um jogo de acao,

portanto o deslocamento pelo labirinto e 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 decisao de enfrenta-los, ou tentar encontrar o

tesouro por outro caminho. Na versao final do jogo o jogador deve evoluir com o tempo

e diferentes equipamentos, como armas e itens magicos poderao ser utilizados.

No prototipo foi implementado o basico para o jogo, que e a geracao do labirinto

45

grafico 3D, visto em primeira pessoa, o posicionamento de objetos representados por uma

imagem, resposta aos comandos de usuario para movimentacao do personagem e interacao

com os objetos.

No game design desenvolvido com uma descricao mais detalhada de cada elemento do

jogo pode ser visto no anexo A

A fig. 6 e mostra uma tela do jogo visto no emulador, aonde no fundo do corredor

esta o tesouro. Como nao foi aplicado efeito de transparencia, esta aparecendo o fundo

branco da imagem.

Figura 6: Screen shot do jogo Gor no emulador.

5.1.2 Implementacao

O game design para o jogo Gor(anexo A) foi analisado para identificacao dos requisitos

para o prototipo. Os requisitos identificados foram:

• O labirinto deve ser em forma de uma grade, aonde as linhas representam as paredes

ou sua ausencia. Sendo que sao obrigatorias as paredes que delimitam o labirinto;

• O labirinto 3D deve permitir diferentes texturas, sendo que ela pode ser definidas

por parede;

46

• Deve existir uma separacao entre o modelo do labirinto e do labirinto 3D gerado,

uma vez que serao utilizados mapas maiores que o numero suportado pela API 3D.

• A visao do jogador deve ser em primeira pessoa;

• Deve existir um efeito de luz, fumaca ou cor de modo que a visao do jogador seja

limitada pela escuridao;

• A geracao do mapa deve ser dinamica durante sua inicializacao, podera ser carregada

a partir de tipos simples, como array de caracteres ou inteiros;

• Um numero N de objetos podem ser inseridos em um mapa, mas nao necessariamente

podem ser inseridos apos o jogo ter sido iniciado;

• Os objetos ficarao sempre no centro das celulas e serao representados por uma

imagem bidimensional

• Para navegacao do jogador ele deve poder mover para frente e rotacionar para

ambos os lados, deve ser executada de maneira suave em que o usuario possa ver o

deslocamento;

• Para controlar a movimentacao do jogador entre as regioes do mapa deve existir um

sistema de colisao, ele nao sera capaz de atravessar as paredes;

• Quando um jogador entrar em uma regiao do labirinto, se existir algum objeto ali

presente eles deve ser notificado.

A partir destes requisitos foi criado um rascunho de diagrama de projetos (fig. 17) para

identificacao das entidades envolvidas. Tambem foram desenvolvidos alguns prototipos

para testes de alguns algoritmos e para adaptacao do autor com o ambiente que seria

utilizado, no caso da plataforma J2ME e a API 3D. A evolucao destes prototipos em

conjunto com a implementacao do diagrama resultaram no primeiro prototipo.

A interface grafica 3D foi implementada em immediate mode, assim a aplicacao faz

os acessos a API grafica para o desenho, tendo total controle sobre o momento e como

os modelos sao desenhados. Esse tipo de abordagem foi escolhido por causa do algo-

ritmo desenvolvido para o desenho do 3D do labirinto. Para o desenho do labirinto 3D e

criada uma serie de transformacoes para os planos que representarao as paredes de todo

o raio de visao do jogador durante a inicializacao. Durante a movimentacao do jogador

47

apenas e alterado o estado de cada parede para ser desenhado ou nao para represen-

tar diferentes partes do labirinto. Para nao permitir que o usuario possa ver as paredes

aparecendo/desaparecendo no limite de sua visao, foi utilizado efeito de neblina da API.

A movimentacao e feita quando o software recebe um evento de tecla pressionada,

ele altera o status do personagem e ativa algoritmos de animacao. Quando o jogador

se movimenta pelo labirinto, se ele entra no mesmo espaco em que um objeto ja esta

localizado, e gerado um evento para o objeto. No caso dos tesouros o evento e tratado

como a vitoria do jogador, no caso dos monstros e iniciada uma luta.

A representacao dos objetos no labirinto foi feita da maneira muito simples, uma

imagem bidimensional sempre virada para a camera localizada no centro da celula em que

o jogador esta posicionado. Nao foram utilizado modelos, animacoes ou mesmo imagens

com fundos transparentes para representar os objetos no prototipos

Figura 7: Diagrama de classes apos a implementacao do projeto.

Na fig. 7 contem o diagrama de classe da implementacao do primeiro prototipo,

aonde foram retirados diversos elementos para facilitar a leitura. Nele estao descritos

todas as suas classes e alguns de seus metodos mais importantes. O diagrama completo

juntamente com alguns diagramas de sequencia podem ser vistos no anexo B. Para melhor

entendimento, abaixo e explicado as principais responsabilidades e relacionamentos de

48

cada classe.

• Aplicacao: E a classe que implementa o javax.microedition.midlet.Midlet. E

a classe que representa uma aplicacao de usuario no J2ME. A Aplicacao e re-

sponsavel pela inicializacao e configuracao do jogo, alem de tratar funcionalidades

independentes do jogo, como controle de menus, opcoes, etc;

• AtualizadorMotor: Objeto responsavel por fazer as chamadas para atualizacao

do motor de tempos em tempos;

• Motor3D: Implementa javax.microedition.lcdui.Canvas. Representa o jogo

em si, e responsavel pelo controle do jogo, gerenciamento dos objetos, entrada do

teclado e saıda de som e imagem. Os atributos mostrados representam objetos para

o desenho 3D;

• Plano e Cubo: Classe utilitario que cria o modelo para a geracao de um plano 3D

sobre os eixos X/Y, ela armazena constantes para os valores de vertices, normais,

mapeamento de texturas e normais;

• Mapa: Faz o gerenciamento das celulas do mapa. Controla tambem os objetos e

os movimentos do jogador;

• Jogador: Representacao do jogador no jogo, armazena todos os dados como energia,

pontos, posicao, etc;

• Objeto Mapa: Representa um objeto que pode ser colocado no mapa. Ele tem

como propriedade um identificador unico para cada objeto e seu tipo. O metodo

mostrado e o evento que e gerado para o objeto quando o jogador entra na mesma

celula que o objeto;

• Tesouro: E um tipo de objeto que ao entrar em sua celula o jogador ganha o jogo,

adquirindo os pontos;

• Monstro: Tipo de objeto que serve como obstaculo do jogador quando se desloca

pelo labirinto, ao jogador entrar em sua celula e iniciado um combate;

• Direcao: Enumeracao de todas as direcoes possıveis no jogo, que sao os 4 pontos

cardeais alem das direcoes para cima e para baixo. A enumeracao e armazenada em

um valor inteiro. Ela e utilizada pelo jogador para indicar para onde esta virado ou

se deslocando, e pelas celulas do mapa para indicar cada parede.

49

• AnimadorRotacao e AnimadorTranslacao: Sao algoritmos para a animacao

dos movimentos do jogador, o primeiro para rotacao e o segundo para translacao.

5.1.3 Resultados

Os principais requisitos necessarios para o desenvolvimento do prototipo foram rea-

lizados com sucesso, apesar de alguns algoritmos especıficos do jogo ainda apresentarem

alguns problemas ele cumpriu suas metas principais, da criacao do mapa, navegacao do jo-

gador, geracao de eventos para objetos e facilidade na criacao de novos objetos e diferentes

tipos de mapas.

Durante o desenvolvimento, principalmente devido a utilizacao de prototipos, foram

aplicadas algumas otimizacoes iniciais que perderam seu valor posteriormente, como a uti-

lizacao de inteiros para armazenamento do labirinto e algoritmo para desenho do labirinto

3D utilizando o immediate mode, uma vez ele nao foi implementado em um ambiente real

para realizacao de testes de desempenho.

Foram geradas algumas medicoes no final deste primeiro prototipo para posterior-

mente ser comparado com os proximos prototipos.

• Linhas de codigo: 954;

• Numero de classes: 12.

5.2 Desenvolvimento do Segundo Prototipo: Sky

5.2.1 Introducao

O segundo jogo foi o Sky.O objetivo do jogo e simples, o jogador deve dirigir uma

nave espacial em ate o final de uma pista antes que o combustıvel acabe. A nave apenas

pode acelerar, frear e transladar para as laterais. A nave tambem e capaz de saltar, que

e o principal recurso do jogador para transpor os obstaculos da pista. Na fig. 8 pode ser

visto uma imagem do jogo, a pista e suas partes, o retangulo vermelho e a representacao

da nave do jogador, os cubos azuis representam os obstaculos, os planos amarelos sao as

barreiras protetoras da pista, e o os planos cinzas sao a pista.

Novamente para o prototipo foi implementado o basico para o jogo, que e a criacao

da pista 3D, fısica da nave e tratamento de colisao.

50

Figura 8: Screenshot do jogo Sky no emulador.

Este prototipo foi o primeiro a ser implementado utilizando o framework, que foi con-

struıdo em paralelo de forma iterativa, aonde as funcionalidades comuns entre o primeiro

e o segundo prototipo eram fatoradas e implementadas no framework.

5.2.2 Implementacao

Novamente o processo de desenvolvimento do jogo teve inıcio com a analise do game

design (anexo C). A lista de requisitos identificados foram:

• Camera em terceira pessoa que movimente junto com a nave apenas no deslocamento

frontal, nos movimentos laterais e saltos a camera deve manter a mesma posicao;

• A pista e dividida em blocos e ela pode ser criada aleatoriamente atraves da com-

posicao destes diferentes blocos;

• Para cada bloco pode ser definido se ele vai ter o chao, paredes protetoras e os

obstaculos;

• Os obstaculos serao cubos e terao todas suas arestas alinhadas com os eixos;

• Fısica basica para elaboracao do jogo em relacao a nave, de inercia, velocidade,

aceleracao, atrito e gravidade;

51

• A nave deve ser capaz de saltar, acelerar para frente e laterais. Sendo que para

mover para frente ela deve ter contato com o chao;

• Deteccao de colisao com a pista, com as paredes e com os obstaculos;

Como ainda nao temos o framework definido, uma vez que ele sera construıdo em

conjunto com este segundo prototipo. Foi necessario primeiro criar um rascunho de projeto

do prototipo Sky (fig. 9) como se ele fosse desenvolvido sem a utilizacao de um framework.

O objetivo deste diagrama e que ele possa ser analisado com o primeiro prototipo para

identificacao das partes comuns para geracao do framework, esta etapa sera descrita mais

adiante no secao 5.2.2.1.

Figura 9: Rascunho de projeto do Sky sem o framework

Descricao de algumas das classes da fig. 9:

• Aplicacao: Classe que entende javax.microedition.midlet.Midlet e e responsavel

pela inicializacao do jogo;

• Motor3D: Controle do jogo e implementacao da interface grafica 3D, implementa

javax.microedition.lcdui.Canvas;

• Pista: A pista de corrida na qual o jogador ira correr. Ela e composta por um

conjunto de Blocos que define cada trecho da pista;

52

• Nave: Nave que o jogador controla. Ela e responsavel pelo tratamento da fısica

que envolve ela e o tratamento das colisoes com os blocos da pista. Ela deve estar

posicionada em um bloco da pista;

• Bloco: Um bloco define como e a pista naquele trecho, ele e composto pelo chao,

as paredes e os obstaculos.

O processo de implementacao da primeira versao do framework e do segundo prototipo

foram separadas em duas secoes, a secao de 5.2.2.1 que descreve como foram identificadas

as classes para o framework e a secao 5.2.2.2 com a implementacao do prototipo e o

framework.

5.2.2.1 Primeira Versao do Framework

Como dito anteriormente o projeto da primeira versao do framework foi desenvolvido

a partir da comparacao do rascunho de projeto do Sky (fig. 9) com o diagrama de projeto

final do Gor (fig. 7). Esta analise foi feita principalmente com o intuito de utilizar dois

padroes da linguagem de padroes propostas pela metodologiade Frameworks Evolutivos,

os padroes Framework Caixa Branca e Biblioteca de Componentes. O padrao Framework

Caixa Branca foi aplicado atraves da identificacao das classes principais entre os dois pro-

jetos que sao comuns, entao elas foram abstraidas e reaproveitadas no framework atraves

da especializacao. Atraves do padrao de Biblioteca de Componentes foram identificados

as classes utilitarias que eram utilizadas entre os dois prototipos e adicionadas a biblioteca

de componentes.

Analisando os diagramas citados no paragrafo anterior (fig. 9 e 7) foi possıvel identi-

ficar que os dois contem uma classe responsavel pela inicializacao da Midlet, controle da

aplicacao e gerenciamento da execucao do jogo. Ela tambem e responsavel pelos menus.

Em ambos os casos ela se chama Aplicacao. Apesar da classe do Gor Atualizador-

Motor nao estar contido no projeto Sky, por ser responsavel pela atualizacao do motor

foi considerada como sendo parte da Aplicacao. Foi entao criado no framework uma

classe Aplicacao com as funcionalidades de inicializacao e controle dos menus, o codigo

utilizado foi o ja desenvolvido para o Gor.

Em ambos os projetos tem uma classe especıfica para controle do jogo, a classe Mo-

tor3D. Esta classe alem de controlar o jogo e tambem responsavel pelo recebimento dos

comandos de usuario, controle do jogador, som e interface grafica 3D. Nos dois casos e a

classe Motor3D. Apesar de no primeiro prototipo o motor ser implementado como sub-

53

classe de javax.microedition.lcdui.Canvas, no framework foi utilizado a superclasse ja-

vax.microedition.lcdui.game.GameCanvas por adicionar novas funcionalidades para

jogos sem perder as ja existentes em Canvas. Assim como a classe Aplicacao, foi uti-

lizada a classe Motor3D do Gor para controle do jogo no framework.

As entidades Mapa e Pista sao equivalente nos dois projetos, as duas representam o

ambiente do jogo. Elas sao compostas de outros objetos, no primeiro caso por inteiros que

sao as celulas, e no segundo por blocos. Alem disso, o ambiente tambem contem entidades

que estao localizadas em uma determinada parte, no primeiro as entidades sao o Jogador

e ObjetosMapa e suas subclasses, no segundo apenas a Nave. No framework foi criado

a classe Ambiente para representacao das entidades Mapa e Pista. O Ambiente tem

a responsabilidade da representacao do ambiente do jogo e posicionamento de outras

entidades. Para cumprir esses requisitos ela armazena um conjunto de objetos que serao

fixos durante a execucao, eles serao a composicao do ambiente, e objetos dinamicos durante

a execucao, que sao os objetos, entidades e jogadores. Foram criadas ainda duas classes

abstratas, ParteAmbiente que e a parte fixa e ObjetoAmbiente que sao os objetos

dinamicos do Ambiente.

A representacao do usuario no jogo tambem e comum nos dois projetos, no primeiro a

classe Jogador e no segundo a classe Nave. Elas estao posicionadas em uma posicao do

Mapa/Pista e recebem comandos diretamente do Motor3D. No framework foi criada a

classe Jogador para representar o usuario, ela sera uma subclasse de ObjetoAmbiente

devido ao relacionamento de posicao.

As classes Plano e Cubo sao utilizadas nos dois projetos, as duas sao classes que

armazenam a estrutura de vertices para primitivas 3D. Por serem utilizadas nos dois

projetos e muito uteis para prototipacao e testes, elas foram incluıdas na biblioteca de

componentes.

Sao poucas as classes que nao tem nada em comum entre os dois projetos. As espe-

cificas do Gor sao: as especializacoes de ObjetoMapa, a enumeracao Direcao e os

animadores AnimadorRotacao e AnimadorTranslacao. No Sky apenas as partes

que compoem os blocos sao especificas deste jogo. Portanto, por nao haver a principio

nenhuma possibilidade de aproveitamento elas nao foram incluıdas no framework.

A partir das classes identificadas descritas nesta sessao foi criado um diagrama de

classe do framework com as classes Aplicacao, Motor3D, ObjetoAmbiente, Par-

teAmbiente e Jogador que pode ser visto na fig. 10. Os metodos crieMotor na

Aplicacao e os metodos crieAmbiente e crieJogador sao metodos em que o frame-

54

work delega a criacao das classes para a aplicacao, uma vez que apenas ela sabe qual

classe concreta sera utilizada para cada um destes tipos abstratos. O metodo atualize

no Motor3D e o metodo chamado de tempos em tempos para atualizacao do jogo. Este

diagrama nao tem como objetivo incluir todos os metodos e propriedades que poderao ser

utilizados pelo framework, a definicao destas propriedades foram postergadas para serem

incluıdas a medida que forem necessarias durante a implementacao dos prototipos.

Figura 10: Diagrama de classes do framework

5.2.2.2 Jogo e o Framework

Uma vez identificadas as classes do framework (diagrama da fig. 10), foi criado outro

rascunho de diagrama de projeto, desta vez levando em consideracao a implementacao do

prototipo utilizando o framework. Este diagrama pode ser visto na fig. 11.

O processo de implementacao foi focado no desenvolvimento do codigo, a partir do

primeiro diagrama (fig. 11) foram criado diagramas de sequencia para identificacao dos

metodos e implementacao de forma alternada, os diagramas de sequencia podem ser vistos

no anexo D.

Durante este prototipo, para a implementacao da interface 3D foram utilizados ele-

mentos dos grafos de cenas da API (ver anexo 26), deste modo a aplicacao perde parte

do controle de desenho, que deve ser todo preparado antes atraves de alteracoes dentro

do grafo. Esta mudanca foi realizada para tentar aproveitar melhor todo o potencial da

API. No Sky nao foram utilizadas texturas nos objetos, pelo menos nao para o prototipo,

a unica imagem usada e para criacao do fundo.

A execucao do jogo e toda baseada sobre o metodo Motor3D.atualize, aonde sao

utilizados recursos do GameCanvas para identificacao das teclas pressionas e sao feitas

55

Figura 11: Diagrama de classes do framework

alteracoes na fısica da nave e atualizacao dos movimentos.

A implementacao da fısica foi implementada da forma mais simples possıvel para que

cumprisse os requisitos, mas foram implementadas a velocidade, aceleracao, gravidade e

empuxo. Para as colisoes foi considerando como se a nave nao tivesse profundidade, ou

seja, foi considerado apenas sua largura e altura. Sao identificadas as colisoes com as

barreiras laterais e identificacao quando a nave esta em contato com o chao.

Durante o desenvolvimento do prototipo, algumas modificacoes foram realizadas no

framework da fig. 10. Devido a necessidade da criacao de alguns eventos, foram inseridos

no Motor3D metodos abstratos para tratar quando o jogador ganha ou morre no jogo.

Para um melhor controle interno pela classe Ambiente das instancias de ParteAm-

biente que fazem sua composicao, principalmente para o controle espacial, foi criado

um atributo id como identificador unico na classe ParteAmbiente. Foi adicionado no

Ambiente uma estrutura que possibilite retornar apenas as ParteAmbiente que estao

visıveis para o jogador ate N blocos de visibilidade. Tambem foram adicionados metodos

para a execucao de sons no Motor3D.

A fig. 12 contem o diagrama de classes final e do projeto com as classes do Sky e o fra-

mework. Devido as restricoes de espacos, nao estao sendo mostrados os relacionamentos

das classes do framework, as propriedades das classes (metodos get e set), e outros atri-

butos e metodos menos relevantes. Os diagramas finais da primeira versao do framework

e do segundo prototipo estao disponıveis no anexo D.

56

Figura 12: Diagrama com o jogos Sky utilizando o framework

5.2.3 Resultados

De modo geral o framework ficou responsavel por todas as tarefas de controle e ge-

renciamento dos objetos, enquanto para aplicacao ficou responsavel pela tarefa de imple-

mentar ou sobrescrever os metodos do framework para o codigo especifico do domınio do

jogo. Em relacao a implementacao da parte grafica por ser dependente do jogo e como o

primeiro prototipo nao fez uso da cena de grafos, nao foi possıvel passar para o framework,

ficando a implementacao quase que totalmente para a aplicacao.

Quanto ao jogo, ele foi implementado quase que completo, ficando algumas carencias

quanto a implementacao da deteccao e tratamento de colisao com os obstaculos.

Novamente foram realizadas algumas medicoes, desta vez levando em conta tambem

o framework.


• Numero de classes: 16;

• Porcentagem de codigo da aplicacao: 39% (388 linhas);

• Porcentagem de codigo do framework: 46% (455 linhas);

57

• Porcentagem de codigo da biblioteca de componentes do framework: 14% (146 lin-

has).

5.3 Desenvolvimento do Terceiro Prototipo: Tan

5.3.1 Introducao

O terceiro jogo e o Tan. Neste jogo o jogador pilota um tanque e tem como objetivo

defender sua base de tanques inimigos que aparecem aleatoriamente no mapa. O mapa

e composto de varias estruturas que tem influencia de maneiras diferentes no mapa. De-

pendendo do tipo da estrutura ela pode ter diferentes funcionalidades, como os lagos que

nao permitem a passagem do tanque, mas permitem que sejam disparados tiros sobre ela,

e os blocos de concreto, que bloqueiam tanto a passagem do tanque quanto seus tiros,

mas podem ser destruıdos.

Para este prototipo foi gerado o mapa 3D e suas estruturas. Apenas foram utilizados

os blocos do tipo de concreto que poderao ser destruıdos pelos tiros dos tanques. Existe

no mapa um objeto que representa a base do jogador e tambem pode ser destruıda pelos

tiros, e caso isso aconteca, o jogador sera derrotado. Todos os tanques devem sao capazes

de se deslocar e disparar tiros, sendo que o usuario controla um dos tanques, e os outros

tanques sao inimigos e sao controlados pelo jogo.

Na fig. 13 pode ser visto o jogo por uma camera aerea. O chao cinza sao as estruturas

vazias, que permitem o deslocamento livremente, ja os cubos em cima sao as estruturas

de concreto. O tanque do jogador e a piramide amarela, enquanto as dos inimigos esta

em vermelho. A piramide em cianeto no canto esquerdo e a base do jogador.

O framework desenvolvido no segundo prototipo foi utilizado como base para o de-

senvolvimento, na medida que novos requisitos foram aparecendo ele foi adaptado conti-

nuamente para permitir as novas funcionalidades.

5.3.2 Implementacao

Assim como iniciamos a implementacao dos prototipos anteriores, comecamos com a

analise do game deisgn deste terceiro jogo disponıvel no anexo E. Os requisitos sao:

• O mapa e formado por um conjunto de estruturas;

58

Figura 13: Screenshot do jogo Tan no emulador.

• Cada estrutura pode ser de dois tipos, concreto ou vazio.

• As estruturas de concreto podem ser destruıdas, tornando-se entao vazias;

• Os tanques podem se deslocar para frente, sempre do centro de uma estrutura para

a o centro da proxima;

• Os tanques podem rotacionar para ambos os lados, sendo que e realizado sempre

em angulos de 90 graus;

• Um tanque e destruıdo quando e atingido por um tiro;

• Deve existir um objeto que represente a base do jogador;

• Caso a base seja atingida, o jogador sera derrotado;

• O jogador ganha a fase quando todos os inimigos previsto para aquela fase forem

destruıdos;

Uma vez ja tendo o framework e suas classes com funcionalidades e relacionamentos

ja bem definidos, foi criado apenas um rascunho de projeto para identificacao das classes

de aplicacao envolvidas e iniciada a geracao de diagramas de sequencias das principais

partes do jogo e implementacao.

59

Novamente a implementacao grafica foi realizada utilizando grafos de cena (ver anexo

32), que como podera ser visto melhor abaixo permitiu remover algumas referencias de

objetos graficos do framework. A implementacao do mapa 3D foi bastante parecida com

o mapa do primeiro prototipo, mas devido a implementacao do algoritmo de desenho ter

sido implementado immediate mode e nao atraves de grafos de cena, apenas a sua logica

foi aproveitada.

Neste prototipo nao foi utilizada nenhuma textura. Apenas foi utilizado efeito de luz

para criar o realismo 3D. Nao foi feita nenhuma alteracao no framework devido a decisao de

nao utilizar texturas, apenas foi ignorado o atributo da classe Motor3D responsavel por

texturas. O fato de nao utilizar este atributo neste prototipo poderia ser utilizado como

argumento para remove-lo do framework, no entanto esta acao nao foi tomada devido

que as texturas sao fundamentais para aplicacoes 3D, e certamente seriam utilizadas

posteriormente em versoes mais avancadas do jogo.

Diferente do segundo prototipo e a entrada de dados para controle do jogador e feita

pela sobrescrita do metodo keyPress, ao inves da verificacao das teclas pressionadas

durante o ciclo de atualizacoes do Motor3D. A utilizacao desta forma de entrada de

dados tambem nao causou alteracao no framework, uma vez que devido que o Motor3D

implementa a classe GameCanvas, as duas formas de entradas ja estao disponıveis.

Devido a necessidade de representar as diferentes direcoes que um tanque poderia ter,

foi utilizada a classe Direcao desenvolvida no primeiro prototipo, por se tratar de uma

classe util e nao fundamental para a execucao do jogo. De acordo com o padrao Biblioteca

de Componentes, ela foi adicionada a biblioteca de componentes do framework.

No primeiro prototipo o Jogador e o Monstro tinham alguns atributos em comum,

mas nao foi necessario junta-los em uma mesma hierarquia de classes. No segundo apenas

o jogador foi utilizado como objeto do ambiente. Ja no terceiro prototipo, os tanques

dos inimigos sao identicos ao do jogador. Como o Jogador ja herda de ObjetoMapa

dentro do framework, nao existe a possibilidade de representar tanto o jogador quanto os

nao jogadores em uma mesma hierarquia de classes, uma vez que para isso e necessario

que todos os objetos sejam jogadores, ou que se utilize um jogador que nao herda de

Jogador. Para resolver este problema o framework foi alterado de modo a remover a

classe Jogador, assim o objeto que representa o usuario passa a ser um objeto qualquer

que herde de ObjetoMapa.

Na primeira versao do framework, por uma decisao de projeto o identificador era in-

icializado pelo construtor da classe ParteAmbiente pela classe que criava o Ambiente,

60

que no caso do segundo prototipo foi a classe AplicacaoSky. Para permitir que o Am-

biente controle os identificadores da maneira que desejar, o framework foi alterado de

modo que a responsabilidade por alocar estes identificadores ficasse diretamente com a

classe Ambiente.

No framework, para se criar diferentes tipos de objetos, ou diferentes tipos de partes

do ambiente, era necessario criar subclasses. Foi adicionado nas classes do framework

ObjetoAmbiente e ParteAmbiente o atributo tipo, este atributo serve para indicar o

tipo do objeto pela aplicacao, assim e possıvel representar diferentes tipos de objetos sem

a necessidade de criacao de subclasses. Este identificador foi utilizado para a representar

a base de jogador, uma vez que a responsabilidade de identificacao e tratamento colisao

ficaram com o Tiro nao houve a necessidade de criar uma classe para a base.

Com o objetivo de aproximar mais o framework da API grafica 3D, foram removidos os

metodos de desenho e adicionado o atributo world do tipo javax.microedition.m3g.World

que e o topo do grafo de cena. O World atraves da composicao, contem todos os elemen-

tos necessarios para o desenho, portanto se tornou desnecessario armazenar os atributos

camera, luz e background no framework. Tambem foi adicionada a classe ObjeotAm-

biente a propriedade nodo da classe javax.microedition.m3g.Node. A classe Node

representa um nodo do grafo de cena e serve para acessar diretamente a representacao 3D

de um objeto.

Outra alteracao no framework foi que existiam dois metodos abstratos o qual o fra-

mework atraves do Motor3D requisita a aplicacao para que criasse as instancias de

Ambiente e Jogador. Os metodos abstratos foram removidos e adicionados os metodos

concretos setAmbiente e setJogador. A principal razao desta alteracao e permitir que

os modelos 3D possam ser criados dinamicamente durante a execucao da aplicacao, o que

nao ocorria antes com os dois primeiros prototipos, aonde a criacao do modelo 3D era

possıvel fazer mesmo antes de adicionar o Ambiente e ObjetoAmbiente ao Motor3D.

Anteriormente existia um metodo especıfico para alterar a posicao do Jogador, mas

como ele nao existe mais nesta versao do framework e objetos nao jogadores tambem

podem ser movidos, o metodo setPosicaoJogador foi transformado no metodo mova-

Objeto que pode ser utilizado por qualquer objeto do tipo ObjetoAmbiente.

Foi necessario novamente a realizacao de animacoes para o movimento e translacao dos

tanques, foi reutilizado a classe AnimadorRotacao e AnimadorTranslacao desenvol-

vidas no primeiro prototipo, que foram tornadas um pouco mais genericas e adicionadas

a biblioteca de componentes.

61

Foi adicionado tambem a biblioteca de componentes a classe Piramide que armazena

informacoes dos vertices para desenho da primitiva piramide.

Figura 14: Diagrama de classes resultante do terceiro prototipo.

A fig. 14 contem o diagrama de classes resultante apos a implementacao do segundo

prototipo, alguns metodos, atributos, relacionamentos e classes foram removidos do dia-

grama, o diagrama de classes completo do framework pode ser visto na fig. 27 e do jogo

na fig. 29. Todos os diagramas utilizados neste projeto estao disponıveis no anexo F.

Abaixo estao a lista das novas classes criadas especificas para este prototipo:

• Tiro: Representa o tiro de um tanque, ele anda em linha reta ate encontrar um

ObjetoAmbiente ou ParteAmbiente com uma estrutura nao vazio ou atingir as

bordas do mapa;

• Tanque: Tanque que o jogador e o os inimigos controlam, ele controla os estados

e parametros do tanque. E responsavel por controlar suas proprias animacoes. No

caso dos tanques inimigos esta classe deve realizar o processamento da inteligencia

artificial;

• Estrutura: Representa uma parte do Ambiente. Ela pode ser de dois tipos, a

estrutura em si que ocupa espaco e bloqueia o movimento dos objetos, ou vazio. As

62

estruturas tem o atributo energia que e o numero de tiros que pode levar antes de

ser destruıda, o que faz com que ela passe para o tipo vazio;

• Mapa: Apenas implementa o metodo para calculo das ParteAmbiente visıveis;

• AplicacaoTan: Implementa o metodo para criar o MotorTan e sua inicializacao;

• MotorTan: Criacao de toda a estrutura de grafos para interface 3D, alem do

controle das regras gerais do jogo e processamento da entrada de comandos pelo

usuario.

5.3.3 Resultados

A implementacao deste terceiro prototipo foi desenvolvida de forma rapida no inicio,

uma vez que a arquitetura ja estava pronta devido ao framework e as novas classes foram

facilmente implementadas a partir de tipos ja definidos no framework. Entretanto, durante

a implementacao o processo de desenvolvimento se tornou mais lento e mais complexo,

uma vez que as novas funcionalidades resultaram em alteracoes no framework, que se

mostrou nada flexıvel. Contudo estas novas alteracoes no framework foram feitas na

forma de tornar o framework mais abrangente, mas isto somente poderia ser realmente

verificado atraves da implementacao de um quarto prototipo. Na fig. 15 pode ser visto o

diagrama final do framework, com todos os seus atributos e metodos.

Finalmente para finalizar este prototipo foram realizadas novas medicoes em relacao

a quantidade de codigo desenvolvido.


• Numero de classes: 18;

• Porcentagem de codigo da aplicacao: 37% (493 linhas);

• Porcentagem de codigo do framework: 33% (449 linhas);

• Porcentagem de codigo da biblioteca de componentes do framework: 28% (379 lin-

has);

63

Figura 15: Diagrama de classes da segunda versao do framework.

64

6 Conclusoes

Neste trabalho foram desenvolvidos todos os tres prototipos propostos e com eles o

framework para jogos de celulares 3D o trabalho se faz por encerrado.

No final do terceiro prototipo com a segunda versao do framework, conseguiu-se pro-

duzir um framework com uma arquitetura que inclui algumas entidades para a serem

utilizadas nos jogos, suas caracterısticas e relacionamentos. A arquitetura utilizada no

framework permitiu a criacao de tres jogos bastante diferentes, sem a necessidade de

mudancas estruturais muito significativas no framework.

A fig. 16 mostra um grafico com a quantidade de codigo escrito na aplicacao, no

framework e na biblioteca de componentes por prototipo. Como mais da metade do codigo

do segundo e terceiro prototipos pertencem ao framework, o reuso de codigo pode ser

considerado como satisfatorio. No entanto e necessario fazer algumas consideracoes quanto

a evolucao do framework. Primeiro, o fato de tanto os jogos como os frameworks serem

realizados por uma unica pessoa em curto perıodo de tempo pode ter influenciado bastante

na uniformidade das mudancas durante os diferentes prototipos. Segundo, como foram

desenvolvidos prototipos, e estes tratam das partes mais especıficas de cada jogo,tornou

se mais difıcil o aproveitamento de codigo. Terceiro, o uso da API 3D MGE, devido a

diferenca no modo que foram utilizadas entre os prototipos e ao aprendizado do autor

durante seus desenvolvimentos, a reutilizacao dos componentes graficos da interface 3D

foi quase inexistente. Quarto, devido a pequena quantidade de codigo desenvolvida, a

simples criacao de uma classe abstrata e as assinaturas dos metodos fazem diferenca

na linha de codigo, o que causa um aumento na porcentagem da quantidade de codigo

do framework sem um reuso real. Por fim, como nem os prototipos nem o framework

foram implementados em um aparelho real e nem foram desenvolvidos jogos completos,

nao se sabe o impacto que isso poderia ter no framework. Apesar de algumas boas

praticas utilizadas para manter o codigo “leve”, as otimizacoes reais apenas poderiam ser

identificadas atraves de testes de desempenho.

65

Figura 16: Grafico de evolucao do framework em linhas de codigo.

Os padroes propostos pela metodologia de desenvolvimento de frameworks evolutivos

por se tratarem de padroes de alto nıvel, foram utilizadas mais como dicas, ficando ainda

a cargo do conhecimento do programador as tecnicas de refatoracao do codigo e abstracao

do framework. No entanto, eles se mostraram importantes para a evolucao do framework.

Sobre a plataforma movel, a heterogeneidade do ambiente de programacao movel se

mostrou bastaste grande. Sao diversas as plataformas e linguagens e estas sao muitas vezes

dependentes dos hardwares dos dispositivos. Algumas plataformas tentam estabelecer um

padrao, como Brew e J2ME, no entanto, nenhuma delas alcancou este objetivo.

Devido a nao execucao do framework e os jogos produzidos em um aparelho, nao foi

possıvel verificar as limitacoes em ambiente real, no entanto, permitiu o conhecimento de

suas das APIs J2ME e M3G. As APIs utilizadas, mesmo que reduzidas em numero de

funcionalidades em relacao a suas respectivas versoes desktop, se mostraram totalmente

suficiente para o realizacao do trabalho. Principalmente a API grafica M3G, que se

mostrou difıcil de trabalhar no inıcio devido a sua estrutura na forma de grafo de cenas,

no final tornou-se altamente produtiva.

Em relacao aos jogos, o processo de concepcao dos jogos seguindo o game deisgn

se mostrou bastante interessante, mesmo quando este documento nao foi realizado por

completo. O uso do game design tambem foi bastante importante para criacao dos re-

quisitos durante o projeto de cada prototipo, uma vez que nao existia um gerente ou um

especialista no jogo, fica a cargo do que foi definido no game design a palavra final.

66

A implementacao dos jogos mostrou ser um processo bastante complicado, alem da

modelagem de classes padrao para um software a necessidade de organizacao o uso das

estruturas de dados, algoritmos matematicos e a criacao da interface 3D que geralmente

era diferente em cada jogo foi bastante trabalhosa.

Finalizando, o desenvolvimento deste trabalho permitiu um aprofundamento na area

de jogos, das tecnologias existente em plataforma movel e e principalmente no uso e

desenvolvimento de frameworks. O processo de criacao de frameworks durante a producao

de softwares finais se mostrou interessante e a principio funcional. Apesar de nao permitir

um aprendizado sobre o desenvolvimento em aparelhos moveis em um ambiente real,

permitiu conhecer as APIs J2ME e MGE.

6.1 Trabalhos Futuros

A muito que deve ser feito ainda tanto para estudo como para o desenvolvimento do

framework caso se deseje que ele seja algum dia usado de forma satisfatoria. A primeira

tarefa seria a implementacao em um aparelho real para verificar sua viabilidade e otimizar

seu codigo. Segundo desenvolver versoes finais para os jogos. Em terceiro quando o fra-

mework atingir um estagio mais avancado, criar documentos como cookbooks que auxiliem

os programadores para o desenvolvimento de aplicacoes utilizando o framework.

Realizar medicoes mais complexas com as diferentes versoes do framework, e assim

poder fazer um estudo mais real quanto ao codigo aproveitado, o crescimento da comple-

xibilidade, tipo de reuso, etc.

67

Referencias

1 SILVA, R. P. e; PRICE, R. T. O uso de tecnicas de modelagem no projeto deframeworks orientados a objetos.

2 QUALCOMM Brew Home. Disponıvel em: <http://brew.qualcomm.com/brew/en/>.Acesso em: 21/10/2005.

3 JAVA Technology. Disponıvel em: <http://www.java.sun.com>. Acesso em:21/11/2005.

4 ROBERTS, D.; JOHNSON, R. E. Evolving frameworks: A pattern language fordeveloping object-oriented frameworks. In: Pattern Languages of Program Design 3.Addison Wesley, 1997. Disponıvel em: <citeseer.ist.psu.edu/roberts96evolving.html>.

5 MATTSSON, M. Evolution and Composition of Object-Oriented Frameworks. [S.l.:s.n.], 2000.

6 GAMMA RICHARD HELM, R. J. E.; VLISSIDES, J. Design Patterns, Elements OfReusable Object-Oriented Software. [S.l.: s.n.].

7 JOHNSON, R. E. Components, frameworks, patterns. In: ACM SIGS-OFT Symposium on Software Reusability. [s.n.], 1997. p. 10–17. Disponıvel em:<citeseer.ist.psu.edu/johnson97components.html>.

8 FAYAD, M. E.; SCHMIDT, D. C. Object-oriented application frameworks.

9 JOHNSON, R.; FOOTE, B. Designing reusable classes. Journal of Object-OrientedProgramming, 1988.

10 BOSCH PETER MOLIN, M. M. J.; BENGTSSON, P. Object-oriented frameworks -problems and experiences. 1997.

11 HOW to design frameworks. 1993.

12 PREE, W. Design patterns for object oriented software development.

13 JOHNSON, R. E. Documenting frameworks using patterns. In: PAEPCKE,A. (Ed.). Proceedings of the Conference on Object-Oriented Programming Systems,Languages, and Applications (OOPSLA). New York, NY: ACM Press, 1992. v. 27, n. 10,p. 63–72. Disponıvel em: <citeseer.ist.psu.edu/johnson92documenting.html>. Acessoem: 08/03/2005.

14 FORUM Nokia - Developer Resources. Disponıvel em:<http://www.forum.nokia.com/main.html>. Acesso em: 25/03/2006.

68

15 VITAL, V. A. H.; RAMALHO, G. Comparative Analysis of Porting Strategies inJ2ME Games. 2004.

16 PAGINA oficial do OpenGl ES. Disponıvel em:<http://www.khronos.org/opengles>. Acesso em: 07/07/2005.

17 FATHAMMER Ltd. Disponıvel em: <http://www.fathammer.com>. Acesso em:17/11/2005.

18 ENTERTAINMENT Software Association. Disponıvel em:<http://www.theesa.com>. Acesso em: 12/11/2005.

19 FALCO, A. de. Desenvolvedoras de jogos de olho na mobilidade. Disponıvel em:<http://webinsider.uol.com.br/vernoticia.php?id=2240>. Acesso em: 07/07/2005.

20 BBC News, Gamer buys virtual space station. Disponıvel em:<http://news.bbc.co.uk/1/hi/technology/4374610.stm>. Acesso em: 14/11/2005.

21 MORRIS, A. R. e D. Game Architecture and Design: A New Edition. [S.l.]: NewRiders.

69

ANEXO A -- Game Design do Gor

A.1 Primeiro Conceito

O jogador e um guerreiro que deve explorar labirintos infestados de monstros em busca

das tesouros. O jogo sera em primeira pessoa e a medida que evolui ganha mais habilida-

des, e com o dinheiro dos tesouros e possıvel comprar novos equipamentos. Os labirintos

sao aleatorios e estarao disponıveis em diversas dificuldades. O jogador que conseguir o

maior tesouro acumulado antes de morrer ganhara o topo do rank de pontuacoes.

A.2 Core Design

A.2.1 Jogador

O jogador sera um guerreiro que explora os labirintos lutando contra as criaturas em

busca do tesouro. Ele tera tres atributos, ataque, defesa e energia. O ataque indica a

capacidade do jogador de acertar seu inimigo, a defesa a de se proteger dos ataques, e

a energia o numero de ataques bem sucedidos que pode receber antes de morrer. Estes

atributos tem valores iniciais 4, mas a medida que o lutador for progredindo eles podem

ser alterados, tanto devido a experiencia (ver item A.2.5) adquirida do personagem por

matar monstros e adquirir tesouros quanto pelo uso de equipamentos.

A.2.2 Equipamentos

Existe tres tipos de equipamentos que podem ser utilizados pelo personagem, as armas

que altera o atributo ataque, as armaduras que melhora o atributo defesa, e as pocoes

que restaurar as energias perdidas ate o seu maximo.

70

A.2.3 Labirinto

O labirinto e composto por um conjunto de corredores com intersecoes e becos sem

saıdas. Eles devem passar ao jogador a ideia de que esta completamente perdido, mas

algumas caracterısticas de solo ou paredes deve permitir o jogador identificar que esta

avancando. O local aonde o jogador inicia, aonde o tesouro sera colocado, assim como os

monstros serao colocado de maneira aleatoria.

A.2.4 Jogabilidade

O jogo deve exigir reflexos, e seu desenrolar sera feito de forma lenta. O deslocamento

do jogador deve passar a impressao de alguem caminhando. Para aumentar a sensacao de

que esta perdido deve ser utilizado algum efeito de luz ou neblina de modo que o jogador

nao possa ver o fim de corredores longos.

Ao visualizar uma criatura o jogador podera decidir entre enfrenta-lo ou desviar por

outro caminho. Como os monstros serao colocados de fora aleatoria, o jogador nunca deve

saber quando enfrentar um monstro ou desviar o caminho. Eles nao podem ser muito

difıceis, mas devem tornar uma preocupacao para o jogador pouco a pouco enquanto ele

explora o labirinto, ja que a cada combate ele perde um pouco de energia, e a recuperacao

deste atributo e limitada.

Dentro do labirinto deve haver meios o qual o jogador possa recuperar suas energias,

deve ser difıcil de encontrar e seu uso deve ser limitado.

A luta com os monstros sera em tempo real, mas de forma lenta aonde cada ataque

demora cerca de 1 segundo, assim o jogador tera tempo suficiente para tomar suas decisoes,

como utilizar itens, lutar ou fugir.

A.2.5 Evolucao

Um mesmo jogador podera enfrentar varios labirintos diferentes, podendo ser gravado

entre cada investida. Com o tempo ele deve evoluir e seus atributos melhorando, assim

como a dificuldade dos labirintos. Mas se for morto, o jogador nao podera ser restaurado.

Para cada monstro morto ele deve ganhar uma quantidade de experiencia, o mesmo

deve ocorrer com os tesouros. Quanto mais difıcil um monstro ou maio valor o tesouro

mais pontos o jogador recebera. Posteriormente o jogador podera gastar os pontos de

experiencia para aumentar um dos seus 3 atributos.

71

A.2.6 Monstros

Como dito anteriormente os monstros serao espalhados pelo labirinto de forma aleatoria,

e nao serao capaz de se deslocar pelo mapa, apenas servirao de obstaculo para o movi-

mento do jogador. Assim como os jogadores os monstros terao os mesmos 3 atributos,

mas serao fixo durante a sua criacao, nao ganham experiencias e nao podem utilizar itens.

A.2.7 Combate

Quando o jogador entra na mesma celula que se encontra um monstro deve-se entao

ser iniciado o combate. A cada 0.5 segundos um dos lutadores difere um ataque contra

o outro, levando 1 segundo de recarga para o proximo ataque. Para verificar o ataque

deve-se sortear um numero de 1 ate o atributo ataque do atacante, e outro sorteio de 1 ate

o atributo defesa do defensor. Se o valor sorteado de ataque for maior que o sorteado da

defesa o defensor perde 1 ponto de energia. Se o monstro chegar a 0 pontos de energia ele

morre, e o jogador adquire sua experiencia. Se o jogado chegar a zero pontos de energia

ele morre e finaliza o jogo.

Durante o combate ainda o jogador tem a opcao de recuar, fugido do combate para a

celula anterior.

A.3 Prototipo - Design Detalhado

Para o prototipo deve ser implementado as tarefas essenciais para a implementacao do

jogo que sao: uso da interface grafica 3d e vista do jogador em primeira pessoa, geracao do

labirinto 3d, movimentacao do jogador, insercao dinamica de diferentes objetos no mapa

e geracao de eventos para as entidades do jogo.

A.3.1 Labirinto

O labirinto sera composto na forma de uma grade, aonde todas as paredes sao planos

e devem ser alinhadas com os eixos X, Y e Z. As celulas da grade devem representar o

espaco dos corredores e salas, aonde o jogador pode se deslocar. Ja as linhas da grade

devem representar as paredes, que podem ter diferentes texturas. Dentro do labirinto

qualquer linha pode conter ou nao uma parede, mas nos limites obrigatoriamente deve

conter paredes para bloquear a saıda do jogador da area do mapa.

72

Por se tratar de labirintos, o jogo deve ser capaz de suportar mapas de tamanhos

relativamente grandes como dimensoes 20x20. Para isso a geracao dos graficos deve estar

preparada para nao se sobrecarregar caso mapas grandes sejam inseridos.

A.3.2 Jogador

Como o jogo sera realizado em primeira pessoal nao e necessario a criacao de uma

imagem, ou animacao do jogador. Para a navegacao o jogador deve ser capaz de realizar

3 operacoes basicas, se deslocar para frente, rotacionar dentro da mesma celular para

direita ou esquerda. Em momento algum deve ser permitido que um jogador atravesse

uma parede do labirinto. O jogador fica sempre posicionado no centro da celula, apenas

sai desta posicao quando desloca-se para frente, aonde deve percorrer a distancia entre o

centro das duas celulas.

A.3.3 Objetos

Os objetos no jogo ficam em no centro das celulas, eles serao compostos por uma

unica imagem bidimensial e tera sua imagem sempre virada para o jogador.

A.3.4 Monstros

Os monstros sao um tipo de objeto especial que contem animacao de deslocamento,

sao estaticos na celula em que foram colocados. Sao capazes de lutar com jogador e

mata-lo se vencer o combate.

A.3.5 Ciclo de Vida do Jogo

O jogo inicia com o jogador em um determinado ponto do mapa, preferencialmente

aleatorio e no lado oposto do mapa do tesouro. O tesouro, e o objeto o qual o jogador

deve buscar para finalizar o labirinto. Monstros serao colocados no mapa para bloquear

a passagem do jogador, que deve lutar contra eles para poder continuar pelo mesmo

caminho.

O jogo termina quando o jogador for morto por um monstro ou atingir o mesmo

quadrado que o tesouro.

73

ANEXO B -- Diagramas do Gor

Figura 17: Rascunho inicial do diagrama de classes do jogo Gor.

74

Figura 18: Diagrama de classes completo do jogo Gor.

75

Figura 19: Diagrama de sequencia da inicializacao do Gor.

76

Figura 20: Diagrama de sequencia para o fluxo de execucao do Gor.

77

ANEXO C -- Game Design do Sky

C.1 Primeiro Conceito

O jogador e uma pequena nave espacial, o objetivo do jogador e chegar no final da

pista em um tempo mınimo. A pista e apenas reta mas cheia de obstaculos, algumas vezes

nao existe barreira protetoras nas laterais ou mesmo a pista. Para transpor os obstaculos

a nave e capaz de pular. Jogo e realizado em terceira pessoa com a camera fixa, sempre

virada para frente.

C.2 Core Design

C.2.1 Pista

A pista consiste em uma grande reta com grandes paredes dos dois lados, como uma

especie de aqueduto. Em alguns trechos da pista uma destas paredes pode nao existir, o

que pode fazer com que a nave caia para fora da pista. Em outras parte pode tambem

ocorrer que o proprio chao da pista nao exista, o que obriga o jogador saltar ou utilizar

obstaculos como apoio caso existam no trecho da pista.

C.2.2 Obstaculos

A colisao frontal com a nave com um destes obstaculos e fatal para o jogador, mas

eles podem ser utilizados como apoio. Por exemplo como uma ponte em grandes trechos

aonde nao tem o chao da pista.

C.2.3 Nave

A nave e um veıculo espacial que deve andar sobre o chao para poder acelerar, mas

tem a capacidade de saltar ou realizar deslocamento lateral no ar. A nave tem uma certa

78

quantidade de combustıvel que e gasta com o tempo, independente da movimentacao da

nave, e o combustıvel limitara o tempo mınimo do jogador para completar a pista. A nave

deve conter elementos de fısica como inercia, velocidade, aceleracao, gravidade e atrito.

C.2.4 Jogabilidade

O jogo deve exigir do jogador um pouco de habilidade de seu jogador para desviar dos

obstaculos, mas nao deve exigir reflexos. A opcao de o jogador controlar sua propria velo-

cidade permite o escolher a grau de dificuldade que desejar em cada momento, mas claro

sendo que o total do tempo utilizado e controlado pelo combustıvel da nave, obrigando o

jogador a uma dificuldade mınima.

C.3 Prototipo - Design Detalhado

O prototipo para este jogo deve ser capaz de montar o mapa, com os diferentes tipos

de obstaculos. A nave deve ser capaz de deslocar e saltar. Deve ser considerado tambem

as deteccao de colisoes e tratamento das mesmas, como choques frontais e laterais.

C.3.1 Pista

A pista e sempre em linha reta para simplificar a sua criacao e permitir que ela seja

criada de forma dinamica atraves da composicao de varios blocos.

C.3.2 Bloco

Um bloco e um tipo de trecho da pista, ele e composto pela a chao, obstaculos, e as

paredes protetoras.

O chao e o plano basico que permite a nave andar sobre sua superfıcie, dependendo

do bloco pode ser que ela nao exista, o que pode fazer com que a nave caia no espaco.

Quando isto ocorre o jogador deve saltar sobre o a pista faltante, ou ainda aproveitar

outros possıveis obstaculos para transpor o buraco.

Os obstaculos sao cubos, elas tem sempre seus planos retangulares e alinhado aos

eixos do plano cartesiano. Estes obstaculos podem ser colocados em qualquer parte na

pista, seja formando um teto, um tunel ou simplesmente uma barreira. Com excecao da

79

colisao frontal, que e fatal para o jogador, a colisao com este tipo de obstaculo apenas faz

bloqueia a direcao em que a nave se desloca.

As paredes protetoras sao planos nas margens a esquerda e direita da pista, que

serem para bloquear o deslocamento da nave. Alguns pontos da pista pode ocorrer destas

barreiras nao existirem, uma vez a nave saindo da pista o jogador morre.

C.3.3 Nave

Na nave espacial que deve percorrer a pista pode realizar quatro tipos de movimentos.

O movimento frontal serve para aumentar a velocidade da nave, este tipo de movimento

somente pode ocorrer quando a parte inferior da nave esta sobre a pista ou sobre a face

superior de um obstaculo. Os movimentos laterais serve para desviar dos obstaculos e

pode ser utilizado mesmo se nao tiver contato com o chao, mas com menor intensidade.

O terceiro movimento e o salto, este tipo de movimento serve para lancar a nave para o

alto, este movimento tambem so pode ser utilizado quando a nave esta em contato com

o chao.

A nave tem um combustıvel que e gasto com o tempo, independente da velocidade

ou movimentacao utilizadas pelo jogador. Este combustıvel serve para obrigar o jogador

a seguir em uma velocidade media durante a corrida.

C.3.4 Ciclo de Vida do Jogo

No comeco do jogo a nave e colocado no inıcio da pista e com o tanque cheio. E

possıvel ver a frente os obstaculos a ate uma certa distancia. O jogo finaliza com a morte

do jogador quando ele atinge uma altura negativa padrao, ou tem uma colisao frontal com

algum obstaculos. O jogador vence a pista caso finalize atravesse toda a pista.

80

ANEXO D -- Diagramas do Sky

Figura 21: Diagrama de classes da primeira versao do framework.

81

Figura 22: Classes na biblioteca de componentes na primeira versao do framework.

Figura 23: Diagrama de classes completo do jogo Sky.

82

Figura 24: Diagrama de sequencia da inicializacao do Sky.

83

Figura 25: Diagrama de sequencia do fluxo de execucao do Sky.

84

Figura 26: Grafo de cenas para o desenho 3D do Sky.

85

ANEXO E -- Game Design do Tan

E.1 Primeiro Conceito

O jogador e um tanque e deve defender sua base principal quanto o ataque de ordas de

outros tanques. O mapa e composto de diversas estruturas que bloqueiam a passagem dos

tanques, estas estruturas podem ser destruıdas com tiros de canhoes. O jogador ganha

quando o numero total de tanques previstos para a fase se esgotam, e perde caso algum

tanque consiga atirar em sua base.

E.2 Core Design

E.2.1 Mapa

O mapa e composto por ambientes externos, como cidades e florestas, diferentes tipos

de estruturas poderao ser colocadas, como predios e arvores, sendo que todas as estruturas

poderao ser destruıdas pelos tiros dos tanques. Apesar de ter diferentes tipos de estruturas

elas tem sempre a mesma funcionalidade, apenas diferenciando o modelo ou a textura

mostrada.

Cada estrutura dentro do mapa pode ter um tipo e caracterısticas diferentes, entre

exemplos de diferentes estruturas sao: Blocos de concretos que bloqueiam a visao e o mo-

vimento e podem ser destruıdos e lagos que apenas nao permitem os tanques se deslocarem

e nao podem ser destruıdos.

E.2.2 Tanque Jogador

O tanque do jogador e mais rapido que os inimigos tanto no deslocamento quanto no

tempo de recarga para um novo tiro. O tanque pode se deslocar para as quatro direcoes,

86

norte, sul, leste e oeste sem a necessidade de rotacionar. O tanque tem um limite de tiros

que pode receber dos tanques inimigos, uma vez esse limite ultrapassado ele morre.

E.2.3 Tanques inimigos

Os tanques aparecem em determinados pontos do mapa, eles andam e atiram de forma

aleatoria.

E.2.4 Base

A base e um objeto que fica em um ponto do mapa, o objetivo do jogador e defende-la

e se a base for destruıda o jogador perde o jogo.

E.3 Prototipo - Design Detalhado

O prototipo deve criar o mapa com suas estruturas, permitir colocar diferentes tipos

de objetos e estruturas. Os tipos de estruturas que devem ser permitidas colocar sao a de

concreto e vazio. A estrutura de concreto nao deve permitir o deslocamento de objetos e

pode ser destruıda. Ja o tipo de estrutura vazio nao tem nenhuma alteracao no jogo. Os

objetos sao o tanque do jogador, tanque inimigos com inteligencia artificial, os tiros e a

base principal do jogador.

E.3.1 Mapa

O mapa e feito atraves de uma matriz AxB de estruturas, nao existe valores null

dentro deste array. Os limites do mapa existe uma muralha indestrutıvel.

E.3.2 Estrutura

Uma estrutura representa uma determinada regiao do mapa, sendo que ele e definido

por um tipo. Os tipos serao vazio e de concreto. O tipo vazio permite o movimento de

objetos livremente e e o tipo de estrutura padrao, ela nao tem nenhuma representacao

grafica. As de concreto nao permitem a passagem de objetos e pode ser destruıda apos

receber 3 tiros, uma vez destruıda ela passa a ser uma estrutura do tipo vazio.

87

E.3.3 Tanques

O tamanho do tanque deve ocupar quase todo o espaco de um estrutura. Ele tem

alguns parametros sua velocidade, tempo de recarga e quantidade de dano que pode

receber antes de morrer. Todos os tanques podem se deslocara para frente e rotacionar

para ambos os lados. O deslocamento e sempre efetuado do centro de uma estrutura para

outra. A rotacao do tanque e sempre efetuada em angulos de 90 graus. Tanto os tanques

do jogador quando dos inimigos sao tratados iguais.

E.3.4 Tiros

Os tiros partem na estrutura a frente do tanque, para a direcao que ele estiver virado.

Ele se desloca a uma velocidade bem maior que os tanques. Se o tiro tentar entrar em

uma celula que tem um tanque ou uma estrutura do tipo nao vazio, e removido uma

energia do objeto.

88

ANEXO F -- Diagramas do Tan

Figura 27: Diagrama de classes da segunda versao do framework.

89

Figura 28: Classes na biblioteca de componentes na segunda versao do framework.

90

Figura 29: Diagrama de classes completo do jogo Tan.

91

Figura 30: Diagrama de sequencia para inicializacao do Tan.

92

Figura 31: Diagrama de sequencia do fluxo de execucao do Tan.

Figura 32: Grafo de cenas para o desenho 3D para o Tan.

Fabricio Brasiliense - Coordenação de Projetos · Java Micro Edition e utilizado a API A Mobile...

Documents

Transcript of Fabricio Brasiliense - Coordenação de Projetos · Java Micro Edition e utilizado a API A Mobile...