PROPOSTA PARA O TRABALHO DE CONCLUSÃO DE CURSO IMPLEMENTAÇÃO DE UM MOTOR DE JOGOS DE CARTA PARA A PLATAFORMA ANDROID

Transcrição

1 TURNO: NOTURNO VERSÃO: 1 ANO / SEMESTRE: N o UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS DEPARTAMENTO DE SISTEMAS E COMPUTAÇÃO CURSO DE CIÊNCIA DA COMPUTAÇÃO BACHARELADO COORDENAÇÃO DE TRABALHO DE CONCLUSÃO DE CURSO PROPOSTA PARA O TRABALHO DE CONCLUSÃO DE CURSO TÍTULO: IMPLEMENTAÇÃO DE UM MOTOR DE JOGOS DE CARTA PARA A PLATAFORMA ANDROID ÁREA: Aplicativos Mobile Palavras-chave: Android. Jogos. Motor de jogos. 1 IDENTIFICAÇÃO 1.1 ALUNO Nome: Massami Welington Kamigashima Código/matrícula: Endereço residencial: Rua: Frei Gabriel Zimmer n : 508 Complemento: Bairro:Vila Nova CEP: Cidade: Blumenau UF: Telefone fixo: (047) Celular: (047) Endereço comercial: Empresa: Dataprisma Serviços Ltda. Rua: Engenheiro Paul Werner n : 1138 Bairro: Itoupava Seca CEP: Cidade: Blumenau UF: SC Telefone: (047) FURB: mkamigashima@furb.br alternativo: massamik@gmail.com 1.2 ORIENTADOR Nome: Paulo César Rodacki Gomes FURB: rodacki@inf.furb.br alternativo: rodacki@gmail.com

2 2 DECLARAÇÕES 2.1 DECLARAÇÃO DO ALUNO Declaro que estou ciente do Regulamento do Trabalho de Conclusão de Curso de Ciência da Computação e que a proposta em anexo, a qual concordo, foi por mim rubricada em todas as páginas. Ainda me comprometo pela obtenção de quaisquer recursos necessários para o desenvolvimento do trabalho, caso esses recursos não sejam disponibilizados pela Universidade Regional de Blumenau (FURB). Assinatura: Local/data: 2.2 DECLARAÇÃO DO ORIENTADOR Declaro que estou ciente do Regulamento do Trabalho de Conclusão do Curso de Ciência da Computação e que a proposta em anexo, a qual concordo, foi por mim rubricada em todas as páginas. Ainda me comprometo a orientar o aluno da melhor forma possível de acordo com o plano de trabalho explícito nessa proposta. Assinatura: Local/data:

3 3 AVALIAÇÃO DA PROPOSTA 3.1 AVALIAÇÃO DO(A) ORIENTADOR(A) Acadêmico(a): Orientador(a): Massami Welington Kamigashima Paulo César Rodacki Gomes ASPECTOS TÉCNICOS ASPECTOS METODOLÓGICOS ASPECTOS AVALIADOS 1. INTRODUÇÃO 1.1. O tema de pesquisa está devidamente contextualizado/delimitado? 1.2. O problema está claramente formulado? 2. OBJETIVOS 2.1. O objetivo geral está claramente definido e é passível de ser alcançado? 2.2. São apresentados objetivos específicos (opcionais) coerentes com o objetivo geral? Caso não sejam apresentados objetivos específicos, deixe esse item em branco. 3. RELEVÂNCIA 3.1. A proposta apresenta um grau de relevância em computação que justifique o desenvolvimento do TCC? 4. METODOLOGIA 4.1. Foram relacionadas todas as etapas necessárias para o desenvolvimento do TCC? 4.2. Os métodos e recursos estão devidamente descritos e são compatíveis com a metodologia proposta? 4.3. A proposta apresenta um cronograma físico (período de realização das etapas) de maneira a permitir a execução do TCC no prazo disponível? 5. REVISÃO BIBLIOGRÁFICA 5.1. As informações apresentadas são suficientes e têm relação com o tema do TCC? 5.2. São apresentados trabalhos correlatos, bem como comentadas as principais características dos mesmos? 6. REQUISITOS DO SISTEMA A SER DESENVOLVIDO 6.1. Os requisitos funcionais e não funcionais do sistema a ser desenvolvido foram claramente descritos? 7. CONSIDERAÇÕES FINAIS 7.1. As considerações finais relacionam os assuntos apresentados na revisão bibliográfica com a realização do TCC? 8. REFERÊNCIAS BIBLIOGRÁFICAS 8.1. As referências bibliográficas obedecem às normas da ABNT? 8.2. As referências bibliográficas contemplam adequadamente os assuntos abordados na proposta (são usadas obras atualizadas e/ou as mais importantes da área)? 9. CITAÇÕES 9.1. As citações obedecem às normas da ABNT? 9.2. As informações retiradas de outros autores estão devidamente citadas? 10. AVALIAÇÃO GERAL (organização e apresentação gráfica, linguagem usada) O texto obedece ao formato estabelecido? A exposição do assunto é ordenada (as idéias estão bem encadeadas e a linguagem utilizada é clara)? atende atende parcialmente A proposta de TCC deverá ser revisada, isto é, necessita de complementação, se: qualquer um dos itens tiver resposta NÃO ATENDE; pelo menos 4 (quatro) itens dos ASPECTOS TÉCNICOS tiverem resposta ATENDE PARCIALMENTE; ou pelo menos 4 (quatro) itens dos ASPECTOS METODOLÓGICOS tiverem resposta ATENDE PARCIALMENTE. PARECER: ( ) APROVADA ( ) NECESSITA DE COMPLEMENTAÇÃO não atende Assinatura do(a) avaliador(a): Local/data:

4 CONSIDERAÇÕES DO(A) ORIENTADOR(A): Caso o(a) orientador(a) tenha assinalado em sua avaliação algum item como atende parcialmente, devem ser relatos os problemas/melhorias a serem efetuadas. Na segunda versão, caso as alterações sugeridas pelos avaliadores não sejam efetuadas, deve-se incluir uma justificativa. Assinatura do(a) avaliador(a): Local/data:

5 3.2 AVALIAÇÃO DO(A) COORDENADOR DE TCC Acadêmico(a): Avaliador(a): Massami Welington Kamigashima José Roque Voltolini da Silva ASPECTOS TÉCNICOS ASPECTOS METODOLÓGICOS ASPECTOS AVALIADOS 1. INTRODUÇÃO 1.1. O tema de pesquisa está devidamente contextualizado/delimitado? 1.2. O problema está claramente formulado? 2. OBJETIVOS 2.1. O objetivo geral está claramente definido e é passível de ser alcançado? 2.2. São apresentados objetivos específicos (opcionais) coerentes com o objetivo geral? Caso não sejam apresentados objetivos específicos, deixe esse item em branco. 3. RELEVÂNCIA 3.1. A proposta apresenta um grau de relevância em computação que justifique o desenvolvimento do TCC? 4. METODOLOGIA 4.1. Foram relacionadas todas as etapas necessárias para o desenvolvimento do TCC? 4.2. Os métodos e recursos estão devidamente descritos e são compatíveis com a metodologia proposta? 4.3. A proposta apresenta um cronograma físico (período de realização das etapas) de maneira a permitir a execução do TCC no prazo disponível? 5. REVISÃO BIBLIOGRÁFICA 5.1. As informações apresentadas são suficientes e têm relação com o tema do TCC? 5.2. São apresentados trabalhos correlatos, bem como comentadas as principais características dos mesmos? 6. REQUISITOS DO SISTEMA A SER DESENVOLVIDO 6.1. Os requisitos funcionais e não funcionais do sistema a ser desenvolvido foram claramente descritos? 7. CONSIDERAÇÕES FINAIS 7.1. As considerações finais relacionam os assuntos apresentados na revisão bibliográfica com a realização do TCC? 8. REFERÊNCIAS BIBLIOGRÁFICAS 8.1. As referências bibliográficas obedecem às normas da ABNT? 8.2. As referências bibliográficas contemplam adequadamente os assuntos abordados na proposta (são usadas obras atualizadas e/ou as mais importantes da área)? 9. CITAÇÕES 9.1. As citações obedecem às normas da ABNT? 9.2. As informações retiradas de outros autores estão devidamente citadas? 10. AVALIAÇÃO GERAL (organização e apresentação gráfica, linguagem usada) O texto obedece ao formato estabelecido? A exposição do assunto é ordenada (as idéias estão bem encadeadas e a linguagem utilizada é clara)? atende atende parcialmente A proposta de TCC deverá ser revisada, isto é, necessita de complementação, se: qualquer um dos itens tiver resposta NÃO ATENDE; pelo menos 4 (quatro) itens dos ASPECTOS TÉCNICOS tiverem resposta ATENDE PARCIALMENTE; ou pelo menos 4 (quatro) itens dos ASPECTOS METODOLÓGICOS tiverem resposta ATENDE PARCIALMENTE. PARECER: ( ) APROVADA ( ) NECESSITA DE COMPLEMENTAÇÃO OBSERVAÇÕES: não atende Assinatura do(a) avaliador(a): Local/data:

6 3.3 AVALIAÇÃO DO(A) PROFESSOR(A) DA DISCIPLINA DE TCCI Acadêmico(a): Avaliador(a): Massami Welington Kamigashima Joyce Martins ASPECTOS TÉCNICOS ASPECTOS METODOLÓGICOS ASPECTOS AVALIADOS 1. INTRODUÇÃO 1.1. O tema de pesquisa está devidamente contextualizado/delimitado? 1.2. O problema está claramente formulado? 2. OBJETIVOS 2.1. O objetivo geral está claramente definido e é passível de ser alcançado? 2.2. São apresentados objetivos específicos (opcionais) coerentes com o objetivo geral? Caso não sejam apresentados objetivos específicos, deixe esse item em branco. 3. RELEVÂNCIA 3.1. A proposta apresenta um grau de relevância em computação que justifique o desenvolvimento do TCC? 4. METODOLOGIA 4.1. Foram relacionadas todas as etapas necessárias para o desenvolvimento do TCC? 4.2. Os métodos e recursos estão devidamente descritos e são compatíveis com a metodologia proposta? 4.3. A proposta apresenta um cronograma físico (período de realização das etapas) de maneira a permitir a execução do TCC no prazo disponível? 5. REVISÃO BIBLIOGRÁFICA 5.1. As informações apresentadas são suficientes e têm relação com o tema do TCC? 5.2. São apresentados trabalhos correlatos, bem como comentadas as principais características dos mesmos? 6. REQUISITOS DO SISTEMA A SER DESENVOLVIDO 6.1. Os requisitos funcionais e não funcionais do sistema a ser desenvolvido foram claramente descritos? 7. CONSIDERAÇÕES FINAIS 7.1. As considerações finais relacionam os assuntos apresentados na revisão bibliográfica com a realização do TCC? 8. REFERÊNCIAS BIBLIOGRÁFICAS 8.1. As referências bibliográficas obedecem às normas da ABNT? 8.2. As referências bibliográficas contemplam adequadamente os assuntos abordados na proposta (são usadas obras atualizadas e/ou as mais importantes da área)? 9. CITAÇÕES 9.1. As citações obedecem às normas da ABNT? 9.2. As informações retiradas de outros autores estão devidamente citadas? 10. AVALIAÇÃO GERAL (organização e apresentação gráfica, linguagem usada) O texto obedece ao formato estabelecido? A exposição do assunto é ordenada (as idéias estão bem encadeadas e a linguagem utilizada é clara)? PONTUALIDADE NA ENTREGA atende atende parcialmente não atende atraso de dias A proposta de TCC deverá ser revisada, isto é, necessita de complementação, se: qualquer um dos itens tiver resposta NÃO ATENDE; pelo menos 4 (quatro) itens dos ASPECTOS TÉCNICOS tiverem resposta ATENDE PARCIALMENTE; ou pelo menos 4 (quatro) itens dos ASPECTOS METODOLÓGICOS tiverem resposta ATENDE PARCIALMENTE. PARECER: ( ) APROVADA ( ) NECESSITA DE COMPLEMENTAÇÃO OBSERVAÇÕES: Assinatura do(a) avaliador(a): Local/data:

7 3.4 AVALIAÇÃO DO(A) PROFESSOR(A) ESPECIALISTA NA ÁREA Acadêmico(a): Avaliador(a): Massami Welington Kamigashima ASPECTOS TÉCNICOS ASPECTOS METODOLÓGICOS ASPECTOS AVALIADOS 1. INTRODUÇÃO 1.1. O tema de pesquisa está devidamente contextualizado/delimitado? 1.2. O problema está claramente formulado? 2. OBJETIVOS 2.1. O objetivo geral está claramente definido e é passível de ser alcançado? 2.2. São apresentados objetivos específicos (opcionais) coerentes com o objetivo geral? Caso não sejam apresentados objetivos específicos, deixe esse item em branco. 3. RELEVÂNCIA 3.1. A proposta apresenta um grau de relevância em computação que justifique o desenvolvimento do TCC? 4. METODOLOGIA 4.1. Foram relacionadas todas as etapas necessárias para o desenvolvimento do TCC? 4.2. Os métodos e recursos estão devidamente descritos e são compatíveis com a metodologia proposta? 4.3. A proposta apresenta um cronograma físico (período de realização das etapas) de maneira a permitir a execução do TCC no prazo disponível? 5. REVISÃO BIBLIOGRÁFICA 5.1. As informações apresentadas são suficientes e têm relação com o tema do TCC? 5.2. São apresentados trabalhos correlatos, bem como comentadas as principais características dos mesmos? 6. REQUISITOS DO SISTEMA A SER DESENVOLVIDO 6.1. Os requisitos funcionais e não funcionais do sistema a ser desenvolvido foram claramente descritos? 7. CONSIDERAÇÕES FINAIS 7.1. As considerações finais relacionam os assuntos apresentados na revisão bibliográfica com a realização do TCC? 8. REFERÊNCIAS BIBLIOGRÁFICAS 8.1. As referências bibliográficas obedecem às normas da ABNT? 8.2. As referências bibliográficas contemplam adequadamente os assuntos abordados na proposta (são usadas obras atualizadas e/ou as mais importantes da área)? 9. CITAÇÕES 9.1. As citações obedecem às normas da ABNT? 9.2. As informações retiradas de outros autores estão devidamente citadas? 10. AVALIAÇÃO GERAL (organização e apresentação gráfica, linguagem usada) O texto obedece ao formato estabelecido? A exposição do assunto é ordenada (as idéias estão bem encadeadas e a linguagem utilizada é clara)? atende atende parcialmente A proposta de TCC deverá ser revisada, isto é, necessita de complementação, se: qualquer um dos itens tiver resposta NÃO ATENDE; pelo menos 4 (quatro) itens dos ASPECTOS TÉCNICOS tiverem resposta ATENDE PARCIALMENTE; ou pelo menos 4 (quatro) itens dos ASPECTOS METODOLÓGICOS tiverem resposta ATENDE PARCIALMENTE. PARECER: ( ) APROVADA ( ) NECESSITA DE COMPLEMENTAÇÃO OBSERVAÇÕES: não atende Assinatura do(a) avaliador(a): Local/data:

8 UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIA DA COMPUTAÇÃO BACHARELADO IMPLEMENTAÇÃO DE UMA ENGINE DE JOGOS DE CARTAS PARA A PLATAFORMA ANDROID MASSAMI WELINGTON KAMIGASHIMA BLUMENAU 2011

9 MASSAMI WELINGTON KAMIGASHIMA IMPLEMENTAÇÃO DE UMA ENGINE DE JOGOS DE CARTAS PARA A PLATAFORMA ANDROID Proposta de Trabalho de Conclusão de Curso submetida à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso I do curso de Ciência da Computação Bacharelado. Prof. Paulo César Rodacki Gomes - Orientador BLUMENAU 2011

10 2 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 bastante 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 disto, propõe-se o desenvolvimento de um motor que permita facilitar a criação de vários jogos de cartas para a plataforma Android, tendo como principais características: a manipulação do baralho em sua estrutura lógica e o tratamento gráfico na animação das cartas. Este motor terá como principal função ser utilizada como o núcleo de um jogo, contendo um controle das cartas que o baralho deve conter a seqüência de valores e naipes do jogo, a seqüência como as cartas serão retiradas do baralho durante a partida, entre outros fatores. Será inserida uma quantidade limitada de configurações pré-definidas que auxiliarão na implementação de cada jogo, sendo algumas delas: o tipo do baralho utilizado (padrão, espanhol ou personalizado), a seqüência das cartas, o valor de cada carta entre outros dados comuns a jogos do gênero. O motor de jogos será dividido em três partes principais: geração do baralho, manipulação e tratamento das cartas e interface gráfica das cartas. A primeira parte tratará da geração das cartas na seqüência que estas devem estar no baralho durante uma partida. A segunda tratará a seqüência das cartas segundo seus valores e naipes, que deverá permitir alterar sua seqüência caso seja necessária. A terceira será responsável por desenhar as cartas na tela, efetuar animações de movimento, rotação e permitir a manipulação delas pelo jogador dentro do espaço gráfico. Para validar o motor de jogos proposto, será desenvolvido um protótipo de jogo de carta. 1 Um motor de jogo é um software ou biblioteca responsável por implementar parcialmente ou int

11 3 1.1 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 seqüê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) desenvolver 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: o tipo do baralho a ser utilizado, a seqüência das cartas disponíveis no jogo e o valor de cada carta entre outros valores pré-definidos; e) desenvolver um protótipo de jogo utilizando o motor desenvolvido; f) disponibilizar os conjunto de cartas do baralho padrão francês 2 e suas variantes. 1.2 RELEVÂNCIA DO TRABALHO O desenvolvimento de jogos para a plataforma Android ainda é uma prática recente no mercado e sua demanda, assim como nas outras plataformas móveis, está crescendo. O desenvolvimento de um jogo requer tempo e dinheiro relativamente altos, o que pode dificultar sua produção. Desta forma, a utilização de motores traz benefícios quando ao desenvolvimento do jogo, pois reduz substancialmente o tempo necessário para sua implementação e conseqüentemente seu custo de produção. O principal desafio deste projeto será elaborar o efeito de animação das cartas quanto sua interação com ambiente e com os jogadores, pois será necessário descobrir quais recursos serão mais viáveis dentre os disponíveis para a plataforma e quais efeitos resultam em uma melhor renderização das imagens apresentadas na animação, o que será necessário o 2 O baralho padrão francês é o mais utilizado atualmente e é composto por 52 cartas divididos em 4 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.

12 4 conhecimento de algoritmos de computação gráfica. 1.3 METODOLOGIA O trabalho será desenvolvido observando as seguintes etapas: a) levantamento bibliográfico: realizar levantamento de bibliografia sobre a plataforma Android, a programação Java para Android, o motor de jogos, requisitos comuns entre jogos de cartas e trabalhos correlatos; b) elicitação de requisitos: detalhar e reavaliar os requisitos do motor de jogos, observando as necessidades levantadas durante a revisão bibliográfica; c) especificação de modelos de estrutura de jogos: especificar o modelo com análise orientada a objeto utilizando a linguagem Unified Modeling Language (UML). Será utilizada a ferramenta Enterprise Architect (EA) para a elaboração do diagrama de casos de uso, diagrama de estado e do diagrama de classe; d) implementação: desenvolver na linguagem Java no ambiente Eclipse o motor conforme especificado na etapa anterior, utilizando o Android Software Development Kit (SDK). Serão desenvolvidas rotinas gráficas para a interação do usuário com as cartas do protótipo implementado; e) testes: desenvolver um protótipo de jogo utilizando o motor desenvolvido: - especificação: especificar o modelo UML de caso de uso e o diagrama de classe do protótipo elaborado, - implementação: desenvolver um protótipo de Poquer utilizando o motor proposto com as regras conhecidas do jogo; - testes: testar o protótipo desenvolvido utilizando o simulador disponível no Android SDK e utilizando um dispositivo real compatível. As etapas serão realizadas nos períodos relacionados no Quadro jul. ago. set. out. nov. etapas / quinzenas levantamento bibliográfico elicitação de requisitos especificação de modelos de estrutura de jogos implementação testes Quadro 1 - Cronograma

13 5 2 REVISÃO BIBLIOGRÁFICA A seção 2.1 apresenta o conceito sobre a plataforma Android. A seção 2.2 descreve as diferenças da programação Java dentro da plataforma. A seção 2.3 aborda o conceito de motores de jogos. A seção 2.4 trata da definição dos jogos de cartas. Por fim, a seção 2.5 apresenta trabalhos correlatos ao projeto. 2.1 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, 2011a). A Figura 1 demonstra a estrutura do sistema operacional do Android dividida em grandes componentes. Fonte: Android Developers (2011a). Figura 1 - 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 custo de memória, para que seja possível instanciá-la múltiplas vezes, auxiliando no gerenciamento do sistema operacional através de

14 6 threads 3. Para controlar o gerenciamento de memória e de threads, esta máquina virtual utiliza o Linux kernel. 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. 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 divulgação, distribuição e licenciamento dos aplicativos registrados no site (ANDROID DEVELOPERS, 2011d). 2.2 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, 2011b). Pela preocupação na utilização de recursos nos dispositivos móveis, ao se tratar de performance nas aplicações para o Android, na 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. Com base nas regras citadas acima, os desenvolvedores do Android citam algumas formas de reduzir a utilização de recursos do aplicativo (ANDROID DEVELOPERS, 2011c): a) evitar criar objetos desnecessários: variáveis temporárias de curta utilização devem ser evitados, pois uma menor quantidade de objetos significa chamadas menos freqüentes do Garbage Collector (GC), o que impacta diretamente na experiência do usuário; 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 3 Thread é um processo ou tarefa concorrente utilizado em sistemas multitarefas que dependente de um criador.

15 7 na programação orientada a objetos, porém a chamadas destas funções de um alto custo, muito maiores que a chamada direta 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 se aplica 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 eles podem tornar o loop até três vezes mais rápidos; 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, 2011c): 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, é bastante utilizado para comunicar outros aplicativos quando uma requisição for concluída. 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).

16 8 2.3 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 e textura, 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 durante a década de 90 com a popularização de jogos 3D de tiro em primeira pessoa (First Person Shooter - FPS) como Doom e Quake. Devido suas arquiteturas consistirem 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 (GREGORY; LANDER, 2009, p.11-12). Uma motor de jogos pode ser desenvolvido generalizando partes da implementação para qualquer gênero de jogo, inclusive jogos multiplataforma. Porém, vários autores como Gregory e Lander (2009) afirmam que para fins de otimização e melhor resultado, seja definida uma plataforma e um gênero específico para o motor. 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, estas engines também podem ser encontradas 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 Application Programming Interface (API) ou SDKs, e principalmente no caso das gratuitas, é comum encontrar comunidades de desenvolvimento através de fóruns nas quais desenvolvedores podem sugerir e compartilhar novos recursos, melhorias ou corrigir problemas encontrados.

17 9 2.4 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 tratará 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. Existem, porém, alguns jogos onde há uma seqüê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 seqüência. 2.5 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, 2011) e a Havok, criado pela empresa de mesmo nome (HAVOK INC, 2011).

18 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 Open Graphic Library for Embedded Systems (OpenGL ES), 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. O MJ3I, assim como este projeto, não implementou rotinas mais complexas de cálculos de física, sistemas de partículas ou áudio M3GE Pamplona (2005) definiu em seu projeto, a elaboração de 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. Diferente da abordagem utilizada por Pamplona (2005), a plataforma Android utiliza a linguagem Java tradicional no lugar do J2ME, pois os dispositivos atuais apresentam uma significativa melhoria em seus recursos, além da utilização de uma máquina virtual otimizada para este fim. Porém, a preocupação com o consumo de recursos ainda existe e afeta diretamente na durabilidade da bateria do dispositivo 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

19 11 GPL 5, que contém ferramentas de produção gráfica em 2 e 3D, manipulação de grafos de cena, áudio, tratamento de física e colisão, e permite a utilização da linguagem Python para a geração de scripts (VELDHUIZEN, 2010a). O BGE utiliza um plugin do motor de física 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 2 ilustra a interface do BGE. Fonte: Veldhuizen, (2010b). Figura 2 - Interface do BGE Havok Este motor proprietário tem sua fama 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). 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.

20 12 O motor é composto por sete módulos de ferramentas (HAVOK INC, 2011b), sendo eles a Havok 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. Fonte: Havok Inc (2011c). Figura 3 - 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 sem fins comerciais para o Windows.

21 13 3 REQUISITOS DO SISTEMA A SER DESENVOLVIDO O motor para o desenvolvimento de jogos para Android deverá: a) permitir definir o conjunto de cartas a ser utilizado no protótipo de jogo (Requisito Funcional - RF); b) permitir definir a ordem das cartas do protótipo (RF); c) permitir definir o modo de distribuição inicial e durante a partida (RF); d) permitir a movimentação e manipulação das cartas pelo jogador (RF); e) utilizar a linguagem de programação Java para Android (Requisito Não-Funcional RNF); f) utilizar o ambiente Eclipse Integrated Development Environment (IDE) como ambiente de desenvolvimento (RNF); g) utilizar o Android SDK como ambiente de testes (RNF).

22 14 4 CONSIDERAÇÕES FINAIS Devido o desenvolvimento de aplicativos para a plataforma Android ser relativamente recente, a necessidade de criar novos recursos para a criação de novos produtos para esta plataforma ainda é relevante. Isto se deve ao crescente avanço na tecnologia dos dispositivos móveis que estão cada vez mais unindo funções de equipamentos que antes haviam somente uma função específica em um único aparelho. Este projeto terá como meta o desenvolvimento de um motor que permita aos desenvolvedores de jogos da plataforma uma abstração de tratamentos entre os principais elementos de um jogo de cartas. Para isso será utilizado o conceito de orientação a objetos definido para a linguagem Java, e será testado dentro de um simulador e um dispositivo real. Para se utilizar este motor, deverão ser definidas inicialmente, as configurações utilizadas pelo jogo, como o conjunto de cartas a serem utilizadas, sua seqüência de cartas, a ordem de prioridade das cartas, entre outras regras a serem definidas durante o desenvolvimento do projeto. Em relação aos trabalhos correlatos, enquanto os trabalhos acadêmicos citados têm foco principal na abstração gráfica para o desenvolvimento, este projeto compartilhará somente uma pequena parcela destes conceitos, pois este terá um foco maior no gerenciamento da estrutura dos jogos. Entretanto, assim como Pamplona (2005), este trabalho terá uma maior preocupação com a forma como os recursos serão utilizados pela linguagem Java, visando que os dispositivos alvos têm uma quantidade limitada de recursos, enquanto quando desenvolvidas para desktop, estas preocupações são menos visíveis. Da mesma forma na qual a plataforma iphone utilizada por Takano (2011) disponibiliza recursos de Interface Humano-Computador (IHC), como sensores e multi-toque, os eventos relacionados a toque serão utilizados neste projeto utilizando os recursos disponíveis na plataforma Android.

23 15 REFERÊNCIAS BIBLIOGRÁFICAS ANDROID DEVELOPERS. What is Android? [S.l.], 2011a. Disponível em: < Acesso em: 15 mar Application fundamentals. [S.l.], 2011b. Disponível em: < Acesso em: 15 mar Designing for performance. [S.l.], 2011c. Disponível em: < Acesso em: 17 mar Publishing on Android market [S.l.], 2011d. Disponível em: < Acesso em: 17 mar Dalvik JIT. [S.l.], Disponível em: < Acesso em: 17 mar GREGORY, Jason; LANDER, Jeff. Game engine architecture. Wellesley: A K Peters, HAVOK INC. Available games. [S.l.], 2011a. Disponível em: < Acesso em: 22 mar Havok product Family. [S.l.], 2011b. Disponível em: < Acesso em: 26 mar Product screenshots. [S.l.], 2011b. Disponível em: < Acesso em: 26 mar PAMPLONA, Vitor F. Um protótipo de motor de jogos 3D para dispositivos móveis com suporte a especificação móbile 3D Graphics API for J2ME f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau. SCHUYTEMA, Paul; MANYEN, Mark. Game development with LUA. Hingham: Charles River Media, TAKANO, Rafael H. MJ3I: um motor de jogos 3D para o iphone OS f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.

24 16 UOL TECNOLOGIA. Venda de smartphones deve superar a de computadores no Brasil em 2011, diz IDC. [S.l.], Disponível em: < Acesso em: 11 mar VELDHUIZEN, Bart. Game engine. Amsterdam, [2011a?]. Disponível em: < Acesso em: 22 mar VELDHUIZEN, Bart. Features. Amsterdam, [2011b?]. Disponível em: < Acesso em: 26 mar WARD, Jeff. What is a game engine? [S.l.], abr Disponível em: < Acesso em: 20 mar