Marcos Vincius Pereira Marques Pedro Rauiz Estigarribia Gestal Reginaldo Camargo Ribeiro

Engenharia e desenvolvimento de um software de entretenimento

Londrina 2012

Marcos Vincius Pereira Marques Pedro Rauiz Estigarribia Gestal Reginaldo Camargo Ribeiro

Engenharia e desenvolvimento de um software de entretenimento

Trabalho apresentado disciplina Projeto Interdisciplinar, prof. Simone Sawasaki Tanaka

Londrina 2012

Sumrio
Resumo:................................................................................................................................................... 4 1. Introduo ........................................................................................................................................... 5 2. Fundamentao Terica ...................................................................................................................... 6 2.1. Teoria dos Jogos e Game Engine ...................................................................................................... 6 2.2. Orientao a objetos, UML e Diagramas UML ................................................................................. 6 2.3. Threads ............................................................................................................................................. 7 2.4. Manipulao de imagens ................................................................................................................. 8 2.5. Criptografia em jogos ....................................................................................................................... 9 2.5.1. Conceitos gerais sobre a criptografia ............................................................................................ 9 2.5.2. Aplicao em jogos........................................................................................................................ 9 3. Desenvolvimento: ............................................................................................................................. 10 3.1 Engine .............................................................................................................................................. 10 3.1.1 Gerenciador de Monitor (Display Manager) ................................................................................ 10 3.1.2 Game Engine ou Game Core ........................................................................................................ 13 3.1.3 Game Actions e Gerenciador de Entradas ................................................................................... 15 4. Concluso .......................................................................................................................................... 16 5. Referncias ........................................................................................................................................ 17

Resumo:
Engenharia e desenvolvimento de um software de entretenimento e estudo de animao 2D e teoria de jogos tem como objetivo a explorao do tema segundo o que ensinado nas grades curriculares da instituio para promover aprendizado e experincia no assunto. Para simular as principais fases do desenvolvimento de jogos 2D foram usadas varias tcnicas e ferramentas como a Unified Modeling Language (UML) para modelar as classes e o comportamento do sistema, tambm foi necessrio aprender tcnicas como threads, criptografia, animao 2D, manipulao de imagens, entre outros, alm de fazer uso de uma engine de jogos 2D para auxiliar no desenvolvimento do jogo e uma breve discusso sobre as regras e enredo do jogo. Durante o processo de criao, programao e discusses que houveram para desenvolver o trabalho, foi um perodo de grande aprendizado sobre os assuntos que so de comum interesse pelos estudantes do curso.

Palavras-chave: jogos, animao 2D, programao, engenharia de software.

1. Introduo
Este artigo tem como objetivo explicar e aplicar o maior nmero de funcionalidades possveis, dentro do tema Criao e Desenvolvimento de Jogos 2D em Java. Isso se traduz em: explorar a rea que envolve no somente a codificao e desenvolvimento prtico de um jogo, mas tambm analisa todo o embasamento terico por trs deste desenvolvimento prtico. Falaremos, ao longo deste artigo, sobre diagramas de caso de uso e diagramas de classes; ambos so recursos da Unified Modeling Language (UML). Passaremos, tambm, por programao grfica, animao de imagens 2D e Programao Orientada a Eventos. Entenderemos o conceito de uma Engine de Jogos, suas capacidades e funes. Funes, estas, de extrema importncia para o desenvolvimento de um jogo. Uma grande parte deste artigo ter como objetivo exemplificar, atravs de trechos de cdigos de um jogo (autoria prpria), as funcionalidades e recursos da linguagem Java para a codificao de Jogos 2D. Dentre estes se encontram: Listeners (Action; Key; Mouse), JComponents e suas aplicaes, manipulao de imagens, e aplicaes para controle de framerates. O conceito de framerates engloba toda a rea de passagem de tempo e resposta do sistema aos comandos do jogador at a transmisso destes dados de volta ao jogador por intermdio da interface grfica. Durante o desenvolvimento do jogo a equipe desenvolvedora utilizou de ferramentas como NetBeans (IDE), Photofiltre (manipulao de imagens), Microsoft Visio 2007 (desenvolvimento de diagramas UML), <Notepad++> (exemplificao de cdigo).

2. Fundamentao Terica
2.1. Teoria dos Jogos e Game Engine
Primeiramente devemos explorar um campo de pouco interesse para a maioria, porm necessrio para o desenvolvimento de um jogo, chamado de Teoria dos Jogos. Esta teoria ser vista somente nesta seco do artigo. Facilitaremos o entendimento desta teoria exemplificando

grosseiramente a mesma: Um jogo dever proporcionar um nvel proporcional de dificuldade e recompensa. Isto significa, por exemplo, que um determinado marco no jogo (chefes, plataformas de avano, etc.) dever dar ao jogador um senso de recompensa proporcional ao desafio apresentado pelo marco. Este jogador deve ser "recompensado" por suas decies corretas, tomadas com base em suas escolhas. Esta teoria influencia em decises ao longo do design de um jogo e, por isso, resolvemos dedicar este pargrafo a mesma. Tambm pode ser aplicada em campos fora da computao como: Economia e ADM dentre outros. Tal teoria pode, tambm, ajudar ao jogador a tomar decises estratgicas dentro do jogo, porm este aspecto no ser tratado aqui. Determinado o conceito que mais influencia no design, temos agora que determinar mais um conceito genrico sem o qual no seria possvel, de modo simples, a criao de um jogo. Este conceito denominado de Game Engine. Existem vrias Engines no mercado; Source, Unity, Frostbite, estas, todas, para ambientes 3D. Existem tambm engines para ambientes 2D (Foco deste trabalho). Engines so os motores por traz dos jogos, como a traduo indica. Considerando uma engine para o desenvolvimento de jogos 2D, ela contm uma sequencia de funcionalidades(similar uma biblioteca) para o desenvolvimento geral do jogo: game loop, tratamento de imagens (animao), contagem de tempo, e o importante conceito de game object. Uma engine de desenvolvimento 3D , ao contrario da maioria das 2Ds, um framework. Manipula-se os objetos diretamente na tela e elementos como cmeras, luzes, texturas so aplicados aos objetos com o auxilio destes frameworks. Tambm necessrio mencionar que estas engines contm fsica aplicada em cima de seus objetos.

2.2. Orientao a objetos, UML e Diagramas UML

O conceito principal da orientao a objeto o prprio objeto. Um objeto uma ocorrncia especifica de uma classe uma forma de representar essa ocorrncia. Esse mesmo objeto (na funo

de representar a ocorrncia da classe) serve para abstrair alguma coisa de algum problema e tem a capacidade de comunicar-se entre outros objetos a fim de passar informaes relevantes. A UML um padro para modelagem de sistemas. Durante todo o processo da construo do software usaremos UML, seja para visualizar os requisitos, modelar as classes, definir as sequencias de implementao e o ambiente onde o sistema ser executado. com certeza uma ferramenta para tomarmos como base o processo de criao do software. O processo simples, usando a UML ns modelamos todo o contedo do jogo e suas classes. Desenvolvemos diagramas de caso de uso e de classes, para poder explicar melhor nosso software e ajudar na hora do desenvolvimento. como ver todo o processo por cima, quando alguns insistem em ver por baixo s o que esta na sua frente e continuar construindo algo que pode facilmente sair do controle.

2.3. Threads
Cada programa executado dentro de um processo que armazena todas as informaes de quantidade mxima de arquivos que podem ser abertos simultaneamente, quantidade de threads ou subprocessos que podem ser criadas, prioridade de execuo, entre outras. Thread uma linha ou um trecho de cdigo que pode ser executado concorrentemente dentro de um processo. Em sistemas multithread os threads podem ser executados simultaneamente garantindo alto desempenho e agilidade na execuo dos programas. Cada thread iniciado com um Thread Control Block ou bloco de controle de thread (TCB) que possui as informaes de endereamento, quantidade de arquivos abertos simultaneamente, capacidade do buffer (Memria auxiliar temporria) de E/S(Entrada e sada), seu identificador, entre outros. Sempre que o sistema operacional carrega um thread ela colocada em estado de criao, ento ele cria o PCB e aguarda para que os recursos exigidos pelo thread estejam disponveis colocando o thread em estado de espera. Assim que os recursos esto disponveis o sistema operacional coloca o thread em estado de pronto esperando apenas o trmino ou ento a concluso da fatia do tempo do thread que est usando o processador. Assim que liberado o thread passa para o estado de execuo at ser interrompido pelo sistema operacional, por outro thread ou por si prprio (trmino das instrues ou necessidade de informaes de outro thread). Caso o thread tenha se encerrado ele passa para o estado de trmino e ento removido da memria bem como seu TCB.

Em um software de entretenimento mais especificamente um jogo, necessrio trabalhar com threads, pois os eventos gerados por estes so em grande parte grficos e exige trocas de quadros de imagem muitas vezes em um determinado padro de tempo (geralmente um quadro por segundo). Para realizar estas trocas dando a impresso de continuidade da cena com em uma animao preciso trabalhar com trs threads no mnimo, sendo a primeira para desenhar o quadro, a segunda para carregar uma imagem que ser desenhada no prximo quadro de animao e o ltimo a thread principal do programa.

2.4. Manipulao de imagens

Para programar a animao dos jogos, so necessrias, primeiramente, uma engine de jogo 2D, para programar e organizar toda a animao e as regras do jogo. Ela , em geral, especializada em manipulao de imagens especificas para jogos 2D, e tem como objetivo acelerar o desenvolvimento do jogo, pois ser necessrio apenas programar o necessrio e se concentrar na produo do jogo em si. Ainda pensando na criao das animaes usando a engine de jogos, sero necessrias agora as imagens, elas servem para formar a animao do personagem, o cenrio do jogo, eventos, ou itens da jogabilidade, entre elas existem os Sprites, que so objetos grficos bi ou tridimensionais que se movem na tela em forma de animao, so usados para fazer a animao de personagens ou de efeitos especiais, e ainda Tiles que ideia de diviso de uma imagem ou ainda inmeras imagens que formam a superfcie do mundo onde o personagem andar. Animao ainda envolve vetores. Na diviso convencional das telas dos computadores, divididas em forma de coordenadas em que um nmero X e Y de pixels na tela, uma forma organizada de dividir a tela e trabalhar em cima dela. Ao criar uma varivel numrica bidimensional que comporta os respectivos nmeros X e Y destinados posicionar algum objeto na tela conforme as coordenadas, pode-se mover objetos de pixel em pixel gerando uma animao. A animao se faz usando uma tcnica de iluso, em que devido a rpida troca de imagens (estrategicamente posicionadas), somada a disposio da imagem na coordenada da tela formam a iluso de que um personagem ou objeto grfico qualquer esteja se movendo.

2.5. Criptografia em jogos 2.5.1. Conceitos gerais sobre a criptografia

O termo Criptografia surgiu da fuso das palavras gregas "Krypts" e "grphein", que significam respectivamente, escondido e escrito, criptografia portanto significa escrita escondida. A criptografia uma tcnica empregada sobre um conjunto de informaes a fim de ocult-la (criptograf-la) provisoriamente, para isto utilizado uma chave que serve tanto para ocultar, quanto para revelar(descriptografar). Uma chave de criptografia um conjunto de informaes pertencentes ao mesmo tipo da informao a ser criptografada, pois cada unidade atmica ou um subconjunto desta chave ser comparado a uma unidade atmica ou um subconjunto da informao. Utilizando uma chave e baseando-se em sequncias algortmicas, as informaes atuais do conjunto, em geral a mais bsica ou atmica (letra, dgito, entre outros), so substitudas por outras tornando a informao ilegvel. Para recuperar a informao empregado o mesmo algoritmo de maneira reversa utilizando a mesma chave para substituir as informaes atuais por novas informaes, caso a chave esteja correta estas informaes se equivalero s originais.

2.5.2. Aplicao em jogos

A criptografia em jogos til tanto para proteger as informaes do usurio, jogador, quanto do sistema. Um sistema com informaes mal protegidas pode permitir que os usurios malintencionados ou at mesmo leigos mudem estas informaes, corrompendo ou atualizando dados com informaes que iro lev-lo a benefcios dentro deste sistema, benefcios estes que podero permitir aumentar ou reduzir os prprios privilgios ou os privilgios de outro usurio. Para este jogo foi utilizado um algoritmo de criptografia por chave simples e arquivos texto comum para manipular as informaes do sistema. Inicialmente as informaes do usurio so todas criptografadas e ento salvas em um buffer(local para armazenamento temporrio de dados). Deste buffer as informaes so enviadas para os mecanismos de I/O (Entrada e sada) do sistema operacional para enfim serem salvas em um arquivo texto. Em caso de recuperao destas informaes, ser enviado uma mensagem ao sistema operacional para ler o arquivo principal de captura dos dados, pois pode haver mais de um arquivo

de jogador, com estas informaes pode-se ir diretamente ao arquivo do jogador atual, descriptografando e carregando as informaes na memria para utilizao. O mesmo processo ser vlido para arquivos de configurao do sistema, contendo informaes de personalizao feitas pelo usurio e feitas pelo prprio sistema, tais como configurao da tela (resoluo, aparncia, entre outros), atalhos do teclado, ou ainda configuraes nativas do sistema.

3. Desenvolvimento:
Veremos agora as aplicaes dos conceitos de Engine, Animao e Criptografia na linguagem Java.

3.1 Engine

Uma engine uma grande abstrao de elementos encontrados em todos os jogos. Nesta seo veremos as seguintes classes Java: Game Action, Gerenciador de Monitor (Display Manager), Gerenciador de Entradas (Input Manager) e, por fim, a Engine em si (classe Game Engine). Vislumbraremos, primeiramente, a classe Display Manager; esta responsvel pelo controle de todo ambiente grfico do sistema.

3.1.1 Gerenciador de Monitor (Display Manager)

Como dito, esta classe responsvel por manter o contexto grfico da engine funcionando. A resoluo do jogo decidida atrves do uso desta classe. Esta abstrao faz uso das classes GraphicsEnvironment e GraphicsDevice da API do Java para controlar os recursos grficos do sistema.
public class DisplayManager {... private GraphicsDevice graphDevice ; // Cria um novo Controlador de Monitor public DisplayManager() { GraphicsEnvironment gEnvironment = GraphicsEnvironment. getLocalGraphicsEnvironment() ; // Pega o ambiente grafico do sistema this.graphDevice = gEnvironment.getDefaultScreenDevice() ; // Pega do ambiente do sistema o monitor } ... }

Antes de analisarmos os outros elementos desta classe, devemos entender seu nico atributo: um GraphicsDevice. Esta classe, assim como o nome indica, um aparelho grfico, isto , o aparelho onde as imagens e interfaces grficas so desenhadas. De modo sucinto, a abstrao de um monitor. Dito isto, podemos verificar que seu construtor recebe, do ambiente grfico do sistema, o monitor localizado nele.
// Cria uma janela e a coloca em modo Tela Cheia em Resoluo. Utiliza um BufferStrategy(Swap) com 2 Buffers. Mostra-se sempre um dos dois enquanto o outro carrega. So alternados enquanto o outro carrega.

public void setModoTelaCheia(DisplayMode dispMode) { final JFrame janela = new JFrame(); janela.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE) ; janela.setUndecorated(true) ; janela.setIgnoreRepaint(true) ; // Define que o sistema no mais controla quando os componentes so desenhados na tela. janela.setResizable(false) ; this.graphDevice.setFullScreenWindow(janela) ; // Verifica se o Device suporta a mudana de Resoluo e se a //resoluo para qual a mudana ser feita no vazia. Se TRUE faz a mudana. Se FALSE no faz nada. if(dispMode != null && graphDevice.isDisplayChangeSupported()) { try { graphDevice.setDisplayMode(dispMode); } catch (IllegalArgumentException e){ // Device no supporta a resoluo(DisplayMode) } } try { EventQueue.invokeAndWait(new Runnable() { public void run() { janela.createBufferStrategy(2) ; // Previne deadlock } }) ; } catch(InterruptedException ex){} catch(InvocationTargetException ex){} } }

No trecho de cdigo acima, ainda pertencente classe DisplayManager, temos o mtodo utilizado para gerar e definir que este contexto grfico dever ser executado em tela cheia. Para isso faz uso da classe JFrame, e pede a mesma, fazendo uso do mtodo setIgnoreRepaint(boolean flag) e setUndecorated(boolean flag), que no utilize atributos indesejados encontrados nela mesma. Aps desabilitar tais componentes, utiliza do metodo da GraphicsDevice,

setFullScreenWindow(Window w), para definir a janela do JFrame criado como a janela deste contexto grfico. Por fim, checa as resolues disponveis e faz mudanas de acordo. Os ultimos mtodos que devem ser mencionados nesta classe so: update() e o getGraphics().

// Retorna o contexto grafico para janela. Como DisplayManager usa o double buffering(swap) necessrio que a aplicao atualize, manualmente, qualquer desenho feito na tela. Utilizando-se do metodo update(), este contendo o show()(Metodo que mostra o conteudo do a ser mostrado) e sync()(Metodo que garante a sincronia do buffer contexto grafico deste Toolkit). public Graphics2D getGraphics() { Window janela = graphDevice.getFullScreenWindow() ; if(janela != null) { BufferStrategy strategy = janela.getBufferStrategy() ; return (Graphics2D)strategy.getDrawGraphics() ; } else { return null ; } }

// Atualiza a janela public void update() { Window janela = graphDevice.getFullScreenWindow() ; if(janela != null) { BufferStrategy bufferSwapper = janela.getBufferStrategy() ; if(!bufferSwapper.contentsLost()) // Verifica se o conteudo carregado na memria // no foi perdido. Se TRUE, mostra a imagem // carregada no buffer. { bufferSwapper.show() ; } } Toolkit.getDefaultToolkit().sync() ; }

Direcionaremos nossa ateno inicialmente ao mtodo getGraphics(). Este mtodo retorna um objeto Graphics2D retirado do BufferStrategy da janela definida no atributo do tipo GraphicsDevice caso esta janela exista, e, caso no, retorna null. J o mtodo update() tem como funo realizar a troca dos contedos dos buffers definidos no graphics device. E, para isso, utiliza do mtodo show() da classe BufferStrategy e do mtodo sync(), do Toolkit Default. Existem alguns outros mtodos nesta classe, so estes: getHeight() e getWidth(), responsveis por retornar o tamanho do eixo Y e X, respectivamente; getResoluoAtual(), que retorna o DisplayMode sendo utilizado no momento pela janela; getTelaCheia(), responsvel por retornar a tela sendo utilizada pelo Graphics Device; restaurarModoJanela(), responsvel por desativar o modo tela cheia; isResoluesIguais(DisplayMode dm1, DisplayMode dm2), este determina se duas resolues so iguais; e, por fim, getResoluesCompativeis(), que retorna as resolues suportadas pelo monitor. Com isso, terminamos o estudo da classe DisplayManager. E podemos seguir para a classe que a coloca em uso: a Game Engine ou Game Core.

3.1.2 Game Engine ou Game Core

Veremos aqui como aplicar os conceitos de game loop e a abstrao da engine na linguagem Java. Assim como na seo anterior, comearemos com seus atributos. Devo ressaltar que esta engine deve ser extendida e personalizada de acordo com o jogo; deve ser utilizada como um esqueleto.
... protected static final int FONT_SIZE = 22 ; protected static final DisplayMode[] MODOS_DISPONIVEIS = { new DisplayMode(1024, 768, 16, 0), new DisplayMode(1024, 768, 32, 0), new DisplayMode(1024, 768, 24, 0), new DisplayMode(800, 600, 16, 0), new DisplayMode(800, 600, 32, 0), new DisplayMode(800, 600, 24, 0), new DisplayMode(640, 480, 16, 0), new DisplayMode(640, 480, 32, 0), new DisplayMode(640, 480, 24, 0),

}; protected boolean isRunning ; protected DisplayManager tela; ...

Declarados acima esto os atributos de um esqueleto de Engine. Seu primeiro atributo uma constante que define o tamanho base de qualquer fonte que venha ser desenhada dentro do jogo utilizando o mtodo da classe Graphics drawString(). Seu segundo um array de possveis resolues na qual esta engine funcionar, este array utilizado para definir se o monitor tem a capacidade de executar, em modo tela cheia, o jogo criado em cima desta engine. Temos, a seguir, um booleano declarado como isRunning. Este define-se, basicamente, como a chave da engine; somente enquanto este booleano for verdadeiro o game loop permanecer funcionando. Finalmente, temos o contexto grfico no qual esta engine realizar os desenhos necessrios; este foi declarado como tela. Visto seus atributos, partiremos agora para seus mtodos que representam ou fazem parte do game loop; o update(long tempoTranscorrido), o draw(Graphics2D g) e o gameLoop(). Os mtodos update(long tempoTranscorrido) e draw(Graphics2D g) so mtodos que devero ser sobreescritos na classe que extender esta, pois, cada jogo deve ter seus componentes atualizados de uma forma no-generalizvel. Mas, o que podemos generalizar a ordem de execuo destes mtodos. Primeiramente devemos atualizar as informaes no sistema, e desenhar,

com posies atualizadas, os componentes no buffer e, por ltimo, fazer a troca dos buffers. E isto feito pelo mtodo gameLoop(), que ser executado enquanto o booleano isRunning for true. Isto demonstrado pelo trecho de cdigo abaixo:

... public void gameLoop() { long tempoComeo = System.currentTimeMillis() ; long tempoAtual = tempoComeo ; while(isRunning) { long tempoDecorrido = System.currentTimeMillis() - tempoAtual ; tempoAtual += tempoDecorrido ;

// Atualiza as informaes na memria update(tempoDecorrido) ; // Desenha o conteudo no buffer e o mostra. Joga o anterior fora. Graphics2D g = tela.getGraphics() ; draw(g); g.dispose() ; // Atualiza o Monitor tela.update() ; } } ...

Visto como o conceito de Game Loop pode ser implementado em Java veremos agora os mtodos restantes da engine que so utilizados para inicializar e finalizar a execuo do jogo. So, estes: inicializarComponetes(), comecarExec(), stop() e finalizarExec(). O stop(), sendo o mais simples, define somente o booleano isRunning como false fazendo com que o loop seja terminado. Abaixo os trechos de cdigo com os mtodos restantes.
... public void inicializarComponentes() { tela = new DisplayManager(); DisplayMode resolucao = tela.encontrarResolucaoCompativel(MODOS_DISPONIVEIS); tela.setModoTelaCheia(resolucao) ;

Window telaCheia = tela.getTelaCheia() ; telaCheia.setFont((new Font("Dialog", Font.PLAIN, FONT_SIZE))) ; telaCheia.setBackground(Color.BLACK) ; telaCheia.setForeground(Color.BLACK) ; isRunning = true ; } ...

Este trecho inicializa os dois nicos componentes existentes neste esqueleto: o monitor e o booleano isRunning. Porm, em suas classes filhas, este mtodo deve ser chamado atravs da chamada super.inicializarComponentes() e ter os componentes inerentes do jogo tambm inicializados aps a chamada mencionada.
/* Chama os mtodos inicializarComponentes() e gameLoop() e, por fim, aps suas respectivas execues, chama o mtodo finalizador de execuo. */ public void comecarExec() { try { inicializarComponentes() ; gameLoop() ;

} finally { finalizarExec(); } }

Este mtodo chamado no mtodo main(String[] args) da aplicao para dar inicio a execuo da engine. Chama o mtodo inicializarComponentes() e, aps seu trmino entra no game loop e l se mantm at que a chamada do mtodo stop() seja feita. E, finalmente, chama o mtodo finalizarExec(); este descrito no trecho abaixo.
/* Faz uso de uma Daemon Thread para forar o desligamento do programa. Espera 2 segundos para ter certeza que existam outras threads que no so Daemon ainda estejam em execuo. Caso existam o codigo deste mtodo ser executado e estas threads tero sua execuo foradamente terminada. Daemon Threads so threads que permitem que estas sejam fechadas caso no existam mais User Threads. O uso delas aqui garante que se existem User Threads sendo executadas quando este mtodo for chamado elas sero foradamente terminadas, caso contrario a VM j estar terminada e nada acontecer.*/

public void finalizarExec() { Thread finalizacao = new Thread() { public void run() { try { Thread.sleep(2000); } catch(InterruptedException ex) { System.exit(0); } } }; finalizacao.setDaemon(true); finalizacao.start(); }

Este mtodo aguarda 2 segundos e faz a chamada para o mtodo System.exit(0) que termina a execuo do programa. Com isso, terminamos as explicaes sobre a superclasse GameEngine. Veremos agora como o jogador far entradas com o sistema.

3.1.3 Game Actions e Gerenciador de Entradas

As classes, cujos nomes esto no ttulo desta seo, tm como objetivo criar uma ponte entre as interfaces Listeners (Key, Mouse, MouseMotion, MouseWheel) e um sistema de controle de aes possveis em um jogo. A primeira tem como definio um conjunto possvel de estados e de comportamentos declarados como valores inteiros constantes ou com o uso da keyword do Java enum. Estas so: os estados pressionado, solto e aguardando soltura; e os comportamentos detectar somente primeiro

clique e normal. Contm uma srie de mtodos de mtodos que retornam o estado atual da ao (se foi chamada ou no), a quantidade de cliques ou de vezes que uma tecla ou boto foi pressionado; estes esto dentre mtodos internos utilizados para suportar a ponte mencionada anteriormente. J a classe GerenciadorDeEntradas utilizada atravs de uma matriz de 600 GameActions ligados as representadas por constantes na classe KeyEvent, e uma segunda matriz ligando GameActions aos 9 possveis movimentos do mouse. Esta classe faz uso das interfaces Listeners mencionadas na introduo desta seo e define os mtodos vindos destas interfaces de modo com que atualizem, nas matrizes de GameActions, a ao chamada. No entanto, para que tal implementao seja possvel, mtodos que transformem a tecla lida na ao correta se fazem necessrios. E, com esse objetivo em mente, utilizamos as matrizes mencionadas anteriormente. Mapeamos as aes nas posies das matrizes de acordo com as constantes declaradas na classe KeyEvent e as constantes declaradas nesta classe, que definem os movimentos do mouse. Por fim o mtodo que recebe um evento do teclado ou mouse e busca, nas matrizes, utilizando a tecla/boto que desencadeou o evento, a ao correta. Com isso terminamos os conceitos desta seo. Na seo seguinte, veremos como aplicarmos os conceitos de criptografia em Java, sem fazer uso de sua API.

4. Concluso
Conclumos que a realizao de um jogo requer mais do que o simples ato de sentar na frente do PC e programar, ela exige uma gama de conhecimentos especficos aplicados a uma teoria central que lida com os jogos. Teoria esta que pode tanto ser aplica a jogos mais simples como em campos mais elaborados tais como: tica, economia e filosofia. Aplicando a teoria dos jogos podemos elaborar o melhor resultado para as estratgias praticadas pelo jogador e utilizando uma srie de conhecimentos especficos de programao(Threads, criptografia, UML, melhorias grficas, animao, entre outros) aplicados a uma Engine teremos o caminho para o desenvolvimento de um jogo, seja ele simples ou complexo, curto ou extenso.

5. Referncias Bibliogrficas
BRACKEEN, David. Developing Games in Java: Disponvel em: http://www.brackeen.com/javagamebook. FURLAN, Jose davi. Modelagem de objetos atravs da UML: analise e desenho orientados a objeto. So Paulo: Campus, 1998. H.M, Deitel, P.J Deitel. Java: como programar. 6 ed. Porto Alegre: Pearson Education do Brasil, 2008 . KATHY, Sierra; BERT, Bates. Use a cabea: Java. 2 ed. Rio de Janeiro: Alta Books, 2007. MACHADO, Francis Berenguer; MAIA, Luiz Paulo. Arquitetura de sistemas operacionais. 4ed. Rio de Janeiro: LTC, 2007.