universidade do estado do amazonas - ueatiagodemelo.info/monografias/2011/tcc-george-nunes.pdf ·...
TRANSCRIPT
UNIVERSIDADE DO ESTADO DO AMAZONAS - UEA
ESCOLA SUPERIOR DE TECNOLOGIA
ENGENHARIA DE COMPUTACAO
GEORGE DA ROCHA MEDEIROS NUNES
DESENVOLVIMENTO DE UM JOGO DE DOMINO
PARA ANDROID
Manaus
2011
GEORGE DA ROCHA MEDEIROS NUNES
DESENVOLVIMENTO DE UM JOGO DE DOMINO PARA ANDROID
Trabalho de Conclusao de Curso apresentado
a banca avaliadora do Curso de Engenharia
de Computacao, da Escola Superior de
Tecnologia, da Universidade do Estado do
Amazonas, como pre-requisito para obtencao
do tıtulo de Engenheiro de Computacao.
Orientador: Prof. M. Sc. Jucimar Maia da Silva Junior
Manaus
2011
ii
Universidade do Estado do Amazonas - UEA
Escola Superior de Tecnologia - EST
Reitor:
Jose Aldemir de Oliveira
Vice-Reitor:
Marly Guimaraes Fernandes Costa
Diretor da Escola Superior de Tecnologia:
Mario Augusto Bessa de Figueiredo
Coordenador do Curso de Engenharia de Computacao:
Danielle Gordiano Valente
Coordenador da Disciplina Projeto Final:
Raimundo Correa de Oliveira
Banca Avaliadora composta por: Data da Defesa: 16/12/2011.
Prof. M.Sc. Jucimar Maia da Silva Junior (Orientador)
Prof. M.Sc. Tiago Eugenio de Melo
Prof. M.Sc. Antenor Ferreira Filho
CIP - Catalogacao na Publicacao
N972d NUNES, George
Densenvolvimento de um jogo de domino para Android / George Nunes;
[orientado por] Prof. MSc. Jucimar Maia da Silva Junior - Manaus: UEA,
2010.
61 p.: il.; 30cm
Inclui Bibliografia
Trabalho de Conclusao de Curso (Graduacao em Engenharia de Com-
putacao). Universidade do Estado do Amazonas, 2011.
CDU: 004
iii
GEORGE DA ROCHA MEDEIROS NUNES
DESENVOLVIMENTO DE UM JOGO DE DOMINO PARA ANDROID
Trabalho de Conclusao de Curso apresentado
a banca avaliadora do Curso de Engenharia
de Computacao, da Escola Superior de
Tecnologia, da Universidade do Estado do
Amazonas, como pre-requisito para obtencao
do tıtulo de Engenheiro de Computacao.
Aprovado em: 16/12/2011BANCA EXAMINADORA
Prof. Jucimar Maia da Silva Junior, Mestre
UNIVERSIDADE DO ESTADO DO AMAZONAS
Prof. Tiago Eugenio de Melo, Mestre
UNIVERSIDADE DO ESTADO DO AMAZONAS
Prof. Antenor Ferreira Filho, Mestre
UNIVERSIDADE DO ESTADO DO AMAZONAS
iv
Agradecimentos
Agradeco a Deus, por permitir que eu desen-
volvesse esse trabalho de conclusao de curso.
Ao meus pais, Mario Cesar e Maria Julieta,
por terem me dado condicoes de cursar uma
universidade estadual.
Ao professor Jucimar Junior pela compreen-
sao, paciencia e aceitar ser orientador desta
monografia.
Aos meus amigos de Engenharia da Com-
putacao, Bruno Mendes, Clarice Souza,
Emiliano Firmino, Joao Guilherme, Victor
Kaleb e Yasmine Souza que me acompan-
haram desde a metade final do curso e sempre
me apoiaram e nao me deixaram desistir.
E ao Igor Jacauna Martins, designer que fez
a arte do jogo.
v
Resumo
Esta monografia descreve o desenvolvimento de um jogo de domino para Android,
um jogo popular no Amazonas onde e jogado com regras especıficas que o tornam mais
interessante.
Palavras Chave: jogo, domino, Android, Amazonas.
vi
Abstract
This thesis describes the development of a domino game for Android, a popular game
on Amazonas where it is played with specific rules that make it more interesting.
Key-words: domino, game, Android, Amazonas.
vii
Sumario
Lista de Figuras ix
Lista de Codigos ix
1 Introducao 1
1.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Android 4
2.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Open Handset Alliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Licenca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Fragmentacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Caracterısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.7 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7.1 Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7.2 Runtime e Dalvik . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7.3 Bibliotecas de Sistema . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7.4 Camada de Aplicacao . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8 O Kit de Desenvolvimento de Software (SDK) . . . . . . . . . . . . . . . . 13
3 Domino 15
3.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Modalidade Amazonense . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
viii
3.2.1 Inıcio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2 Saıda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.3 Jogada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.4 Bucho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.5 Pontuacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.6 Passe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.7 Galo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.8 Batida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.9 Jogo fechado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.10 Fim do jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4 Desenvolvimento 22
4.1 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1 Interface Grafica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Codificacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4 Imagens do jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5 Conclusao 48
5.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Referencias Bibliograficas 49
6 Apendice 50
ix
Lista de Figuras
2.1 Arquitetura do Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Pecas do jogo de domino . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Inicio de uma partida na modalidade Amazonense de domino . . . . . . . . 17
3.3 Saıda em uma partida na modalidade Amazonense de domino . . . . . . . 17
3.4 Jogada em uma partida na modalidade Amazonense de domino . . . . . . 18
3.5 Jogada no “bucho” em uma partida na modalidade Amazonense de domino 19
3.6 Placar da partida apos as jogadas da figura 3.4 e da figura 3.5 . . . . . . . 20
4.1 Ideia inicial da tela de jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Printscreen da interface Sony Ericsson Xperia Android 1.6 e 2.1 . . . . . . 24
4.3 Esboco da tela de jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4 Diagrama de fluxo de telas do jogo Domino Manaus . . . . . . . . . . . . . 25
4.5 Diagrama de Casos de Uso do jogo Domino Manaus . . . . . . . . . . . . . 26
4.6 Diagrama de Atividades do jogo Domino Manaus . . . . . . . . . . . . . . 27
4.7 Diagrama de Classes do jogo Domino Manaus . . . . . . . . . . . . . . . . 29
4.8 Tela de menu principal e tela de inıcio de jogo (saıda) . . . . . . . . . . . . 44
4.9 Vez do jogador humano e jogada inicial da 1a partida . . . . . . . . . . . . 44
4.10 Vez do jogador maquina e tela de jogo fechado . . . . . . . . . . . . . . . . 45
4.11 Recomeco de jogo fechado pela dupla adversaria e jogada no bucho . . . . 45
4.12 Jogada de carroca marcando 5 pontos . . . . . . . . . . . . . . . . . . . . . 45
4.13 Tela de garagem e nova partida iniciada pelo jogador que bateu . . . . . . 46
4.14 Jogador humano sem jogada (so pode passar) e tela de pause . . . . . . . . 46
4.15 Tela de fim de jogo e paginacao do placar . . . . . . . . . . . . . . . . . . . 47
4.16 Tela de creditos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
x
Lista de Codigos
4.3.1 AndroidManifest.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.2 Classe DominoManausGame.java . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.3 Classe LoadingScreen.java . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.4 Classe Assets.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.5 Classe MainMenuScreen.java . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.6 Atributos e Construtor da Classe GameScreen.java . . . . . . . . . . . . . 37
4.3.7 Metodo de update da Classe GameScreen.java . . . . . . . . . . . . . . . . 38
4.3.8 Metodo present da Classe GameScreen.java . . . . . . . . . . . . . . . . . . 38
4.3.9 Metodo updateSaida da Classe GameScreen.java . . . . . . . . . . . . . . . 39
4.3.10Metodo saida da Classe Jogo.java . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.11Metodo update da Classe Jogo.java . . . . . . . . . . . . . . . . . . . . . . 40
4.3.12Metodo desenhaPartida da Classe GameScreen.java . . . . . . . . . . . . . 41
4.3.13Metodo updateFechado da Classe GameScreen.java . . . . . . . . . . . . . . 42
4.3.14Metodo updateGaragem da Classe GameScreen.java . . . . . . . . . . . . . 43
Capıtulo 1
Introducao
O domino e um jogo de mesa tradicional no Amazonas, onde e disputado de maneira
peculiar, com caracterısticas e termos proprios. Por exemplo, as pecas (ou pedras, como
sao chamadas) recebem nomes de acordo com a quantidade de pontos: 0 pontos - “branco”,
1 ponto - “as”, 2 pontos - “duque”, 3 - “terno”, 4 - “quadra”, 5 - “quina” e 6 - “sena”. Pedras
com as duas pontas iguais sao chamadas de “carroca”.
Na modalidade Amazonense, as partidas sao disputadas por quatro participantes, que
formam duas duplas e sentam em posicoes alternadas. A primeira partida e iniciada com
a carroca de sena. E possıvel jogar nas 4 pontas da pedra inicial. Os pontos devem ser
multiplos de 5. O passe concede 20 pontos aos adversarios. Ganha o jogo a dupla que fizer
200 ou mais pontos.
Em 2011 foi realizada a 4a edicao da Copa A Critica de Domino, evento promovido
pela Rede Calderaro de Comunicacao e que tem por finalidade incentivar a pratica do
esporte, que estimula o raciocınio logico e proporciona integracao e confraternizacao entre
os participantes, conforme [Crıtica2011]. O evento contou com a participacao de 216 duplas
e tinha como premiacao a quantia de R$20.000,00 para a dupla 1a colocada e de dois freezers
cheios de cerveja para os 2os colocados.
Objetivo 2
1.1 Objetivo
1.1.1 Geral
Desenvolver um jogo de domino para Android.
1.1.2 Especıficos
• Design da GUI do jogo de domino.
• Engine basica do jogo de domino.
• Engine completa da modalidade Amazonense do jogo de domino.
• Nıvel de dificuldade iniciante.
• Nıvel de dificuldade intermediario.
1.2 Justificativa
Com a intencao de padronizar uma plataforma livre e de codigo aberto para celulares
e atender as expectativas e tendencias do mercado atual, empresas lıderes em tecnologia
movel formaram um grupo chamado Open Handset Alliance (OHA). O grupo, liderado pelo
Google, tem como integrantes nomes consagrados como a HTC, LG, Motorola, Samsung,
Sony Ericsson, Toshiba, Sprint Nextel, China Mobile, T-Mobile, Asus, Intel, Garmim, entre
outros. O resultado dessa uniao foi o nascimento do Android.
De acordo com [Lecheta], o Android e uma nova plataforma de desenvolvimento para
aplicativos moveis, baseada no sistema operacional Linux, com interface visual rica e am-
biente de desenvolvimento multiplataforma.
Segundo [Farago2011], em 2009 os sistemas operacionais moveis iOS e Android cresce-
ram em 5% do mercado de games nos Estados Unidos, com um volume total de US$ 500
milhoes em vendas. Em 2010, o aumento foi de 8%. Isso representa um aumento de US$
300 milhoes em receita e equivale a metade da participacao do mercado de videogames
portateis, uma concorrencia para os fabricantes tradicionais.
Metodologia 3
Nos dados especıficos para os dispositivos moveis, os numeros sao ainda mais expressivos
para os sistemas da Apple e da Google. As vendas de jogos para iOS e Android saltaram
de 10% em 2009 para 32% em 2010, fazendo com que as vendas de jogos do Nintendo DS
reduzissem de 70% para 57%, e no caso do PlayStation Portable, a reducao foi de 11%
para 9%, no mesmo perıodo.
Outro dado a ser observado e que, segundo as analises, as vendas de jogos para iOS e
Android no ano passado foram maiores que as vendas de jogos para PCs, que arrecadou o
volume total de US$ 700 milhoes nos Estados Unidos.
Os resultados dos estudos mostram que os smartphones com sistema Android e iOS
estao se tornando os preferidos entre os jogadores de videogames portateis.
1.3 Metodologia
• Projetar as telas que o jogo ira possuir.
• Diagramar o fluxo das telas projetadas.
• Modelar o jogo de domino utilizando UML.
• Criar as classes do jogo de domino em Java.
• Montar o jogo em cima do framework.
• Criar as interfaces graficas usando o framework.
• Tratar os eventos para cada tela utilizando o framework.
• Executar e testar o jogo em dispositivos moveis.
Capıtulo 2
Android
O Android e uma plataforma de codigo aberto para dispositivos moveis que inclui sistema
operacional, middleware e aplicativos.
2.1 Historia
A Android, Inc. foi fundada em Palo Alto, California, Estados Unidos, em outubro
de 2003 por Andy Rubin (co-fundador da Danger), Rich Miner (co-fundador da Wildfire
Communications, Inc.), Nick Sears (vice-presidente da T-Mobile) e Chris White (lıder de
projeto e desenvolvimento de interface na WebTV), para desenvolver, nas palavras de Rubin
”... dispositivos moveis mais inteligentes que conhecem melhor a localizacao e preferencias
de seus donos”. Apesar das obvias realizacoes passadas de seus funcionarios iniciais, a
Android Inc. operava secretamente, revelando apenas que estava trabalhando em software
para celulares.
O Google adquiriu a Android, Inc. em agosto de 2005, tornando-a uma subsidiaria
da Google Inc. Funcionarios-chave como Andy Rubin, Rich Miner e Chris White, per-
maneceram na empresa apos a aquisicao. Pouco se sabia sobre a Android Inc. quando ela
foi adquirida, mas muitos acharam que o Google estava planejando entrar no mercado de
celulares com essa aquisicao. A equipe liderada por Rubin desenvolveu uma plataforma
para dispositivos moveis sobre o kernel do Linux e o Google apresentou a plataforma aos
Open Handset Alliance 5
fabricantes de celulares e operadoras com a premissa de ser uma plataforma flexıvel, aberta
e de facil atualizacao.
Especulacoes sobre a intencao do Google em entrar no mercado de comunicacoes moveis
continuaram a surgir ate dezembro de 2006. Houveram rumores de que o Google estaria
desenvolvendo um celular com a sua marca. Especulava-se que o Google estaria definindo
especificacoes tecnicas e estava mostrando prototipos para os fabricantes de celular e op-
eradores de telefonia movel. Em setembro de 2007 a InformationWeek1 cobriu um estudo
da Evalueserve reportando que o Google apresentou varios pedidos de patentes na area de
telefonia movel.
No dia 5 de novembro de 2007, e revelada a Open Handset Alliance, um consorcio de 34
empresas de hardware, software e telecomunicacoes lideradas pelo Google com o objetivo
de desenvolver padroes abertos para dispositivos moveis e tambem seu primeiro produto, o
Android, uma plataforma para dispositivos moveis construıda sobre o kernel 2.6 do Linux.
Segundo [Zechner2011], desde o seu lancamento em 2008, o Android recebeu varias
atualizacoes de versao, todas com nomes de sobremesa. Cada versao adicionou novas
funcionalidades a plataforma Android, que sao relevantes aos desenvolvedores de jogos de
um jeito ou de outro. A versao 1.5 (Cupcake) adicionou suporte a bibliotecas nativas as
aplicacoes Android, que antes eram restritas a serem escritas em Java puro. Codigo nativo
pode ter muitos benefıcios em sintuacoes onde o desempenho e o mais importante. A
versao 1.6 (Donut) introduziu support para diferentes resolucoes de tela. Na versao 2.0
(Eclair) foi adicionado suporte a telas multi-toques, e na versao 2.2 (Froyo) adicionaram
a compilacao just-in-time (JIT) a maquina virtual Dalvik. O JIT acelera a execucao de
aplicacoes Android, dependendo do cenario, em ate 5 vezes. A versao mais atual e a 2.3,
chamada de Gingerbread, que adicionou um garbage collector concorrente ao da maquina
virtual Dalvik.
2.2 Open Handset Alliance
Conforme [Pereira and Silva], a Open Handset Alliance consiste em todas as estruturas
envolvidas no processo de telefonia movel:
1http://www.informationweek.com/news/201807587
Licença 6
• Operadoras de telefonia movel: responsavel pela conexao. Fornecem o servico
para o usuario final;
• Fabricantes de aparelhos: responsaveis pela criacao do hardware;
• Empresas de semicondutores: fazem os chips dos aparelhos celulares;
• Empresas de software: desenvolvem os softwares que serao executados no Android;
• Empresa de comercializacao: responsaveis pela divulgacao, marketing e comer-
cializacao dos produtos para o usuario;
Como refere [Zechner2011], muitos membros da OHA desenvolvem versoes personal-
izadas do Android para seus dispositivos, com interface grafica modificada - por exemplo
a HTC Sense da HTC e a MOTOBLUR da Motorola. A natureza de codigo aberto do
Android tambem permite que entusiastas criem e distribuam suas proprias versoes do An-
droid, chamadas de mods, firmwares ou ROMs. A mais conhecida ROM alternativa e
desenvolvida por um colaborador conhecido como Cyanogen e tem como objetivo trazer as
mais novas e melhores mudancas a todos os tipos de dispositivos com Android.
2.3 Licenca
O Android esta disponıvel sob licencas livres e de codigo aberto, desde 21 de outubro
de 2008 ate marco de 2011. O Google publicou o codigo fonte das modificacoes ao kernel
do Linux sob a licenca GNU General Public License versao 2, e o resto do codigo (incluindo
a pilha de rede e telefonia) sob a licenca Apache versao 2. E tambem mantem uma lista
de correcoes revisadas aberta publicamente para qualquer um ver e comentar.
A Open Handset Alliance desenvolve a parte sob licenca GPL do Android, que sao
as modificacoes ao kernel do Linux, com codigo fonte disponıvel publicamente a qualquer
momento. O resto do Android e desenvolvimento em particular, com codigo fonte liberado
publicamente quando uma nova versao principal e lancada. Tipicamente o Google faz
parceria com um fabricante de hardware para produzir um dispositivo carro-chefe figurando
a nova versao do Android, tornando o codigo fonte disponıvel depois de o dispositivo ter
sido lancado.
Fragmentação 7
No comeco de 2011, o Google decidiu nao publicar o codigo fonte da versao somente
para tablets Honeycomb, criando duvidas sobre seu compromisso com o codigo aberto do
Android. A razao, segundo Andy Rubin (executivo responsavel pelo Android e atual vice
presidente senior do Google) em sua postagem no blog oficial do Android, foi porque a
Honeycomb foi apressada para a producao do Motorola Xoom, e eles nao queriam terceiros
criando uma experiencia ruim para o usuario, tentando colocar em celulares uma versao
que e destinada a tablets. O Google confirmou depois que o codigo fonte da Honeycomb
nao sera liberado ate que ela seja mesclada com a Gingerbread e lancada como Ice Cream
Sandwich.
Apesar de ser um software de codigo aberto, os fabricantes nao podem usar a marca
Google Android a menos que o Google certifique que o dispositivo e compatıvel com seu
Documento de Definicao de Compatibilidade. Dispositivos tambem devem obedecer a essa
definicao para poderem licenciar aplicacoes de codigo fechado do Google, como o Android
Market.
2.4 Fragmentacao
De acordo com [Zechner2011], a grande flexibilidade do Android tem um preco: em-
presas que optam por desenvolver suas proprias interfaces graficas tem que acompanhar
o passo do lancamento de novas versoes do Android. Isso pode levar celulares lancados a
alguns meses a ficarem rapidamente desatualizados ja que as operadoras e fabricantes de
celulares se recusam a criar atualizacoes que incorporem as melhorias das novas versoes do
Android.
A fragmentacao tem varias caras. Para o usuario final, significa nao poder instalar
e usar certas aplicacoes e funcionalidades por estarem encalhados em uma versao antiga
do Android. Para desenvolvedores, significa que alguns cuidados tem de ser tomados na
criacao de aplicacoes que devem rodar em todas as versoes do Android. Enquanto aplicacoes
escritas para as primeiras versoes do Android rodarao normal em versoes novas, o inverso
nao e verdadeiro. Algumas funcionalidades adicionadas em versoes novas do Android nao
estao disponıveis em versoes antigas, como o suporte ao multi-toque. Isso faz com que os
desenvolvedores tenham que criar caminhos separados de codigo para diferentes versoes do
Segurança 8
Android.
No caso dos desenvolvedores de jogos, a preocupacao maior e com a capacidade do
hardware do que com a diferenca entre as APIs.
2.5 Seguranca
Segundo [Pereira and Silva], como e executado em um kernel Linux, toda vez que um
aplicativo for instalado em um dispositivo com Android, e criado um novo usuario Linux
para aquele programa, com diretorios que serao usados pelo aplicativo, mas somente para
aquele usuario Linux. Como os aplicativos ficam completamente isolados uns dos outros,
qualquer tentativa de acessar informacoes de outro aplicativo precisa ser explicitamente
autorizada pelo usuario, podendo ser negada a instalacao do aplicativo, ou autorizada a
instalacao, mas controlando as permissoes que este aplicativo podera ter atraves de um
mecanismo de permissao.
Cada processo da aplicacao no Android e considerado uma sandbox, um mecanismo
de seguranca que separa os programas em execucao em um ambiente isolado, com acesso
limitado aos recursos do sistema. So e possıvel acessar outras aplicacoes caso tenha as per-
missoes explicitamente declaradas, para que elas possam ser conhecidas desde o momento
da instalacao, e nada ira fazer com que sejam alteradas apos isto.
2.6 Caracterısticas
O Android nao e so mais uma distribuicao Linux para dispositivos moveis. Muitas vezes
o programador nem chega a ter contato direto com o kernel do Linux. A face do Android
vista pelo programador e uma plataforma que abstrai a camada do kernel do Linux e e
programada via linguagem Java. Em uma visao de alto nıvel, o Android possui algumas
caracterısticas:
Uma camada de aplicacao que fornece um conjunto de APIs para criar varios tipos de
aplicacao. Tambem permite a reutilizacao e substituicao de componentes fornecidos pela
plataforma e aplicativos de terceiros.
Arquitetura 9
A maquina virtual Dalvik, que e responsavel por executar aplicacoes no Android e e
otimizada para dispositivos portateis.
Navegador de internet baseado no motor de codigo aberto WebKit.
Um conjunto de bibliotecas graficas para programacao 2D e 3D. Suporte multimıdia
para audio comum, vıdeo e formatos de imagem como Ogg Vorbis, MP3, AAC, AMR,
MPEG-4, H.264, PNG, GIF e JPEG. Possui inclusive uma API especializada para tocar
efeitos sonoros, util no desenvolvimento de jogos.
APIs para acessar perifericos como a camera, sistema de posicionamento global (GPS),
bussola, acelerometro, tela sensıvel ao toque, dispositivos apontadores e teclado. Nem
todos os dispositivos Android possuem todos esses perifericos, resultando na fragmentacao
de hardware.
Ambiente de desenvolvimento rico, incluindo emulador de dispotivos, ferramentas de
depuracao, profiling de memoria e desempenho e plugin para a IDE Eclipse.
2.7 Arquitetura
A arquitetura do Android e composta de uma pilha de componentes e cada componente
e construıdo sobre os componentes da camada inferior. A figura 2.1 mostra uma visao dos
principais componentes do Android:
Arquitetura 10
Figura 2.1: Arquitetura do Android
2.7.1 Kernel
O Android baseia-se na versao 2.6 do Linux para os servicos centrais do sistema como
seguranca, gerenciamento de memoria e de processos e rede. O kernel age com uma camada
de abstracao entre o hardware e o restante da pilha de software e fornece os drivers basicos
para os componentes de hardware.
2.7.2 Runtime e Dalvik
O runtime do Android e construido em cima do kernel do Linux e e responsavel por
criar e executar aplicacoes Android. Cada aplicacao executa em seu proprio processo e
com sua propria maquina virtual Dalvik.
A Dalvik executa programas no formato de bytecode DEX. O arquivo comum .class do
Java e transformado para o formato DEX atraves de uma ferramenta chamada dx que e
fornecida no kit de desenvolvimento de software. O formato DEX foi projetado para ter
Arquitetura 11
menos utilizacao de memoria se comparado com o arquivo .class classico do Java. Isso e
alcancado atraves de compressao pesada, tabelas e fusao de multiplos arquivos .class.
A maquina virtual Dalvik utiliza as bibliotecas de nucleo, que fornecem as funcional-
idades basicas disponıveis para os programas Java. As bibliotecas de nucleo fornecem
algumas, mas nao todas, as classes disponıveis no Java SE por meio do uso de um sub-
conjunto da implementacao Java Apache Harmony. Isso quer dizer que nao ha Swing ou
Abstract Window Toolkit (AWT) disponıvel, nem classes que podem ser encontradas no
Java ME. Entretanto, com algum cuidado, ainda e possıvel utilizar muitas bibliotecas de
terceiros disponıveis para Java SE na Dalvik. Antes do Android 2.2 (Froyo), todo bytecode
era interpretado. O Froyo introduziu um compilador JIT rastreavel, que compila partes
do bytecode para codigo de maquina no momento do uso. O compilador JIT pode usar
funcionalidades da CPU espeficiamente adaptados para processamentos especiais como a
unidade de processamento de ponto flutuante (FPU) dedicada.
A Dalvik tambem possui um garbage collector (GC) integrado. A versao 2.3 do Android
(Gingerbread) tem um aperfeicoado GC concorrente.
Cada aplicacao executando em uma instancia da maquina virtual Dalvik tem um total
de 16MB a 24MB de memoria heap disponıvel.
2.7.3 Bibliotecas de Sistema
Alem das bibliotecas de nucleo, existe um conjunto de bibliotecas nativas em C/C++
que constroem a base para a camada de aplicacao. Essas bibliotecas de sistemas sao as
principais responsaveis por tarefas computacionamente pesadas como renderizacao grafica,
reproducao de audio e acesso a banco de dados, que nao seria adequado para a maquina
virtual Dalvik. As APIs estao embrulhadas por meio das classes Java na camada de
aplicacao. Abaixo a relacao das principais bibliotecas e suas caracterısticas:
• System C library: uma implementacao da biblioteca de sistema padrao C (libc)
derivada do BSD, ajustada para dispositivos embarcados baseados em Linux.
• Surface Manager: gerencia o acesso ao subsistema de exibicao e combina camadas
2D e 3D de multiplas aplicacoes.
Arquitetura 12
• Skia Graphics Library (SGL): renderizador de graficos 2D, e responsavel por
rederizar a interface grafica das aplicacoes Android.
• 3D Libraries: uma implementacao baseada no OpenGL for Embedded Systems
(OpenGL ES), o padrao da industria para renderizacap de graficos acelerado por
hardware. A versao 1.0 e 1.1 esta disponıvel no Java em todas as versoes do Android.
A versao 2.0 que possui sombreadores (shaders) so esta disponıvel no Android 2.2
(Froyo) em diante.
• Media Libraries: baseada na OpenCORE da PacketVideo, as bibliotecas permitem
reproducao e gravacao de audio, video e imagens em varios formatos populares como
Ogg Vorbis, MP3, AAC, AMR, MPEG4, H.264, JPG e PNG.
• FreeType: e uma biblioteca para carregar e renderizar fonts bitmaps e vetoriais,
mais especificamente o formato TrueType.
• SQLite: um leve e poderoso motor de banco de dados relacional disponıvel para
todas as aplicacoes.
2.7.4 Camada de Aplicacao
A camada de aplicacao reune as bibliotecas de sistema e o runtime, criando o lado do
usuario do Android. A camada gerencia as aplicacoes e fornece um framework elaborado
no qual as aplicacoes funcionam. Os desenvolvedores criam aplicacoes para essa camada
atraves do conjunto de APIs Java que cobrem tais areas como programacao da interface
grafica, servicos em segundo plano, notificacoes, gerenciamento de recursos, acesso a per-
ifericos e assim por diante. Todas as aplicacoes de nucleo fornecidas juntamente com o
Android, como o cliente de email, sao escritas usando essas APIs.
Aplicacoes, sejam graficas ou servicos de segundo plano, podem comunicar suas ca-
pacidades com outras aplicacoes. Um exemplo simples e uma aplicacao que precisa tirar
uma foto e entao realizar alguma operacao com ela. A aplicacao requisita do sistema um
componente de outra aplicacao que fornece esse servico. A primeira aplicacao pode reusar
o componente (por exemplo a aplicacao nativa da camera ou galeria de fotos). Isso re-
O Kit de Desenvolvimento de Software (SDK) 13
duz significativamente o fardo dos programadores e permite a personalizacao de diversos
aspectos do comportamento do Android.
Os desenvolvedores de jogos criam aplicacoes com interface grafica nessa camada. Por
isso e importante conhecer a arquitetura e o ciclo de vida da aplicacao, e tambem como
ela interage com o usuario.
Por baixo de todas as aplicacoes estao uma serie de servicos e sistemas, incluindo:
• Um rico e extenso conjunto de Views que podem ser usados para construir aplicacoes,
incluindo listas, grids, caixas de texto, botoes e ate mesmo um navegador que pode
ser embutido.
• Content Providers que permitem aplicacoes acessar dados de outras aplicacoes (como
o aplicativo nativo Contatos), ou compartilhar seus proprios dados.
• Um Resource Manager, fornecendo acesso a recursos que nao sao codigo fonte como
cadeias de caracteres, desenhos e arquivos de disposicao (layout).
• Um Notification Manager que permite a todas as aplicacoes exibirem alertas person-
alizados na barra de status.
• Um Activity Manager que gerencia o ciclo de vida das aplicacoes e fornece uma pilha
de volta para navegacao
2.8 O Kit de Desenvolvimento de Software (SDK)
Para desenvolver aplicacoes para Android, utiliza-se o Kit de Desenvolvimento de Soft-
ware (SDK) do Android. O SDK e composto por um conjunto de ferramentas, documen-
tacao, tutoriais e amostras que ajudaram o desenvolvedor a comecar a qualquer momento.
Tambem estao inclusas as bibliotecas Java necessarias para criar aplicacoes para Android.
Essas contem as APIs da camada de aplicacao. A maioria dos sistemas operacionais para
desktop sao suportados como ambiente de desenvolvimento.
As caracterısticas principais do SDK sao:
• O depurador, capaz de depurar aplicacoes executando em um dispositivo ou emulador
O Kit de Desenvolvimento de Software (SDK) 14
• O profile de memoria e desempenho que ajudam a encontrar vazamentos de memoria
e identificar trechos de codigo lento
• O emulador de dispositivos, baseado no QEMU (uma maquina virtual de codigo
aberto para simular diferentes plataformas de hardware), que, apesar de preciso,
pode ser um pouco lento algumas vezes
• Utilitarios de linha de comando para comunicar com os dispositivos
• Scripts prontos e ferramentas para empacotamento e instalacao de aplicacoes
O SDK pode ser integrado ao Eclipse, um completo e popular ambiente de desenvolvi-
mento integrado (IDE) Java de codigo aberto. A integracao e feita atraves do plugin
Android Development Tools (ADT), que adiciona uma serie de novas funcionalidades ao
Eclipse para criar projetos, executar, depurar e analizar (profiling) aplicacoes no emulador
ou em um dispositivo, alem de empacotar e implantar aplicacoes no Android Market. E
possıvel integrar o SDK a outras IDEs, como o NetBeans, mas nao ha suporte oficial pra
isso.
Capıtulo 3
Domino
Domino e um tipo de jogo de mesa jogado com pecas retangulares, dotadas de uma es-
pessura que lhes da a forma de paralelepıpedo, em que uma das faces esta marcada por
pontos indicando valores numericos. A figura 3.1 mostra as pecas de domino. O conjunto
tradicional de dominos, conhecido como sino-europeu, e formado por 28 pecas, ou pedras.
O termo domino tambem e usado para designar individualmente as pecas que compoem
este jogo. Uma das faces retangular de um domino e divida em duas partes quadradas, ou
”pontas”, que sao marcadas por um numero de pontos de 1 a 6, ou deixadas em branco.
Figura 3.1: Pecas do jogo de domino
3.1 Historia
De acordo com [Kelley1999], o domino nao tem sua origem esclarecida. E conhecido
por inumeros povos e, portanto, tem inumeras variacoes. A primeira mencao ao jogo de
Modalidade Amazonense 16
domino vem da China. Segundo lendas daquele paıs, o jogo teria sido inventado por um
funcionario do imperador Hui Tsung. Outra remete a invencao do jogo aos anos de 234
a 181 a.C, quando teria vivido Huang Ming, um soldado-heroi. No Brasil, o jogo teria
chegado com os portugueses no sec. XVI, virando passatempo para os escravos.
3.2 Modalidade Amazonense
O domino jogado no Amazonas tem regras bastante peculiares, tornando o jogo mais
interessante.
Alem disso, e usada a seguinte nomeclatura para as pedras, conforme a quantidade de
pontos em cada ponta: 0 pontos - “branco”, 1 ponto - “as”, 2 pontos - “duque”, 3 - “terno”,
4 - “quadra”, 5 - “quina” e 6 - “sena”. A pedra [2|4] por exemplo e chamada de duque e
quadra ou quadra e duque. Pedras com as duas pontas iguais sao chamadas de “carroca”.
A seguir sao explicadas detalhadamente cada uma das caracterısticas dessa modalidade.
3.2.1 Inıcio
Os jogadores de cada dupla sentam-se a mesa, de frente um para o outro, e colocam as
pedras na mesa com a face marcada voltada para baixo para que possam ser misturadas,
ilustrado na figura 3.2. Apos a mistura cada jogador deve pegar 7 pedras. Caso algum
jogador possua 5 carrocas, ele deve mostra-las aos outros jogadores que devem devolver
suas pedras para que todas possam ser misturadas novamente.
Modalidade Amazonense 17
Figura 3.2: Inicio de uma partida na modalidade Amazonense de domino
3.2.2 Saıda
A saıda e a jogada que inicia uma partida. Na primeira partida do jogo e realizada
pelo jogador que possui a carroca de sena [6|6]. O jogador “saıdo” posiciona a carroca no
centro da mesa voltada horizontalmente para sı, para que seja possıvel identificar a dupla
que “saiu”. Um exemplo de saıda feito pelo jogador 3 pode ser visto na figura 3.3.
Figura 3.3: Saıda em uma partida na modalidade Amazonense de domino
Modalidade Amazonense 18
3.2.3 Jogada
Apos a saıda, o jogador a esquerda do jogador que iniciou a partida deve escolher uma
pedra, entre as 7 que possui (chamada de ”mao”), cuja ponta corresponda a uma das pontas
do jogo na mesa. Entao deve encaixa-la na ponta da mesa com a ponta correspondente.
Inicialmente as jogadas sao feitas nos lados da pedra saıda (e nao nas pontas). As carrocas
sao jogadas na perpedicular em relacao as demais pedras. Na figura 3.4 e possıvel ver a
jogada feita pelo jogador 4.
Figura 3.4: Jogada em uma partida na modalidade Amazonense de domino
3.2.4 Bucho
Apos os dois lados da saıda estarem ocupados, e possıvel jogar nas duas pontas da
pedra saıda, chamado de “bucho”. A jogada no “bucho” tambem recebe o nome de “furar
o bucho” ou “correr para o bucho” em alusao a uma possıvel falta de pedra para jogar nas
outras pontas. A figura 3.5 ilustra uma jogada feita no bucho pelo jogador 1.
Modalidade Amazonense 19
Figura 3.5: Jogada no “bucho” em uma partida na modalidade Amazonense de domino
3.2.5 Pontuacao
A pontuacao e contada com multiplos de 5. Caso o jogador anuncie que ira pontuar
(chamado de “cantar”) antes de efetuar sua jogada, e ao realiza-la, a soma das pontas da
mesa corresponda a pontuacao “cantada” por ele, essa pontuacao e adicionada ao placar da
dupla. Em pontas que houverem carrocas, as duas pontas da carroca seram contabilizadas.
Normalmente, os pontos sao marcados usando papel e caneta, onde sao anotadas as
iniciais de cada jogador da dupla e para cada 5 pontos da dupla e marcado um traco, sendo
o proximo traco marcado perpendicular ao primeiro, formando uma cruz, que equivale a
10 pontos (2 tracos). A primeira cruz e desenhada grande e as 4 proximas sao desenhadas
menores nos quadrantes determinados pela primeira, fechando 50 pontos. Daı entao e feito
uma nova cruz grande para os proximos 10 pontos e assim por diante. Na figura 3.6 e
possıvel observar o placar da partida apos as jogadas da figura 3.4 e da figura 3.5, se os
respectivos pontos tiverem sido contados.
Modalidade Amazonense 20
Figura 3.6: Placar da partida apos as jogadas da figura 3.4 e da figura 3.5
Outra forma de marcar a pontuacao e utilizando fichas pontuadas ou coloridas. Sao
usadas 2 fichas de 5 pontos, 8 fichas de 10 pontos e 6 fichas de 50 pontos. Conforme os
pontos sao marcados pelas duplas, as fichas sao trocadas por fichas de maior valor, ate
que uma dupla complete 200 pontos e devolva suas fichas para o marcador, chamado de
“pagar a casa”. Novos pontos marcados pela dupla que “pagou a casa” sao novamente
contabilizados com as fichas correspondentes, lembrando sempre que esta dupla possui 200
pontos alem daqueles representados pelas fichas que possui.
3.2.6 Passe
Quando um jogador nao possui nenhuma pedra que possa jogar, ele passa a vez ao
proximo jogador a sua esquerda e sao marcados 20 pontos para os adversarios. Se o
proximo jogador tambem nao tiver pedra jogavel, somente passa a vez, sem dar 20 pontos
aos adversarios, chamado de “passe nas costas”.
3.2.7 Galo
Da-se o nome de “galo” a jogada previamente cantada pelo jogador, na qual ele faz
a sua jogada e nenhum outro jogador consegue jogar, sendo a vez novamente do jogador
que deu o galo. Essa jogada por sı so vale 50 pontos (alem dos pontos na mesa, se forem
Modalidade Amazonense 21
cantados). Caso um jogador cante galo e apos a sua jogada algum outro jogador consiga
jogar, chamado de “galo gay”, os 50 pontos sao marcados para os adversarios e a partida
segue.
3.2.8 Batida
E chamado de “batida” a jogada da ultima pedra de um jogador. Quando a batida
e feita de carroca, se for cantada, da direito a 20 pontos a dupla que bateu, chamado de
“domino de 20”. A batida encerra a partida e calcula-se a“garagem”, a soma das pedras dos
adversarios, que arredondada para baixo de um multiplo de 5, e adicionada a pontuacao
da dupla que bateu. A partida seguinte, caso haja, e iniciada pelo jogador que bateu, que
pode “sair” com qualquer carroca. Caso nao tenha carroca, passa a vez (regra do passe),
ate que o proximo jogador que possua uma carroca possa comecar a nova partida.
3.2.9 Jogo fechado
O chamado “jogo fechado” ocorre quando nenhum jogador possui pedra possıvel de
jogar. Nesse caso, a partida e encerrada e sao somadas as maos de cada dupla, sendo as
somas diferentes, a maior soma arredondada para baixo de um multiplo de 5, e computada
ao placar da dupla de menor soma. A partida seguinte, caso haja, e iniciada pelo jogador
que pegar a carroca de sena.
3.2.10 Fim do jogo
O jogo termina quando, ao final de uma partida, uma dupla tenha somado 200 ou mais
pontos. Em caso de empate, e jogado uma nova partida de desempate ate que haja uma
dupla vencedora.
Capıtulo 4
Desenvolvimento
Este capıtulo descreve o desenvolvimento do jogo Domino Manaus, uma versao eletronica
do jogo de domino de mesa do mundo real. Por ser uma implementacao da modalidade
jogada no Amazonas, o jogo recebeu o nome da capital do estado, Manaus.
4.1 Projeto
Nesta fase foram tomadas as decisoes de projeto do jogo, como:
• Android 1.6 ou superior - para ser compatıvel com a maioria dos dispositivos com
Android.
• Resolucao de 240x320 - menor resolucao de tela de um dispositivo com Android,
por motivos de compatibilidade.
• Controles na tela (Touchscreen) - tecnologia disponıvel em todos os dispositivos
com Android e de facil uso.
• Modalidade Amazonense - o jogo deve conter todos os elementos da modalidade
Amazonense de domino.
Na modalidade Amazonense de domino, o jogador pode fazer 4 acoes na sua vez:
• Cantar ponto - e preciso cantar ponto para que a pontuacao seja computada.
Projeto 23
• Cantar galo - e preciso cantar galo para ganhar os 50 pontos e poder jogar nova-
mente.
• Jogar - acao de escolher uma pedra e uma ponta valida e realizar a jogada na mesa.
• Passar - acao realizada quando nao se tem pedra possıvel de jogar.
Para tornar o jogo eletronico fiel a sua versao de mesa, definiu-se que o placar seguirıa
o modelo de marcacao com papel e caneta, em que cada traco representa 5 pontos.
4.1.1 Interface Grafica
Definidos os requisitos, partiu-se para o design da tela do jogo. Nela o jogador deve
poder visualizar as suas pedras, a mesa de jogo, a quantidade de pedras do seu parceiro e
adversarios, o placar e tambem poder realizar as acoes descritas anteriormente quando for
a sua vez. Uma ideia inicial de como seria a tela de jogo pode ser visto na figura 4.1.
Figura 4.1: Ideia inicial da tela de jogo
Devido a resolucao limitada, optou-se por utilizar o artifıcio adotado pela Sony Ericsson
em sua interface personalizada do Android em sua linha de celulares Xperia, na qual as
principais funcionalidades podem ser realizadas por meio de ıcones posicionados nos cantos
da tela, conforme e possıvel observar na figura 4.2.
Projeto 24
Figura 4.2: Printscreen da interface Sony Ericsson Xperia Android 1.6 e 2.1
A figura 4.3 mostra um esboco da tela do jogo, com o espaco reservado aos ıcones
das acoes e a forma como e realizada a jogada pelo jogador humano, na qual uma pedra
fantasma aparece no lugar onde e possıvel se jogar a pedra escolhida. Para facilitar a
escolha de uma pedra pelo jogador, foram adicionadas setas ao lado das suas pedras.
Figura 4.3: Esboco da tela de jogo
Nesta fase tambem foi elaborado o diagrama de fluxo de telas, que pode ser visto na
figura 4.4. Ele e importante para se ter uma visao global de como sera o jogo, descrevendo
a sequencia de transicao das telas.
Modelagem 25
Figura 4.4: Diagrama de fluxo de telas do jogo Domino Manaus
Com o jogo projetado, passou-se para a fase de modelagem.
4.2 Modelagem
A modelagem permite avaliar o projeto como um todo antes que se inicie a fase de
codificacao. Isso possibilita identificar e solucionar problemas antecipadamente, evitando
retrabalho durante programacao. E importante ressaltar que os diagramas apresentados a
seguir representam a versao final do jogo, pois foram alterados durante a fase de codificacao
para atender as necessidades que nao foram previstas.
O primeiro diagrama produzido foi o de Casos de Uso, que identifica os atores e suas
interacoes com o sistema. No jogo Domino Manaus o unico ator e o jogador humano, pois
e ele quem interage com o sistema realizando as acoes de pegar suas pedras, jogar, cantar
ponto, cantar galo e passar a vez, conforme e possıvel ver na figura 4.5.
Modelagem 26
Figura 4.5: Diagrama de Casos de Uso do jogo Domino Manaus
Em seguida, produziu-se o diagrama de sequencia, pois a partir dele seria possıvel
analisar o passo a passo do programa e determinar se estava correto. A figura 4.6 mostra
a versao final do diagrama de atividades do jogo Domino Manaus.
Modelagem 27
Figura 4.6: Diagrama de Atividades do jogo Domino Manaus
Modelagem 28
Conhecendo os atores, suas acoes e o passo a passo do jogo, foi possıvel elaborar o
diagrama de Classes, que pode ser visto na figura 4.7. Nele sao especificadas as classes,
seus atributos e metodos e como elas interagem entre si. As classes JogadorHumano e
JogadorMaquina sao especificacoes da classe Jogador e implementam seu metodo abstrato
joga de maneiras diferentes.
Modelagem 29
Figura 4.7: Diagrama de Classes do jogo Domino Manaus
Codi�cação 30
Com o projeto modelado, partiu-se a codificacao do jogo.
4.3 Codificacao
A arquitetura do jogo estava definida, mas ainda nao se sabia como implementa-lo para
o Android. O que se sabia era que para programar para Android utilizava-se a linguagem
Java, e por isso o primeiro passo foi criar as classes do jogo com seus atributos e metodos,
uma vez que para isso nao e necessario conhecimento das APIs do Android.
Segundo [Zechner2011], todo jogo necessita de um pequeno framework para facilitar
a comunicacao com a camada do sistema operacional, podendo ser dividido em modulos
como:
• Window management: responsavel por criar uma janela e gerenciar o fechamento,
pausa ou resumo da aplicacao no Android.
• Input: relativo ao modulo Window management, monitora os Inputs do usuario
(como eventos de toque na tela, pressionar de teclas e leitura do acelerometro).
• File I/O: permite acessar o disco para obter os recursos utilizados no jogo.
• Graphics: modulo responsavel por carregar e desenhar na tela a parte grafica do
jogo.
• Audio: modulo responsavel por carregar e tocar sons.
• Game framework: junta todos os anteriores e fornece uma base de facil uso para
codificar jogos.
Cada modulo desse e composto de uma ou mais interfaces. Cada interface tem pelo
menos uma implementacao concreta que implementa a semantica da interface baseada no
que a plataforma abaixo dela fornece, no caso o Android. Isso permite focar na semantica e
nao em detalhes de implementacao. Alem disso, mudancas na implementacao da interface
sao transparentes a camada superior. Um exemplo seria trocar a renderizacao 2D feita
pela CPU por OpenGL ES.
Codi�cação 31
O processo de criacao e implementacao do framework utilizado neste trabalho pode ser
acompanhado em [Zechner2011] e por este motivo nao sera detalhado neste capıtulo. No
framework define-se uma resolucao de tela nativa para a aplicacao e a imagem da aplicacao
e ampliada ou reduzida conforme a resolucao de tela do dispositivo onde ela sera executada.
O mesmo acontece com o sistema de coordenadas para os eventos de toque na tela. Isso faz
com que o desenvolvedor somente precise se preocupar com uma unica resolucao de tela, a
resolucao nativa da aplicacao.
No caso do jogo Domino Manaus, em que e preciso que todas a pedras da mesa possam
ser vistas, as pedras precisam ter uma resolucao pequena para que seja possıvel mostrar um
maior numero de pedras na mesa. Caso se optasse por uma resolucao nativa alta, quando
um dispositivo de baixa resolucao executasse o jogo, talvez nao fosse possıvel identificar a
pedra por ela ter sido reduzida, por isso optou-se pela resolucao nativa de 320x240 (menor
resolucao de tela de um dispositivo com Android).
O primeiro passo foi editar o arquivo AndroidManifest.xml para definir a orientacao
da tela para paisagem e esconder o teclado virtual, adicionando os atributos screenOrien-
tation=“landscape” e configChanges=“keyboard|keyboardHidden|orientation” ao elemento
<activity>, conforme e possıvel observar no Codigo 4.3.1.
1 <?xml version="1.0" encoding="utf-8"?>2 <manifest xmlns:android="http://schemas.android.com/apk/res/android"3 package="br.domino.manaus"4 android:versionCode="1"5 android:versionName="1.0">6 <application android:icon="@drawable/icon" android:label="Domino Manaus">7 <activity android:name=".DominoManausGame"8 android:label="Domino Manaus"9 android:configChanges="keyboard|keyboardHidden|orientation"
10 android:screenOrientation="landscape">11 <intent-filter>12 <action android:name="android.intent.action.MAIN" />13 <category android:name="android.intent.category.LAUNCHER" />14 </intent-filter>15 </activity>16
17 </application>18 <uses-permission android:name="android.permission.WAKE_LOCK" />19 <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>20 <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="3"/>21 </manifest>
Codigo 4.3.1: AndroidManifest.xml
Para permitir que a aplicacao nao deixe a tela desligar apos um perıodo de
inatividade e possa escrever em arquivos externos (salvar configuracoes, por ex-
Codi�cação 32
emplo), foram adicionados dois elementos <uses-permission> ao elemento <mani-
fest>, cujos atributos sao respectivamente “android.permission.WAKE LOCK” e “an-
droid.permission.WRITE EXTERNAL STORAGE”.
No elemento <activity> esta definida a classe da activity que sera chamada ao iniciar
a aplicacao, que nesse caso e a classe DominoManausGame.java vista no Codigo 4.3.2.
1 package br.domino.manaus;2
3 import br.domino.manaus.framework.Screen;4 import br.domino.manaus.framework.impl.AndroidGame;5
6 public class DominoManausGame extends AndroidGame {7 @Override8 public Screen getStartScreen() {9 return new LoadingScreen(this);
10 }11 }
Codigo 4.3.2: Classe DominoManausGame.java
A classe DominoManausGame herda da classe AndroidGame que e definida no frame-
work como uma classe que herda da classe Activity e implementa a classe Game do frame-
work. Ela cria uma instancia da classe LoadingScreen (Codigo 4.3.3), que e a classe re-
sponsavel por carregar para a classe Assets (Codigo 4.3.4) os recursos que serao utilizados
pelo jogo e setar a tela de Menu como tela inicial do jogo.
Codi�cação 33
1 package br.domino.manaus;2
3 import br.domino.manaus.framework.Game;4 import br.domino.manaus.framework.Graphics;5 import br.domino.manaus.framework.Screen;6 import br.domino.manaus.framework.Graphics.PixmapFormat;7
8 public class LoadingScreen extends Screen {9 public LoadingScreen(Game game) {
10 super(game);11 }12
13 @Override14 public void update(float deltaTime) {15 Graphics g = game.getGraphics();16
17 Assets.cantar = g.newPixmap("cantar.png", PixmapFormat.ARGB4444);18 Assets.galo = g.newPixmap("galo.png", PixmapFormat.ARGB4444);19 Assets.passar = g.newPixmap("passar.png", PixmapFormat.ARGB4444);20 Assets.placar = g.newPixmap("placar.png", PixmapFormat.ARGB4444);21 Assets.pontuacao = g.newPixmap("pontuacao.png", PixmapFormat.ARGB4444);22 Assets.pxxV = g.newPixmap("pxxv.png", PixmapFormat.ARGB4444);23 Assets.pppV = g.newPixmap("pppv.png", PixmapFormat.ARGB4444);24 Assets.pxxH = g.newPixmap("pxxh.png", PixmapFormat.ARGB4444);25 Assets.pppH = g.newPixmap("ppph.png", PixmapFormat.ARGB4444);26 Assets.direita = g.newPixmap("direita.png", PixmapFormat.ARGB4444);27 Assets.esquerda = g.newPixmap("esquerda.png", PixmapFormat.ARGB4444);28 Assets.dominoV = g.newPixmap("dominov.png", PixmapFormat.ARGB4444);29 Assets.dominoH = g.newPixmap("dominoh.png", PixmapFormat.ARGB4444);30 Assets.logo = g.newPixmap("logo.png", PixmapFormat.ARGB4444);31 Assets.confirm = g.newPixmap("confirm.png", PixmapFormat.ARGB4444);32 Assets.home = g.newPixmap("home.png", PixmapFormat.ARGB4444);33 Assets.help = g.newPixmap("help.png", PixmapFormat.ARGB4444);34 Assets.info = g.newPixmap("info.png", PixmapFormat.ARGB4444);35 Assets.play = g.newPixmap("play.png", PixmapFormat.ARGB4444);36 Assets.config = g.newPixmap("config.png", PixmapFormat.ARGB4444);37 Assets.fundo = g.newPixmap("fundo.png", PixmapFormat.RGB565);38
39 game.setScreen(new MainMenuScreen(game));40 }41
42 @Override43 public void present(float deltaTime) {44
45 }46
47 @Override48 public void pause() {49
50 }51
52 @Override53 public void resume() {54
55 }56
57 @Override58 public void dispose() {59
60 }61 }
Codigo 4.3.3: Classe LoadingScreen.java
Codi�cação 34
1 package br.domino.manaus;2
3 import br.domino.manaus.framework.Pixmap;4
5 public class Assets {6 public static Pixmap cantar;7 public static Pixmap galo;8 public static Pixmap passar;9 public static Pixmap placar;
10 public static Pixmap pontuacao;11 public static Pixmap pxxV;12 public static Pixmap pxxH;13 public static Pixmap pppV;14 public static Pixmap pppH;15 public static Pixmap direita;16 public static Pixmap esquerda;17 public static Pixmap dominoV;18 public static Pixmap dominoH;19 public static Pixmap fundo;20 public static Pixmap logo;21 public static Pixmap confirm;22 public static Pixmap home;23 public static Pixmap help;24 public static Pixmap info;25 public static Pixmap play;26 public static Pixmap config;27 }
Codigo 4.3.4: Classe Assets.java
A tela de menu e descrita pela classe MainMenuScreen (Codigo 4.3.5) e, assim como
todas as telas do jogo, possui dois metodos principais, o metodo update, que verifica eventos
de toque na tela e o metodo present que desenha a tela. Ambos os metodos sao chamados
automaticamente pelo framework, repetidas vezes, enquanto a tela estiver sendo mostrada.
Codi�cação 35
1 package br.domino.manaus;2
3 import java.util.List;4
5 import android.graphics.Color;6 import br.domino.manaus.framework.Game;7 import br.domino.manaus.framework.Graphics;8 import br.domino.manaus.framework.Input.TouchEvent;9 import br.domino.manaus.framework.Screen;
10
11 public class MainMenuScreen extends Screen {12 public MainMenuScreen(Game game) {13 super(game);14 }15
16 @Override17 public void update(float deltaTime) {18 List<TouchEvent> touchEvents = game.getInput().getTouchEvents();19 game.getInput().getKeyEvents();20
21 int len = touchEvents.size();22 for (int i = 0; i < len; i++) {23 TouchEvent event = touchEvents.get(i);24 if (event.type == TouchEvent.TOUCH_UP) {25 if (inBounds(event, 272, 0, 48, 48)) { // play26 game.setScreen(new GameScreen(game));27 return;28 }29 if (inBounds(event, 272, 192, 48, 48)) { // config30 game.setScreen(new ConfigScreen(game));31 return;32 }33 if (inBounds(event, 0, 192, 48, 48)) { // help34 game.setScreen(new HelpScreen(game));35 return;36 }37 if (inBounds(event, 0, 0, 48, 48)) { // info38 game.setScreen(new InfoScreen(game));39 return;40 }41 }42 }43 }44
45 private boolean inBounds(TouchEvent event, int x, int y, int width,46 int height) {47 if (event.x > x && event.x < x + width - 1 && event.y > y48 && event.y < y + height - 1)49 return true;50 else51 return false;52 }53
54 @Override55 public void present(float deltaTime) {56 Graphics g = game.getGraphics();57
58 // pinta o fundo59 g.clear(Color.rgb(35, 175, 75));60
61 // desenha o logo62 g.drawPixmap(Assets.logo, (g.getWidth() - Assets.logo.getWidth()) / 2,63 (g.getHeight() - Assets.logo.getHeight()) / 2);64
65 // desenha os icones66 g.drawPixmap(Assets.info, 0, 0, 0, 0, 48, 48);67 g.drawPixmap(Assets.play, g.getWidth() - Assets.play.getHeight(), 0, 0,68 0, 48, 48);69 g.drawPixmap(Assets.help, 0, g.getHeight() - Assets.help.getHeight(),70 0, 0, 48, 48);71 g.drawPixmap(Assets.config, g.getWidth() - Assets.config.getHeight(),72 g.getHeight() - Assets.config.getHeight(), 0, 0, 48, 48);73
74 }75
Codigo 4.3.5: Classe MainMenuScreen.java
Codi�cação 36
A partir da tela de menu e possıvel iniciar um novo jogo ou abrir as telas de Ajuda,
Configuracoes ou Informacoes. Essas telas seguem o mesmo padrao da tela de menu, e seus
respectivos codigos podem ser encontrados no Apendice.
A classe GameScreen e responsavel pela a tela de jogo, fazendo a interface com o
usuario e controlando o jogo. Por isso seu codigo e bastante extenso e somente as partes
mais importantes dele serao mostradas e comentadas no decorrer deste capıtulo. O codigo
na ıntegra pode ser visto no Apendice.
Codi�cação 37
1 package br.domino.manaus;2
3 import java.util.ArrayList;4 import java.util.List;5
6 import android.graphics.Color;7 import android.graphics.Paint;8 import android.graphics.Rect;9 import android.graphics.Typeface;
10
11 import br.domino.manaus.framework.Game;12 import br.domino.manaus.framework.Graphics;13 import br.domino.manaus.framework.Input.TouchEvent;14 import br.domino.manaus.framework.Pixmap;15 import br.domino.manaus.framework.Screen;16
17 public class GameScreen extends Screen {18 enum GameState {19 Saida,20 Partida,21 Fechado,22 Garagem,23 Fim,24 Pausa25 }26
27 static int espaco = 2; // pixels28 static int margem = 3; // pixels29 static int pedraVertH = Assets.pxxV.getHeight();30 static int pedraVertW = Assets.pxxV.getWidth();31 static int pedraHorzH = pedraVertW;32 static int pedraHorzW = pedraVertH;33 static int maoW = 7*pedraVertW + 6*espaco;;34 static int maoH = pedraVertH;35 static int maoX = 48 + (((320 - (112 + 48)) / 2) - (maoW / 2));;36 static int maoY = 240 - (margem + pedraVertH);;37 static int direitaH = Assets.direita.getHeight();38 static int direitaW = Assets.direita.getWidth();39 static int direitaX = (maoX + maoW);40 static int direitaY = 240 - (margem + direitaH);41 static int esquerdaH = Assets.esquerda.getHeight();42 static int esquerdaW = Assets.esquerda.getWidth();43 static int esquerdaX = maoX - esquerdaW;44 static int esquerdaY = direitaY;45 GameState state = GameState.Saida;46 Jogo jogo;47 public ArrayList<Jogada> jogadas = new ArrayList<Jogada>(4);48 Paint paint = new Paint();49 Typeface font = Typeface.SANS_SERIF;50 Rect bounds = new Rect();51 int iPedraEscolhida = -1;52 int iPlacar = 0;53 int iPlacarMax = 0;54
55 public GameScreen(Game game) {56 super(game);57 jogo = new Jogo();58 }59
Codigo 4.3.6: Atributos e Construtor da Classe GameScreen.java
No trecho de Codigo 4.3.6 e possıvel ver os atributos e o construtor da classe, onde e
criado uma instancia da classe Jogo, responsavel pelo jogo em si. O construtor da classe
Codi�cação 38
Jogo cria tres jogadores maquina e um jogador humano. Para controlar os estados do jogo,
utilizou-se um atributo do tipo GameState, que e uma enumeracao de estados possıveis do
jogo. Ele e utilizado no metodo update (Codigo 4.3.7) para determinar os eventos de toque
na tela esperados em cada estado.
60 @Override61 public void update(float deltaTime) {62 List<TouchEvent> touchEvents = game.getInput().getTouchEvents();63 game.getInput().getKeyEvents();64
65 switch (state) {66 case Saida:67 updateSaida(touchEvents);68 break;69 case Partida:70 updatePartida(touchEvents, deltaTime);71 break;72 case Pausa:73 updatePausa(touchEvents);74 break;75 case Fechado:76 updateFechado(touchEvents);77 break;78 case Garagem:79 updateGaragem(touchEvents);80 break;81 case Fim:82 updateFim(touchEvents);83 break;84 }85 }
Codigo 4.3.7: Metodo de update da Classe GameScreen.java
No metodo present (Codigo 4.3.8), a tela do jogo e desenhada conforme o estado.
322 @Override323 public void present(float deltaTime) {324
325 if(state == GameState.Saida)326 desenhaSaida();327 if(state == GameState.Partida)328 desenhaPartida();329 if(state == GameState.Pausa)330 desenhaPausa();331 if(state == GameState.Fechado)332 desenhaFechado();333 if(state == GameState.Garagem)334 desenhaGaragem();335 if(state == GameState.Fim)336 desenhaFim();337
338 }339
Codigo 4.3.8: Metodo present da Classe GameScreen.java
Codi�cação 39
O jogo inicia no estado Saida e aguarda que o usuario toque na tela. Ao tocar na tela o
estado do jogo e alterado para Partida e e chamado o metodo iniciaPartida da classe Jogo,
como pode ser visto no Codigo 4.3.9.
87 private void updateSaida(List<TouchEvent> touchEvents) {88 if(touchEvents.size() > 0) {89 state = GameState.Partida;90 jogo.iniciaPartida();91 }92 }93
Codigo 4.3.9: Metodo updateSaida da Classe GameScreen.java
O metodo iniciaPartida da classe Jogo cria a mesa e mistura as pedras evitando que
os jogadores possam pegar cinco carrocas (na versao de mesa as pedras sao misturadas
novamente). Cada jogador puxa suas 7 pedras para formar a sua mao e e chamado o
metodo saida.
117 public void saida() {118 if ((numPartida == 1) || (jogoFechado)) { // encontra jogador com a sena119 while (!jogadorVez.temPedra(6,6))120 proximoJogador();121 jogadorVez.jogaveis.add(new Pedra(6,6));122 }123 else124 setaJogaveis();125 novaJogada = true;126 }
Codigo 4.3.10: Metodo saida da Classe Jogo.java
No metodo saida (Codigo 4.3.10) e verificado se e a primeira partida ou a partida
anterior terminou com jogo fechado. Nesse caso o jogador que possui a carroca de sena
e localizado para iniciar a partida. Perceba que o atributo novaJogada e setado como
verdadeiro. Na proxima chamada do metodo update da classe GameScreen, o estado do
jogo sera Partida e sera chamado o metodo updatePartida, que verifica analiza os eventos
de toque na tela para esse estado e atualiza o jogo chamando o metodo update da classe
Jogo.
Codi�cação 40
128 public void update(float deltaTime) {129 int iDupla, iDuplaAdv;130
131 if (fimPartida)132 return;133
134 // desenha a partida e depois desenha a jogada135 if (novaJogada) { // diferenca perceptivel na saida do jogador maquina devido ao delay136 novaJogada = false;137 jogadorVez.joga(mesa);138 }139
140 if (jogadorVez.confirmaPasse) { // confirma passe141 if (!jogadorAntPassou) { // nao eh passe na costa142 iDuplaAdv = (getiVez()+1) % 2;143 pontuacao[iDuplaAdv] += 20;144 }145 jogadorAntPassou = true;146 jogadorVez.confirmaPasse = false;147
148 proximoJogador();149 setaJogaveis();150 novaJogada = true;151 }152 else { // nao passou153 if (jogadorVez.confirmaJogada) { // confirma jogada154 // se for saida, as pontas da mesa estao vazias, seta o jogador saido155 if ((mesa.pontas.get(0).isEmpty()) && (mesa.pontas.get(1).isEmpty()) &&156 (mesa.pontas.get(2).isEmpty()) && (mesa.pontas.get(3).isEmpty()))157 mesa.iJogadorSaido = getiVez();158 jogadorVez.confirmaJogada = false;159 jogadorAntPassou = false;160 iDupla = getiVez() % 2;161 if (jogadorVez.cantouPonto) {162 pontuacao[iDupla] += mesa.contaPontos();163 if ((jogadorVez.bateu()) && (mesa.ultimaPedra.ehCarroca()))164 pontuacao[iDupla] += 20;165 jogadorVez.cantouPonto = false;166 }167 if (jogadorVez.bateu()) {168 fimPartida = true;169 numPartida++;170 jogoFechado = false;171 contaGaragem();172 }173 else {174 if (fechado()) {175 fimPartida = true;176 numPartida++;177 jogoFechado = true;178 contaMaos();179 }180 }181 if (jogadorVez.cantouGalo) {182 jogadorVez.cantouGalo = false; // desmarca botao de galo183 if ((!fimPartida) && (ehGalo())) {184 pontuacao[iDupla] += 50;185 ehGalo = true;186 }187 else { // galo gay188 iDuplaAdv = (getiVez()+1) % 2;189 pontuacao[iDuplaAdv] += 50;190 ehGalo = false;191 }192 }193 if (!fimPartida) {194 if (!ehGalo) // se nao for galo a vez eh do proximo195 proximoJogador();196 ehGalo = false;197 setaJogaveis();198 novaJogada = true;199 }200 }201 }202
Codigo 4.3.11: Metodo update da Classe Jogo.java
Codi�cação 41
O metodo update da classe Jogo (Codigo 4.3.11) e o laco principal do jogo. Nele e
verificado se e a novaJogada e em caso afirmativo e chamado o metodo joga do jogadorVez.
Caso o jogador da vez confirme seu passe, a vez e passada ao proximo jogador, conforme a
regra do passe, caso contrario, e verificado se o jogador da vez confirmou a jogada. Nesse
caso, e checado se e a primeira jogada da mesa, para identificar o jogador saıdo. E tambem
tratado se o jogador cantou ponto. Em caso de batida, e contada a garagem, caso contrario,
e verificado se o jogo fechou, e se for o caso e somada as maos. Os dois ultimos setam a
fimPartida como verdadeiro, se forem verdadeiros. Por ultimo, e checado se o jogador
cantou galo e se e um galo valido.
Ao retornar ao metodo update da classe GameScreen, e verificado se e fim de partida
e se for o caso o estado e alterado para Garagem em caso de batida ou para Fechado em
caso de jogo fechado.
Na proxima chamada ao metodo present da classe GameScreen a tela sera desenhada de
acordo com o estado do jogo. Se o estado for Partida e chamado o metodo desenhaPartida.
356 private void desenhaPartida() {357 Graphics g = game.getGraphics();358 desenhaFundo(g);359 desenhaBotoes(g);360 desenhaPlacar(g);361 desenhaMaoOutros(g);362 desenhaMaoJogador(g);363 desenhaMesaCentralizada(g);364 // vez do jogador humano365 if (jogo.getiVez() == 2) {366 desenhaSetas(g);367 desenhaJogadas(g);368 }369 }
Codigo 4.3.12: Metodo desenhaPartida da Classe GameScreen.java
Nesse metodo (Codigo 4.3.12) sao desenhados o fundo, os botoes (habilitados quando
e a vez do jogador e desabilitados quando nao), o placar, as maos dos outros jogadores
(pedra com a face virada para baixo), a mao do jogador, a mesa, e se for a vez do jogador
as setas para facilitar a escolha das pedras e as jogadas caso seja possıvel jogar com a pedra
selecionada.
Caso o estado do jogo seja Garagem, e chamado o metodo desenhaGaragem, que de-
senha as pedras e o valor da garagem, alem do placar e o icone de continuar o jogo no canto
superior direito. No caso do estado ser Fechado, o metodo desenhaFechado e chamado e
Codi�cação 42
desenha as pedras restantes de ambas as duplas e o valor da soma das maos da dupla, alem
do ıcone de continuar o jogo no canto superior direito.
Se na proxima chamada ao metodo update da classe GameScreen o estado do jogo
for Fechado ou Garagem, serao chamados os metodos updateFechado (Codigo 4.3.13) e
updateGaragem (Codigo 4.3.14) respectivamente para tratar dos eventos de toque na tela
para esses estados.
231 private void updateFechado(List<TouchEvent> touchEvents) {232 if(touchEvents.size() > 0) {233 int len = touchEvents.size();234 for(int i = 0; i < len; i++) {235 TouchEvent event = touchEvents.get(i);236 if(event.type == TouchEvent.TOUCH_UP) {237 if ((event.x > 320-48) && (event.y < 48)) {238 jogo.processaJogoFechado();239 if (jogo.terminou())240 state = GameState.Fim;241 else { // comeca nova partida242 state = GameState.Partida;243 jogo.iniciaPartida();244 }245 }246 // avanca placar247 if ((event.x > (320 - (112 / 2))) && (event.y > (240 - 48))) {248 iPlacar++;249 if (iPlacar > iPlacarMax)250 iPlacar = iPlacarMax;251 }252 // retrocede placar253 if ((event.x > (320 - 112)) && (event.x < (320 - (112 / 2))) && (event.y > (240 - 48))) {254 iPlacar--;255 if (iPlacar < 0)256 iPlacar = 0;257 }258 }259 }260 }261 }
Codigo 4.3.13: Metodo updateFechado da Classe GameScreen.java
Codi�cação 43
263 private void updateGaragem(List<TouchEvent> touchEvents) {264 if(touchEvents.size() > 0) {265 int len = touchEvents.size();266 for(int i = 0; i < len; i++) {267 TouchEvent event = touchEvents.get(i);268 if(event.type == TouchEvent.TOUCH_UP) {269 if ((event.x > 320-48) && (event.y < 48)) {270 jogo.processaGaragem();271 if (jogo.terminou())272 state = GameState.Fim;273 else { // comeca nova partida274 state = GameState.Partida;275 jogo.iniciaPartida();276 }277 }278 // avanca placar279 if ((event.x > (320 - (112 / 2))) && (event.y > (240 - 48))) {280 iPlacar++;281 if (iPlacar > iPlacarMax)282 iPlacar = iPlacarMax;283 }284 // retrocede placar285 if ((event.x > (320 - 112)) && (event.x < (320 - (112 / 2))) && (event.y > (240 - 48))) {286 iPlacar--;287 if (iPlacar < 0)288 iPlacar = 0;289 }290 }291 }292 }293 }
Codigo 4.3.14: Metodo updateGaragem da Classe GameScreen.java
Em ambos os metodos, e possıvel paginar o placar, pois este somente exibe no maximo
200 pontos de cada vez. Apos clicar no ıcone no canto superior direito para seguir o jogo,
e processada a garagem ou a contagem de maos e verificado se o jogo terminou, em caso
afirmativo e mudado o estado para Fim, e em caso negativo o estado e mudado para Partida
e o metodo iniciaPartida da classe Jogo e chamado novamente.
Quando o estado do jogo e Fim, o metodo present da classe GameScreen chama o
metodo desenhaFim que desenha a dupla vencedora, a pontuacao final, o placar do jogo e
o icone de voltar a tela inicial do jogo no canto superior esquerdo.
Imagens do jogo 44
4.4 Imagens do jogo
Figura 4.8: Tela de menu principal e tela de inıcio de jogo (saıda)
Figura 4.9: Vez do jogador humano e jogada inicial da 1a partida
Imagens do jogo 45
Figura 4.10: Vez do jogador maquina e tela de jogo fechado
Figura 4.11: Recomeco de jogo fechado pela dupla adversaria e jogada no bucho
Figura 4.12: Jogada de carroca marcando 5 pontos
Imagens do jogo 46
Figura 4.13: Tela de garagem e nova partida iniciada pelo jogador que bateu
Figura 4.14: Jogador humano sem jogada (so pode passar) e tela de pause
Imagens do jogo 47
Figura 4.15: Tela de fim de jogo e paginacao do placar
Figura 4.16: Tela de creditos
Capıtulo 5
Conclusao
Neste trabalho foi desenvolvido um jogo para Android, sendo possıvel concluir que o An-
droid e uma plataforma completa, com curva de aprendizado medio e com a vantagem de
ser aberto e multiplataforma.
Programar jogos nao e um ciencia exata e pode ser feito de diversas maneiras. A
maneira adotada neste trabalho, definindo os requisitos e modelando o jogo antes de iniciar
a codificacao, permitiram codificar de maneira simples um jogo de diversas regras.
A utilizacao de um framework como interface entre o jogo e a arquitetura do Android,
possibilitou o foco na semantica do jogo e nao em detalhes de implementacao.
Para que a mesa de jogo estivesse sempre visıvel em uma tela de resolucao limitada
como a adotada (para aumentar a compatibilidade) seria necessario, alem de centralizar a
mesa, a quebra das pontas que atingissem seu limite. Devido a complexidade desta solucao,
nao foi possıvel implementa-la durante o desenvolvimento desta monografia.
5.1 Trabalhos futuros
Desenvolver um novo metodo de desenhar a mesa que alem de centralizar o jogo faca a
quebra da ponta da mesa caso ela atinja o limite da mesma.
Poderia ser desenvolvido um modo para multiplos jogadores, criando uma classe Jo-
gadorRemoto e deixando ela transparente para o jogo.
Seria interessante desenvolver uma inteligencia artificial mais avancada, que analizasse
o jogo na mesa, as jogadas do parceiro, os passes dos adversarios e as pedras na mao antes
de realizar a jogada.
Referencias Bibliograficas
[Crıtica2011] Crıtica, A. (2011). Regulamento geral - 4a copa a crıtica de domino.
[Farago2011] Farago, P. (2011). Apple and google capture u.s. video game market share in
2010. http://blog.flurry.com/bid/60307/Apple-and-Google-Capture-U-S-Video-Game-
Market-Share-in-2010.
[Kelley1999] Kelley, J. (1999). Great Book of Domino Games. Sterling.
[Lecheta] Lecheta, R. Google ANDROID - Aprenda a criar aplicoes para dispositivos
moveis com o Android SDK. Novatec.
[Pereira and Silva] Pereira, L. and Silva, M. Android para desenvolvedores. Brasport.
[Zechner2011] Zechner, M. (2011). Beginning Android Games. Apress Series. Apress.
Capıtulo 6
Apendice
Os codigos-fonte desta monografia encontram-se no CD que acompanha a mesma.