to de um jogo para or utilizando blender e python
TRANSCRIPT
FACULDADES INTEGRADAS DE TAQUARA CURSO DE SISTEMAS DE INFORMAO
DESENVOLVIMENTO DE UM JOGO PARA COMPUTADOR UTILIZANDO BLENDER E PYTHON
CELIO PAULO FERREIRA DE ALMEIDA KIRSCH
TAQUARA
2010
2
CELIO PAULO FERREIRA DE ALMEIDA KIRSCH
DESENVOLVIMENTO DE UM JOGO PARA COMPUTADOR UTILIZANDO BLENDER E PYTHON
Trabalho de concluso de curso apresentado ao Curso de Sistemas de Informao das Faculdades Integradas de Taquara, sob orientao do Me. Marcelo Azambuja.
Taquara
2010
3
AGRADECIMENTOS
Ao orientador professor Marcelo Azambuja pela auxilio no desenvolvimento do projeto. A minha esposa, pela pacincia e ao meu filho, pelo incentivo.
4
RESUMO
Esta monografia demonstra a construo de um jogo para computador. Relata, de forma sucinta, a histria dos jogos para computador, a metodologia, a construo e as ferramentas utilizadas. A importncia da inteligncia artificial no jogo est baseada no algoritmo de busca, pois, seu objetivo deixar o jogo interessante e imprevisvel para o jogador.
5
LISTA DE FIGURAS
Figura 1 - Fases ou marcos em uma estrutura RUP........................................................... 14 Figura 2 - Caso de uso mais significativo............................................................................. 17 Figura 3 - Desenhos do menu................................................................................................ 18 Figura 4 - Tela do jogo........................................................................................................... 18 Figura 5 - Modelo de domnio............................................................................................... 20 Figura 6 - Fluxograma do menu........................................................................................... 21 Figura 7 - Fluxograma do inimigo........................................................................................ 22 Figura 8 - Fluxograma do jogador....................................................................................... 22 Figura 9 - Painel Logic no aplicativo Blender................................................................. 24 Figura 10 - Hierarquia da Game Engine.............................................................................. 25 Figura 11 - Mapa rodovirio simplificado da cidade de Taquara. Distncia entre cidades g(n)........................................................................................................................ 28 Figura 12 - Deslocamento de Porto Alegre at Taquara utilizando rvore para escolher o menor caminho.................................................................................................... 29 Figura 13 - Mapa de deslocamento, vista superior............................................................. 30 Figura 14 - Mapa de deslocamento, pesquisa de caminhos vlidos................................... 31 Figura 15 - Definindo variveis para deslocamento........................................................... 32 Figura 16 - Verificao das distncias entre verde e azul.................................................. 32 Figura 17 - Primeiro deslocamento...................................................................................... 33 Figura 18 - Escolha do melhor quadrado............................................................................ 34 Figura 19 - Definindo quadrado........................................................................................... 35 Figura 20 - Consulta de caminho.......................................................................................... 35 Figura 21 - Caminho definido............................................................................................... 36 Figura 22 - Hierarquia dos objetos. De cima para baixo. A palavra material refere-se ao tipo de textura e cor do objeto........................................................................... 37 Figura 23 - Modelos para construo dos objetos............................................................... 38 Figura 24 - Passos para modelar um objeto........................................................................ 40 Figura 25 - Modelando inimigo, objeto Corpo.................................................................... 41 Figura 26 - Aplicativo Arbaro, configurando uma rvore para executar no Blender.... 42 Figura 27 - rvore em trs dimenses importada do aplicativo Arbaro.......................... 42
6
Figura 28 - Textura de um objeto Sheding. Objeto Cylinder ligado ao material chamado Material................................................................................................................ 43 Figura 29 - Mapeamento de uma foto sobre a superfcie de um objeto utilizando UV Calculation........................................................................................................... 44 Figura 30 - Objeto Corpo e Armature (esqueleto) separados. Depois alinhados.............. 45 Figura 31 - Seleo dos vrtices abdominais ( em rosa ) do objeto Corpo para ser vinculado ao osso (Bone) chamado abdomen............................................... 46 Figura 32 - Quadros-chaves 1 e 5......................................................................................... 46 Figura 33 - Criao de quadros-chaves nos intervalos 10 e 15.......................................... 47 Figura 34 - Volta ao estado inicial........................................................................................ 47 Figura 35 - Parte do cdigo Andar.py, capturando dados................................................. 49 Figura 36 - Sensor: nome do Sensors Mouse ligado ao objeto Vazio................................ 49 Figura 37 - Atribuio de pesos para as posies em volta do inimigo............................. 51 Figura 38 - Algoritmo com a posio do jogador inimigo.................................................. 51 Figura 39 - Vista superior cdigo Python verificando caminho. Menor distncia.......... 52 Figura 40 - Funes do objeto Jogador (cor rosa).............................................................. 53 Figura 41 - Cdigo Movimento.py........................................................................................ 54 Figura 42 - Seta azul indica eixo Z, seta vermelha eixo X e verde eixo Y......................... 55 Figura 43 - Jogador (Cube)................................................................................................... 56 Figura 44 - Cdigo mouse.py................................................................................................ 57 Figura 45 - Objeto vazio ligado a arma. A seta vermelha indica a cena ativa ou tela principal do jogo.................................................................................................. 58 Figura 46 - Layer onde o objeto Bala (em vermelho com pontinho rosa) est quando no chamado............................................................................................................ 59 Figura 47 - Conjunto de sensores e atuadores do objeto Armature................................... 60 Figura 48 - Sensores e atuadores ligados aos objetos Empty.001....................................... 60 Figura 49 - Objeto Empty.001 ( Vazio ) filho ligado ao esqueleto (Armatrure) do jogador inimigo, embaixo da textura de camuflagem.................................................... 61 Figura 50 - Contador decrescente da vida........................................................................... 63 Figura 51 - Contador de munio......................................................................................... 63 Figura 52 Menu................................................................................................................... 64 Figura 53 - Cenas................................................................................................................... 65
7
LISTA DE QUADROS
Quadro 1 - Tabela de desenvolvimento................................................................................ 15 Quadro 2 - Distncia em linha reta at Taquara (valores inteiros)................................... 28 Quadro 3 - Caso de tese na fase de elaborao.................................................................... 39 Quadro 4 - Caso de teste na fase de construo.................................................................. 66 Quadro 5 - Tabela de caso de uso......................................................................................... 72 Quadro 6 - Alguns casos de uso: Processo escolher menu e jogar.................................... 73
8
SUMRIO
1
INTRODUO................................................................................................... 10
2
JUSTIFICATIVA................................................................................................ 12
3
OBJETIVO.......................................................................................................... 13
4
METODOLOGIA............................................................................................... 14
5. 6.1 6.2 6.3
FASE DE INICIAO....................................................................................... 16 Requisitos do sistema.......................................................................................... 16 Desenvolvimento.................................................................................................. 17 Ferramentas utilizadas....................................................................................... 19
7. 7.1 7.2 7.2.1 7.2.2 7.2.3 7.2.3 7.3 7.4
FASE DE ELABORAO................................................................................ 20 Modelagem do sistema........................................................................................ 20 Descrio do sistema........................................................................................... 21 Estudo da Game Engine........................................................................................ 23 Estudo da inteligncia artificial............................................................................. 26 Descrio do algoritmo A*................................................................................... 30 Estudo da hierarquia dos objetos........................................................................... 36 Modelo para construo dos personagens........................................................ 38 Teste na fase de elaborao................................................................................ 39
8 8.1 8.2 8.3 8.4 8.4.1 8.4.2 8.4.3 8.4.4
FASE DE CONSTRUO................................................................................. 40 Desenvolvimento dos personagens e cenrios................................................... 40 Desenvolvimento da animao dos personagens.............................................. 45 Integrando cdigo Python, algoritmo A* e personagens................................. 48 Descrio dos objetos lgicos do aplicativo Blender........................................ 53 Objeto jogador...................................................................................................... 53 Objeto inimigo...................................................................................................... 59 Objeto vazio.......................................................................................................... 61 Objeto contador de munio e vida....................................................................... 62
9
8.4.5 8.5
Objeto menu.......................................................................................................... 64 Testes na fase de construo............................................................................... 66
9
FASE DISTRIBUIO...................................................................................... 67
10
CONCLUSO..................................................................................................... 68
REFERNCIAS.................................................................................................. 69
ANEXOS.............................................................................................................. 71
10
1 INTRODUO
O desenvolvimento da tecnologia de jogos para computador sempre sofreu influncia dos movimentos sociais, polticos e culturais durante sua evoluo. Segundo Channel (2007), com o impacto da guerra fria, nos anos 50, e a possibilidade das potncias Estados Unidos e Unio Sovitica destrurem o mundo com suas bombas nucleares levou os cientistas a desenvolver tecnologias computacionais para simular testes balsticos de msseis e criar cenrios para prever os resultados de uma guerra nuclear. A mesma tecnologia foi utilizada pelo cientista William Higinbothan para desenvolver o primeiro jogo para computador em 1958 conhecido como Tennis for Two, em um rstico osciloscpio. Na era da Corrida Espacial e Guerra do Vietn, jogos como Space War, de Steve Russell, surgiram junto com as primeiras empresas do ramo de videogames. O sucesso foi estrondoso durante anos, pois o conceito de coloca o jogador no controle da diverso superior ao fato de assistir televiso de forma passiva. Entre os anos de 1970 e 1980 uma revoluo acontece: Jogos com espaonaves ou imagens que representam raquetes de tnis ou carros do lugar a uma nova tecnologia de videogame onde os personagens so reconhecveis pelo seu rosto e abre a possibilidades de se criar histrias complexas como Mario, Donkey Kong e Zelda. A passagem para a adolescncia dos adoradores de videogames na dcada de 90 j no estavam sendo supridas pela indstria e para acompanhar a cultura pop da poca, empresas correm para lanar personagens carismticos e hericos como Sonic. Por outro lado, anti-heris dures e mais realistas tambm eram bem aceitos pelo pblico como no jogo Grand Theft Auto III. Outra revoluo aconteceu com a tecnologia 3D. Esta tecnologia rica em detalhes coloca o jogador literalmente dentro do jogo. Conforme Channel (2007), suas caractersticas marcantes so perspectiva e profundidade nos cenrios que seduziam a todos tanto pelo ambiente como pelo tema polmico abordado nos primeiros jogos. Doom e Castle Wolfenstein 3-D, considerados jogos revolucionrios, simulavam com preciso o mundo real e criavam o paradoxo ente o que real e o que virtual. Apesar da violncia destes dois jogos com atiradores em primeira pessoa, eles foram um gnero muito popular em sua poca. Outro acontecimento revolucionou o mundo dos videogames: Aps os ataques terroristas de 11 de setembro, o governo norte americano lana seu prprio jogo com o intuito de recrutar jovens para o exrcito. Surgia um novo jogo, Americas Army, e uma nova polmica tambm. Estaria certo recrutar jovens para guerras reais atravs da brincadeira de um videogame? Jogos com temas tnicos que simula conflitos entre naes estariam gerando uma guerra virtual?
11
Outro evento marca os jogos de videogames: A internet revolucionou o mundo e os videogames tambm. Conforme Channel ( 2007), quando a ARPANET apareceu, quase que imediatamente usurios comearam a usar esta nova tecnologia para jogar. Ela foi criada em 1960, interligava computadores militares e foi precursora da internet. Jogar pela internet criou a cultura onde as pessoas podem criar seus personagem e nele acrescentar traos pessoais para serem reconhecidos neste mundo. Esta possibilidade de ter uma vida virtual paralela atraiu muitas pessoas e levou a outra polmica: natural pessoas passarem mais tempo neste mundo virtual do que no mundo real? Por outro lado, experincias virtuais so na verdade experincias humanas e so proporcionadas pelas modernas tecnologias de jogos eletrnicos. Apesar do pouco desenvolvimento na rea, h empresas internacionais interessadas no mercado de desenvolvimento de jogos no Brasil. Elas acreditam na capacidade de desenvolvimento dos programadores nacionais. Conforme Globo (2009), empresas de destaque internacional no desenvolvimento de jogos eletrnico, como Sony, esto observando os desenvolvedores nacionais atravs de eventos como o Simpsio Brasileiro de Jogos e Entretenimento Digitais (SBGames), bem como em contatos com a Associao Brasileira das Desenvolvedoras de Jogos Eletrnico (Abragames) para conhecer a tendncia dos desenvolvedores nacionais.
12
2 JUSTIFICATIVA
Desenvolver jogos eletrnicos significa entrar em um mundo financeiramente promissor e abordar um assunto que desperta o interesse de muitas pessoas. O projeto de um jogo se mostra promissor devido ao fato de abranger vrias reas da cincia da computao e proporcionar o desenvolvimento dos conceitos de gerenciamento de projeto, desenvolvimento e anlise de software. uma atividade multidisciplinar atuando em vrias reas do conhecimento humano e de Sistemas de Informao. Segundo Clua e Bittencourt (2005), com esta diversidade, todos os mdulos devem funcionar em perfeita harmonia e explorar ao mximo o hardware e placas grficas. Enquanto a maioria dos softwares segue apenas uma srie de requisitos e atende somente para o que foi programado, os jogos, alm disso, devem ser divertidos e agradveis, pois devem proporcionar entretenimento para as pessoas. A imerso sua caracterstica mais forte e obtida atravs da arte e da tecnologia, unindo Educao, Psicologia, Artes Plsticas e aspectos computacionais como a compreenso de varias tecnologias como Computao Grfica, Inteligncia Artificial, Redes de Computadores e Multimdia. Muitos jogos possuem excelentes grficos e em seu lanamento atinge um grande pblico ao redor do mundo, porm, histrias fracas, personagens que no envolvem ou com falta de inteligncia so defeitos apontados entre os jogos mais modernos. Conforme Uol (2010), ao analisar um jogo lanado em 2010, cita a fraca amarrao da trama e os personagens secundrios no sendo carismticos para segurar a ateno do jogador at o final. Desenvolver um jogo com uma histria atraente e envolvente pode ser o diferencial para competir com empresas que do nfase aos grficos do jogo acima de tudo.
13
3 OBJETIVO
Entre os tipos de jogos eletrnicos atualmente conhecidos, o foco desse estudo direcionado para jogos de computador, e entre os vrios tipos de jogos, o gnero tiro em primeira pessoa. Do ingls, FPS (First Person Shooter) ou jogo de tiro em primeira pessoa significa o jogador assumir o lugar do personagem principal. A viso do personagem substituda pela viso do jogador, como se ele estivesse, de fato, dentro do jogo e interagindo diretamente com o ambiente. Este trabalho tem como objetivo principal desenvolver um jogo de tiro em primeira pessoa para computador atendendo as expectativas dos jogadores que apreciam este gnero. O trabalho visa tambm analisar as melhores tcnicas a fim de tornar o jogo adequado em termos de interao como o usurio e explorar o potencial de desenvolvimento do software Blender.
14
5 METODOLOGIA
As metodologias utilizadas para este projeto de desenvolvimento de software foram o Unified Modeling Language (UML) e o Rational Unified Process (RUP), pois, trata-se de um processos de especificao e implementao popular, com etapas claras e com vasto material de apoio. Segundo Martins (2004), sua estrutura proporciona ao desenvolvedor uma viso clara da integrao das vrias facetas do processo de desenvolvimento. A premissa do RUP que o software est baseado em componentes interconectados entre si. O RUP possui as seguintes fases: Abertura (ou Concepo, ou Iniciao), Elaborao, Construo e Transio. As fases tambm so chamadas de marcos, conforme mostrado na Figura 1.
Figura 1 - Fases ou marcos em uma estrutura RUP. Fonte: WTHREEX (2010).
Na fase de iniciao deve-se deixar clara a viso do sistema do ponto de vista do negcio, concluir se o projeto vivel ou no. Segundo Martins (2004), o objetivo principal na fase de abertura do projeto : especificar a viso do produto final, garantir que as funcionalidades estejam mapeadas e a descrio do comportamento do cenrio. Na fase de elaborao, alm de elencar os requisitos faltantes necessrio definir a arquitetura e monitorar os riscos para as prximas fases. Conforme Martins (2004), a elaborao da fase um processo de engenharia, primeiro especificando a arquitetura e depois planejando o software para o restante do projeto. Seu objetivo principal : ter uma viso completa do sistema, como escopo, requisitos, funcionalidades, etc. Na fase de construo, o sistema e documentao sero desenvolvidos. Segundo Martins (2004), a construo considerada uma fase de processo de manufatura, focando o
15
gerenciamento dos recursos, otimizao de tempo, custos e qualidade. Os objetivos sero alcanados se o sistema for construdo, testado e alcanado a aprovao dos investidores. Na fase de distribuio, o software dever se tornar operacional. Conforme Martins (2004), o objetivo da verso beta verificar se as necessidades do usurio foram atendidas, verificar riscos no previstos, problemas no resolvidos e identificar dificuldades ao utilizar o sistema e a necessidade de treinamento. A Tabela de Desenvolvimento serve para visualizar o projeto como um todo. Demonstra os itens das fases, o inicio e o desenvolvimento das disciplinas. A letra i significa inicio e a letra r refinamento. Segundo Larman (2007) as disciplinas descrevem atividades de trabalho especficas. Estas atividades so chamadas de artefatos e pode ser definidos como qualquer produto do trabalho: cdigo, grficos, diagramas, texto, etc. Quadro 1.
Disciplina Modelagem de Negcio Requisitos
Artefato Modelo de domnio Modelo de caso de uso Viso Especificaes suplementares Modelo de projeto Documento de Arquitetura de software Prottipos de tela
Iniciao/ Concepo
Elaborao i
Construo r r r r r r r r i i
Transio r r r r r r r r r r i
i i i
r r r i i
Projeto (Analise e Design)
i
r i
Desenvolvimento/ Implementao
Modelos de objetos Desenvolvimento dos componentes Integrao dos componentes Modificaes e acerto Caso de teste Script de teste Teste da verso final Concluso do empacotamento do sistema Ferramentas i
i
Teste Desdobramento ou Implantao Codificao e Mudanas
r i
r i i
r
r
Quadro 1 - Tabela de Desenvolvimento
16
6 FASE DE INICIAO
Ao se desenvolver um jogo o estudo de caso no se enquadra em um estudo tradicional. Conforme Larman (2007), o estudo de caso de um software para jogos, apesar dos objetos e a aplicao da UML serem iguais a outros projetos mais tradicionais como banco de dados os requisitos no so os mesmos.
6.1 Requisitos do sistema
A viso descreve as principais idias do projeto. Segundo Schuytema (2008), elas podem ser:
a) b)
o jogador deve conhecer o objetivo logo no incio e no ficar vagando pelo cenrio; as vitrias devem ser aninhadas, referindo-se ao jogador conquistar vitrias parciais ao decorrer do jogo, ou decifrar enigmas, at alcanar o objetivo maior e no descarregar toda sua adrenalina para desafios mais simples;
c)
ter um contexto compreensvel para o jogador satisfazer sua expectativa em relao ao jogo, geralmente estes jogos so familiares ao usurio e ele no deve ter dificuldade de entender o contexto, pois, prejudicaria a experincia vivida;
d)
os cones devem dispensar tradues. A parte de interface com o usurio considera as funes obvias de agir da interface;
e)
a maioria dos jogadores usurio Windows, e ser interessante basear a representao visual neste estilo para criar uma atmosfera familiar ao jogador. Outra observao de interface est na sua coerncia. Como o ser humano tem habilidade para tarefas repetitivas, ao descobrir como uma coisa funciona, ele tem a expectativa que esta funcione da mesma maneira nas prximas vezes. Por exemplo: se no jogo a tecla Enter executa a mesma tarefa que um clique do mouse, ento, deve-se manter a coerncia deste padro durante todo o jogo;
f)
para causar um impacto visual mais realstico as texturas so utilizadas com fotos ou desenhos;
17
O caso de uso mais significativo no projeto o Jogar Selva (visto na Figura 2 e Quadro 2). Como ele uma simulao de computador e observado por apenas uma pessoa, pode-se concluir que o jogador um observador. Conforme Deitel (2005), o caso de uso modela a interao entre uma entidade externa, chamado de ator, ou melhor: Observador, e usando um sistema para atingir um objetivo. A tentativa de captar todas as regras do jogo em um formato de caso de uso pode deixar o diagrama confuso e no natural. Estas regras podem ser enquadradas como regras do negcio e sero enquadradas em outras especificaes. Jogar Selva foi o nome provisrio do jogo.
Figura 2 - Caso de uso mais significativo
Especificaes no funcionais do sistema so: a) A mquina virtual Python essencial para o funcionamento do jogo, porm, dever ser transparente para o usurio ao instalar o jogo. b) O idioma nos menus ser escritos em ingls, para maior abrangncia de usurio.
6.2 Desenvolvimento A visualizao da interface do jogo utilizando desenhos das telas principais deixa claro o que esperado do software.
18
Figura 3 - Desenhos do menu.
Figura 4 - Tela do jogo
19
6.3 Ferramentas utilizadas
a) b) c) d)
Python 2.5.4. Blender verso 2.48a. Arbaro 1.8.9. Jude Comunity 5.5 (Model Version: 30).
20
7 FASE DE ELABORAO
Nesta fase foram desenvolvidas as disciplinas de Modelagem de negcio, Projeto e Implementao.
7.1 Modelagem do sistema
Lista informal de requisitos para elaborao do modelo de domnio do jogo proposto: a) b) Apenas um jogador pode jogar; Um jogo inicia quando o jogado assume o personagem principal e ele est no cenrio com liberdade para se locomover e atira; c) A entrada do usurio consiste nos disparos de sua arma e comandos para o deslocamento no jogo; d) e) f) A arma possui vrios cartuchos com 10 cpsulas; O objetivo do inimigo procurar e eliminar o jogador; O jogador atingido por alguns tiros encerra o jogo.
Figura 5 - Modelo de Domnio
21
7.2 Descrio do sistema
O modelo de projeto utilizado como base para as atividades de implementao e testes, podendo ser visto como uma abstrao da implementao do sistema, sendo utilizado para conceber e documentar o projeto do sistema de software, Figura 6, 7 e 8.
Figura 6 - Fluxograma do menu
22
Figura 7 - Fluxograma do inimigo
Figura 8 - Fluxograma do jogador
23
O desenvolvimento da arquitetura de software nesta fase define a viso lgica do sistema.
7.2.1 Estudo da Game Engine
A descrio da hierarquia da Game Engine um aspecto importante do projeto e a adoo de tecnologias com a filosofia de software livre tambm. Portanto, os softwares utilizados para o desenvolvimento so todos gratuitos. O uso da linguagem de programao Python se justifica por ser ela a base para as programaes do aplicativo Blender. Esta linguagem foi utilizada para desenvolver a inteligncia artificial do jogo, na construo de scripts que controlam principalmente o personagem no jogador, aquele controlado pelo computador. Segundo Lutz e Ascher (2007), Python uma linguagem orientada a objetos, de estruturao e reutilizao de cdigo. Pode-se ainda construir scripts para sistemas orientados a objetos como C++ e Java e, assim como Perl e Linux, seu cdigo-fonte aberto e com uma grande rede de suporte pela internet. Blender foi o principal software para desenvolver o projeto. Nesta ferramenta os testes so feitos simultaneamente, ou seja, a modelagem, a texturizao e a ao de executar o jogo na ferramenta podem ser feitos a qualquer momento, sem a necessidade dele estar pronto. Conforme Brito (2008), uma ferramenta completa para criao de objetos 3D, para modelao, texturizao e visualizao de contedo 3D interativo. O Blender possibilita a criao de espaos tridimensionais, imagens, vdeos e com seu motor 3D, em tempo real permite o desenvolvimento de jogos com sua prpria Game Engine. Originado da empresa Not a Number (NaN), ele hoje Software Livre e disponvel sobre licena GNU GPL. A programao foi estruturada entre o aplicativo Blender e a linguagem de programao Python. Entre os dois existe a API Blender para ligar as duas estruturas como um ponto em comum. Os cdigos Python so chamados de scripts e so usados em tempo de execuo, ou seja, medida que o software utilizado o cdigo acionado.
24
Figura 9 - Painel Logic no aplicativo Blender
Os objetos modelados no aplicativo Blender, como personagens, rvores e cho, sero controlados durante o jogo pela especificao do script Python criado pelo programador e ativados atravs da Game Engine do aplicativo Blender. A Figura 9 demonstra a ligao de dois Sensors Armature, dois Controllers Armature e dois Actuadors Armadure. Armadure o nome dado ao objeto responsvel pelo movimento de braos e pernas do inimigo no jogo. O resultado destas ligaes a movimentao do inimigo em direo ao jogador como resposta ao acionamento do boto esquerdo do mouse. Cada sensor Sensors chamado de bloco lgico Logic Brick e cada bloco recebe um nome. O primeiro se chama sensor2 e sempre Always est ativado para executar uma ao pr-determinada. Este sensor est ligado a um bloco lgico controlador Controllers, chamado de cont e est ativado na funo lgica AND que avalia se o bloco sensor est ativado. Se ativado (verdadeiro) o controlador executa o atuador Actuadors correspondente. O atuador se chama act2 e executa uma ao Action que significa pegar uma animao pronta do objeto armadura e execut-la. No bloco act2 est definida uma animao chamada de Action e ser executada do quadro um at o vinte. Uma animao no Blender como um desenho animado, o conjunto de vrios desenhos passados em um determinado espao de tempo cria a impresso do movimento. Geralmente para um desenho animado so necessrios no mnimo de vinte e quatro quadros ou desenhos em seqencia para criar uma animao de um segundo. No Blender esta condio tambm deve ser considerada, porm, ela ocorre de forma automtica. Os objetos animados no aplicativo devem estar registrados em uma posio inicial e tambm deve ser colocado na posio final para ser registrado onde ele inicia e deve parar. Para chegar da posio inicial
25
at a final o prprio aplicativo preenche os espaos. Por exemplo: para animar o deslocamento de uma esfera necessrio marcar a posio inicial do objeto e em seguida marca a posio onde ela deve parar. Em seguida executada a animao e o Blender, em uma seqncia de quadros predefinida, completa a animao do incio ao fim. Em cada quadro o aplicativo apaga o objeto do quadro anterior e recria no quadro seguinte, em seqncia, e tem-se a impresso do movimento. O segundo sensor chamado de sensor ativado atravs do mouse, especificamente quando o boto esquerdo acionado. O segundo quadrado com os trs pontinhos pressionados significa que a cada dez ciclos do relgio do computador ser verificado se o boto esquerdo do mouse foi acionado. A especificao do ciclo est descrita em f10, Figura 9. O sensor est ligado a um controlador chamado cont1 e est configurado para executar um cdigo Python, O cdigo est em um arquivo chamado de Andar.py que define como o objeto armature deve se comportar em relao ao andar. O controlador act define os tipos de movimento do armature, como deslocamento e rotao representados por loc, rot, force, torque, etc. A vantagem de utilizar o cdigo Python est na possibilidade de usar os dados do bloco lgico controlador dentro do cdigo, potencializando sua utilizao atravs de consultas e atribuio de valores. Os dados impostos direto no bloco controlador so estticos e no manipulveis.
Figura 10 - Hierarquia da Game Engine. Fonte: PROCEDURALBASE (2007).
26
A hierarquia dentro da Game Engine no jogo desenvolvido crescente, Figura 10. Sua base o script Python que est disponibilizado atravs do controlador. O controlador recebe informaes dos sensores atravs de vrios componentes como teclado e mouse e repassa para o cdigo Python. O controlador tambm avalia as funes disponveis no atuador, como act e rot, (ver Figura 9), para ser processada no script Python. Com estas duas informaes o controlador avalia o cdigo Python e repassa o resultado para o objeto ser executado. A cena formada por todos os objetos no jogo. Para chegar ao atuador a estrutura do cdigo ser: Script controlador atuador.
7.2.2 Estudo da inteligncia artificial
A Inteligncia Artificial do jogo teve um aspecto relevante no projeto, pois para atender as expectativas do usurio o software deve simular o ambiente com maior realismo possvel. Foi adotado o algoritmo de busca A*, (pronuncia-se A - estrela), para controlar o inimigo do usurio (jogador). Sua funo no projeto escolher a melhor rota para o inimigo chegar at o jogador. Sabendo onde o jogador se encontra o algoritmo analisa todas as rotas e, ento, toma a deciso levando em considerao o caminho mais curto e com o menor custo. Segundo Russell e Peter (2004), este tipo de algoritmo se chama Algoritmo de Busca com Informao e utiliza o conhecimento especfico do problema. A abordagem geral chamada de Busca Pela Melhor Escolha, ou Best-First. Busca A* significa minimizar o custo total estimado da soluo. Pode-se representar o custo em uma busca como o gasto que o elemento tem ao deslocar-se de um n at o seu objetivo. Este algoritmo pode ser representado por uma estrutura de dados rvore, chamada de rvore de busca. Consiste em compara ns no algoritmo como se fossem pontos de ramificaes em uma rvore real. Quando um n, ou ramificao, selecionado no algoritmo para ser comparado com outro n, ou ramificao da mesma rvore, a busca ocorre nos ns a frente sempre dando preferncia para o que proporcionar a menor distncia g(n). Outra caracterstica deste algoritmo a funo heurstica h(n), que representa o custo estimado em linha reta para ir de um n at o objetivo, independente se existe outros ns no caminho. A escolha do melhor caminho feita com base em uma funo de avaliao f(n), que escolhe o n com valor mais baixo, no caso da rvore a ramificao com o n mais prximo e o valor menor para chegar at o objetivo. Neste algoritmo a frmula f(n) = g(n) + h(n) representa o
27
custo estimado da soluo de custo mais baixo passando por n = custo para alcanar cada n + custo para ir do n at o objetivo. Para que se encontre a soluo de custo mais baixo ser verificar o n com valor mais baixo g(n) + h(n). Segundo Russell e Peter (2004), a estratgia efetuar uma busca com informaes especificas do problema e definir o prprio problema. O custo para alcanar cada n g(n) e pode ser exemplificada como a distncia entre as cidades de Taquara, Figura 11. O custo para chegar at ao objetivo h(n) e pode ser representada pela distncia em linha reta de cada cidade at a cidade de Taquara, Tabela 4. A estimativa da soluo de custo mais baixo passando por n f(n), atravs da avaliao g(n) + h(n), Figura 12 e a observao mais importante ser sobre a heurstica admissvel, onde, h(n) nunca superestime o custo para alcanar o objetivo, ou seja, nenhuma cidade ter o valor calculado f(n) menor do que a distancia em linha reta desta cidade h(n). A heurstica admissvel sempre considera que o custo da resoluo do problema seja menor do que ele na realidade. O custo g(n) o custo exato para se alcanar n, tem-se como conseqncia imediata que f(n) nunca ir superestimar o custo verdadeiro de uma soluo passando por n. Pode-se considerar um mapa rodovirio para sair de Porto Alegre e chegar a Taquara usando-se uma BUSCA-EM-RVORE.
28
Figura 11 - Mapa rodovirio simplificado da cidade de Taquara. Distncia entre cidades g(n) Fonte: Adaptado de Russell e Peter (2004, p. 65).
Alvorada Cachoeirinha Campo Bom Canela Canoas Caxias do Sul Esteio Gramado Gravata Igrejinha Novo Hamburgo
48 44 25 31 48 64 45 31 39 7 34
Parob Porto Alegre Rolante Santo Antnio da Patrulha So Francisco So Leopoldo Sapiranga Sapucaia Taquara Trs Coroas
3 60 21 35 30 37 21 40 0 14
Tabela 2 - Distncia em linha reta at Taquara (valores inteiros) Fonte: Adaptado de Russell e Peter (2004, p. 96).
29
Figura 12 - Deslocamento de Porto Alegre at Taquara utilizando rvore para escolher o menor caminho. Fonte: Adaptado de Russell e Peter (2004, p. 98).
30
A funo g(n) acumula o custo de uma cidade para outra. Pode-se observar que na cidade de Porto Alegre h um caminho por Canoas, porm, o custo por Alvorada menor e o algoritmo explora esta ramificao. Em Canoas existe vrios caminhos alternativos para chegar em Taquara, mas nenhum uma soluo tima, com menor f(n).
7.2.3 Descrio do algoritmo A*
A rea onde ocorrer a busca deve ser divida por linhas e colunas, transformando o local em uma grade quadrada. Cada espao quadrado representa uma posio. Portanto, se um objeto em um quadrado necessita deslocar-se at outro quadrado ele deve escolher os quadrados que proporcionem o caminho mais curto. Caso haja no caminho do objeto algum quadrado que ele no possa acessar ele deve contorn-lo para chegar ao seu destino. A Figura 13 demonstra esta situao: o quadrado verde deve chegar at o quadrado azul e os quadrados pintados de preto a parede entre eles.
Figura 13 - Mapa de deslocamento, vista superior. Fonte: Adaptado de LESTER (2005).
Passo 1:
31
O quadrado verde para comear sua caminhada deve selecionar todos os quadrados em sua periferia, excluindo quadrado que contenha paredes, Figura 14. Os quadrados selecionados representam possveis caminhos e devem ser guardados na memria. Outro dado que deve ser guardar em memria a posio anterior e atual do quadrado verde. Segundo Lester (2005), criada uma lista aberta para verificar os possveis caminhos e outra lista fechada para e excluir a posio do quadrado verde das pesquisas futuras. Nesta situao o quadrado verde ser o quadrado pai e todos os amarelos convergem para ele.
Figura 14 - Mapa de deslocamento, pesquisa de caminhos vlidos Fonte: Adaptado de LESTER (2005).
Passo 2:
Para verificar a melhor posio cada quadrado amarelo dever conter o custo de deslocamento do verde para o amarelo g(n), o custo de cada amarelo at o azul h(n) e o custo estimado da soluo f(n), figura 15.
32
f(n)
f(n)
f(n)
g(n) f(n)
h(n)
g(n)
h(n)
g(n) f(n)
h(n)
g(n) f(n)
h(n) f(n)
g(n) f(n)
h(n)
g(n)
h(n)
g(n)
h(n)
g(n)
h(n)
Figura 15 - Definindo variveis para deslocamento Fonte: Adaptado de LESTER (2005).
Os valores de deslocamento entre verde e amarelo tem o custo na vertical e horizontal de 1, para deslocamentos em diagonal o custo ser 1.4. Para calcular a distncia de cada quadrado amarelo at o azul ser adotado o mtodo de Manhathan. Segundo (LESTER, 2005), este mtodo consiste em contar os quadrados apenas na vertical e horizontal entre o amarelo desejado e o azul, Figura 16. Sua adoo no a melhor porque superestima a distncia restante, porm, ser adotado na explicao do algoritmo.
1
2
3
4
5
6
7
8
9
7.4
6
5.4
1.4 6 6
1
5
1.4 4 4
1 7.4
5 6
1 5.4
3
2
1
1.4
6
1
5
1.4
4
Figura 16 - Verificao das distncias entre verde e azul Fonte: Adaptado de LESTER (2005).
33
Passo 3:
A verificao do melhor local leva em considerao a soma f(n) = g(n) + h(n) dos quadrados amarelos (lista aberta). eleito o menor f(n) e desconsidera-se a lista fechada com seus elementos. No exemplo a menor distncia f(n) = 4, Figura 17.
1
2
3
4
5
6
7
8
9
7.4
6
5.4
1.4 6 6
1
5
1.4 4 4
1 7.4
5 6
1 5.4
3
2
1
1.4
6
1
5
1.4
4
Figura 17 - Primeiro deslocamento Fonte: Adaptado de LESTER (2005).
Passo 4:
Nesta etapa f(n)=4 colocado na lista fechada e eleita uma nova lista amarela tendo em vista o quadrado verde eleito como base. Os elementos da lista fechada e quadrados representando paredes devem ser desconsiderados. No exemplo, o caminho mais prximo do quadrado azul so os dois quadrados com a funo: f(n) = 5.4 (acima do ltimo quadrado verde eleito) e f(n)=5.4 (abaixo do ltimo quadrado verde eleito). Neste caso, a escolha do quadrado depende da construo do cdigo-fonte, pode ser o primeiro a entra na lista aberta ou o ltimo. Para o desenvolvimento do algoritmo a consulta dos quadrados amarelos se d de cima para baixo e da esquerda para a direita. Caso haja alguma funo f(n) igual ser
34
considerado a ltima encontrado. Portanto o quadrado eleito f(n) = 5.4 abaixo do ltimo quadrado verde eleito, Figura 18.
1
2
3
4
5
6
7
8
9
7.4
6
5.4
1.4 6
6
1 5
5
1.4 4
4
1 7.4
5
1 6
4
1 5.4
3
2
1
1.4
6
1
5
1.4
4
Figura 18 - Escolha do melhor quadrado Fonte: Adaptado de LESTER (2005).
Passo 5:
Considerando a pesquisa no quadrado f(n) = 5.4, Figura 19, o melhor caminho encontrado foi f(n) = 6, ltimo quadrado com valor igual encontrado na pesquisa da na lista aberta.
35
0 1 2
1
2
3
4
5
6
7
8
9
7.4
6
5.4
31.4 6 6 1 5 5 1.4 4 4
41 7.4 5 1 6 4 1 5.4 3 2 1
51.4 6 1 7.4 5 1.4 6 4 3
61.4 6 1 5 4
7Figura 19 - Definindo quadrado. Fonte: Adaptado de LESTER (2005).
0 1 2
1
2
3
4
5
6
7
8
9
7.4
6
5.4
31.4 6 6 1 5 5 1.4 4 4
41 7.4 5 1 6 4 1 5.4 3 2 1
51.4 6 1 7.4 5 1.4 6 4 3
61.4 8.4 6 1 7 5 6.4 4
71.4 7 1 6 1.4 5
Figura 20 Consulta de caminho. Fonte: Adaptado de LESTER (2005).
Pode-se observar o revs na marcha para chegar ao quadrado azul, pois, o menor custo para chegar ao quadrado azul no a funo f(n) = 6.4, na coluna 5, linha 7, Figura 20, Tecnicamente o menor custo a funo f(n) = 6, na coluna 3, linha 5. A lista fechada ser consultada e o algoritmo bloquear qualquer deslocamento para uma funo f(n) com o mesmo valor existente nesta lista.
36
0 1 2
1
2
3
4
5
6
7
8
9
7.4
6
5.4
31.4 6 6 1 5 5 1.4 4 4 2.4
41 7.4 5 1 6 4 1 5.4 3 2 1.4 3 1 2.4
51.4 8 6 1 7.4 5 1.4 6 4 3 1 4.4 2 1.4 3 1
61 9.4 7 1.4 8.4 6 1 7 5 6.4 4 1.4 5 3 1 2
71.4 8 1.4 7 1 8 6 1.4 7.4 5 1 4
1
7
1.4
6
Figura 21 - Caminho definido. Fonte: Adaptado de LESTER (2005).
As consultas seguintes sero repeties dos passos um a cinco, Figura 21. O caminho ideal est demonstrado pelas setas. Foi criada uma lista fechada com sete posies: [(3,4) (4,4) (4,5) (4,6) (5,7) (6,6) (7,5)] que ser o caminho para chegar ao quadrado azul.
7.2.3 Estudo da hierarquia dos objetos:
A compreenso da atuao dos objetos est relacionada com qual outro objeto ele mantm uma relao de dependncia ou imposio. A hierarquia est definindo qual objeto pode ser influenciado. Por exemplo: Todos os outros objetos dependem do objeto Selva. O objeto Inimigo influenciado pelo objeto Selva, porm, o objeto Corpo, Ao e Pose esto todos relacionados com Inimigo.
37
Figura 22 - Hierarquia dos objetos. De cima para baixo. A palavra material refere-se ao tipo de textura e cor do objeto.
38
7.3 Modelo para construo dos personagens
Figura 23 - Modelos para construo dos objetos. Fonte: DESENHEPINTE (2008), MOREIRA (2008), SOUSMAN (2008), TERRESTRE (2009)
A Figura 23 serve como modelo para arma do jogador e inimigo. O desenho do corpo humano ser usado como modelo para corpo do inimigo. As figuras com o rosto sero utilizadas para modelar a face do inimigo. O ltimo desenho estuda o movimento do andar.
39
7.4 Teste na fase de elaborao
Os testes so parte fundamental no sucesso do projeto. Segundo Martins (2007), a correo de problemas de software de 100 a 1000 vezes mais cara de realizar aps a implantao do sistema. O modelo de testes indica os elementos que vo ser testados e o modo como sero testados. Os utilizados neste projeto sero os de Caso de Teste: verificam os objetivos, dados dos testes, condies de execuo e resultado esperado.
Caso de teste: CT1 Cenrio/Condio: Distancia em linha reta entre inimigo e jogador com obstculo. Entradas: Parede em forma de U. Parede muito comprida. Jogador posicionado dentro de um quadrado representado por uma parede. Resultado: Em todos estes casos o inimigo anda de forma desorientada. Como ele no deixa sobrescrever f(n) com o mesmo valor. A funo para o inimigo sair de uma parede em U seria passar ele por um quadrado que tenha o mesmo valor de f(n). Mesmo este no esteja na lista fechada ele no poderia se deslocar para esta sada, pois, o algoritmo no permite sobrescrever funes na lista fechada. O fato de o inimigo entrar no U em busca do melhor caminho impossibilita sua sada porque estando dentro do U, para sair necessitaria voltar e esta volta passa pela mesma distncia de entrada, apesar de quadrados diferentes. Caminhar perpendicularmente em uma parede muito grande traz problema de h(n) porque em uma determinada parte da parede se torna mais perto chegar ao jogador se o inimigo se afastar um quadrado da parede e voltar para o centro da parede caminhando de forma perpendicular a ela. Nesta situao ele percorre todos os quadrados atrs da parede com a distncia menor que a distncia do centro da parede at o final dela. Se o jogador est posicionado dentro de um quadrado que representa parede o algoritmo no vai encontra a posio do jogador. Os quadrados que representam a parede so descartados para efeito de clculos. O algoritmo no prev o controle do jogador sobre a matriz, ele apenas captura sua posio para ser calculada.Tabela 3 - Caso de teste na fase de elaborao.
40
8 FASE DE CONSTRUO
Na fase de construo, o sistema e documentao sero desenvolvidos
8.1 Desenvolvimento dos personagens e cenrios
Todos os objetos do jogo foram criados pelo aplicativo Blender. No Modo de Edio, Edit Mode, possvel manipular objetos atravs de suas faces. Para modelar uma pessoa parte-se de um objeto simples como um cubo. O cubo possui seis faces, oito vrtices e doze arestas. Ao aplicarmos uma diviso neste objeto todos estes itens se duplicam, ou ento, podese aplicar uma diviso apenas em uma face, ou uma aresta para duplicar uma parte do cubo em particular. Criando componentes e movendo-os possvel modelar qualquer objeto. Para suavizar a aparncia do objeto aplicado um modificador Subesurf para suavizar as arestas do objeto. Figura 24.
Figura 24 - Passos para modelar um objeto
41
A imagem de um ser humano de frente e perfil no Edit Mode, Figura 25, serviu como modelo para a criao do jogador inimigo a partir de um cubo. Como Cube o nome padro do objeto ele ser alterado para Corpo.
Figura 25 - Modelando inimigo, objeto Corpo.
A estrutura do jogador apenas um cubo com uma cmera. Seu principal atributo ser invisvel. Para modelar a arma foi utilizado o mesmo procedimento, uma foto de modelo para a modelagem do objeto arma. No cenrio no foi utilizado foto. Ele foi modelado na forma de um cubo grande para colocar todos os outros objetos dentro como rvore, jogador, pedras e inimigo. O aplicativo para desenvolver rvores foi o Arbaro. Com ele foi possvel criar uma rvore a partir de um modelo em duas dimenses, como um desenho em uma folha de papel. O aplicativo pede o nmero de folhas, o formato da copa da rvore, o tipo de tronco, etc, Figura 26.
42
Figura 26 - Aplicativo Arbaro, configurando uma rvore para executar no Blender.
No Blender, importa-se o projeto criado no Arbore com a forma de objeto Wavefront Object e, ento, a rvore criada em trs dimenses, Figura 27.
Figura 27 - rvore em trs dimenses importada do aplicativo Arbaro.
43
Os objetos foram coloridos de duas formas. A primeira utilizando Shading para aplicar cores. Alguns objetos como cones de vida e munio foram feitos nesta forma selecionando o objeto e, em Sheding, criando um novo material ligado de forma automtica ao objeto selecionado, no cone munio ou corao, manipulando a sua cor e sua textura, Figura 28.
Figura 28 - Textura de um objeto Sheding. Objeto Cylinder ligado ao material chamado Material.
A segunda forma est relacionada a carregar arquivos em formatos de imagens com extenso Jpeg ou Gif. A roupa do inimigo, o cho do cenrio e as pedras foram feitas com esta tcnica. No modo de edio seleciona-se o objeto, ou face do objeto, e aciona-se a UV Calculation, para calcular como a imagem se enquadra na superfcie do objeto, Figura 29.
44
Figura 29 - Mapeamento de uma foto sobre a superfcie de um objeto utilizando UV Calculation.
45
8.2 Desenvolvimento da animao dos personagens
O andar do jogador inimigo desenvolvido na funo de animao do Blender, Timeline. O objeto responsvel pela ao a armature e ela representa o esqueleto do jogador inimigo, sua construo ocorre com a adio do Bones, ossos, e um osso est sempre ligado ao outro, sua hierarquia o primeiro osso criado pai do segundo, assim, sucessivamente. Significa dizer se movimentar o osso fmur os ossos restantes da perna tambm sero movidos. Com os ossos da perna direita e esquerda foram aplicadas as tcnicas de cinemtica inversa. Segundo Brito (2008), a cinemtica serve para mover um conjunto de ossos prdefinido conforme o movimento que apenas um osso deste conjunto executar. Se for movido o p para cima, os ossos da articulao tornozelo e joelho so influenciados conforme o movimento. Para criar uma animao esse recurso torna-se prtico, pois no h a necessidade de controlar os ossos individualmente durante o movimento de andar.
Figura 30 - Objeto Corpo e Armature (esqueleto) separados. Depois alinhados.
Alinhando o objeto Armature com o objeto Corpo, Figura 30, pode-se ligar estes dois objetos. O movimento que o esqueleto, Armature, executar o corpo tambm acompanhar. Para este efeito, Figura 31, selecionado o osso desejado e o conjunto de vrtices do objeto Corpo que ser deformado em seguida ativando a funo Assign. Todos os ossos devem passar por este procedimento. Quando o osso Abdmen for movido o corpo tambm ser.
46
Figura 31 - Seleo dos vrtices abdominais (em rosa) do objeto Corpo para ser vinculado ao osso (Bone) chamado abdmen.
O Timeline do Blender produz a animao do jogador inimigo. Iniciando no quadro 1, Start:1, e termina no quadro 20, End:20, sua durao de 0.8 segundos. Na figura 32, o quadro 1 representa o inicio da animao, ento o inimigo colocado em uma pose de inicializao e o quadro 1 eleito como quadro-chave para capturar a pose do inimigo. No quadro 5 a pose do inimigo foi modificada para dar seqncia na dinmica da caminhada. Com esta nova pose acionado outro quadro-chave no quadro 5. Na figura 33 ocorre a seqncia da caminhada.
Figura 32 - Quadros-chaves 1 e 5.
47
Figura 33 - Criao de quadros-chaves nos intervalos 10 e 15.
No quadro 20, Figura 34, termina a animao e o ciclo da ao de caminhar est completo, pois, o inimigo voltou a pose inicial.
Figura 34 - Volta ao estado inicial.
48
No Timeline, a rgua de tempo 0.0 a 0.8 ativada para animar o inimigo, as linhas azuis verticais representam os quadros-chaves criados no intervalo. O quadro 1 foi criado em 0.0 segundos, quadro 5 em 0.2 segundos, quadro 10 em 0.4 segundos, quadro 15 em 0.6 segundos e quadro 20 em 0.8 segundos. A linha vertical verde representa a posio da animao em relao ao tempo e o quadro correspondente. Na Figura 34, a linha verde est posicionada na posio quadrado 20 tempo 0.8 segundos. Ao ativar a animao os quadros restantes se completam. Por exemplo: do quadrochave 1 at o quadro-chave 5 os quadros que esto no intervalo so completados automaticamente. O deslocamento das pernas do jogador passam do quadro 1 para o quadro 2, 3 e 4 at 5 de uma forma suave e contnua. Na seqncia o deslocamento das pernas esto direcionadas do quadro 5 para o quadro-chave 10, ocorrendo o deslocamento das pernas nos quadros deste intervalo. Esta dinmica ocorre at o quadro 20 e termina a ao e cada perna executa um passo completo. Acionando a animao de forma continua cria-se a sensao da ao de caminhar. importante notar que apenas est correndo a animao de caminhar, ele no possui a ao de deslocamento pelo cenrio, o deslocamento ser criado pelo cdigo Python.
8.3 Iintegrando cdigo Python, algoritmo A* e personagens
O cdigo Andar.py desenvolvido em Python serve para controlar inimigo dentro do cenrio. O algoritmo A* (A estrela) foi remodelado devido a no eficincia em algumas situaes conforme est relatado na seo de testes. O conceito do algoritmo continua A*. A Figura 35, mostra o cdigo Andar.py importando as bibliotecas para execuo de alguns comandos, capturando informaes do sensor e atuador atravs da hierarquia GameLogic. Em seguida, est se desmembrando as posies de deslocamento e rotao do jogador, inimigo e vazio. Em if clic.isPositiove( ): est se definindo que, caso o mouse seja acionado, o objeto vazio recebo os dados da posio do jogador, valores em A e valores em B. Os nomes sensor, Empty, Cube e Armature em vermelho so nomes dos objetos criados atravs dos Blocos lgico da Figura 36.
49
Figura 35 - Parte do cdigo Andar.py, capturando dados.
Figura 36 - Sensor: nome do Sensors Mouse ligado ao objeto Vazio
50
O algoritmo A* consiste em capturar a posio e orientao do jogador, inimigo, objeto vazio e verificar o estado do mouse. Foi organizada uma seqncia de nmeros que representam a posio de um objeto no jogo. Por exemplo: pedra=[20,05], na posio eixo X=20 e eixo Y=05 representa o obstculo pedra e quando a posio do inimigo, tambm atravs de orientao X e Y, for igual a da pedra significa posio proibida para inimigo, ele deve desviar esta posio. Outro controle ser aquele caso o inimigo esteja na mesma posio do ltimo disparo do jogador representado pelo objeto vazio. Quando o inimigo chegar na posio do objeto vazio, ele deve andar em direo a outra posio escolhida de forma aleatria entre quatro posies, onde cada uma estar localizada em um canto do cenrio. Em seguida, o algoritmo verifica as posies que esto em volta do inimigo (frente, atrs e dos lados) Figura 37, e atribui um peso. Os valores do eixo C e D do objeto vazio representam a posio do ltimo disparo do jogador dentro do jogo e elas so comparadas com os eixos X e Y do inimigo. Dependendo da combinao, por exemplo: eixo X do inimigo igual ao C do vazio e eixo Y do inimigo maior do que eixo D do vazio, ento se aplica o valor definidos no algoritmo calculando a distncia entre inimigo e vazio (PeI) e aplicando o valor 2 a distncia para representar o maior peso: PI00=PeI +2. Na seqncia organizada uma lista que representa as posies em volta do inimigo com peso, posio X e posio Y. As variveis PI00, PI01, PI02, etc, representam as posies frente, atrs e lados do jogador inimigo. Figura 38.
Figura 37 - Atribuio de pesos para as posies em volta do inimigo.
Para contornar objetos verificado as posies em volta do inimigo (frente, atrs e dos lados), se existir uma posio pedra (vista anteriormente) com os mesmos valor de uma
51
posio em volta do inimigo acrescentado um peso de 40 a distncia desta posio. Agora a lista de posio em volta do inimigo est atualizada com o peso da distncia ou peso do obstculo, e a posio. Por exemplo: PosioFrenteEsquerda[peso,X,Y],
PosioFrente[peso,X,Y], PosioFrenteDireita[peso,X,Y] ou [PI00,X00,Y00], etc. PoI o conjunto das posies do inimigo.
Figura 38 - Algoritmo com a posio do jogador inimigo.
Os valores de X e Y do vazio so comparados com o X e o Y do inimigo novamente. Em seguida, verificado qual o menor peso entre as trs posies mais baixa. Por exemplo: se a PosioFrenteEsquerda tiver o peso menor do que a PosioFrente, ento, a orientao acionada para que o inimigo fique voltado para a menor posio, depois acionado o deslocamento do inimigo. A frente do inimigo est voltada para o eixo Y. Figura 39. A seta verde representa o eixo Y do inimigo apontando para a menor posio que o inimigo pode ir. Se ela estive-se voltada para baixo sua rotao seria de zero grau, como est voltada para cima sua rotao de 180 graus. Em comparao com a ltima posio do inimigo, no caso 135 graus, acionada a rotao para alinhar o inimigo com sua nova direo, depois se aciona o deslocamento no eixo Y para o inimigo simular uma caminhada para frente.
52
f(n)10 PI00
f(n)09 PI002
f(n)10 PI03
f(n)11 PI04
f(n)11 PI06
f(n)12 PI07
f(n)11 PI08
f(n)12 PI09
f(n)10 PI00
f(n)09 PI01
f(n)10 PI02
f(n)11 PI03
f(n)11 PI06
f(n)12 PI07
f(n)11 PI08
f(n)12 PI09
Figura 39 - Vista superior cdigo Python verificando caminho. Menor distncia.
Os demais cdigos ApareceMouse.py e SaiMouse.py e Mouse.py, servem apenas para deixar o mouse visvel nos menus, invisvel durante o jogo e atualizar a posio cmera do jogador com as teclas de direo.
8.4 Descrio dos objetos lgicos do aplicativo Blender
8.4.1 Objeto Jogador
53
O objeto que representa o jogador o objeto Jogador, ele feito a partir de um cubo. Para manipular a cmera como se fosse a viso do jogador o cubo deve andar pelo cenrio e atravs dos sensores, controladores e atuadores ler as entradas do teclado para orientar a direo. Os sensores Keyboard chamados de sobe, desce, esq, dir esto todos ligados a um controlador Python e, ao mesmo tempo, cada sensor est ligado a um controlador AND e a um atuador do tipo Sound que executa um arquivo de som chamado Caminha.wav. Ele toca um som de passos que executado em Loop Stop, ou seja, executa de forma repetida do inicio ao fim em quanto a tecla correspondente estiver pressionada. Figura 40.
Figura 40 - Funes do objeto Jogador (cor rosa).
O controlador Python est associado a um atuador Motion, chamado de vai, para capturar as variveis de posio e rotao do objeto. A manipulao dos dados feita exclusivamente pelo cdigo Python chamado de Movimento.py, ele executa movimento de deslocamento e rotao do Jogador. Na Figura 41, o cdigo importa as bibliotecas necessrias
54
e captura o objeto Jogador em uma varivel chamada de Valor. A varivel cont captura as informaes dos sensores do objeto, por exemplo: a varivel so captura as informaes do sensor chamado sobe. Logo a baixo, o selecionador if (em vermelho) est associada a uma funo so.isPositive() que verifica se o mouse foi acionado com a tecla sobe, se confirmado ento ocorre o deslocamento no eixo Y com a intensidade 0.1. Se outra tecla for pressionada o cdigo executa o selecionador apropriado e, em seguida, as informaes so atualizadas na varivel Valor, para ocorrer o movimento de deslocamento desejado pelo jogador.
Figura 41 - Cdigo Movimento.py
Outra funo do objeto Jogador a capacidade de rotacionar sobre seu eixo Z como se o jogador estivesse virando o corpo em direo ao seu alvo. Figura 42.
55
Figura 42 - Seta azul indica eixo Z, seta vermelha eixo X e verde eixo Y.
Vinculado ao objeto Jogador foi criado um Add Property do tipo Float com nome de rot, ver Figura 43, para acumular valores. Um sensor Always sempre verifica o atuador Ipo do tipo Property atuando sobre a propriedade rot. Valores do movimento de rotao sero acumulados nesta propriedade. O movimento de rotao do objeto Jogador feito selecionando o eixo RotZ no display Ipo Curve Editor. Os valores mnimos e mximos de rotao dos eixos X e Y so respectivamente -180 a 180, -18 a 18. A faixa de rotao permite o objeto girar de um lado para o outro apenas entre estes valores e seu valor atual ser passado para o rot. A fsica do objeto Jogador dinmica. Seu peso de 20 e Radius 1.30, significando a distncia de coliso para qualquer outro objeto. Ela representada pela circunferncia dentro do objeto jogador. Figura 43. A gravidade igual a do planeta terra 9.80.
56
Figura 43 - Jogador (Cube)
O objeto cmera chamada de Cmera est ligado diretamente ao objeto Jogador, qualquer movimento efetuado por ele acompanhado pela cmera. O parentesco entre eles o pai objeto Jogador e o filho objeto Cmera. O sensor criado e vinculado a cmera um sensor Always e est sempre verificando o atuador Ipo com propriedade chamada de rot. Esta propriedade criada em Add Prorerty, ela do tipo Float com nome rot e acumula os valores do deslocamento da cmera, pois est vinculado a ela. Seu deslocamento ser de cima para baixo e para gerar este movimento foi utilizado o Ipo Curve Editor. Os valores de faixa para o movimento ficaram ente X mnimo -60 e X mximo 89, Y mnimo -2 e Y Maximo 12. A cmera tambm possui um atuador Mouse que captura o movimento do mouse e joga em um controlador do tipo Python. O cdigo deste controlador, Figura 44, se chama mouse.py e serve para passar a sensao inversa ao mouse deslocando-se pela tela do computador, o mouse fica fixo no centro da tela e a imagem se desloca para enquadrar o mouse no centro da tela. Realmente o mouse est se movendo, porm com a tela fixa nele.
57
Figura 44 - Cdigo mouse.py Fonte: ENGASGAMES(2008)
A arma do jogador no possui nenhuma funo lgica, porm, ela filha da cmera e qualquer movimento da cmera a arma tambm acompanha. Existe um objeto vazio filho, Figura 45, ligada a arma e posicionado em sua frente, ele possui um sensor do tipo mouse que captura um acionamento da tecla esquerda do mouse e passando por um controlador END aciona um atuador Editor de Objetos, Edit Object, do tipo Adiciona Objeto, Add Object, fazendo o objeto aparecer na tela principal no lugar do vazio. No caso, o objeto que aparece ser o objeto Bala. Ao mesmo tempo envia uma mensagem, atuador Message, para outro sensor de outro objeto. Esta mensagem se chama 1 e significa a tecla esquerda do mouse foi pressionada.
58
Figura 45 - Objeto vazio ligado a arma. A seta vermelha indica a cena ativa ou tela principal do jogo.
O objeto que aparece na tela principal chama Bala e est em um Layer invisvel, uma tela na mesma sena que no est ativa, os objetos deste layer no esto aparecendo no jogo. Quando a tecla esquerda do mouse pressionada a Bala aparece na tela principal. Esta bala sempre Always executar um movimento de deslocamento no eixo Y com velocidade 1.00, Figura 46.
59
Figura 46 - Layer onde o objeto Bala (em vermelho com pontinho rosa ) est quando no chamado.
8.4.2 Objeto inimigo
Todos os sensores do jogador inimigo esto ligados a armadura dele, Armature, ela a estrutura pai de todos os outros objetos ligado ao inimigo como objeto chapu, objeto pele, etc. O objeto Armature a estrutura do jogador inimigo, Figura 47. Nele est ligado um sensor Mouse que verifica se o boto esquerdo foi pressionado. Se foi pressionado a informao enviado para o cdigo Python chamado Andar.py que calcula as posies do jogador e do inimigo e efetua a ao de caminhar. O sensor que encontra o jogador no cenrio o sensor de aproximao Near ligado a armature. Quando o objeto Jogador se aproximar a uma distncia de 30 metros do jogador, no caso cada unidade representa 1 metro, ento o sensor acionado e atravs de um controlador AND aciona um atuador Edit Object, do tipo Track To, que faz o Armature sempre aponta seu eixo Y para o jogador dentro desta distncia. O arquivo Andar.py apenas aciona o deslocamento do inimigo e no avalia o caminho at o jogador, ele deixa isto para o sensor. H um objeto vazio, chamado de Empty.001, ligado ao esqueleto e seu sensor um Ray que emite um raio com distancia de 30 metros.O controlador ser acionado somente se o raio encontrar um objeto especifico com a propriedade chamada de rot que pertence ao objeto Jogador. Encontrando o jogador o atuador executa um Edit Object, que adiciona um objeto,
60
Add Object, chamado Bal que est invisvel em outra tela. Esta estrutura serve para disparar a bala do jogador inimigo. Ao mesmo tempo, um atuador Message envia uma mensagem para outro objeto, ela chamada de 11. Com a aproximao do jogador o sensor Near deixa alinhado o inimigo com o jogador. O objeto Empty.001, Figura 48, ligado ao inimigo tambm est alinhado nesta posio, logo, quando o sensor Ray bate no jogador ele disparado um objeto Bal. Bal transportada para a tela principal e executa um deslocamento com velocidade 1.00. O tiro do inimigo.
Figura 47 - Conjunto de sensores e atuadores do objeto Armature.
Figura 48 - Sensores e atuadores ligados aos objetos Empty.001.
61
Figura 49 - Objeto Empty.001(Vazio) filho ligado ao esqueleto (Armatrure) do jogador inimigo, embaixo da textura de camuflagem.
8.4.3 Objeto vazio
H trs objetos vazio no jogo que servem como referncia para os blocos lgicos e o cdigo Python. H dois vinculados um jogador e outro ao inimigo, eles servem como referncia para quando ocorrer o disparo da arma de amos. O terceiro objeto vazio reservado para referenciar o caminho analisado pelo inimigo. Quando o jogador dispara um tiro clicando com o boto esquerdo do mouse o cdigo captura a posio do jogador e atribui o valor para o objeto vazio, ento, ele assume a posio do jogador. O inimigo analisa o melhor caminho e parte na direo do vazio, independente do jogador estar l ou no. Se o jogador dispara outro tiro o processo repetido. O objetivo deste cdigo simular o inimigo ouvir o disparo e andar na direo do som, propiciando ao jogador realismo na experincia. O inimigo sempre descobre a posio do jogador atravs do disparo do tiro. Sempre que o inimigo chegar na posio do objeto vazio sem encontrar o jogador o vazio colocado em uma posio estabelecida do cenrio. Esta funo representa o inimigo no saber onde o jogador se encontra, ento ele vasculha o cenrio at detectar o jogador atravs do sensor Near ou Ray.
62
8.4.4 Objeto contador de munio e vida
O objeto Vida e o objeto Munio, os nmeros que contam a quantia de munio e a quantia de vida do jogador, so feitos pelo UV Calculation, com uma imagem de uma letra em um fundo preto, geralmente @ (arroba), colada em um objeto plano. No Edit Mode, com o plano selecionado, no menu Editing e em Texture Face, as opes Alpha, para deixar o objeto transparente onde a cor for preto e Text, para editar textos durante o jogo so selecionados e depois adicionada uma propriedade, Add Property do tipo inteiro, Int, com o nome de Text que ser utilizada para acrescentar ou diminuir valores ligado ao objeto Vida. Na Figura 50, a propriedade em Add Property chamada Text est com a capacidade de vida 10. Nesta figura, O sensor Message chamado sensor recebe uma mensagem de outro objeto, esta mensagem se chama 2, Subject:2. Este outro objeto acionado quando ocorrer a coliso do projtil inimigo com o corpo do jogador, ele emitir uma mensagem chamada 2, ao mesmo tempo, o objeto Vida receber esta mensagem atravs do sensor Message e executa um atuador Property chamado act. Este atuador tem a caracterstica Add, sempre efetua uma adio na propriedade chamada Text e o valor sempre -1(menos um), ou seja, uma contagem regressiva. O contador chegando a zero acionando outro sensor chamado de sensor 1 que um Property, ele est relacionado com a propriedade Text e quando Text estiver em zero o sensor sensor 1aciona um controlador do tipo AND ligado a um atuador, que encerra o jogo.
63
Objeto Vida
Figura 50 - Contador decrescente da vida.
Para contar a munio do jogador criado em Add Property uma propriedade do tipo Int, inteiro, com nome Text ligado ao objeto Munio e com capacidade para 10 tiros, conforme a Figura 51. O primeiro sensor do objeto Munio um Message e se chama 1 Subject:1, o objeto que envia esta mensagem para ele o vazio responsvel pelo disparo do tiro, quando este ocorrer. Ao receber a mensagem do disparo o Subject :1 executa um atuador Property com caracterstica Add, de somatrio, e vinculado a propriedade Text com valor de -1 (menos um). Executando uma contagem regressiva na propriedade Text da munio. Ao mesmo tempo executa o som do disparo.
Objeto Munio
Figura 51 - Contador de munio
64
8.4.5 Objeto menu
Os menus foram desenvolvidos a partir de objetos planos. O mapeamento UV Calculation foi aplicado em sua face e a viso do menu de cima para baixo. Cada objeto possui um tipo de sensor, no caso do objeto Plane.001, com a imagem escrita New Game, os sensores vinculados ao plano foram um Mouse para executar uma animao e outro mouse do tipo Left Button para acionar outra cena quando o boto esquerdo do mouse for acionado. O primeiro sensor Mouse do tipo Mouse over para executar a animao apenas quando o mouse estiver sobre o objeto Plane.001. Como est na Figura 52, a ligao do sensor chamado sensor convergem para a animao e para o controlador do sensor sensor1. Significa que para trocar de cena o mouse deve estar sobre o objeto e ser clicado com o boto esquerdo ao mesmo tempo. Aps acionar o menu New Game a cena que aparece para o jogador Carregando, e esta aciona o jogo. O ttulo no tem funo lgica e os demais objetos do menu direcionam o jogador para cenas especficas.
Figura 52 - Menu.
65
As cenas no Blender, Figura 53, servem para organizar as sees do projeto. No jogo a cena Menu Principal onde se encontra o menu e onde se encontra o jogador antes de iniciar a partida. Escolhendo iniciar a partida ele direcionado para a cena Carregando. Esta serve apenas como transio entre MenuPrincipal e o Jogo, Na verdade, a cena Carregando possui uma funo esttica, a imagem Laoding fica travada enquanto o software carrega outra cena.
Figura 53 - Cenas
66
8.5 Testes na fase de construo
Caso de teste: CT2 Cenrio/Condio: Distancia em linha reta entre inimigo e jogador sem obstculo. Entradas: Jogador prximo ao inimigo. Jogador a uma distncia mdia em relao ao inimigo. Jogador longe do inimigo. Resultado: Em todos estes casos o inimigo encontra o jogador e anda em sua direo. O algoritmo se mostra muito deficiente quando o jogador est a uma distncia mdia ou longa do inimigo. Visualmente a ordenao da rota mais longa deixa o jogo travado, como se estivesse em cmera lenta. A ordenao utiliza muitos comandos for. Este comando no jogo foi utilizado para procurar dados especficos em uma lista percorrendo ela ou ento, ordenar nmeros desordenados em outra lista, por exemplo: uma lista que recebe nmeros aleatrios deve ser ordenada de forma crescente, ou ento, deve ser encontrado um nmero em especfico nesta lista. No algoritmo A* so criadas vrias listas: uma para guardar valores temporrios, outra para guardar valores permanentes, outras listas so criadas como piv para serem utilizados na lista temporria e outras so criadas para recolher dados atualizados. O algoritmo construdo utiliza muito for percorrendo listas dentro de listas, com isto, o processador ocupado exclusivamente com elas deixando as funes do jogo em um segundo plano. O jogo parece estar em cmera lenta porque a consulta das listas ocorre de forma contnua prejudicando a dinmica do jogo. Em distncias curtas ocorriam o mesmo processo, porm, so poucos nmeros dentro das listas envolvidos no for. O tamanho das listas diminuiu em funo de ser uma distncia curta. Visualmente para o jogador o efeito de cmera lenta no era notado.Tabela 4 - Caso de teste na fase de construo.
67
9 FASE DE DISTRIBUIO
Nesta fase o jogo ser disponibilizado para o usurio final. A implantao consiste em apenas desenvolver um arquivo executvel para ser utilizado em qualquer computador com sistema operacional Windows. Ele prtico para o usurio porque sua instalao fcil, basta ter os arquivos em seu computador e clicar no arquivo com extenso EXE e o jogo ser inicializado. Para construir este arquivo foi utilizada a funo Save Runtime do Blender e de forma automtica o arquivo executvel gerado. Para o jogo ser executado em qualquer computador com sistema operacional Windows foi criado uma pasta com o nome do jogo e dentro dela colocado o arquivo executvel com os arquivos pthreadVC2.dll, python26.dll e o arquivo compactado zip python25, todos extrados do Blender. Esta pasta pode ser instalada em qualquer computador e executado o jogo independente do Blender ou Python estar instalados na mquina.
68
10 CONCLUSO
Este trabalho demonstrou a viabilidade de construir um jogo para computador utilizando tecnologia gratuita com a filosofia de software livre. Os softwares utilizados se mostraram teis e apropriados para o desenvolvimento de jogos profissionais. A inteligncia artificial do jogo foi destacada atravs do algoritmo A*, responsvel pelo inimigo procurar o jogador durante o jogo. Foi demonstrado o conceito, a descrio do algoritmo e a implantao no software. O comportamento do jogador inimigo durante a execuo do jogo se mostra satisfatria, seu objetivo de andar e procurar o jogador pelo cenrio foi atingido. Porm, em certos momentos, o movimento lembra a aparncia de um rob e seu deslocamento, em um de seus eixos faz o inimigo girar sem sair do lugar. Isto ocorre porque o algoritmo esta definindo o melhor caminho e geralmente ocorre quando no esta no campo de viso do jogador, sendo irrelevante para o desenvolvimento da partida. O estudo sobre o que atrativo em um jogo para o usurio tambm foi levado em conta. Como se trata de um prottipo, no foram desenvolvidas fases no jogo e nem desafios complexos. O que foi levado em considerao sobre a jogabilidade foi o estudo da interface, projetada para ser intuitiva e prtica para o usurio. Os comandos foram projetados de forma simples e direta. Nos testes com usurios ficou claro a facilidade de manipular o menu e atuar durante o jogo, pois, as teclas de controle do jogo foram dispostas iguais a maioria dos jogos de tiro em primeira pessoa disponvel no mercado. A estrutura do projeto utilizando RUP foi adequada, pois as fases de desenvolvimento proporcionaram uma viso clara e objetiva do software. Em cada fase ficou evidente a evoluo do projeto. Na fase inicial a coleta dos dados, fornecendo os objetos de como seria o jogo. Na fase de construo representando como passar estas idias para o papel, de forma clara e em uma linguagem acessvel para todos. Na fase de construo o desenvolvimento do software em si e na fase de distribuio a entrega do produto. Como concluso, construir um jogo simples, com boa histria, personagens interessantes e uma jogabilidade fcil um caminho possvel economicamente para se produzir um jogo popular. E explorar estes itens em detrimento de grficos poderosos vivel, pois, um jogo depende da combinao harmoniosa de todos os elementos para se tornar um jogo de sucesso.
69
REFERNCIA
LARMAN, Craig. Utilizando UML e Padres. Porto Alegre: Bookman, 2007. RUSSELL, Stuart; PETER, Norvig. Inteligncia Artificial. Rio de Janeiro: Elsevier, 2004. LUTZ, Mark; ASCHER, David. Aprendendo Python. Porto Alegre: Bookman, 2007. BRITO, Alan. Blender 3D Guia do Usurio. So Paulo: Novatec Editora, 2008. SCHUYTEMA, Paul. Design de Games um Abordagem Prtica. So Paulo: Cengage Learning, 2008. MARTINS, Jos Carlos Cordeiro. Gerenciando projetos de desenvolvimento de software com PMI, RUP e UML. Rio de Janeiro: Brasport, 2004. DEITEL, H. M. Java como programar. So Paulo: Pearson Prentice Hall, 2005. GLOBO, Rede. Sony quer brasileiros na produo de jogos para o PlayStation. G1, out. 2009. Disponvel em : Acesso em: 26 set 2010. CHANNEL, Discovery. A Era do Videogame, mai. 2007. Disponvel em:
. Acesso em: 29 set. 2010. CLUA, Esteban Walter Gonzalez BITTENCOURT Joo Ricardo. Desenvolvimento de jogo 3D: Concepo, design e programao. Universidade do Vale do Rio dos Sinos, jul. 2005. Disponvel em:. Acesso em: 22 out. 2010. PROCEDURALBASE. Hierarquia no Game Engine. Blender Game Engine, mai de 2007. Disponvel em: . Acesso em: 25 set. 2010. WTHREEX. Rational Unified Process: Fases. Rational Software Corporation, verso 2002.05.00. Disponvel em: . Acesso em: 25 set. 2010. LESTER, Patrick. A* Pathfinding para Iniciantes. Policyalmanac, jun de 2005. Disponvel em: . Acesso em: 25 set. 2010. DSENHEPINTE. Figura Humana Propores. Aprenda Pintura e Desenho, set de 2008. Disponvel em: . Acesso em: 02 out. 2010.
70
MOREIRA, Altamir. Proporo do rosto humano. Arteamil, jan de 2008. Disponvel em: . Acesso em: 02 out. 2010. SOUSMAN. Ciclo de caminhada. Sousman, mar de 2008. Disponvel em:
. Acesso em: 02 out. 2010. TERRESTRES, Foras. Os principais fuzis em uso no mundo: Leia, comente e vote na enquete. Foras Terrestres, abr de 2009. Disponvel em:
. Acesso em 02 out. 2010. ENGASGAMES. Mouse look no Blender Game Engine. EngasGames, mar de 2008. Disponvel em: . Acesso em 24 out. 2010. UOL. Anlise, PC Medal of Honor. Jogos UOL, out de 2010. Disponvel em: . Acesso em 15 de nov. 2010.
71
ANEXOS
72
ANEXO A Descrio do software
Escopo: aplicao Jogo Selva. Nvel: objetivo do usurio. Interessados e Interesses: Jogador, tambm chamado de Observador. Deseja observar as sadas da simulao do jogo. Principal cenrio de sucesso: 1 Observador solicita um jogo novo.
2 Observador comea a jogar, caminhando e atirando no cenrio. 3 O sistema ativa ao conforme o tipo de interao do jogador, tanto do observador como do inimigo. As aes sero definidas posteriormente. Repetir passo trs at encontrar vencedor ou Observador cancelar. Requisitos Especiais: Disponibilizar modos de rastreamento grfico e textura.
Quadro 5 - Tabela de caso de uso
73
ANEXO B Descrio do jogador, inimigo e cenrio
Ator: Jogador Processo Escolher Menu: Ao iniciar o jogo, o jogador (observador) encontra o menu principal com as funes de iniciar o jogo, verificar crditos ou ento sair do jogo. Optando por iniciar o jogo a prxima tela o observador estar dentro do jogo interagindo com o cenrio. Pressionando uma tecla pr-determinada ele volta ao menu principal. Optando por ver crditos visualizado dado sobre o autor e o software, com uma tecla pr-definida volta ao menu principal. Optando por sair, o jogo encerrado.
Ator: Jogador Inimigo (sistema) Processo Jogar: Durante a partida o inimigo sempre caminha pelo cenrio e verifica se o jogador est em sua frente; se estiver, ele dispara a arma. O inimigo caminha para a posio que o jogador se encontrava no inicio do jogo. Caso ocorra um disparo da arma do jogador o inimigo caminha para esta posio. Se o jogador no for encontrado nesta ltima posio o inimigo se desloca aleatoriamente pelo cenrio procurando ou aguardando um tiro do jogador. Se o inimigo estiver a uma distncia mnima do jogador automaticamente ele efetuar a mira e dispara tiros. Saindo desta distncia mnima o inimigo volta a seguir o seu caminho, independente da localizao do jogador. Se alguns tiro do inimigo acertar o jogador o jogo termina.
Ator: Jogador Processo Jogar: Durante a partida o jogador pode se deslocar para qualquer lugar do cenrio. Ele no consegue atravessar rvores ou paredes. Os disparos da arma ocorrem um por vez. Ao acertar alguns tiros no inimigo ele morre e o jogo termina.
Quadro 6 - Alguns casos de uso: processo escolher menu e jogar