CENTRO UNIVERSITÁRIO RITTER DOS REIS FACULDADE DE SISTEMAS DE INFORMAÇÃO JOÃO CARLOS ZIMMERMANN

CENTRO UNIVERSITÁRIO RITTER DOS REIS FACULDADE DE SISTEMAS DE INFORMAÇÃO JOÃO CARLOS ZIMMERMANN DESENVOLVIMENTO DE JOGOS PARA CELULARES PROJETO DE CONCLUSÃO DE CURSO PORTO ALEGRE 2006

CENTRO UNIVERSITÁRIO RITTER DOS REIS FACULDADE DE SISTEMAS DE INFORMAÇÃO JOÃO CARLOS ZIMMERMANN DESENVOLVIMENTO DE JOGOS PARA CELULARES Projeto Final de Curso, como requisito para obtenção do grau em Sistemas de Informação, no Centro Universitário Ritter dos Reis, sob a orientação da professora Silvia de Castro Bertagnolli. PORTO ALEGRE 2006 2

SUMÁRIO 1 INTRODUÇÃO... 6 1.1 MOTIVAÇÃO... 6 1.2 OBJETIVOS... 7 1.2.1 Objetivo Geral... 7 1.2.2 Objetivos Específicos... 7 1.3 ORGANIZAÇÃO DO TEXTO... 8 2 DESENVOLVIMENTO ÁGIL... 9 2.1 SCRUM... 11 2.2 FEATURE DRIVEN DEVELOPMENT... 12 2.3 CRYSTAL... 13 2.4 DYNAMIC SYSTEM DEVELOPMENT METHOD... 14 2.5 EXTREME PROGRAMMING... 15 3 RUP (RATIONAL UNIFIED PROCESS)... 18 4 TECNOLOGIAS PARA DESENVOLVIMENTO DE JOGOS... 23 4.1 BREW... 23 4.2 FLASH LITE... 24 4.3 J2ME... 25 4.4 DISPOSITIVOS MÓVEIS... 29 4.4.1 Comunicação de celulares... 30 5 DESENVOLVIMENTO DE JOGOS... 33 5.1 CLASSIFICAÇÕES DE JOGOS... 33 5.2 ELEMENTOS DE UM JOGO... 35 6 SOLUÇÃO ELABORADA... 39 6.1 CONTEXTUALIZAÇÃO DO JOGO... 39 6.2 ANÁLISE E ESPECIFICAÇÃO DOS REQUISITOS... 40 6.3 ANÁLISE E PROJETO DO JOGO... 44 6.3.1 Classe Aqua... 47 6.3.2 Classe Engine... 47 6.3.3 Floor... 48 6.3.4 Historia... 49 6.3.5 Mapas... 49 6.3.6 Menu... 49 6.3.7 Toxicman... 50 6.3.8 UIFont... 50 6.3.9 Warrior... 50 6.4 IMPLEMENTAÇÃO... 51 7 RESULTADOS... 53 7.1 ELEMENTOS PRINCIPAIS DO JOGO... 53 7.2 PERSONAGENS DO JOGO... 55 7.3 FASES E CENÁRIOS... 58 7.4 OS PROBLEMAS... 61 7.5 JOGOS - TESTES REALIZADOS... 63 7.5.1 Jogo Singleplayer 2D de Tipo Arcade... 63 7.5.2 Jogo de Corrida 2D Multiplayer Utilizando Bluetooth... 64 7.5.3 Jogo 2D Tipo RPG Estilo Livro-jogo... 64 8 CONCLUSÕES... 66 REFERÊNCIAS BIBLIOGRÁFICAS... 68 3

LISTA DE SIGLAS E ABREVIAÇÕES API BREW CDC CLDC DSDM FDD HTTP J2ME JCP JVM MIDP MMS PDA PNG RUP SMS XML XP Aplication Programing Interface Binary Runtime Environment for Wireless Conected Device Configuration Conected Limited Device Configuration Dynamic System Development Method Feature Driven Development Hyper Text Transfer Protocol Java 2 Micro Edition Java Comunity Process Java Virtual Machine Mobile Information Device Profile Multimedia Messaging Service Personal Digital Assistents Portable Network Graphics Rational Unified Process Short Message Service Extensible Markup Language extreme Programming 4

LISTA DE FIGURAS E QUADROS FIGURA 1 DIAGRAMAS DA UML USADOS PARA MODELAGEM VISUAL... 19 FIGURA 2 ITERAÇÕES NO RUP... 20 FIGURA 3 ORGANIZAÇÃO DO RUP... 22 FIGURA 4 EXEMPLOS DE INTERFACES GRÁFICAS COM FLASH LITE... 25 FIGURA 5 MÁQUINAS VIRTUAIS JAVA... 26 FIGURA 6 GAME API... 28 FIGURA 7 CÉLULAS E RÁDIO BASES... 31 FIGURA 8 MODELOS DE CELULARES... 31 FIGURA 9 JOGO 3D: PRIMEIRA PESSOA... 33 FIGURA 10 JOGO 3D: TERCEIRA PESSOA... 34 FIGURA 11 JOGO 2D... 34 FIGURA 12 IMAGEM SIMPLES... 36 FIGURA 13 - IMAGEM COMPOSTA... 37 FIGURA 14 CASO DE USO DO JOGADOR... 41 QUADRO 1 CASO DE USO ESSENCIAL CRIAR NOVO JOGO... 42 QUADRO 2 CASO DE USO ESSENCIAL PAUSAR JOGO... 42 QUADRO 3 CASO DE USO ESSENCIAL CONTINUAR JOGO... 42 QUADRO 4 CASO DE USO ESSENCIAL SAIR DO JOGO... 42 FIGURA 15 DIAGRAMA DE CASO DE USO DO AVATAR... 43 QUADRO 5 CASO DE USO ESSENCIAL PULAR... 43 QUADRO 6 CASO DE USO ESSENCIAL PULAR... 43 QUADRO 7 CASO DE USO ESSENCIAL PULAR... 44 FIGURA 16 DIAGRAMA DE CLASSES... 46 FIGURA 17 JOGO EXECUTANDO... 53 FIGURA 18 MARCADOR DE ÁGUA... 54 FIGURA 19 PERSONAGEM PRINCIPAL ATACANDO INIMIGOS... 54 FIGURA 20 INIMIGOS E RESÍDUOS TÓXICOS... 54 FIGURA 21 MENSAGEM DE FINALIZAÇÃO... 55 FIGURA 22 FONTE DE ÁGUA... 55 FIGURA 23 PERSONAGEM PRINCIPAL... 56 FIGURA 24 PERSONAGEM ONDINA... 56 FIGURA 25 HOMEM TÓXICO... 57 FIGURA 26 GOLEM DE LAVA... 57 FIGURA 27 FASE 1... 58 FIGURA 28 FASE 2... 59 FIGURA 29 MARCANDO TÉRMINO DE FASE... 59 FIGURA 30 FASE 3... 60 5

1 INTRODUÇÃO 1.1 Motivação Este trabalho tem como motivação principal estabelecer um conjunto de regras exemplificando e mostrando os passos para a criação de jogos para celulares. Isso é necessário porque, após uma breve análise da literatura, foi encontrado um número reduzido de trabalhos, tanto na área de dispositivos móveis (celulares, PDA s Personal Digital Assistant ) como para o desenvolvimento de jogos. Outra motivação compreende a dificuldade de criação de aplicativos genéricos, ou seja, que funcionem em todos os tipos de celulares disponíveis no mercado. Isso se deve a alguns fatores, tais como com um conjunto em comum de características, como tamanho de tela e cores. Para escrever um aplicativo genérico ainda existe um problema a ser resolvido, pois os celulares não possuem um padrão que aborde todos os aspectos da KVM (K Virtual Machine, a sigla utiliza o K, pois, esta implementação da máquina virtual do Java utiliza apenas alguns kilobytes para executar), tais como: implementação de imagens executadas de formas diferentes, alguns dispositivos fazem por hardware e outros por software. Existe também a implementação das teclas de softkeys e joysticks, as quais não possuem padronização, pois cada companhia de celular coloca para cada tecla um código da KVM diferente. Encontram-se ainda outras dificuldades a serem vencidas, tais como processamento reduzido, espaço de armazenamento extremamente limitado em muitos aparelhos. Alguns aparelhos têm a limitação estendida, pois utilizam cartões 6

de memória, ainda assim eles só podem utilizar um cartão de memória por vez o que resulta em no máximo 1 GB de espaço em disco. A próxima seção apresenta o objetivo geral e os específicos utilizados para o desenvolvimento deste trabalho. 1.2 Objetivos 1.2.1 Objetivo Geral O objetivo geral do projeto é o desenvolvimento de um jogo para celular onde o processo resulte em algumas regras para a criação de jogos. O jogo desenvolvido irá demonstrar como estas regras podem ser aplicadas explorando alguns caminhos possíveis. 1.2.2 Objetivos Específicos Como objetivos específicos para este trabalho, propõem-se: 1. estudo de plataformas móveis (hardware e software); 2. estudo de notações para modelagem de software; 3. estudo de processos para desenvolvimento de software; 4. estudo de uma linguagem de programação para celular; 5. modelagem do jogo proposto; 6. construção do jogo; 7. estabelecimento de um conjunto de regras de desenvolvimento. 7

1.3 Organização do Texto O texto do trabalho encontra-se organizado como segue: Capítulo 2 apresenta os conceitos (processos ágeis) relacionados com o desenvolvimento ágil e introduz conceitos chave relacionados com o método de desenvolvimento XP (extreme Programming); Capítulo 3 aborda o processo de desenvolvimento RUP (Rational Unified Process), o qual descreve os principais conceitos e fases; Capítulo 4 apresenta as principais tecnologias para o desenvolvimento de jogos, uma abordagem geral sobre esse tema, além de realizar uma introdução às principais classificações e características de alguns dispositivos móveis; Capítulo 5 descreve, brevemente, aspectos e classificações fundamentais relacionadas ao desenvolvimento de jogos; Capítulo 6 descreve a solução elaborada, em detalhes, bem como alguns elementos considerados pertinentes ao trabalho; Capítulo 7 apresenta os resultados obtidos com a aplicação do trabalho; Capítulo 8 descreve algumas das conclusões obtidas com o desenvolvimento do trabalho. 8

2 DESENVOLVIMENTO ÁGIL Estamos descobrindo maneiras melhores de se desenvolver software, aplicando-as e ajudado outros a aplicá-las. Deste trabalho, nós valorizamos: 1. Indivíduos e interações mais que processos e ferramentas; 2. Software em funcionamento mais que documentação abrangente; 3. Colaboração do cliente mais que negociação contratual; 4. Responder as mudanças mais que seguir um plano. Isto é, embora tenham valor os itens da direita nós valorizamos mais os itens da esquerda. (Beck, 2001) No início da década de 80, os processos de desenvolvimento de software começaram a ser muito utilizados, pois, havia uma necessidade de organização do processo criação e descrição para futuras mudanças ou manutenabilidade do software. Essa foi uma tentativa de tornar a criação de software mais previsível e eficiente. Nessa época, existia pouco planejamento e organização, o que acarretava um trabalho extremamente repetitivo e desnecessário, sendo que até mesmo os erros eram repetidos. Os programas possuíam um número excessivo de erros e a manutentabilidade praticamente inexistia, porque era mais fácil começar o projeto do zero em alguns casos do que dar manutenção no código (Santos, 2006). Estes primeiros processos de desenvolvimento de software focalizavam-se no planejamento e em como seguí-lo. As pessoas envolvidas no projeto não eram relevantes, além disso, eles não ofereciam espaço para mudanças fazendo com que o processo ficasse muito burocrático e lento. Isso ocorria porque eles exigiam a criação de muitos documentos, desde antes do início do projeto, e a documentação 9

exigida para mudanças (trocas de funcionalidades ou a inclusão das mesmas) era também demasiadamente abusiva (Santos, 2006). Neste contexto, mais político do que produtivo, surgiu como resposta o desenvolvimento ágil, o qual determinou uma nova forma de criação, mais flexível e fácil de utilizar, pois ele induz respostas rápidas às mudanças de contexto e funcionalidades ao contrário dos métodos antigos (Santos, 2006). No desenvolvimento ágil, novas soluções começaram a serem criadas e testadas baseadas em processos mais ágeis, leves e menos rígidos e que produzissem uma documentação mais concisa, direcionada para a qualidade do código, ciclos de iteração e intensa colaboração entre cliente e equipe de desenvolvimento (Santos, 2006). Uma das características fundamentais deste tipo de processo é o comprometimento com as mudanças (rápida adaptação a novos requisitos ou a mudanças dos mesmos), tornando o processo ágil altamente adaptativo. Para garantir isto ele foi fundamentado em um ciclo de vida iterativo e incremental (Santos, 2006). Outra das suas características seria o foco nas pessoas, onde as pessoas são extremamente valorizadas e reconhecidas por fazerem à diferença em um projeto, pois são elas que dizem se o software foi um total sucesso ou um completo fracasso. Nos processos tradicionais, as pessoas utilizam as ferramentas definidas no início do projeto e ficam presas a elas utilizando-as com pouco ou nenhum benefício. Já nos métodos ágeis, existe a tentativa de se criar um ambiente de colaboração e de troca de informações, onde as ferramentas podem ser alteradas dependendo das pessoas e da forma com a qual elas irão ter uma produção muito superior (Santos, 2006). 10

O foco nas pessoas contém outro ponto importante que é o envolvimento do cliente no projeto, pois o projeto é para o cliente e ele vai determinar o sucesso do resultado final, ou o seu fracasso. Os processos ágeis visam estimular a participação das pessoas no projeto durante o processo de criação, momento em que sempre estarão sendo adicionadas informações, benefícios ou mudanças como a troca de funcionalidades prioritárias e correção de código (Santos, 2006). Os métodos ágeis por sua vez questionam a criação excessiva de documentação e apóiam a utilização apenas dos artefatos necessários. Dentre os processos ágeis mais difundidos, hoje, têm-se (Santos, 2006): o Scrum, o Feature Driven Development (FDD), o Crystal, Dynamic System Development Method (DSDM) e o extreme Programming (XP), conforme apresentam as próximas seções. 2.1 Scrum Segundo Krebs (2005), o Scrum é um conjunto de técnicas para gerenciar qualquer tipo de projeto baseado em modelos iterativos de desenvolvimento, além de definir um conjunto de práticas para planejar o acompanhamento e a medição desse tipo de projeto. No Scrum, as funcionalidades a serem implementadas ficam em um repositório chamado de product blacklog, este é criado com um conjunto de funcionalidades, as quais podem sofrer alterações durante o projeto (atualizações ou incorporar novas funcionalidades). Nele, cada iteração possui trinta dias e é chamado de sprint, onde no início de cada ciclo há uma reunião chamada sprint planning meeting, onde serão definidas 11

as funcionalidades que serão implementas naquele ciclo de acordo com a prioridade atribuída pelo cliente (product owner). A cada fim de iteração existe uma nova reunião (review sprint meeting), para que as funcionalidades, já implementadas, sejam apresentadas e revisadas. Outra característica do Scrum é que todo dia há uma reunião rápida, de mais ou menos quinze minutos, para atualizar a equipe sobre o andamento do projeto. 2.2 Feature Driven Development O FDD é um processo iterativo voltado a features (outro nome para as funcionalidades e as características do sistema), que utiliza iterações de duas semanas, código proprietário e modelagem antes do início de cada ciclo (FDD, 2006, Santos,2006). Este processo encontra-se dividido em cinco atividades: (i) desenvolvimento de um modelo geral, (ii) construção de uma lista de features, (iii) planejamento por feature, (iv) projetar por feature, (v) construção por feature. A equipe de trabalho produz um modelo geral do domínio utilizando diagramas de classes da UML. Após a finalização dos mesmos, eles são integrados em um único diagrama. Após, é criada a lista de features a partir dos modelos de domínio e novas features podem vir a ser adicionadas, conforme as necessidades do cliente. A feature é projetada usando-se o modelo de classes do domínio e criando-se um diagrama de seqüência UML detalhado (FDD, 2006, Santos, 2006). A feature, então, é construída e testada pelos desenvolvedores para serem entregues. Por fim, é feita a priorização e a estimação de tempo para a implementação de cada feature, e elas são agrupadas nos features sets conforme suas finalidades. 12

No FDD, existem os Chief Programmers (CP) que coordenam a implementação das features e os Class Owners (CO) que são responsáveis por um conjunto de classes e criam os métodos necessários para a implementação das features. 2.3 Crystal O Crystal (Crystal, 2006, Santos, 2006) é um conjunto de processos, onde o idealizador pensa que cada projeto precisa de um processo específico. Assim, foram definidos conjuntos de processos para funcionarem como ponto de partida, os quais devem ser escolhidos e adaptados conforme a necessidade da equipe. A escolha do processo depende do número de pessoas envolvidas no projeto e a probabilidade de ocorrerem riscos no projeto. A família de métodos Crystal é formada pelos processos Crystal Clear, Crystal Amarelo, Crystal Laranja, Crystal Vermelho, Crystal Marrom, Crystal Azul e Crystal Violeta, onde o Crystal clear é o mais ágil de todos e define um número mínimo de elementos para o processo funcionar. Para cada outro processo são adicionados alguns elementos para suportar equipes maiores. Apesar das diferenças existentes eles compartilham um conjunto de princípios, tais como entregas freqüentes, melhoria por reflexão e comunicação. 13

2.4 Dynamic System Development Method Um projeto para ser desenvolvido utilizando DSDM (DSDM, 2006, Santos, 2006) deve iniciar fazendo um estudo de viabilidade para verificar se o processo é adequado para o projeto. Após, é realizado um estudo de negócio para a definição do escopo, da visão geral da arquitetura e do plano de projeto. O processo possui, ainda, três fases iterativas: (i) iteração de modelagem funcional (levantamento dos requisitos, funcionais e não funcionais, e criação dos protótipos para o melhor entendimento); (ii) iteração de projeto e construção (os protótipos são refinados e evoluídos para se tornarem o produto em si) e (iii) implementação (passagem do produto para o ambiente de produção, treinamento dos usuários e preparação da infra-estrutura). Além das fases iterativas ele possui alguns princípios dentre os quais os mais importantes são: envolvimento ativo dos usuários, equipe de desenvolvimento com poder de decisão, entregas freqüentes, adequações aos propósitos de negócio, desenvolvimento iterativo e incremental, colaboração e cooperação entre todos os envolvidos. Outro modelo ágil muito utilizado é o extreme Programming (XP) foi criado por Kent Beck durante o desenvolvimento de um sistema de folha de pagamento. Este processo é constituído por valores e práticas que devem guiar o desenvolvedor. Dentre os processos ágeis enumerados anteriormente, pretende-se utilizar alguns aspectos deste último, o XP, ele será descrito com mais detalhes na próxima seção. 14

2.5 Extreme Programming O objetivo do extreme Programming (XP) é a criação de um software com qualidade, produzido através de um processo de desenvolvimento simples e ágil. O XP é fundamentado em práticas e valores (XP, 2006). As práticas adotadas pelo XP compreendem: cliente sempre disponível, utilização de metáforas, jogo do planejamento, pequenas versões, testes de aceitação, testes em primeiro lugar (Test First Design), integração contínua (Continuous Integration), simplicidade de projeto, refatoração, programação em pares (Pair Programming), rodízio de pessoas (Move People Around), padronização do código, otimização das jornadas de trabalho (40 Hour Week) (XP, 2006). Dentre as práticas do XP, acima citadas, apenas algumas serão utilizadas neste trabalho. Isso se deve ao fato de que somente essas se enquadram no escopo e nas necessidades do mesmo, são elas (XP, 2006): 1. cliente sempre disponível (Customer is Always Available) - o cliente sempre está disponível para esclarecer dúvidas, colaborar com eventuais alterações e prioridades do projeto. Isso permite um alto dinamismo e uma troca de informações muito acentuada entre a equipe de desenvolvimento e o cliente; 2. jogo do planejamento são realizadas reuniões constantes entre o cliente e os desenvolvedores, que visam o entendimento das "user stories", ou seja, as estórias do usuário no uso do sistema. Essas estórias têm o objetivo de explicar e exemplificar as regras de negócio do sistema, bem como as suas funcionalidades; 15

3. liberação de pequenas versões (Small Releases) - conforme são concluídos algumas versões do software solicitado, o cliente recebe versões do sistema com partes funcionais, tanto para que ele acompanhe o andamento do projeto, como para que auxilie na sua validação; 4. teste de aceitação (Acceptance Tests) - são definidos pelo cliente na fase inicial do projeto e são os critérios de aceitação do software. Esses testes de aceitação são utilizados para verificar se o sistema desenvolvido atingiu os resultados esperados; 5. refatoração (refactoring) - toda nova funcionalidade adicionada ao códigofonte é revisada em busca de melhorias, ou apenas da sua simplificação; 6. padronização de código (Coding Standards) - o código deve ser desenvolvido seguindo um padrão definido pela equipe. Isso serve para evitar confusões e possíveis erros no CVS (Concurrent Versions System) da equipe. Além das práticas, esta técnica de desenvolvimento costuma fundamentar-se em alguns valores, os quais compreendem: comunicação: alguém que já conhece o problema e sabe como resolvê-lo guia a comunicação, que é a melhor forma de se difundir o conhecimento; simplicidade: manter o sistema simples apenas com as funcionalidades e os problemas prioritários; feedback: a resposta do cliente é melhor forma de saber se o sistema está tomando a direção correta. Informar o cliente sobre como está o andamento do projeto é melhor forma dele tomar conhecimento do andamento do projeto. Assim, o cliente torna-se mais confiante, pois está participando efetivamente da criação do mesmo; 16

coragem: o cliente, conforme o andamento do projeto, descobre e aprende coisas novas na interação com a equipe de desenvolvimento. Logo, mudanças irão surgir e novas prioridades também. Desse modo, é necessária coragem para mudar o que já estava funcionando, ou seja, para que o sistema fique melhor deve-se correr o risco de que o sistema pare de funcionar. Além do XP, alguns desenvolvedores costumam utilizar o processo de desenvolvimento unificado, denominado RUP, conforme apresenta o próximo capítulo. 17

3 RUP (RATIONAL UNIFIED PROCESS) O RUP é um processo de desenvolvimento de software iterativo e incremental, dirigido por casos de uso que utiliza a UML (Unified Modeling Language) para gerar seus artefatos e é centrado na arquitetura (Booch, 2000). Esse processo possui algumas práticas de desenvolvimento que o tornam um dos mais utilizados. Essas práticas, denominadas as melhores práticas, compreendem (Fernandes, 2006): desenvolvimento iterativo várias iterações são realizadas para desenvolver todo o software. Isso facilita a identificação/gerenciamento de riscos para o projeto. Também, permite estimar prazos e custos, além de possibilitar um melhor entendimento do escopo; gerenciamento de requisitos - recomenda a utilização de casos de uso e cenários para determinar as funcionalidades do software; arquitetura baseada em componentes o projeto utiliza uma arquitetura flexível (que pode sofrer mudanças), compreensível, promovendo a reutilização de unidades de software os componentes; 18

modelagem visual adota elementos gráficos, modelos e diagramas que possibilitam uma melhor compreensão da modelagem do software, a exemplo temos os diagramas mostrados na Figura abaixo (Figura 1); Figura 1 Diagramas da UML usados para Modelagem Visual Fonte NERI, 2004. verificação da qualidade de software realizada por atividades de validação que garantem a qualidade do produto. Elas devem ser realizadas durante todo o processo de desenvolvimento; controle de mudanças do software controle sobre mudanças dos requisitos do software, visando manter a qualidade do sistema. 19

Além dessas práticas, o RUP é fundamentado em três características que o definem como processo de desenvolvimento de software (Fernandes, 2006): 1. guiado por casos de uso os casos de uso orientam todo o desenvolvimento, pois servem para mapear os requisitos, determinar o modelo conceitual, definir as classes, o código e são, também, utilizados para fornecer os casos de teste; 2. iterativo e incremental - aspecto no qual o projeto é subdividido em miniprojetos ou iterações, que serão integrados em um único software ao término do projeto. A Figura 2 apresenta as disciplinas do RUP que serão divididas posteriormente em iterações; Figura 2 Iterações no RUP Fonte NERI, 2004. 3. centrado na arquitetura a arquitetura de sistema é utilizada pelo RUP para determinar como serão os relacionamentos entre as camadas e entre os componentes das diversas versões liberadas. 20

Conforme mencionado anteriormente, o RUP é um processo iterativo e incremental, para tanto ele foi organizado em quatro fases (Jacobson, 1999) (Booch, 2000): 1. iniciação as atividades desta fase resumem-se em definir os critérios de sucesso de projeto, os riscos e os recursos necessários, a data de realização das principais etapas a delimitação do escopo do projeto, identificação dos atores que interagem com o sistema, identificação das interações dos atores com o sistema e as funcionalidades principais (casos de uso). Nesta fase, ainda, é construído o modelo inicial de casos de uso, o glossário do projeto e a definição de objetivos e viabilidade do projeto; 2. elaboração - a finalidade desta fase é eliminar os elementos de maior risco do projeto através da criação de uma arquitetura coerente e consistente da solução, contando com a construção de protótipos executáveis, em uma ou mais interações, e dar prioridade aos casos de uso críticos, criando protótipos para demonstrar para clientes e usuários. Nesta fase os casos de uso estão praticamente completos (mais de 80% concluídos); 3. construção desenvolvimento de todos os componentes e características não resolvidas nas fases anteriores, testando-as e integrando-as na forma de um produto, um release estável; 4. transição realização de testes e validação, release final, com a entrega do produto final e treinamento de usuários a mantenedores, distribuição e vendas. 21

A Figura 3 mostra as fases do RUP, bem como as disciplinas descritas anteriormente. Figura 3 Organização do RUP Fonte Fernandes, 2002. Podem ocorrer diversas iterações em cada fase, sendo que cada iteração é desenvolvida em um conjunto de fluxos de trabalho: análise e especificação de requisitos, análise e projeto, implementação, integração e testes. Um processo de desenvolvimento pode ser utilizado nos mais diversos contextos, por exemplo, na área de jogos, conforme aborda a próxima seção. 22

4 TECNOLOGIAS PARA DESENVOLVIMENTO DE JOGOS 4.1 Brew Uma das tecnologias as quais podem ser utilizadas para o desenvolvimento de jogos para celular é o BREW (Binary Runtime Environment for Wireless), lançado pela Qualcomm em 2001, não é apenas uma plataforma de desenvolvimento, mas também um ambiente de execução (Qualcomm, 2004). A plataforma BREW possui como linguagem nativa o C/C++, levando isto em consideração a curva de aprendizado do Brew para desenvolvedores C/C++ é mínima, fator que para programadores de outras linguagens é bem diferente. O desempenho da execução de aplicativos Brew é bem superior aos dos outros aplicativos escritos em outras linguagens, pois essa plataforma não utiliza máquinas virtuais (Qualcomm, 2004). Uma vantagem, e ao mesmo tempo uma desvantagem, no Brew é o acesso irrestrito do dispositivo, onde a aplicação Brew não é segura, nem confiável, pois ela tem acesso a todos os recursos do celular. Para balancear e proteger os celulares, a Qualcomm possui um modelo de negócios, onde apenas ela pode distribuir os aplicativos (ela ou as operadoras, por exemplo, a vivo). Assim, antes do aplicativo ser disponibilizado para download (com assinatura digital) ele é testado e validado por uma equipe Qualcomm. Por não haver possibilidade de download por outros meios que não pela operadora com assinatura digital não existem ainda jogos piratas de Brew. 23

4.2 Flash Lite O Flash Lite é uma versão do Macromedia Flash, a qual foi criada para dispositivos móveis, com baixo poder de processamento e com pouca memória, para que os usuários possam executar em seus celulares aplicativos flash (animações interativas) (Andrade,2005). Os aplicativos para o Flash Lite são desenvolvidos com o Macromedia Flash 8 ou com o Macromedia Flash MX 2004. O Flash Lite possui algumas vantagens sobre outras linguagens dentre as quais está a programação visual, pois criar uma animação em flash é muito mais rápido do que em C++. A criação de interfaces gráficas é bem mais rápida, e, além disso, como o flash é interpretado os aplicativos são multi-plaforma. Porém, isto torna o desempenho de aplicativos flash um pouco mais lentos do que nas outras linguagens. Um outro ponto negativo do flash é que as aplicações não têm um nível de complexidade elevado para a criação de aplicativos mais requintados (Andrade, 2005). Algumas das características do Flash Lite são (Andrade, 2005): 1. possibilidade de armazenamento de informações no celular; 2. acesso via protocolo HTTP (Hyper Text Transfer Protocol); 3. envio de mensagens SMS (Short Message Service) e MMS (Multimedia Messaging Service); 4. possibilita utilizar a tecnologia de XML (Extensible Markup Language); 5. oferece suporte à multimídia (arquivos de som e vídeo). Destaca-se que o Flash Lite é ótimo para desenvolver aplicativos rápidos ou protótipos, sem grande complexidade de negócio. 24

A Figura 4 ilustra alguns exemplos de interfaces desenvolvidas utilizando-se o Flash Lite. Figura 4 Exemplos de Interfaces Gráficas com Flash Lite Fonte Fernandes, 2002. Outra tecnologia muito utilizada para desenvolvimento de jogos é a plataforma Java para dispositivos móveis, conforme descreve a próxima seção. 4.3 J2ME A linguagem de programação Java oferece uma plataforma de programação chamada J2ME (Java 2 Micro Edition) utilizada para programação de dispositivos móveis como celulares e PDA s (MUCHOW, 2004). A plataforma J2ME possui uma máquina virtual Java um pouco diferente. A JVM (Java Virtual Machine) para dispositivos móveis é chamada de KVM, definiram um nome diferente para ela porque ela executa apenas programas que necessitem de alguns kilobytes. A KVM é necessariamente pequena pelas restrições que os dispositivos móveis possuem, não permitindo o desenvolvimento de aplicativos muito grandes ou que consumam muito processamento devido ao pouco poder de processamento (não paralelo e multi-processado) e por não possuir muita memória disponível (MUCHOW, 2004). 25

A plataforma J2ME não possui todas as classes e pacotes da plataforma Java tradicional por causa das restrições físicas do dispositivo, como já mencionado (Figura 5). Figura 5 Máquinas Virtuais Java Fonte Muchow, 2004. A programação de dispositivos móveis pode utilizar duas configurações (MUCHOW, 2004): CDC (Connected Device Configuration) que utiliza a JVM tradicional e é utilizada em dispositivos com mais memória e mais poder de processamento. Algumas características do CDC são: 512 Kb memória para Java e 256 Kb de memória para uso em tempo de execução; CLDC (Connected Limited Device Configuration) utiliza especificamente a KVM a qual serve apenas para dispositivos com pouca memória e pouco processamento. Algumas características do CLDC compreendem: 128 KB memória para Java, 32 KB de memória para uso em tempo de execução e interface restrita. 26

Acima da configuração, em um nível mais alto, existem ainda os perfis com API s (Application Programming Interfaces) para determinados tipos de dispositivos (como por exemplo, extensões das configurações). O perfil utilizado para celulares é o MIDP (Mobile Information Device Profile), que define bibliotecas e/ou componentes para entrada de dados, tratamento de eventos de interface com o usuário, persistência de dados, interligação de redes e cronômetros levando em consideração limitações de tela processamento e memória dos dispositivos (MUCHOW, 2004). O J2ME possui algumas especificações (API s) as quais podem ser agregadas aos programas de acordo com a necessidade do aplicativo. Hoje, devido à JCP (Java Community Process) é possível encontrar na literatura algumas especificações a mais, os chamados JSR s. Por exemplo, o JSR- 82 é uma API para utilização do dispositivo bluetooth do celular. Pois, embora um celular possua bluetooth sua KVM pode não estar habilitada para esse dispositivo físico, assim o aplicativo não rodará no celular, o mesmo acontece com algumas outras especificações existentes (MUCHOW, 2004). Existem alguns problemas na implementação das KVM s dos celulares, que por não haver uma convenção (padronização de botões) existem os botões chamados proprietários, os quais a plataforma Java não permite o acesso, como por exemplo, os botões de volume, liga e desliga (MUCHOW, 2004). Outros problemas são os softbuttons e os joysticks, pois, embora, praticamente todos os celulares de hoje os possuam, as KVM s dos fabricantes de celulares não padronizaram os códigos dos mesmos. Por exemplo, o softbutton 1 de um celular Nokia possui o código de KVM igual a menos cinco (-5), já em celulares Motorola este código varia de vinte e dois e menos vinte e dois (22 e -22). 27