IMPLEMENTAÇÃO DE UM MOTOR DE JOGOS DE CARTA PARA A PLATAFORMA ANDROID

Transcrição

1 UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIA DA COMPUTAÇÃO BACHARELADO IMPLEMENTAÇÃO DE UM MOTOR DE JOGOS DE CARTA PARA A PLATAFORMA ANDROID MASSAMI WELINGTON KAMIGASHIMA BLUMENAU /2-19

2 MASSAMI WELINGTON KAMIGASHIMA IMPLEMENTAÇÃO DE UM MOTOR DE JOGOS DE CARTA PARA A PLATAFORMA ANDROID Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciência da Computação Bacharelado. Prof. Paulo César Rodacki Gomes, Dr. - Orientador BLUMENAU /2-19

3 IMPLEMENTAÇÃO DE UM MOTOR DE JOGOS DE CARTA PARA A PLATAFORMA ANDROID Por MASSAMI WELINGTON KAMIGASHIMA Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por: Presidente: Membro: Membro: Prof. Paulo César Rodacki Gomes, Dr. Orientador, FURB Prof. Dalton Solano dos Reis, M. FURB Prof. Mauro Marcelo Mattos, Dr. FURB Blumenau, 12 de dezembro de 2011

4 Dedico este trabalho a minha família, amigos e principalmente a todos que me apoiaram direta e indiretamente no desenvolvimento deste trabalho.

5 AGRADECIMENTOS A Deus, pela vida que possuo. À minha família, que está sempre ao meu lado em todos os momentos. A todos os meus amigos, que me apoiaram e deram forças para continuar. Ao meu orientador, Paulo César Rodacki Gomes, por ter me dado a idéia e todo apoio para que este trabalho fosse possível.

6 RESUMO Este trabalho apresenta a elaboração de um motor de jogos para a plataforma Android em forma de uma biblioteca e sua implementação um protótipo de jogo de pôquer. São apresentados conceitos básicos sobre os principais recursos disponíveis para o desenvolvimento de uma aplicação nesta plataforma. O motor disponibiliza ao desenvolvedor a estrutura básica de um jogo de cartas, tais como a gerência das cartas do baralho, posicionamento dos elementos na tela e a interação das cartas com o usuário. Palavras-chave: Android. Jogos. Motor de jogos.

7 ABSTRACT This work describes the development of a game engine for Android platform in the form of a library and the implementation of a poker game prototype. Basic concepts are also presented on the main resources available to develop an application on this platform. The engine provides the designer with the basic structure of a card game, such as management of the cards in the deck, positioning of elements on the screen and interact of the user with the cards. Key-words: Android. Games. Game engine.

8 LISTA DE ILUSTRAÇÕES Figura 1- Imagens de uma partida de pôquer (esq.) e uma partida de paciência (dir.) Figura 2 - Arquitetura da plataforma Android Figura 3 - Representação da pilha de atividades Figura 4 - LinearLayout Figura 5 - TableLayout Figura 6 RelativeLayout Figura 7 Exemplo de aplicação do MJ3I Figura 8 - Interface do BGE Figura 9 - Interface do Havok Physics Figura 10 Diagrama de casos de uso Figura 11 Diagrama de classes do motor de jogos Figura 12 Pacote engine.model Figura 13 Pacote engine.view Figura 14 - Pacote engine.view (cont.) Figura 15 Tela principal Figura 16 Tela de seleção de jogo Figura 17 Tela de seleção de jogadores Figura 18 Menu de exibição Figura 19 engine.control Figura 20 Pacote engine.gamemode Figura 21 Diagrama de sequência do caso de uso UC Figura 22 Tela de opções Figura 23 Listagem de cores Figura 24 Tela de jogo Figura 25 Opções de apostas Figura 26 Regulamentos do jogo Figura 27 Pontuação do jogo... 64

9 LISTA DE QUADROS Quadro 1 - Estrutura XML de um TableLayout Quadro 2 Estrutura XML de um RelativeLayout Quadro 3 - Exemplo de inserção de recursos Quadro 4 AndroidManifest.xml Quadro 5 res/layout/gamevalues.xml Quadro 6 res/values/strings.xml Quadro 7 res/values/attrs.xml Quadro 8 Múltipla tipagem de constantes Quadro 9 Acessando constantes tipadas Quadro 10 res/menu/game_menu.xml Quadro 11 Instância de menus e tratamento dos botões Quadro 12 XML parcial da tela de entrada Quadro 13 Inicialização do GameDisplay Quadro 14 Inicialização de variáveis do jogo Quadro 15 setgame() Quadro 16 Definindo as propriedades do jogo Quadro 17 Rotina de distribuição das cartas Quadro 18 Ciclo de desenho Quadro 19 Atualização da posição das cartas Quadro 20 Verificação de posição Quadro 21 Ciclo de desenho de cartas em movimento Quadro 22 Função onbackpressed() Quadro 23 Verificação do botão de apostas Quadro 24 onpause() Quadro 25 MergeSort de cartas Quadro 26 Lista de pontuações do jogo de pôquer Quadro 27 Caso de uso UC Quadro 28 Caso de uso UC Quadro 29 Caso de uso UC Quadro 30 Caso de uso UC Quadro 31 Caso de uso UC

10 Quadro 32 Caso de uso UC LISTA DE TABELAS Tabela 1 Média de quadros por segundo (fps)... 65

11 LISTA DE SIGLAS AAPT - Android Asset Packaging Tool ADT Android Development Tools AI - Artificial Intelligence API Application Programming Interface ARGB - Alpha, Red, Green, Blue BGE - Blender Game Engine GB Giga Bytes GHz Giga Hertz GPU Graphic Processing Unit IDE - Integrated Development Environment JIT Just In Time J2ME - Java 2 Micro Edition M3GE - Mobile 3D Game Engine MB Mega Bytes MJ3I - Motor de Jogos 3D para o IPhone OS OpenGL ES - Open Graphic Library for Embedded Systems RAM - Random Access Memory SDK - Software Development Kit UML - Unified Modeling Language USB - Universal Serial Bus XML - extensible Markup Language

12 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS DO TRABALHO ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA MOTOR DE JOGOS PADRÕES DE JOGOS DE CARTAS ANDROID PROGRAMAÇÃO JAVA PARA ANDROID FrameLayout LinearLayout TableLayout RelativeLayout RECURSOS GRÁFICOS NO ANDROID Bibliotecas 2D Views Canvas OpenGL ES GLSurfaceView Renderer RESOURCES E XMLS AndroidManifest.xml res.layout res.drawable res.values Personalizando menus do sistema TRABALHOS CORRELATOS MJ3I M3GE Blender Game Engine (BGE) Havok DESENVOLVIMENTO... 39

13 3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ESPECIFICAÇÃO Casos de uso Diagramas de classe Pacote engine.model Pacote View Pacote engine.control Pacote engine.gamemode Diagrama de Sequência IMPLEMENTAÇÃO Técnicas e ferramentas utilizadas Inicialização da partida Algoritmos gráficos Algoritmos de controle onbackpressed() ontouch() onpause() roundwinner() Operacionalidade da implementação RESULTADOS E DISCUSSÃO CONCLUSÕES EXTENSÕES REFERÊNCIAS BIBLIOGRÁFICAS ANEXO A UC01 - Iniciar a partida ANEXO B UC02 - Alterar as configurações de jogo ANEXO C UC03 - Selecionar as opções de jogo ANEXO D UC04 - Distribuir as cartas ANEXO E UC05 - Mover as cartas da mão ANEXO F UC06 - Modificar o valor da aposta... 75

14 13 1 INTRODUÇÃO Para 2011, tem-se que a previsão de vendas dos smartphones será superior a dos computadores desktop no Brasil (UOL TECNOLOGIA, 2011). Entre os smartphones mais populares estão os que utilizam a plataforma Android. Com esta popularização, há uma grande demanda por desenvolvimento de aplicativos para estes dispositivos, nas quais os aplicativos direcionados para o entretenimento, especialmente jogos, e outros são bastante visados. Porém, para se desenvolver jogos para smartphones, assim como para outras plataformas, é necessário tempo e conhecimento. Neste ponto os motores de jogos 1 são muito utilizados para reduzir o tempo de produção dos jogos, pois são reaproveitados vários recursos comuns a múltiplos jogos, de forma que o desenvolvedor possa se dedicar mais aos detalhes específicos do jogo que está desenvolvendo do que com as necessidades padrões dos jogos do gênero. Diante disso, este trabalho tem como propósito facilitar o entendimento sobre o desenvolvimento de aplicativos dentro da plataforma Android a partir da implementação de um motor de jogos de cartas. Este motor tem como principal característica a gerência dos componentes vitais de um jogo de cartas, tais como o baralho, a pilha de descartes, a diferenciação de valores e naipes das cartas, entre outras características. Este motor atua em três frentes principais: o gerenciamento da estrutura de cartas, a interface com o usuário e as regras de jogo. A primeira frente visa a geração de cartas do baralho e sua sequência de retirada das cartas. A segunda é encarregada de produzir o desenho dos objetos do aplicativo na tela, a interação do toque do usuário com o aplicativo e efetuar as rotinas de movimento das cartas dentro do espaço gráfico. A terceira deve ser responsável pela definição de regras que um jogo deve seguir, tais como a determinação da ordem de prioridade das cartas, a pontuação da partida, os critérios de desempate entre outros. Para validar o motor proposto, foi implementado um protótipo de jogo de pôquer, o qual foi testado tanto em simuladores quanto em um dispositivo Android. 1 Um motor de jogo é um software ou biblioteca responsável por implementar parcialmente ou integralmente as funcionalidades de um jogo, podendo ser encontrada na forma de ferramentas ou bibliotecas.

15 OBJETIVOS DO TRABALHO O objetivo deste trabalho é desenvolver um motor de jogo para facilitar o desenvolvimento de jogos de cartas para a plataforma Android. Os objetivos específicos do trabalho são: a) disponibilizar um gerador de cartas de um baralho que permita armazenar uma sequência fixa ou aleatória do baralho durante a partida; b) disponibilizar funções para a distribuição das cartas entre o(s) jogador(es); c) disponibilizar recursos gráficos para a manipulação de cartas pelo cenário; d) determinar um conjunto limitado de constantes para auxiliar na implementação do protótipo de jogo, sendo algumas delas: a quantidade de cartas que cada jogador poderá segurar, a sequência das cartas disponíveis no jogo e o valor de cada carta entre outros valores pré-definidos; e) disponibilizar um motor para jogos de cartas e validá-lo através de um estudo de caso; f) implementar um protótipo de jogo utilizando o motor desenvolvido; g) disponibilizar os conjunto de cartas do baralho padrão francês 2 e suas variantes. 1.2 ESTRUTURA DO TRABALHO A estrutura deste trabalho é dividido em quatro capítulos, sendo que o segundo capítulo contém a fundamentação teórica necessária para o entendimento do trabalho. O terceiro capítulo apresenta o desenvolvimento do trabalho utilizando diagramas de casos de uso, de classes e de sequência que definem o motor e o protótipo. Neste capítulo também é apresentado as principais rotinas utilizadas na aplicação além de resultados e discussões que ocorreram durante o desenvolvimento deste trabalho. Por fim, o quarto capítulo apresenta as conclusões do trabalho e sugestões para trabalhos futuros. 2 O baralho padrão francês é o mais utilizado atualmente e é composto por 52 cartas divididas em quatro naipes (espadas, ouros, copas e paus). Em alguns países, foi inserido ao baralho um conjunto de cartas denominadas curingas, ou jokers, que são cartas independentes de valor ou naipe.

16 15 2 FUNDAMENTAÇÃO TEÓRICA A seção 2.1 aborda o conceito de motores de jogos. A seção 2.2 trata da definição dos jogos de cartas. A seção 2.3 apresenta um conceito geral sobre a plataforma Android. A seção 2.4 descreve as peculiaridades da programação Java dentro da plataforma. A seção 2.5 traz conceitos sobre os recursos gráficos disponíveis na plataforma. A seção 2.6 descreve a forma como os arquivos XML são utilizados no aplicativo. Por fim, a seção 2.7 apresenta trabalhos correlatos ao projeto. 2.1 MOTOR DE JOGOS Segundo Ward (2008), um motor de jogos, também conhecido como game engine, é uma abstração de detalhes como as tarefas comuns a jogos, como renderização, física, entrada de dados, interface gráfica com o usuário e até inteligência artificial. Porém, o conteúdo, a modelagem gráfica e texturas, o significado atrás das entradas, colisões e a interação dos objetos no ambiente são os componentes que definem o jogo. O termo game engine originou-se durante a década de 90 com a popularização de jogos 3D de tiro em primeira pessoa (First Person Shooter) tais como Doom e Quake. Devido ao fato de suas arquiteturas consistirem em componentes bem definidos e separados do núcleo do jogo (renderização, tratamento de colisões ou áudio) da arte, regras de jogo e experiência de jogo, permitiram que seus desenvolvedores criassem novos produtos alterando elementos do mundo e as regras de jogo com mínimas alterações no motor, marcando desta forma o início da comunidade de mods. Esta comunidade é composta por grupos de jogadores e pequenos estúdios que constroem novos módulos (mods) ou jogos utilizando ferramentas disponibilizadas pelos desenvolvedores do jogo original (GREGORY; LANDER, 2009, pg.11-12). Um motor de jogos pode ser desenvolvido generalizando-se partes da implementação para qualquer gênero de jogo, inclusive jogos multiplataforma. Porém, vários autores, como Gregory e Lander (2009, pg.11-12), afirmam que para fins de otimização e melhor resultado, deve ser definida uma plataforma e um gênero específico para o motor.

17 16 Atualmente são encontrados na internet inúmeros motores de jogos disponíveis gratuitamente ou licenciados por seus desenvolvedores para diversos fins. Não necessariamente específicas para jogos, estes motores também podem ser encontrados na produção de animações e filmes, além de simuladores para fins educativos, militares entre outros. Na maior parte dos casos, costuma-se encontrá-las em forma de APIs ou SDKs, e principalmente no caso das gratuitas, é comum encontrar comunidades de desenvolvimento através de fóruns nas quais os desenvolvedores podem sugerir e compartilhar novos recursos, melhorias ou corrigir problemas encontrados. 2.2 PADRÕES DE JOGOS DE CARTAS Segundo Schuytema e Manyen (2005, p. 92), um jogo é uma atividade composta por um conjunto de ações limitadas a um conjunto de regras, direcionadas para um determinado fim. Estas regras servem para delimitar e contextualizar as ações do jogador, além de criar situações de desafio e oposição ao jogador. Os jogos de cartas, muitas vezes associados como jogos de azar, também compartilham um conjunto de regras com o intuito de se alcançar um fim. Atualmente são encontrados vários jogos de cartas com suas próprias regras e cartas personalizadas, porém, este documento trata somente de jogos nas quais são utilizadas as cartas existentes no baralho francês. O baralho francês, assim como o espanhol, é composto por quatro conjuntos de cartas denominados naipes: Paus ( ), Espadas ( ), Copas ( ) e Ouros ( ). Cada naipe é composto por um conjunto de 13 cartas, contendo os valores de 2 a 10 e as cartas: Ás (A ou Ace), Valete (J ou Jack), Dama (Q ou Queen) e Rei (K ou King), que representam os valores 1,11,12 e 13, respectivamente. Em alguns jogos, utiliza-se um par de cartas especiais sem naipe chamados Coringas. Existem, porém, alguns jogos onde há uma sequência diferente de valores e naipes que ainda podem conter variações dependendo da regionalidade dos jogadores, como por exemplo, o jogo de truco, que possui regras diferentes em cada região do Brasil e em outros países onde é jogado. Ainda há regras como as do jogo de canastra que permite o uso do Ás como o décimo quarto valor (após o K), porém se esta carta for utilizada para este fim, não poderá ser utilizada para iniciar uma nova sequência. A origem dos jogos de cartas é desconhecida, mas acredita-se que originou na China

18 17 por volta do século X sendo trazido por árabes para a Europa durante o século XIV (JOGATINA, 2009). Acredita-se que o baralho francês foi inventado por um pintor chamado Jacquemin Gringonneur, sob encomenda do rei Carlos VI de França. Gringonneur elaborou um baralho de forma que cada naipe representasse um grupo social da França: copas para o clero, ouro para a burguesia, espadas para os militares e paus para os camponeses (JOGOS DE CARTAS, 2007). A Figura 1, ilustra alguns jogos populares na atualidade. Fonte: Genkistar (2011). Figura 1- Imagens de uma partida de pôquer (esq.) e uma partida de paciência (dir.) 2.3 ANDROID O Android é uma plataforma de software para dispositivos móveis que inclui um sistema operacional, uma camada intermediária (middleware) e aplicativos chave (ANDROID DEVELOPERS, 2011). A Figura 2 demonstra a estrutura do sistema operacional do Android dividida em grandes componentes.

19 18 Fonte: Android Developers (2011). Figura 2 - Arquitetura da plataforma Android O desenvolvimento de aplicações para Android é feito utilizando a linguagem Java na máquina virtual Dalvik, que se trata de uma máquina virtual otimizada para dispositivos móveis. Esta máquina virtual utiliza um baixo consumo de memória, para que seja possível instanciá-la múltiplas vezes, auxiliando no gerenciamento do sistema operacional através de threads 3. Para controlar o gerenciamento de memória e de threads, esta máquina virtual utiliza o kernel Linux. Cada aplicação utiliza um ID próprio e é executado em uma máquina virtual distinta. Uma ferramenta chamada DX que está inserida junto ao Android SDK trata de comprimir e converter arquivos.class Java em arquivos.dex utilizados pela máquina virtual Dalvik. Todas aplicações do Android devem conter um arquivo chamado AndroidManifest.xml que é responsável por informar ao sistema operacional os componentes utilizados pela aplicação. O manifest também é responsável por fornecer a ordem de prioridade dos componentes, mapear as Application Programming Interface (API) utilizadas pela aplicação, definir a versão do sistema operacional a ser utilizada, recursos de software e hardware que a aplicação irá utilizar e definir parâmetros de comportamento de cada componente (ANDROID DEVELOPERS, 2011). Aplicações desenvolvidas para o Android podem ser distribuídas gratuitamente ou vendidas utilizando o serviço Android Market, mantido pela Google, que permite a 3 Thread é um processo ou tarefa concorrente utilizado em sistemas multitarefas que dependente de um criador.

20 19 divulgação, distribuição e licenciamento dos aplicativos registrados no site (ANDROID DEVELOPERS, 2011). O Android disponibiliza várias classes relacionadas ao hardware dos dispositivos que o comportam, dentre elas está a classe de câmera e sensores de toque, acelerômetro e bússola. Também está disponível classes de entrada USB, mídia, banco de dados, entre outros (ANDROID DEVELOPERS, 2011). A seção 2.4 irá detalhar um pouco mais sobre algumas dessas classes. 2.4 PROGRAMAÇÃO JAVA PARA ANDROID Como anteriormente citado, as aplicações desenvolvidas para a plataforma Android são escritas na linguagem Java. Entretanto, para se desenvolver estes aplicativos, é necessária a utilização do Android SDK, responsável por compilar o código e arquivos do projeto e armazená-los em um único pacote, um arquivo com extensão.apk que será responsável pela instalação da aplicação no dispositivo (ANDROID DEVELOPERS, 2011). Pela preocupação na utilização de recursos nos dispositivos móveis, ao se tratar de desempenho nas aplicações para o Android, no qual pode implicar diretamente no consumo de bateria que a aplicação utilizará, segundo os desenvolvedores do Android, duas regras básicas devem ser seguidas: Não faça trabalho desnecessário e Evite alocar memória se possível (ANDROID DEVELOPERS, 2011). Com base nas regras citadas acima, os desenvolvedores do Android consideram algumas formas de reduzir a utilização de recursos do aplicativo (ANDROID DEVELOPERS, 2011), sendo elas: a) evitar criar objetos desnecessários: variáveis temporárias de curta utilização devem ser evitadas, pois uma menor quantidade de objetos significa chamadas menos frequentes do Garbage Collector, reduzindo assim consideravelmente o consumo de memória; b) preferir o uso de métodos estáticos a virtuais: o uso de métodos estáticos tornamnos de 15% a 20% mais rápidos; c) evitar o uso de getters e setters: a utilização destas funções são bastante difundidas na programação orientada a objetos, porém as chamadas destas funções são de um

21 20 alto custo, muito maiores que as chamadas diretas de suas respectivas variáveis. É aceitável o uso das funções ao utilizar chamadas entre classes. Porém dentro de uma mesma classe, a variável deve ser sempre acessada diretamente, pois além do consumo de memória, o acesso a variáveis diretamente é três vezes mais rápida, ou até 7 vezes em sistemas com Just-In-Time 4 (JIT); d) utilizar static final para constantes: a utilização do parâmetro final facilita o acesso ao valor da constante, pois ao invés de consultar uma tabela de constantes, o valor é diretamente acessado. Esta regra aplica-se somente para tipos primitivos como int e String; e) utilizar o loop For otimizado: aconselha-se o uso de for-each na interação de vetores, pois ele pode tornar o loop até três vezes mais rápido; f) conhecer e usar as bibliotecas: métodos da biblioteca do sistema podem ser melhores que o melhor método produzido pelo JIT para um equivalente escrito manualmente em Java. Os aplicativos desenvolvidos para o Android contêm quatro principais componentes (ANDROID DEVELOPERS, 2011): a) atividades (activities): representa uma tela única de interface com o usuário. Cada atividade é independente das outras e outra aplicação pode chamá-la se a atividade permitir; b) serviços (services): representa um componente sem interface com o usuário que roda ocultamente para executar processos de longa duração ou remotos; c) provedores de conteúdo (content providers): gerenciador de dados da aplicação, controlando seu acesso ao banco de dados e se necessário, alterar dados do usuário; d) receptores de transmissão (broadcast receivers): este componente gerencia as notificações e alertas da aplicação, sendo utilizado para comunicar-se com outros aplicativos quando uma requisição for concluída. Dos quatro componentes citados acima, o mais utilizado é a atividade pelo fato desta ser o componente responsável por exibir uma interface que permita ao usuário interagir. Uma aplicação pode conter apenas uma tela ou múltiplas, contidas em suas respectivas atividades. Cada atividade permite que seja chamada uma nova atividade que é colocada à frente da atual, 4 JIT é um compilador desenvolvido para a máquina virtual Dalvik, disponível a partir do Android 2.2, que analisa o código da aplicação e o converte para uma forma mais eficiente enquanto o aplicativo está rodando (ANDROID DEVELOPERS, 2010).

22 21 sendo armazenado numa pilha de atividades, também conhecido como back-stack, conforme ilustra a Figura 3. Fonte: Android Developers (2011). Figura 3 - Representação da pilha de atividades Cada atividade chamada antes da atual é armazenada na pilha guardando as variáveis disponíveis no momento e quando pressionado o botão back, a atividade atual é destruída e o conteúdo da atividade anterior é recuperado. Ao chamar uma nova atividade, a anterior é parada, eventos de mudança de estado são disparados, como o onpause(), e recomenda-se que ao mudar o estado da atividade os dados utilizados nesta atividade sejam gravados pois não há garantias que o usuário retorne a esta atividade. Sugere-se também que ao parar uma atividade, objetos grandes como conexões de rede ou bancos de dados, devem ser liberados e recuperados no momento que a atividade for restituída (ANDROID DEVELOPERS, 2011). Um conjunto de atividades pode ser agrupado em tarefas, permitindo que esse conjunto possa ser movido para o plano de fundo quando pressionado o botão home sem que as atividades sejam destruídas. Ao mover a tarefa para o plano de fundo, os dados das atividades são armazenados e serão recuperados assim que o usuário retornar à aplicação. Porém, caso o desenvolvedor desejar que as informações da atividade atual sejam preservadas quando o usuário pressionar o botão back, será necessário armazená-las de alguma forma, nas quais os meios mais utilizados são armazenando na classe SharedPreferences, que permite armazenar dados de tipos primitivos como int, String, long entre outros, salvando no banco de dados sqllite, nativo do Android ou armazenando-os em um arquivo (ANDROID DEVELOPERS, 2011). Os serviços são componentes que não necessitam de uma interface com usuário e podem rodar operações de longo prazo em plano de fundo. Um serviço iniciado pela aplicação

23 22 continuará rodando mesmo após a aplicação perder o foco. Este componente costuma ser utilizado para gerenciar conexões, tocar músicas e comunicar com bancos e dados. Cada serviço, como os outros componentes, deve ser declarado no manifest e caso ele necessite utilizar um grande consumo de recursos, ele deverá ser criado em um thread separada para reduzir o risco de travar a aplicação (ANDROID DEVELOPERS, 2011). Os provedores de conteúdo são os componentes responsáveis por efetuar a comunicação entre aplicações, permitindo integrar vários tipos de dados comuns, tais quais arquivos de áudio, vídeo, imagens, dados pessoais entre outros. Há duas formas de utilizar os provedores: criando um nova instância da classe ContentResolver, ou utilizando um provedor já existente desde que este seja de mesmo tipo e haja permissão de escrita (ANDROID DEVELOPERS, 2011). Para se implementar uma Graphic User Interface (GUI) para a aplicação, utiliza-se derivados da classe View e ViewGroup. Cada View é responsável por uma região retangular na atividade e permite que o usuário interaja nesta região. A classe View contém subgrupos chamados widgets, objetos de interface como botões e campos de texto, enquanto o ViewGroup contém as subclasses de layouts, responsáveis por estruturar os componentes na tela (ANDROID DEVELOPERS, 2011). Há quatro tipos principais de layouts: FrameLayout, LinearLayout, TableLayout e RelativeLayout FrameLayout O tipo mais simples de layout. É composto por um elemento que ocupa todo o espaço da tela e pode ser ocupado total ou parcialmente por somente um elemento, como uma imagem por exemplo. O objeto inserido neste layout sempre será fixo no canto superior esquerdo da tela, e novos objetos inseridos neste layout irão sobrepor os objetos anteriores LinearLayout Este layout alinha os componentes associados a ele na direção horizontal ou vertical

24 23 dependendo de qual for o parâmetro definido na propriedade orientation. Cada elemento filho do layout é empilhado abaixo do elemento anterior. Este layout permite também que seus elementos tenham pesos diferenciados, permitindo assim que elementos com maior peso preencham um espaço maior na tela, como pode ser visto na Figura 4. A imagem da esquerda ilustra elementos sem peso definido, que por padrão o valor é zero, enquanto na imagem da direita, o campo de comentários tem um peso igual a 1 dando maior prioridade a ele. Caso o campo de nome também tivesse peso 1, os dois campos teriam o mesmo tamanho. Fonte: Android Developers (2011). Figura 4 - LinearLayout TableLayout Este layout utiliza uma estrutura de tabela, dividido em linhas e colunas. Cada tabela irá possuir a quantidade de colunas igual à linha com o maior número de células dentro dela. Cada linha deste layout é definido pelo objeto TableRow, que pode conter zero ou mais células e cada célula é definida por qualquer componente da classe View. O Quadro 1 demonstra o extensible Model Language (XML) que estrutura uma tabela simples contendo duas linhas e duas colunas, como pode ser visualizado na Figura 5.

25 24 <?xml version="1.0" encoding="utf-8"?> <TableLayout xmlns:android=" android:layout_width="fill_parent" android:layout_height="fill_parent" android:stretchcolumns="1"> <TableRow> <TextView android:padding="3dip" /> <TextView android:gravity="right" android:padding="3dip" /> </TableRow> <TableRow> <TextView android:padding="3dip" /> <TextView android:gravity="right" android:padding="3dip" /> </TableRow> </TableLayout> Fonte: Android Developers (2011). Quadro 1 - Estrutura XML de um TableLayout Fonte: Android Developers (2011). Figura 5 - TableLayout RelativeLayout O RelativeLayout permite que os componentes dispostos nele sejam posicionados em relação ao container ou a algum outro elemento pelo seu id. Caso seja utilizado um arquivo XML para determinar os elementos do layout, deve-se criar o elemento base antes do elemento que irá referenciá-lo. O Quadro 2 exemplifica uma estrutura simples de um layout relativo com quatro componentes básicos, como pode ser visto na Figura 6.

26 25 <?xml version="1.0" encoding="utf-8"?> <RelativeLayout xmlns:android=" android:layout_width="fill_parent" android:layout_height="wrap_content" android:padding="10px" > <TextView android:layout_width="fill_parent" android:layout_height="wrap_content" android:text="type here:" /> <EditText android:layout_width="fill_parent" android:layout_height="wrap_content" /> <Button android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignparentright="true" android:layout_marginleft="10px" android:text="ok" /> <Button android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="cancel" /> </RelativeLayout> Fonte: Android Developers (2011). Quadro 2 Estrutura XML de um RelativeLayout Fonte: Android Developers (2011). Figura 6 RelativeLayout

27 RECURSOS GRÁFICOS NO ANDROID Android Developers (2011), comenta que há três principais recursos gráficos disponíveis na plataforma, sendo eles as bibliotecas gráficas 2D do pacote drawable, as APIs de Open Graphic Library for Embedded Systems (OpenGL ES) e as APIs do RenderScript. Essas bibliotecas devem ser utilizadas com consciência da necessidade que a aplicação irá utilizar, pois cada uma possui características que permitem facilitar o desenvolvimento em determinados casos, conforme comentado a seguir Bibliotecas 2D Há duas formas principais de se desenhar gráficos em 2D, sendo elas a utilização de Views ou desenhando diretamente em um Canvas (ANDROID DEVELOPERS,2011) Views Para o desenvolvimento de gráficos e animações em 2D, existem duas bibliotecas disponíveis no Android para desenhar imagens e formas, sendo elas a android.graphics.drawable e a android.view.animation. Segundo Android Developers (2011), um objeto da classe Drawable é algo que pode ser desenhado. Há três formas de se instanciar um objeto Drawable: utilizando uma imagem existente dentro do projeto, utilizando um arquivo XML para definir as propriedades do objeto ou utilizando construtores da classe. Utilizar imagens salvas dentro do projeto são recomendadas para a utilização em ícones, logos ou outros gráficos como os utilizados em um jogo. As imagens suportadas pela classe Drawable são: Portable Network Graphics (PNG) que é preferível, Joint Photographic Experts Group (JPG) que é considerado aceitável e Graphics Interchange Format (GIF) é desencorajado pela plataforma. Para utilizar uma imagem, ela deve estar inserida na pasta res/drawable/ ou na pasta res/raw/. Caso ela esteja na pasta res/drawable/, na construção do projeto, uma ferramenta chamada Android

28 27 Asset Packaging Tool (AAPT), responsável por criar a classe R.java, que automaticamente efetua a compressão otimizada de imagens sem perda de qualidade, reduzindo assim o consumo de memória ao utilizar esta imagem. Por exemplo, uma imagem PNG que utiliza menos que 256 cores, é convertido para um PNG 8 bits. Porém, caso a imagem deva ser utilizada em seu estado original na forma de bitmap, a imagem deve ser inserida na pasta res/raw/. O Quadro 3 demonstra um exemplo de implementação de uma imagem chamada card_background_blue.png existente dentro da pasta drawable/nodpi/ no projeto (ANDROID DEVELOPERS, 2011). Resources res = getcontext().getresources(); Drawable img = res.getdrawable(r.drawable.card_background_blue); Quadro 3 - Exemplo de inserção de recursos Canvas Segundo Android Developers (2011), desenhar utilizando o Canvas é melhor em casos onde é necessário que a tela seja redesenhada regularmente. O Canvas atua como um intermediador armazenando as chamadas de desenho do aplicativo e convertendo-os em um Bitmap que será inserido na tela. É possível criar um novo Canvas passando como parâmetro um Bitmap que define a área de desenho, porém recomenda-se que seja utilizado o Canvas disponível pela função View.onDraw() ou SurfaceHolder.lockCanvas(). A classe disponibiliza várias funções de desenho como o drawrect() e o drawbitmap(), permitindo também utilizar recursos da classe Drawable OpenGL ES A biblioteca OpenGL para a plataforma Android disponibiliza gráficos de alta performance tanto para 2D como 3D utilizando a API OpenGL ES. No Android, há duas classes fundamentais que permitem a criação e manipulação de gráficos pelo OpenGL ES.

29 GLSurfaceView Esta classe derivada da classe View, é muito semelhante à classe SurfaceView, que é uma View que permite ser alterado seu formato e tamanho utilizando ordenação por profundidade para organizar seus objetos. Esta classe é responsável por gerenciar superfícies que são componentes especiais na visualização no Android, renderização utilizando threads dedicadas para melhorar o desempenho e suporta renderização sob demanda ou contínuo. Toda GLSurfaceView necessita de um Renderer, que é registrado pela função setrenderer(renderer). Após definido o Renderer, é possível alterar seu modo padrão de renderização contínua para sob demanda Renderer A interface genérica Renderer deriva do pacote GLSurfaceView e é responsável por fazer o OpenGL desenhar os quadros na tela. Cada Renderer gera uma nova thread, para que o desempenho da aplicação não seja prejudicada. 2.6 RESOURCES E XMLS Os aplicativos do Android têm forte vínculo com arquivos XML, desde o mapeamento dos componentes do sistema até os layouts e atributos das classes. A partir do arquivo AndroidManifest.xml (Quadro 4), ao compilar o projeto são mapeados os recursos e propriedades utilizados pelo aplicativo que deseja-se aplicar a todas as atividades ou a um algumas em específico. Ao criar um novo projeto Android no Eclipse, é criada uma pasta chamada res que possui por padrão as pastas drawable, layout e values. Os arquivos inseridos dentro da pasta res devem utilizar somente letras minúsculas, números e sublinhado, sendo que o primeiro caractere deve ser uma letra.

30 AndroidManifest.xml <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="(...)/apk/res/android" package="engine.view"> <uses-sdk android:targetsdkversion="10" android:minsdkversion="10" /> <application android:debuggable="true" android:label="card Engine" <activity android:name="home"> <intent-filter> <action android:name="android.intent.action.main" /> <category android:name="android.intent.category.launcher"/> </intent-filter> </activity> <activity android:name="gamedisplay" android:screenorientation="landscape" /> <activity android:name="option" /> <activity android:name="scoreboard" /> <activity android:name="gamerules" /> </application> </manifest> Quadro 4 AndroidManifest.xml No Manifest descrito no quadro acima, dentro do nó raiz <manifest> é necessário utilizar o atributo package, pois este define o caminho onde a classe R se localiza. Em geral a maioria das propriedades que se dizem respeito ao às configurações do aplicativo iniciam-se com o prefixo android:. Dentro do nó raiz, o primeiro nó <uses-sdk> define a versão alvo do aplicativo. O valor 10 dentro desses parâmetros se refere à versão do Android. O segundo nó detalha as informações necessárias para a aplicação em si, onde o primeiro parâmetro android:icon se refere ao caminho do ícone que será exibido no dispositivo. O parâmetro android:debuggable com valor true permite que o desenvolvedor possa utilizar o modo debug da ferramenta no aplicativo. O parâmetro android:label define o título do aplicativo que o usuário verá no dispositivo e na barra de título caso esta esteja disponível. O valor Theme.NoTitleBar.Fullscreen do ultimo parâmetro define que em todos os momentos dessa aplicação não haverá nem a barra de título do aplicativo nem a barra de status do sistema. Dentro do segundo nó estão contidos os nodos que definem as atividades (telas) que compõem a aplicação. Cada atividade deve conter o nome da classe estendida de Activity que será utilizada na aplicação, caso contrário, ao instanciar esta classe, será disparado um erro de atividade não encontrada.

31 30 O nó Home possui um sub-nó <intent-filter> onde é definido que esta atividade inicia a aplicação. No nó GameDisplay, a propriedade android:screenorientation, força que esta atividade seja somente exibida em modo paisagem. Contudo, pode ser definido também para somente modo retrato (portrait) e por padrão o sistema adapta os elementos da tela em relação a orientação do dispositivo res.layout A pasta layout contém as estruturas das atividades que são utilizadas no projeto, podendo cada XML utilizar tanto Views pré-definidas pelo ambiente, como botões, campos de texto e rótulo, como mapear novas Views personalizadas que serão criadas pelo desenvolvedor. Ao definir o layout de uma atividade, todas as Views inseridas dentro do XML devem conter os atributos android:layout_height e android:layout_width que podem receber os valores wrap_content, match_parent e fill_parent ou valores numéricos fixos nos seguintes formatos de medidas: px (pixels), dp (pixels independentes de densidade), sp (pixels escalados, baseados no tamanho preferencial de fonte), in (polegadas) e mm (milímetros) (ANDROID DEVELOPERS, 2011). O valor fill_parent a partir da versão 8 da API do Android foi depreciado em favor do valor match_parent e ambos tem a função de dimensionar a View de forma a preencher todo o espaço ocupado pela View que a contém, ou preencher toda a tela caso esta seja a View raiz. No Quadro 5 é possível visualizar o layout da tela de regras da atividade GameRules descrito no arquivo gamerules.xml.

32 31 <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android=" android:layout_width="match_parent" android:layout_height="match_parent" <ScrollView android:padding="15px" android:layout_width="match_parent" android:layout_height="wrap_content" android:fillviewport="true"> <RelativeLayout android:padding="10px" android:layout_width="match_parent" android:layout_height="wrap_content"> <TextView android:layout_width="match_parent" android:layout_height="wrap_content" /> <Button android:layout_centerhorizontal="true" android:layout_margin="15px" android:layout_width="wrap_content" android:layout_height="wrap_content" /> </RelativeLayout> </ScrollView> </LinearLayout> Quadro 5 res/layout/gamevalues.xml Cada View pode possuir uma imagem ou cor de fundo sendo o arquivo buscado através do ou utilizando os valores hexadecimais Alpha, Red, Green, Blue (ARGB). As Views também podem possuir um id que é utilizado posteriormente para ser referenciado por outros elementos ou funções. A sintaxe para a definição de um id onde nome_var deve ser um id único no pacote. Para acessar o id criado anteriormente, como pode ser visto nas propriedades da View Button do quadro acima res.drawable Por padrão, ao criar um novo projeto Android no Eclipse, são gerados três pastas dentro da pasta res: drawable-hdpi, drawable-mdpi e drawable-ldpi. Estas três pastas são geradas a fim de armazenar os componentes gráficos e exibi-los para o usuário dependendo da resolução disponível no dispositivo, porém caso não se deseje trabalhar desta

33 32 forma, existe a opção de armazenar arquivos numa única pasta chamada drawable-nodpi onde para todas as resoluções, será utilizada a mesma proporção para as imagens. Além das proporções citadas antes, também estão disponíveis os valores xhdpi e tvdpi (ANDROID DEVELOPERS, 2011) res.values A pasta values criada por padrão na geração do projeto contém o arquivo strings.xml que por padrão armazena os valores literais que são utilizados na aplicação. O Quadro 6 ilustra o conjunto de strings que são utilizadas na aplicação. Estas strings podem ser acessadas a qualquer R.string.string_name. momento pelo desenvolvedor utilizando a referência <?xml version="1.0" encoding="utf-8"?> <resources> <string name="showrules">rules</string> <string name="showscore">scoreboard</string> <string name="exitgame">quit Game</string> <string name="colorchooser">select a color:</string> <string-array name="colors"> <item>black</item> <item>blue</item> <item>red</item> <item>green</item> <item>yellow</item> <item>silver</item> </string-array> <string name="poker_rules">( )</string> </resources> Quadro 6 res/values/strings.xml Dentro desta pasta também é permitido criar outros arquivos de propriedades como o attrs.xml descrito no Quadro 7 que possui as propriedades do protótipo de pôquer.

34 33 <?xml version="1.0" encoding="utf-8"?> <resources> <!-- deck type 0 = default, type 1 = spanish style --> <item type="pokervars" format="integer" name="deck_type">0</item> <item type="pokervars" format="integer" name="player_money">50</item> <item type="pokervars" format="integer" name="hand_limit">5</item> <item type="pokervars" format="integer" name="initialbet">5</item> <item type="pokervars" format="boolean" name="bet">true</item> <item type="pokervars" format="boolean" name="joker">false</item> <item type="pokervars" format="boolean" name="auto_draw">true</item> <item type="pokervars" format="boolean" name="upcard">false</item> <!-- Multiplayer setup --> <item type="pokervars" format="integer" name="min_players">2</item> <item type="pokervars" format="integer" name="max_players">4</item> <item type="pokervars" format="boolean" name="discard">false</item> <!-- Allows to shuffle the discard pile back to the deck --> <item type="pokervars" format="boolean" name="restart_on_end">false</item> </resources> Quadro 7 res/values/attrs.xml Os itens do quadro anterior possuem uma variável type que permite que o desenvolvedor insira um tipo qualquer, nativo ou mesmo inexistente, que auxilia ao mesmo que encontre com maior facilidade para acessar as variáveis desejadas. Definir tipos diferentes permite inserir outros nós com o mesmo nome, como pode ser visto no Quadro 8. <item type="pokervars" format="boolean" name="joker">false</item> <item type="canastravars" format="boolean" name="joker">true</item> Quadro 8 Múltipla tipagem de constantes Para o desenvolvedor acessar esta variável, deve-se buscar o tipo definido no parâmetro format através dos Resources da aplicação passando como parâmetro o caminho através da classe R (Quadro 9). Resources res = getresources(); this.joker = res.getboolean(r.pokervars.joker); Quadro 9 Acessando constantes tipadas Personalizando menus do sistema Para criar um menu de opções do Android são necessários três procedimentos: elaborar um layout, sobrescrever a função oncreateoptionsmenu() e atribuir as ações quando um dos botões for selecionado utilizando a função onoptionsitemselected().

35 34 O menu foi gerado a partir do arquivo res/menu/game_menu.xml (Quadro 10) onde cada item possui um id para permitir mapear seu evento posteriormente, o ícone que deve ser exibido na tela e o nome do botão para auxiliar o usuário a entender a utilidade dele. <?xml version="1.0" encoding="utf-8"?> <menu xmlns:android=" <item android:id="@+id/showrules" android:icon="@drawable/icocards" android:title="@string/showrules" /> <item android:id="@+id/showscore" android:icon="@drawable/icocoins" android:title="@string/showscore" /> <item android:id="@+id/exitgame" android:icon="@drawable/icoexit" android:title="@string/exitgame" /> </menu> Quadro 10 res/menu/game_menu.xml Após elaborado o layout, a View deve sobre-escrever as funções citadas anteriormente (Quadro 11). Quando um item do menu é pressionado, a função onoptionsitemselected() é chamada recebendo como parâmetro o item selecionado permitindo assim efetuar o tratamento do clique a partir do id definido no XML pela função public boolean oncreateoptionsmenu(menu menu){ MenuInflater inflater = getmenuinflater(); inflater.inflate(r.menu.game_menu, menu); return public boolean onoptionsitemselected(menuitem item) { // Handle item selection switch (item.getitemid()) { case R.id.showRules: showrules(); return true; case R.id.showScore: showscore(); return true; case R.id.exitGame: exitgame(); return true; default: return super.onoptionsitemselected(item); Quadro 11 Instância de menus e tratamento dos botões

36 TRABALHOS CORRELATOS Nesta seção são descritos quatro trabalhos correlatos relacionados ao desenvolvimento de motores de jogos para Android, quais sejam: Motor de Jogos 3D para o iphone OS (MJ3I) apresentado por Takano (2009), Mobile 3D Game Engine (M3GE), desenvolvido por Pamplona (2005), Blender Game Engine, disponibilizado pela Blender Foundation (VELDHUIZEN, 2010a) e a Havok, criado pela empresa de mesmo nome (HAVOK INC, 2011a) MJ3I Este projeto desenvolvido por Takano (2009) teve como foco o desenvolvimento de um motor de jogos para o iphone com foco na construção de um ambiente 3D utilizando o OpenGL ES (Figura 7), gerenciamento de grafos de cena, importação de arquivos 3D e tratamento de colisões para abstrair a implementação de rotinas básicas necessárias para um jogo em 3D. A linguagem de programação utilizada no projeto foi o Objective-C no ambiente de desenvolvimento xcode. Fonte: Takano ( 2009). Figura 7 Exemplo de aplicação do MJ3I

37 M3GE Pamplona (2005) descreve o protótipo de um motor de jogos 3D para dispositivos móveis utilizando um algoritmo leitor de arquivos de modelo 3D e montagem visual do cenário ao jogador, implementação de câmeras de visualização e movimentação do personagem do cenário. Para o desenvolvimento do projeto foi utilizada a plataforma Java 2 Micro Edition (J2ME), uma das extensões do Java para sistemas embarcados, com o intuito de além de criar uma ferramenta de desenvolvimento para jogos, testar a portabilidade e velocidade de processamento onde o jogo gerado seria instalado Blender Game Engine (BGE) O BGE, desenvolvido pela Blender Foundation, é uma ferramenta gratuita open source, escrita na linguagem C++. Parte da ferramenta gráfica Blender sob a licença da GNU GPL 5, este motor contém ferramentas de produção gráfica em 2 e 3D, manipulação de grafos de cena, entre outros recursos e permite a utilização da linguagem Python para a geração de scripts (VELDHUIZEN, 2010a). Segundo Veldhuizen (2010a), o BGE utiliza um plugin de um motor de física para jogos 3D chamado Bullet para gerenciar a detecção de colisão, a dinâmica de corpos rígidos e maleáveis de objetos 3D criados na ferramenta. Este motor, também utiliza a biblioteca Open Audio Library (OpenAL) para gerenciar os efeitos sonoros do ambiente. A Figura 8 ilustra a interface do BGE. 5 GNU General Public Licence (GNU GPL), criada em 1989, foi a primeira licença para softwares livres e atualmente a mais utilizada pelos desenvolvedores de softwares de código aberto.

38 37 Fonte: Veldhuizen (2010b). Figura 8 - Interface do BGE Havok Este motor proprietário é considerado pela sua utilização multiplataforma em títulos de sucesso como Soul Callibur IV (PlayStation 3, Xbox 360), Spore (Personal Computer - PC) e StarCraft II (PC) entre outros (HAVOK INC, 2011a). O motor é composto por sete módulos de ferramentas (HAVOK INC, 2011b), sendo eles a Havok Artificial Intelligence (AI), Animation, Behavior, Cloth, Destruction, Physics e Script, sendo o Havok Animation e o Physics os mais utilizados pelos jogos. Cada módulo foi projetado para atender a uma necessidade específica de um jogo 3D, abstraindo cálculos complexos necessários para seu desenvolvimento. A Figura 9 ilustra uma das ferramentas da empresa, o Havok Physics.

39 38 Fonte: Havok Inc (2011c). Figura 9 - Interface do Havok Physics Embora esta ferramenta seja paga, ela também é distribuída gratuitamente com os módulos Physics e Animation em parceria com a Intel, para desenvolvedores Windows sem fins comerciais.

40 39 3 DESENVOLVIMENTO Neste capítulo são abordadas as etapas de desenvolvimento do trabalho. São ilustrados os requisitos, a especificação, implementação e por fim são listados resultados e discussão. 3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO O motor para o desenvolvimento de jogos para Android deve: a) permitir alterar regras de jogo durante a implementação de cada jogo (Requisito Funcional - RF); b) permitir alterar a velocidade dos movimentos das cartas na cena (RF); c) permitir configurar a pontuação do jogo (RF); d) permitir definir o conjunto de cartas a ser utilizado no protótipo de jogo (RF); e) permitir definir a ordem das cartas do protótipo (RF); f) permitir definir o modo de distribuição inicial e durante a partida (RF); g) permitir a movimentação e manipulação das cartas pelo jogador (RF); h) utilizar a linguagem de programação Java para Android (Requisito Não-Funcional RNF); i) utilizar o ambiente Eclipse Integrated Development Environment (IDE) como ambiente de desenvolvimento (RNF); j) utilizar um dispositivo Android e o Android SDK como ambiente de testes (RNF). O protótipo de jogo de pôquer deve: a) permitir ao jogador iniciar ou continuar uma partida (RF); b) permitir ao jogador visualizar sua pontuação e de seus adversários (RF); c) permitir reorganizar as cartas de sua mão (RF); d) permitir ao jogador modificar o verso das cartas (RNF).

41 ESPECIFICAÇÃO A especificação deste trabalho foi elaborada utilizando a ferramenta Enterprise Architect, utilizando conceitos de orientação a objetos baseando nos diagramas da Unified Modeling Language (UML), produzindo os diagramas utilizados nas próximas seções Casos de uso Nesta seção são descritos os casos de uso deste projeto. Um ator foi identificado: o Usuário, que irá interagir com o jogo resultante do projeto. A Figura 10 ilustra o diagrama de casos de uso deste ator. uc Use Case Model UC01 - iniciar a partida UC06 - Modificar o v alor da aposta UC02 - Alterar as configurações do jogo UC05 - Mov er cartas da mão Usuário UC03 - Selecionar opções do jogo UC04 - Distribuir as cartas Figura 10 Diagrama de casos de uso O detalhamento de cada caso de uso do diagrama encontra-se nos anexos A até F Diagramas de classe Nesta seção são apresentadas as classes que compõem a estrutura do motor e as classes do protótipo, seus relacionamentos e propriedades. Para facilitar o entendimento da estrutura,

42 41 foi adotado o modelo de padrões de projetos chamado Model-View-Controller (MVC) para dividir cada grupo de classes baseado em suas funções. A Figura 11 representa a estrutura do motor de jogos o pacote GameMode está contido no pacote Control, pois as classes derivadas da classe Game determinam as rotinas de gerenciamento do jogo. class Simple Model engine.model Card Player Constants engine.view GameView GameDisplay Home GameRules Option ScoreBoard engine.control engine.gamemode FPS Deck Game Poker Figura 11 Diagrama de classes do motor de jogos Pacote engine.model O pacote engine.model constitui as classes de base do projeto ilustradas na Figura 12. Neste pacote estão incluídas as classes Card, Player e Constants que são utilizadas na maioria das classes dos outros pacotes do projeto.

43 42 class Class Model engine.model Card + angle: float + tox: float + id: int + suit: int + value: int + visible: boolean + toy: float + x: float + y: float - toangle: float + Card(int, int) : void + getimage() : String + getsuit() : String + getvalue() : String Player + hand: ArrayList<Card> + name: String + points: int + tierbreaker: ArrayList<Card> + coins: int + betstatus: int + Player(String) : void + sorthand() : void Constants + BGNONE: int = R.drawable.card_none {readonly + BOARDMARGIN: int = 20 {readonly + CARDMOVE: int = 5 {readonly + DEFAULT_SEQUENCE: int = 0 {readonly + DRAWTIME: int = 900 {readonly + SPANISH_DECK: int = 1 {readonly + CARD_HEIGHT: int = 113 {readonly + CARD_WIDTH: int = 78 {readonly + PREF_FILE: String = PreferencesFile {readonly - TOP_LEFT: int = 0 {readonly - TOP: int = 1 {readonly - TOP_RIGHT: int = 2 {readonly - LEFT: int = 3 {readonly - CENTER: int = 4 {readonly - RIGHT: int = 5 {readonly - BOTTOM_LEFT: int = 6 {readonly - BOTTOM: int = 7 {readonly - BOTTOM_RIGHT: int = 8 {readonly Figura 12 Pacote engine.model A classe Card contém os atributos básicos de uma carta, seu valor e naipe, posição x e y, margem e ângulo. O construtor da classe recebe como parâmetro o valor da carta e naipe, que depois quando chamadas as funções getsuit e getvalue retornam a versão literal destes valores para se obter o nome do arquivo de imagem correto a ser retornado pela função getimage. A classe possui também o atributo visible que define se será exibido a frente ou o verso da carta e as variáveis de movimentação tox, toy e toangle. Card é utilizada na classe Player para compor as cartas da mão do jogador e armazenar as cartas para desempate (tierbreaker). Na classe Deck, ela é utilizada para a composição das cartas do baralho que são distribuídas para os jogadores e disponibilizadas na mesa caso necessário. As classes Game e GameView também utilizam esta classe e serão abortados mais a diante. A classe Player contém em seus atributos o nome do jogador, seus pontos da rodada, dinheiro da partida e status da aposta na rodada, além de uma lista de cartas que possui na mão e uma lista adicional para auxiliar no critério de desempate. Esta classe é utilizada na classe Game e GameView para o gerenciamento do número de jogadores dentro do jogo, sua manipulação e gerenciamento de suas cartas. A classe estática Constants armazena valores e propriedades relacionadas ao desenho da tela e utilizadas na maioria das classes do projeto, sendo mais utilizadas as variáveis de posicionamento dos elementos, como TOP_LEFT, TOP_RIGHT e BOTTOM, definição do tamanho da imagem das cartas e o espaço das margens da tela.

44 Pacote View O pacote engine.view (Figura 13 e Figura 14) é responsável pelo gerenciamento de layouts do sistema sendo cada classe, excluindo a classe GameView, responsável por uma tela do programa. class Class Model GameView - mpaint: Paint - card: Bitmap - fps: FPS - game: Game - time: long + roundbet: int + drawmode: int + card_bg: int - GAME_MODE: int = 0 {readonly - BET_MODE: int = 1 {readonly - status: String - currentbet: String - betview: RelativeLayout - bettext: TextView + setgame(game) : void - initdrawview() : void + savestate() : Bundle + restorestate(bundle) : void + ondraw(canvas) : void + ontouch(view, MotionEvent) : void + update() : void + onsizechanged(int, int, int, int) : void GameDisplay - gameview: GameView - settings: SharedPreferences - game: Game - rulesintent: Intent - scoreintent: Intent - requestcode: int + raise: Button + fold: Button + call: Button + back: Button + coin5: Button + coin10: Button + coin25: Button + coin50: Button + coin100: Button + oncreate(bundle) : void + showrules() : void + exitgame() : void + oncreateoptionsmenu(menu) : void + onoptionsitemselected(menuitem) : void + onpause() : void + showscore() : void + onbackpressed() : void + onactivityresult(int, int, Intent) : void Figura 13 Pacote engine.view class Class Model ScoreBoard + onbackpressed() : void + oncreate(bundle) : void Home - gameintent: Intent - optionsintent: Intent - settings: SharedPreferences - gamename: String + oncreate(bundle) : void + startgame(string, boolean, int) : void GameRules + oncreate(bundle) : void + onbackpressed() : void Option - settings: SharedPreferences - spinner: Spinner - playername: EditText + oncreate(bundle) : void + onsaveinstancestate(bundle) : void Figura 14 - Pacote engine.view (cont.)

45 44 A classe Home é responsável por exibir os menus iniciais do aplicativo como pode ser visto nas figuras 15, 16 e 17. Home, assim como as outras classes que estendem da classe Activity no projeto, possui uma View e utiliza um XML para definir seu layout, editado parcialmente no Quadro 12 a partir do arquivo main.xml para corresponder à figura 15, que descreve a estrutura de componentes e propriedades da tela. Figura 15 Tela principal Figura 16 Tela de seleção de jogo Figura 17 Tela de seleção de jogadores <?xml version="1.0" encoding="utf-8"?> <RelativeLayout xmlns:android=" android:layout_width="match_parent" android:layout_height="match_parent" android:background="@drawable/bghome"> <Button android:id="@+id/buttonstart" android:background="@drawable/btnewgame" android:layout_centerhorizontal="true" android:layout_margintop="50px" android:layout_width="wrap_content" android:layout_height="wrap_content"/> (...) <Button android:id="@+id/buttonquit" android:background="@drawable/btquit" android:layout_below="@id/buttonoptions" android:layout_centerhorizontal="true" android:layout_margintop="50px" android:layout_width="wrap_content" android:layout_height="wrap_content"/> </RelativeLayout> Quadro 12 XML parcial da tela de entrada A partir da tela inicial, o jogador tem a opção de acessar as configurações do aplicativo pelo botão de opções do menu, criando uma instância da classe Option que abre uma nova View utilizando o layout definido em options.xml. Por outro lado, o jogador pode

46 45 optar por iniciar uma nova partida selecionando o jogo desejado e o número de adversários ou continuando uma partida já existente, criando assim uma nova instância de GameDisplay. A classe GameDisplay utiliza o arquivo game.xml para definir seu layout e, diferentemente das Views citadas anteriormente, possui uma View personalizada chamada GameView. GameView é a principal responsável por desenhar e interagir com o usuário durante o jogo através dos métodos ondraw e ontouch estendidos das classes View e ontouchlistener respectivamente. As classes GameRules e ScoreBoard estão disponíveis durante a execução do jogo. Ao abrir o menu (Figura 18) e o jogador selecionar o botão de regras ou de pontuação. Os arquivos de layout relacionados a esses dois arquivos são o gamerules.xml e scoreboard.xml respectivamente. Figura 18 Menu de exibição Pacote engine.control O pacote engine.control está dividido em dois grupos, o primeiro composto pelas classes FPS e Deck (Figura 19), e a segunda composta pelas classes contidas no pacote engine.gamemode (Figura 20). Figura 19 engine.control

47 46 A classe FPS é responsável pela visualização da taxa de quadros por segundo que a aplicação está executando. Ela é criada e manipulada pela classe engine.view.gameview. A classe Deck é a responsável por gerenciar todas as cartas que estão no baralho, mesa, pilha de descartes ou em movimento no jogo, além de ser responsável por produzir o conjunto de cartas do baralho e efetuar o embaralhamento das cartas Pacote engine.gamemode Este pacote faz parte do pacote engine.control no diagrama de classes por compartilharem a função de controle e gerenciamento da aplicação, porém dentro do projeto estão separados para fins de organização. Neste pacote (Figura 20) estão as classes Game, e Poker que herda as propriedades de Game. A classe Game é a principal gerenciadora da manipulação das cartas em função das propriedades do jogo além de efetuar um tratamento específico dos eventos de toque da aplicação, é a partir desta classe que o desenvolvedor deverá se focar em modificar, pois nela que as variáveis de jogo são definidas e manipuladas. A classe Poker herda as propriedades de Game, permitindo personalizar as propriedades do jogo. Alguns métodos de Game necessitam ser sobrepostos, como o setvalues() que a partir dos valores definidos para o jogo no arquivo attrs.xml, define as configurações de uso de curingas, quantidade de cartas na mão do jogador ou o uso da pilha de descartes por exemplo.

48 Figura 20 Pacote engine.gamemode 47