FELIPE ROBERTO MIOTO
ESTRUTURA DE UM JOGO 2D
Florianópolis 2010
FELIPE ROBERTO MIOTO
ESTRUTURA DE UM JOGO 2D
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Ciências da Computação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharelado em Ciência da Computação.
Orientador: Ricardo Villarroel Dávalos
Florianópolis
FELIPE ROBERTO MIOTO
ESTRUTURA DE UM JOGO 2D
Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharelado em Ciência da computação e aprovado em sua forma final pelo Curso de Graduação em Ciência da Computação da Universidade do Sul de Santa Catarina.
________________, ______ de _________________ de 20 ____ Local dia mês ano
_________________________________________________________ Professor e orientador Ricardo Villarroel Dávalos.
Universidade do Sul de Santa Catarina
_________________________________________________________ Membro da Banca Mauro Madeira.
Universidade do Sul de Santa Catarina
_________________________________________________________ Membro da Banca Jayson Nienkotter De Melo.
RESUMO
Este trabalho apresenta o desenvolvimento da estrutura de um jogo 2D Side-Scrolling, utilizando a linguagem C++, Code::Blocks e a biblioteca gráfica Allegro. Todo o projeto é montado sobre Windows, porém pode ser perfeitamente válido para outras plataformas. O jogo tem semelhanças com outros, tais como Mario Bros e Sonic, mas sua proposta HackAndSlash se assemelha mais com títulos como Castlevania e Diablo. Um Side-Scrolling é um dos projetos de jogos 2D mais complexos de serem desenvolvidos devido principalmente a liberdade de movimento e ações dada ao jogador. Esta monografia visa documentar de um ponto de vista estritamente técnico os principais processos para a criação desta estrutura, para isso o jogo é dividido em três camadas: Gráficos – parte que gerência a arte e imagens da tela, Engine – parte que controla as equações de fundo como a física e Jogo – parte que representa o conteúdo que o jogador irá interagir. São diversos os processos que englobam a estrutura do jogo aqui criado, sendo dentre eles: Interação com IA, Física para jogos, animação, interface humano-computador e até mesmo alguns conceitos de game-design. Enfim, os dados levantados e documentados possuem um objetivo didático e visam apresentar um material organizado para ajudar estudantes de programação brasileiros que queiram ingressar na indústria do entretenimento através dos jogos digitais.
LISTA DE ILUSTRAÇÕES
Figura 1 – Modelo organizacional do projeto ... 17
Figura 2 – Exemplo de Animação ... 21
Figura 3 – Etapas Metodológicas... 36
Figura 4 – Proposta de Solução ... 38
Figura 5 – Game Flow... 43
Figura 6 – Colisão ... 48
Figura 7 – Adicionamento de scrolling ... 52
Figura 8 – Máquina de estados 01 ... 57
Figura 9 – Tecnologias utilizadas ... 66
Figura 10 – Metodologia RUP... 67
Figura 11 – Esquema dos componentes ... 71
Figura 12 – Validação dos componentes ... 74
Figura 13 – Blocos de Saúde ... 75
Figura 14 – Menu Inicial ... 78
Figura 15 – Stage Clear ... 79
LISTA DE QUADROS
Quadro 1 – Código de movimentação para a direita... 45
Quadro 2 – Código de colisão ... 49
Quadro 3 – Código de scrolling ... 54
Quadro 4 – Principais requisitos funcionais ... 62
Quadro 5 – Principais requisitos não funcionais ... 63
Quadro 6 – Principais Regras de Negócio ... 64
TERMOS TÉCNICOS E ABREVIAÇÕES
AAA – Jogos de grande porte, geralmente levam de 1 a 3 anos para serem desenvolvidos e custam vários milhões de dólares.
Biblioteca – Na linguagem C/C++ uma biblioteca engloba um conjunto de funções úteis que podem ser incorporadas a uma outra aplicação.
Buffer – Neste caso um buffer armazena várias imagens em uma única “folha digital”, com o intuito de aplicar estas imagens na tela de uma só vez.
Engine – Representa o “motor” de um jogo, englobando o funcionamento interno de um jogo e que geralmente possuem um teor de mais baixo nível.
GameFlow – Corresponde ao fluxo do jogo, ou seja, a seqüência de ações que o jogador pode ou deverá tomar no decorrer da experiência.
GamePlay – referente a parte “jogável” do jogo, diz respeito a interação que o jogador final deve ter com o jogo, não engloba as partes técnicas de mais baixo nível da aplicação.
HackAndSlash – Categoria de um jogo, representa jogos onde a principal experiência do jogador será despachar grande número de inimigos, assim como em jogos como Diablo e Castlevania.
IA – Sigla para inteligência artificial. IA primeiramente é um conjunto de técnicas, porém várias vezes neste projeto se usa esse termo para referenciar o sistema de Inteligência artificial em si, isso devido a tradição da área em usar o termo nestas condições.
RGB – Formato para atribuir uma cor a um pixel da tela usando uma combinação das cores primárias: vermelho, verde e azul.
Side-Scrolling – Categoria de um jogo, representa jogos onde o cenário se move lateralmente no decorrer do jogo, assim como em jogos como Mário Bros e Sonic.
SUMÁRIO 1 INTRODUÇÃO ... 10 1.1 PROBLEMÁTICA ... 12 1.2 OBJETIVO ... 13 1.2.1 Objetivos Específicos ... 13 1.3 JUSTIFICATIVA... 14 1.4 ESTRUTURA DA MONOGRAFICA ... 15 2 REVISÃO BIBLIOGRÁFICA ... 17 2.1 GRÁFICOS... 18
2.1.1 Carregamento e Impressão de imagens ... 18
2.1.2 Buffers ... 20
2.1.2 Animações ... 21
2.2 ENGINE ... 22
2.2.1 Física Para Jogos ... 23
2.2.1.1 Colisão ... 24 2.2.1.1.1 Bounding Box ... 24 2.2.1.1.2 Bounding Circle ... 25 2.2.1.1.3 Heavy Bound ... 25 2.2.1.1.4 Pixel Perfect ... 26 2.2.1.2 Gravidade ... 26 2.2.1.3 Ação e Reação ... 27 2.3 JOGO ... 28
2.3.1 Inteligência Artificial (IA) ... 28
2.3.1.1 Máquina de Estados Finitos (ME) ... 29
2.3.1.2 Algorítimo Genético ... 30 2.3.1.3 Rede Neural ... 31 2.3.1.4 A* PathFinding ... 32 2.4 CONCLUSÕES DO CAPÍTULO ... 33 3 MÉTODO ... 35 3.1 ETAPAS METODOLÓGICAS ... 35 3.2 PROPOSTA DE SOLUÇÃO ... 37 3.3 DELIMITAÇÕES ... 39
4.1 GAME FLOW ... 41
4.2 GERÊNCIA DE INPUT ... 44
4.3 COLISÃO BOUNDING BOX ... 47
4.4 SCROLLING ... 51
4.5 INTELIGÊNCIA ARTIFICIAL (IA) ... 52
4.6 TIMER... 59
4.7 LEVANTAMENTO DE REQUISITOS ... 61
4.7.1 Principais Requisitos Funcionais ... 62
4.7.2 Principais Requisitos Não Funcionais ... 63
4.7.3 Principais Regras de Negócio ... 63
4.8 CONCLUSÕES DO CAPÍTULO ... 64
5 DESENVOLVIMENTO ... 65
5.1 TECNOLOGIAS UTILIZADAS ... 65
5.2 PROCEDIMENTOS METODOLÓGICO UTILIZADO ... 67
5.2.1 Concepção ... 68 5.2.2 Elaboração ... 68 5.2.3 Construção ... 69 5.2.4 Transição ... 69 5.3 DESCRIÇÃO DO SISTEMA ... 70 5.4 VALIDAÇÃO ... 72
5.4.1 Apresentação macro dos componentes ... 74
5.4.2 Sistema de Saúde ( 1 ) ... 75
5.4.3 Sistema de Inventário ( 2 e 5 ) ... 75
5.4.4 Sistema de Scrolling ( 3 ) ... 76
5.4.5 Colisão com Máquina de Estados seguida de Ataque ( 4 ) ... 76
5.4.6 Tela de Menu Inicial ... 77
5.4.7 Telas de Score ... 78 5.4.8 Animação ... 80 5.5 CONCLUSÕES DO CAPÍTULO ... 81 6 CONCLUSÃO E RECOMENDAÇÕES ... 82 6.1 CONCLUSÕES ... 82 6.2 RECOMENDAÇÕES ... 83 REFERÊNCIAS ... 84 Apêndice A ... 86
1 INTRODUÇÃO
Este trabalho visa compreender o desenvolvimento de uma estrutura para a criação de um jogo e as dificuldades técnicas encontradas, para isso, esta estrutura foi separada em 3 blocos principais: gráficos, engine e jogo.
A parte que diz respeito a gráficos trata de como o jogo irá lidar com a sua parte visual ou artística, isso diz respeito a algoritmos de impressão de imagens na tela, carregamento de imagens, animações, efeitos especiais e etc. Esta é a camada de mais baixo nível do projeto.
Uma engine se trata do “motor” do jogo, mais precisamente, ela se encarrega de cálculos matemáticos que não dizem respeito ao jogo em si, como por exemplo, o sistema de física que engloba equações de colisão, gravidade e ações e reações apropriadas para cada tipo de objeto.
Estas duas camadas abordadas (engine e gráficos) são de menor nível e geralmente ficam “escondidas” do usuário final, contudo, a camada posterior, a do jogo, representa o meio com o qual o jogador irá realmente interagir, que são aspectos como inteligência artificial, controle de movimentos, teclas, etc.
Ao decorrer da monografia, será apresentado o desenvolvimento de um jogo que visa satisfazer as necessidades básicas de um Side-Scrolling 2D, por ser 2D, significa que o mesmo não trabalha com objetos em um espaço, e sim com imagens sobrepostas criando a ilusão de espaço.
A principal diferença entre um projeto 2D para um 3D é a quantidade de dimensões em que se trabalha. Um jogo 2D possui apenas duas dimensões ( X, representando a diretriz horizontal e Y representado a vertical), sendo que um projeto 3D também inclui a diretriz Z que representa a profundidade.
Como já mencionado anteriormente, o jogo desenvolvido diz respeito a um Side-Scrolling, tal termo se refere a uma subdivisão dos jogos, correspondendo a jogos nos quais o personagem fica parado na tela e o cenário se mexe perpendicularmente à diretriz horizontal.
Do inglês, Side significa lado e Scrolling significa rolamento, ou seja, rolamento para o lado, correspondendo ao cenário se movendo para o lado à medida que o personagem avança. Exemplos de tal jogo seriam os populares Super Mario Brothers, Sonic e Contra.
Outra característica sobre o jogo desenvolvido é o enquadramento no tipo de jogo casual, que são feitos para pessoas que normalmente não possuem muito tempo livre e não podem ficar horas jogando-os. Simplificando, são jogos feitos para se jogar casualmente e não para o usuário “imergir” em sua “profundidade”.
O mercado dos jogos casuais cresce rapidamente, assim como o próprio mercado de jogos de grande porte, porém com o atual sucesso do console Nintendo Wii, ficou aparentemente claro para a grande parte dos analistas de mercado que os jogos casuais possuem ainda maior possibilidade para oferecer um empreendimento bem sucedido.
Os números são espantosos: segundo a organização, pelo menos 200 milhões de pessoas jogam títulos casuais através da internet, os quais estão substituindo a televisão como principal aliviador de estresse após uma jornada de trabalho. Só em 2007, esse mercado rendeu mais de US$ 2,25 bilhões apenas nas plataformas PC, Mac, Xbox Live Arcade e celulares. O ritmo de crescimento é de 20% ao ano. (SAMPAIO, 2008)
Analisando que jogos casuais não consomem exorbitantes quantidades de recursos e podem produzir mais dinheiro do que se pensava anteriormente, Cole (2009) escreveu “Consumidores tem uma abundância de jogos de baixo custo que cresce rapidamente” (tradução do autor), levando em consideração a atual “bolha” de jogos casuais capitaneada pelo Nintendo Wii.
Apesar de jogos casuais não possuírem o mesmo nível de complexidade que jogos de grande porte, mais comumente chamados de jogos AAA, os jogos casuais normalmente levam vários meses e quantidades expressivas de recursos para serem desenvolvidos.
Em níveis de complexidade, um jogo Side-Scrolling é considerado por muitos autores como o mais difícil jogo 2D de ser implementado, devido ao fato de unir vários elementos como Scrolling, Inteligência Artificial (IA), detecção de colisão em todas as direções, dar ampla liberdade ao jogador, dentre outras razões.
O ultimo jogo que eu sugiro você criar é um SideScroller, como Super Mario Brothers, onde você pode pular em múltiplas plataformas, atirar,abaixar-se e interagir com inimigos. Como existe arte envolvida neste jogo, eu iria sugerir o uso de SpriteLib para um simples e grátis uso de arte. (HOWLAND, 2000) (Tradução do autor)
1.1 PROBLEMÁTICA
A problemática da monografia está em documentar, solucionar e descrever os processos que compreendem a estrutura de um jogo Side-Scrolling 2D, que se mostrou desafiador devido a complexidade dos algoritmos encontrados e de não se encontrar material em abundância sobre o assunto escrito em português.
Dentre as três camadas em que foi separado o projeto (gráfica, engine e jogo), a mais complexa é a da engine. Nesta etapa está a parte da física que precisa ser posta de maneira dinâmica, isso significa imitar os eventos ocorridos na vida real e transportá-los para a aplicação, incluindo o uso de fórmulas de física da vida real.
Ao invés de desenvolver uma física dinâmica, é sempre possível tentar “forçar” eventos que deveriam ocorrer naturalmente na engine, como por exemplo: quando o personagem pular, ordenar posição por posição, que este faça uma parábola pré- estabelecida, ao invés de criar um sistema usando gravidade, aceleração e massa para calcular esta parábola.
Esta maneira estática de se demonstrar os processos não será abordada neste trabalho, visto que tal técnica não oferece suporte a um jogo de mais ampla mobilidade.
A física evoluiu muito nos jogos, e quem está ingressando somente agora na indústria, pode se sentir intimidado se começar a pesquisar em lugares poucos apropriados, assim como Zunino (2009) escreve: “Antigamente, quando se falava em física nos jogos, não se tinha nem idéia do que ela poderia vir a fazer um dia. Nem para sua principal utilidade ela era usada: collision detection”.
Dentre os setores que englobam a física de um jogo, o mais particularmente complexo de ser descrito, como abordado anteriormente por Zunino, é o de colisão, por exemplo: o personagem controlado pelo jogador encontra o chão, deve ocorrer uma colisão entre ele e o chão, impossibilitando assim que o personagem “caia da tela”.
Outra característica problemática é a de que engines complexas geralmente escondem dos usuários as suas equações mais complicadas, a fim de não criar concorrência para si mesmas com essa prática. Este trabalho visa descrever alguns destes principais processos, visando diminuir a curva de aprendizado de recém chegados nesta ramificação da tecnologia de informação.
Além da engine, o jogo também possui elementos que serão documentados aqui para o aprendizado do leitor, como um sistema de inventário, sistema de saúde, e outros aspectos amplamente utilizados no desenvolvimento de jogos digitais.
Ainda dentre os sistemas que dizem respeito ao jogo, o que mais merece ser observado com atenção é o de duas máquinas de estados opostas, uma tentando se manter perto do personagem e a outra a manter distância. A dificuldade aqui está em fazê-las cooperar de maneira efetiva e sempre reagindo às ações do próprio jogador.
Além disso, também existe a camada gráfica, que deve ter os seus críticos processos documentados apesar de que esta etapa será a única não desenvolvida neste projeto, ao invés disso se usará uma biblioteca gráfica, a Allegro, pois reimplementar instruções de tão baixo nível pode ser considerado como uma “reinvenção da roda”.
1.2 OBJETIVO
O objetivo deste trabalho é realizar um estudo, desenvolvendo uma estrutura para o funcionamento de um jogo 2D Side-Scrolling.
1.2.1 Objetivos Específicos
1 - Estabelecer um Game Play, com condição de derrota e vitória para o jogador.
2 - Construir um sistema baseado em conceitos de física, ou seja, com gravidade e outros sistemas naturais ocorrendo pelo fato de terem sido implementados individualmente e não por ilusão.
3 - Criar um sistema de colisão utilizando a técnica bounding Box em conjunto com a técnica Pixel Perfect.
4 - Criar sistema de inventário onde o usuário possa coletar, armazenar, utilizar, selecionar, e descartar itens encontrados no decorrer do estágio.
5 - Utilizar a técnica de máquina de estados, para criar inimigos no decorrer do GamePlay criado.
6 - Criar sistema de saúde que indique a energia do personagem principal, podendo cair no decorrer do jogo, ativando uma condição de derrota.
7 - Estabelecer sistema de Scrolling tal que o personagem possa se mover de maneira suave do início até o final de um longo cenário.
8. Apresentar uma documentação dos processos e soluções referentes a edição gráfica, a criação de uma engine e ao jogo propriamente dito.
1.3 JUSTIFICATIVA
Atualmente existem muitas pessoas que querem trabalhar na área de jogos, pois esta ramificação da tecnologia de informação pode oferecer uma proposta de trabalho divertido, onde existe um maior apelo gráfico/visual. Além disso, boa parte dos profissionais da área são grandes entusiastas de jogos digitais, portanto trabalham com o que gostam.
Apesar disso, é difícil para pessoas de países de terceiro mundo como o Brasil, ingressarem nesta área, existe um abismo de diferença entre a indústria Americana, Japonesa e Européia e a nossa. Fato que se comprova com a observação de que a maioria absoluta do material para estudos está em inglês.
Além disso, o ensino de técnicas relacionadas a jogos em faculdades no Brasil não é muito utilizado, sendo que atualmente poucas faculdades o disponibilizam e boa parte das que o fazem tem como objetivo não a transmissão de conhecimento e sim a cativação de alunos novos, incentivando-os a ingressar em um curso que a mesma disponibiliza.
Tendo em vista a enorme distância que existe entre a indústria de jogos estrangeira e brasileira, este trabalho, através de uma descrição dos métodos para a criação de um jogo, pode contribuir para reduzir um pouco esta diferença, podendo
auxiliar estudantes interessados no tema, mas que não encontram amplo material disponível sobre o assunto.
A idéia de se fazer um jogo Side-Scrolling surgiu também por questões didáticas, pois somente existe tempo para o desenvolvimento de um jogo, e este é exatamente o mais complexo no ramo 2D, ou seja, é o tipo de jogo que um principiante mais teria dificuldades para compreender, tornando este trabalho de maior utilidade.
Até mesmo o fato de estar sendo usada uma Biblioteca gráfica pronta e não se desenvolver uma do zero tem fundamentos didáticos, visto que este ramo já está há muito tempo saturado. Atualmente não existe razão para se redesenvolver o que já está solucionado, e o principiante deveria focar a sua atenção em questões mais imediatas e práticas.
1.4 ESTRUTURA DA MONOGRAFIA
Capítulo 1: Introdução - Este capítulo apresenta a introdução e encontra-se definido pela problemática, objetivos e justificativa.
Capítulo 2: Revisão Bibliográfica - Define o acompanhamento de revisão bibliográfica a respeito dos temas de física e manipulação gráfica, disponibilizando o conteúdo relacionado existente, levantando os seus aspectos positivos e negativos e a partir deste ponto justificando as escolhas de técnicas tomadas.
Capítulo 3: Método – metodologia e procedimentos escolhidos para o desenvolvimento do trabalho.
Capítulo 4: Descrição dos processos - Neste capítulo será descrito a modelagem do sistema, utilizando os respectivos diagramas para cada aspecto do projeto. Também serão apresentados os códigos correspondentes.
Capítulo 5: Implementação e validação - Neste capítulo será abordado o desenvolvimento do projeto proposto e sua respectiva validação.
2 REVISÃO BIBLIOGRÁFICA
Atualmente existem várias técnicas para a criação de equações para jogos. Neste capítulo serão apresentadas as principais técnicas de acordo com o tema geral do projeto e também a técnica escolhida de cada área.
Todas as técnicas citadas aqui possuem um lado negativo e um lado positivo, exatamente por isso que elas serão citadas e devidamente explicadas para o melhor compreendimento da escolha das mesmas no projeto.
Como já citado anteriormente, este projeto está organizado em 3 camadas, gráficos, engine e jogo, além disso existe o sistema operacional que oferece suporte ao sistema, porém este trabalho não abordará seus detalhes, pois isso se distanciaria do objetivo principal da monografia.
A seguir, se apresenta um modelo sobre como o jogo e como este capítulo está organizado. Cada camada inferior oferece suporte à superior, seguindo de mais baixo nível para mais alto nível conforme a seta. O cinza representa o que não será abordado e o amarelo escurecido o que será abordado, mas não implementado especificadamente para este projeto.
A seguir, segue uma figura abordando a estrutura pela qual este projeto foi organizado.
Figura 1: Modelo organizacional do projeto Fonte: Elaboração do autor (2010)
2.1 GRÁFICOS
Exceto no caso de se tratar de um jogo de texto, o mesmo precisa de um meio para a manipulação de seus aspectos gráficos, mecanismo que normalmente é utilizado pela engine a fim de criar possibilidades mais amplas para o jogo.
Gráficos de qualidade são um grande atrativo para jogos, mas existe espaço para debate, como fala SCHMIEG:
Há também o fator necessidade. Todo jogo realmente precisa ter gráficos poderosos? Eu não vejo a menor necessidade de gráficos ultra-realistas em um jogo de futebol, por exemplo. Não quero ver cabelos esvoaçantes ou homens suados, eu quero ver é bola na rede! (SCHMIEG ,2010)
Em uma plataforma 3D, o fator gráfico estaria relacionado ao posicionamento de objetos em um ambiente virtual, porém no ambiente 2D em questão o mesmo se limita a impressão de imagens na tela, apenas criando a ilusão de espaço e profundidade.
Para o auxílio nesta etapa, a biblioteca gráfica Allegro foi usada neste projeto. Ela possui funcionalidades básicas que facilitam muito a manipulação gráfica, disponibilizando desta forma mais tempo para o desenvolvimento da engine e do jogo.
Tais funcionalidades são: a impressão de imagens na tela, o carregamento das mesmas para variáveis no programa, dentre outras.
2.1.1 Carregamento e impressão de imagens
Uma das funcionalidades mais óbvias que um jogo 2D precisa ter é a utilização de imagens para usar no decorrer do GamePlay, para isso o mesmo deve contar com recursos gráficos.
Estas operações são extremamente caras em termos de desempenho, devido ao fato de ser necessária uma leitura pixel a pixel da imagem, se for levado em consideração que a imagem de fundo deste projeto equivale a 800 por 600 pixels, isso significa 480000 pixels a serem computados.
Esta operação normalmente precisa ser executada várias vezes por segundo e existem muitas outras imagens na tela ao mesmo tempo, sendo assim, quase toda a otimização feita na parte gráfica é muito eficiente.
Sobre o abordado, Natkin (2006) ressalta: “O desenhar da imagem em tempo real é a computação desta imagem à medida que ela é vista pelo jogador” (Tradução do Autor), sendo que um recurso gráfico somente deve ser usado caso o jogador possa vê-lo.
Este projeto varia entre dois tipos de imagem, imagens com extensão .bmp e .png. As imagens .bmp mais conhecidas como bitmaps somente compreendem o padrão RGB (Red, Green, Blue), em português: (vermelho, verde, azul) , usando estas três cores primárias para formar todas as outras que conseguir.
Existe esta informação em cada pixel da tela e é usada para interpretar a cor dele, se fosse colocado um pixel com valor (0,255,0), esta cor representaria o verde absoluto. Cada um dos espaços representa um valor de 0 a 255, significando a intensidade da respectiva cor do pixel.
Quando se deseja usar imagens .bmp que tenham partes transparentes sacrifica-se uma das 16777216 cores possíveis para esta sacrifica-ser a key-color, a cor que sacrifica-será ignorada pelo motor gráfico para significar transparência, no caso da Allegro, esta é a (255,0,255), ou seja, o rosa absoluto.
Além disso, também existe a opção do uso de imagens .png, estas são muito mais caras em performance, porém possuem uma qualidade maior, elas também são capazes de compreender o canal-alpha, isso lhes dá a capacidade de visualizar a transparência real, eliminando dificuldades na utilização destas imagens.
Allegro não possui suporte nativo para .png e foi necessário utilizar outra biblioteca para isso, a alpng. O projeto usou as duas extensões, visando explorar melhor as vantagens e desvantagens de cada uma delas.
2.1.2 Buffers
As imagens não podem ser impressas na memória de vídeo (tela) de maneira imediata, pois causariam problemas como fazê-las piscar de maneira desagradável ao olhar. Para corrigir este problema existe o buffer.
Com o uso de buffers, as imagens são armazenadas nele à medida que é necessário e então quando todas as imagens necessárias para determinado frame estiverem armazenadas, o buffer pode ser impresso na tela, isso cria uniformidade, fazendo com que todas as imagens sejam postas de uma só vez.
O funcionamento e uso de um buffer pode ser exemplificado no relato abaixo:
Dispomos de um bitmap auxiliar (chamado de buffer) que, normalmente, possui o tamanho da tela (ou o tamanho da região onde ocorre a animação). Desenhamos, neste buffer, os objetos que devem ser apresentados na tela. Após isso, desenhamos o conteúdo do buffer na tela, fazendo com que os objetos apareçam. Limpamos, então, o buffer, desenhamos os objetos novamente em suas novas posições, passamos o conteúdo do buffer para a tela, e assim por diante. (MOTA, 2009)
Apesar de existirem vários meios de como utilizar buffers, como o uso de vários buffers que se alterem na impressão de componentes na tela, este projeto somente disponibilizará suporte pra um único, pois não há necessidade de um sistema com teor mais amplo.
Também existe uma técnica disponível chamada PageFlipping, esta consiste em criar duas “folhas virtuais”, usando uma para guardar imagens e outra pra imprimir na tela, alterando a função das duas no decorrer da aplicação.
Porém, PageFlipping apenas apresenta vantagens ao uso em tela cheia, e o projeto rodará em uma tela de 800x600 pixels.
2.2.3 Animações
A animação utilizada em jogos 2D se trata de uma versão computadorizada de quando se tem um punhado de imagens em seqüência que estão em pedaços de papéis distintos e se passa o olhar rapidamente entre eles.
Sobre Animação em jogos, Natkin (2006) fala: “Criar animações em jogos ainda é um grande problema em termos de animação e custos. A maioria das animações é baseada na mesma técnica usada em filmes de animação 3D. Frames.” (Tradução do autor.)
Aqui as imagens são jogadas uma em cima da outra em uma velocidade muito alta, criando assim a ilusão da animação, postas lado a lado fica perceptível ao olho humano a estrutura da técnica.
Figura 2: Exemplo de Animação Fonte: Elaboração do Autor (2010)
Embora aparentemente simples, esta técnica esconde alguns empecilhos, a primeira vista a melhor maneira de se implementar a técnica seria através de uma estrutura de laço para cada seqüência de animação.
Porém, já foi abordado que o jogo inteiro se passa dentro de uma estrutura de laço gigante, sendo assim outro laço no interior do código faria com que todos os outros sistemas do jogo parassem para esperar a animação ser finalizada, o que não faz sentido. Sendo assim, é necessário que o código tenha a dimensão dos frames passando para poder utilizá-los a fim de substituir a necessidade de um laço. As animações são especialmente problemáticas em seqüência que não podem ser interrompidas a qualquer momento, como uma seqüência de salto.
2.2 ENGINE
As engines dizem respeito ao “motor” do jogo, sendo responsáveis por algoritmos que não dizem respeito ao jogo propriamente dito. A engine usa os mecanismos gráficos para a utilização de suas equações, embora em muitos casos a engine seja a própria responsável pelas operações gráficas.
Sem entrar em aspectos técnicos, podemos resumir uma engine como o conjunto de ferramentas que possibilita o desenvolvimento de um jogo. A qualidade dos componentes de um motor desse gênero determina o produto final que jogamos nos consoles ou computadores. (ABRÂO, 2010)
Engines normalmente são desenvolvidas para serem vendidas separadamente como softwares e não como parte de um jogo. O intuito dos desenvolvedores de engines é o de vender o software em questão para outras empresas desenvolverem o seu próprio jogo.
Tal visão de mercado pode ser observada no jogo Crysis da Eletronic Arts. Neste caso a subdivisão da empresa Eletronic Arts, a Crytec desenvolveu uma poderosa engine que foi a mais “poderosa” de sua época, a CryEngine.
O estúdio desenvolveu o jogo usando essa engine e o vendeu ao público. O jogo possuía os melhores visuais da época e diversas funcionalidades de física que nem mesmo eram necessárias para o jogo. A intenção era mostrar as funcionalidades da engine através dele e em seguida vender a mesma para outras empresas. Essa perspectiva cria engines “genéricas”, com o intuito de serem usadas em vários tipos de jogos.
Apesar de existir um grande mercado para engines, para criar uma digna de competição no mercado é necessário uma grande disponibilidade de tempo e pessoas, limitações que existem neste projeto. Portanto este trabalho visa somente tentar compreender os elementos específicos relacionados à criação de uma engine.
As equações internas do jogo podem se tornar extremamente complexas e normalmente o desenvolvedor de jogos está até mesmo disposto a pagar caro por uma engine a não ter que se preocupar com tais elementos de implementação.
Tal fator somente não se aplica a jogos de extremo porte, projetos que custam milhões e levam anos para serem implementados, que freqüentemente podem ser complicados ao ponto de ser necessário criar a própria engine especialmente para o jogo.
Sobre a parte de separação de um jogo em camadas a responsabilidade da engine neste aspecto Natkin (2006) afirma: “Engines facilitam a separação do jogo que vem com a tecnologia básica daquela onde está o conteúdo do desenvolvimento, que está mais perto do audiovisual e filmes.”
2.2.1 Física para Jogos
A física é imprescindível para qualquer jogo de sucesso hoje em dia, embora já tenha existido um tempo em que o público possuía uma exigência inferior para este tema, devido às muitas limitações que os equipamentos eletrônicos antigos estavam implicados. Segundo Lawlor (2009) “A chave é simular o menos possível que se pode, nunca sacrificando o fator da diversão para se aproximar a realidade”. (Tradução do Autor).
Sendo assim, para cada tipo de jogo existe certo nível de necessidade para física, neste caso ela pode ser considerada mediana, pois por um lado os jogadores possuem um certo grau de liberdade perante o cenário, e isso acaba inevitavelmente gerando possíveis ocorrências problemáticas perante a física, e a necessidade por equações elaboradas neste aspecto cresce.
Por outro lado, o jogo em si não possui foco na física, e acaba retirando a atenção do jogador para defeitos menores, isso não ocorre, por exemplo, em um jogo clássico de PinBall, onde o entretenimento proporcionado pelo mesmo é diretamente proporcional a qualidade da física. Levando em consideração esses aspectos chega-se ao nível mediano de necessidade por física em termos de duas dimensões.
2.2.1.1 Colisão
A colisão entre objetos dentro de um jogo é talvez a equação de natureza mais problemática no desenvolvimento inteiro de uma engine. Conforme Iank (2009), “Jogos do estilo Side-Scrolling podem ser muito distintos entre si, mas todos dividem um problema em comum, a detecção de colisão entre objetos do jogo”. Isso ocorre devido à constante alteração de seus parâmetros de posição e a necessidade de verificação freqüente para a ocorrência da mesma.
Porém, muitas vezes, em um sistema, a parte que diz respeito à colisão pura acaba sendo concluída, no entanto, o resultado não é o esperado e os dois objetos ficam presos ou são trocados de posição incoerentemente com o planejado. Isso ocorre não por um problema na equação de colisão em si, mas em uma falha ao se lidar com a mesma, sendo um problema de ação e reação. Tal fator acaba por, injustamente, atribuir ainda mais dificuldade para a sua implementação.
2.2.1.1.1 Bounding Box
A técnica de colisão escolhida para o desenvolvimento desse projeto consiste em atribuir quatro pontos a um objeto, virtualmente assim desenhando uma caixa em torno do mesmo e então usando esta caixa como objeto para colisão, conforme Silva(2009). “Basicamente, a idéia do bounding Box é criar um “quadrado imaginário” em torno das
figuras em que se deseja testar a colisão, e assim tratar as colisões desses quadrados imaginários”. Tal técnica é barata em termos de processamento, pois limita a quantidade de vértices a serem computados em apenas quatro.
Também pode ser considerada de relativa simplicidade de implementação em comparação com as outras técnicas, sendo a escolhida para projetos onde um sistema mais complexo seria imperceptível para o jogador. Nesse projeto além do Bounding Box, será usado o Pixel Perfect em combinação.
2.2.1.1.2 Bounding Circle
Consiste na mesma técnica apresentada no Bounding Box, com a exceção de que, em vez de se tratar de uma caixa, trata-se de um círculo. Em termos de produção em duas dimensões este modelo é muito raramente selecionado, devido a uma complexidade quase sempre considerada desnecessária, tendo em vista que, diferentemente do Boundign Box que possui apenas 4 vértices, um sistema baseado em círculos pode ter muitos.
Além disso, o simples formato de caixa acaba sendo mais conveniente do que um círculo na maioria dos casos. O uso do Bounding Circle normalmente é usado em aplicações 3D.
Na verdade, não existe necessidade de se prender ao formato de uma caixa ou de um círculo, sendo o formato passível de alteração livre por parte do desenvolvedor, porém os dois modelos apresentados são os amplamente mais utilizados.
2.2.1.1.3 Heavy Bounding
Consiste em usar para um mesmo objeto várias caixas para uso de colisão, ou seja, usando vários bounding Box e até mesmo outros formatos simultaneamente.
Tal técnica possui o propósito de tornar a colisão mais realista e em casos especiais como, por exemplo, um personagem que usa uma espada, se um inimigo colidir com o personagem, o efeito deverá ser diferente da colisão com a espada, que pode ser alcançado com o uso desta técnica.
Porém neste projeto esta técnica não será implementada, pois não existe a necessidade de um sistema mais complexo que o bounding Box sozinho.
2.2.1.1.4 Pixel Perfect
A técnica Pixel Perfet é o limite que se pode chegar da perfeição, consistindo em varrer a imagem e ler pixel a pixel, sendo assim o sistema pode detectar a ocorrência da colisão com apenas um pixel de contato entre dois objetos.
Esta prática é caracterizada por um grande uso de poder computacional, considerando que precisa estar freqüentemente testando a colisão com outros objetos do cenário, sendo assim, ela é freqüentemente utilizada em conjunto com a técnica Bounding Box. Desta maneira, o algoritmo Pixel Perfect somente é acionado se a colisão Bound in Box for antes, conforme relatado abaixo:
É uma técnica em que em todos os casos a colisão é detectada perfeitamente sem erros. Apesar disso, é uma das técnicas com menos performance, e por isso só deve ser utilizada quanto realmente houver necessidade de um teste de colisão muito preciso (SILVA, 2009, p. 14)
É de grande importância para este projeto que ele possua uma colisão satisfatória, portando, Pixel Perfect foi usado para as situações mais problemáticas, sempre em conjunto com o Boundign Box.
2.2.1.2 Gravidade
Muitos jogos fazem uso da gravidade em suas equações de física. A implementação da gravidade não apresenta fator de dificuldade expressivo o suficiente para ignorar a sua utilização, apesar disso existem meios para se economizar tempo no desenvolvimento, apenas criando uma ilusão da mesma.
Segundo Grabler (2003) “O conceito de gravidade é importante para muitos tipos de jogos. A menos que seu jogo tome lugar em algum universo alternativo sem gravidade.” (Tradução do autor).
Atualmente, o conceito de gravidade é visto como tão básico que pode ser desafiadora a tarefa de encontrar artigos confiáveis discutindo o seu funcionamento.
Sempre existe a possibilidade da utilização de uma gravidade ilusionária, A utilização desta técnica é observável em jogos de baixíssimo orçamento criados antigamente, porém hoje em dia é extremamente raro se ver a utilização da mesma.
Consiste, por exemplo: no momento em que um objeto sair do chão e atingir o seu limite de altura, ser puxado “a força” às vezes pelo próprio bloco de código que o levantou. Sendo assim, toda a vez que um objeto precisar cair ele deve ser manualmente puxado pelo código, isso gera uma grande limitação para o jogo e projetos de médio porte são inconcebíveis com a utilização dessa técnica.
Sobre criar a ilusão de gravidade, Grabler (2003) escreve: “Existem muitas maneiras de se criar a ilusão de gravidade, nós iremos explorar uma das mais fáceis”. (Tradução do autor).
Ao contrário da gravidade ilusionária, esta técnica oferece a existência de um sistema de física real, ou seja, os objetos não serão puxados para baixo apenas quando forem mandados, eles possuirão uma força que constantemente fará esse trabalho.
Tal método precisa ser usado em conjunto com uma técnica de colisão, sendo que a força é constante e somente o objeto parará de cair se entrar em colisão com algo abaixo dele.
Outra vantagem do uso desta técnica é o fato de ser dinâmica, com a elevação do terreno adiante. Com um sistema de gravidade real isso não é um problema, no entanto usando uma ilusão da mesma, fica quase inconcebível devido à natureza estática do método. Com base nestas informações a Técnica de Gravidade real foi a escolhida para este projeto.
2.2.1.3 Ação e reação
A ação e reação dos materiais é algo que está embutido em todo o sistema de física do jogo e está em toda a parte, como, por exemplo, quando a gravidade faz o personagem colidir com o chão, a reação para o mesmo é que o personagem pare. Em outros casos, como quando um inimigo é atingido pelo personagem principal, em vez de impedir seu movimento, o inimigo deve simplesmente ter sua contagem de saúde reduzida.
Tais efeitos podem ser entendidos com a atribuição de dados de como o objeto deve se comportar, como, por exemplo, fricção e elasticidade, atribuindo assim aos mesmos propriedades que podem ser de metais, madeiras, borrachas, etc. Esta necessidade não se aplica neste projeto.
2.3 JOGO
Esta é a camada do projeto onde realmente se desenvolve o jogo, as anteriores apenas oferecem suporte para que esta possa ser totalmente funcional. Nesta etapa estão vários dos elementos propostos para a aplicação, como o sistema de inventário e o de saúde, mas a parte mais notável é a de Inteligência Artificial.
É na camada do jogo que se encontra o GamePlay, parte que representa a experiência final do jogador e com o que ele pode interagir, devido a este fator existe uma preocupação menor com a performance do código e uma maior com a qualidade geral de como tudo é apresentado, afinal esta camada está exposta ao jogador, ao contrário das demais.
2.3.1 Inteligência Artificial (IA)
Uma das principais características de um jogo Side-Scrolling e também uma das razões que o tornam tão complexo é o fato de requisitar técnicas de inteligência artificial. Tal sistema não diz respeito a engine, e sim ao jogo propriamente dito.
Uma inteligência artificial em jogos normalmente é atribuída aos inimigos do personagem do jogo e é o caso do projeto desenvolvido aqui, porém a inteligência artificial em jogos não se resume somente a isso.
Um exemplo de outro uso de inteligência artificial é que em um jogo originalmente idealizado para dois ou mais jogadores cooperarem entre si (comumente chamados de coop) se encontra uma situação em que somente um jogador deseja jogá-lo, freqüentemente neste caso existem inteligências artificiais para ocupar os lugares dos outros jogadores.
Existe uma quantidade enorme de informação no campo da inteligência artificial, e apenas uma parcela deste campo é aplicável a jogos, sendo algumas técnicas utilizadas com maior freqüência.
Aqui serão apresentadas quatro técnicas que foram compreendidas como as que mais possuem usabilidade no ramo de jogos digitais, porém exclui outras, como por exemplo, a mineração de dados ou um sistema especialista, que embora possam ser usadas não foram consideradas relevantes o suficiente para apresentação neste trabalho.
2.2.1.1 Máquina de Estados Finitos (ME)
Segundo SOARES(2003, p. 4), esta técnica é “um sistema que tem um número limitado de estados”, ela representa uma inteligência que possui diversos estados de atuação.
Esta técnica é a mais usada em jogos eletrônicos, pois suas características são muito compatíveis com as necessidades comuns de um jogo, tanto que para alguns as outras três técnicas demonstradas a seguir podem ser consideradas “especializações” da máquina de estados finitos.
No desenvolvimento do projeto esta técnica é usada para coordenar as duas inteligências artificiais usadas, sendo que este funcionamento será abordado metodicamente no Capítulo 4, referente a modelagem.
Resumidamente, o seu funcionamento consiste em dividir o comportamento de uma inteligência artificial em estados, cada estado que a inteligência artificial entra a faz se comportar de maneira diferente. Sendo assim será utilizado como exemplo o popular jogo Pac Man.
Neste jogo o personagem é perseguido por fantasmas, originalmente eles estão no estado de “procura”, a procurar o personagem para atacá-lo, porém, quando o personagem adquire um item específico, ele se torna capaz de atacar os seus fantasmas perseguidores e também se torna imune aos ataques dos mesmos.
Este fator faz com que o estado dos fantasmas mude de “procura” para “fuga”, pois agora os fantasmas querem evitar o personagem ao máximo, fugindo dele, após determinada quantidade de tempo o item perde o efeito e os fantasmas voltam ao seu estado de “procura” original.
Sendo assim, a máquina de estados finitos consiste em um algoritmo que gerencia dois ou mais estados, normalmente vários, para que interajam entre si e que respondam aos eventos que ocorrem no jogo.
2.2.1.2 Algoritmo Genético
Algoritmos genéticos são bem menos usados na indústria de jogos do que as máquinas de estados, devido ao fato de possuírem alto grau de complexidade em seu desenvolvimento e suas características normalmente não satisfazem as necessidades de um jogo.
Porém, ainda assim é usada em projetos de maior porte e por empresas com amplos recursos disponíveis, consistindo em desenvolver uma técnica com indivíduos que evoluam com o tempo se tornando mais capazes de executar as suas funções a cada geração.
O algoritmo genético é a versão da TI da teoria da Evolução do naturólogo Charles Darwin com o sistema de genética idealizado por Gregor Mendel. O segundo explica como todos os indivíduos são diferentes e como suas informações são passadas para a próxima geração e o primeiro explica como este processo faz os indivíduos evoluírem para serem mais eficientes.
Métodos estocásticos de busca cega de soluções quase ótimas. Neles se mantém uma população que representa um conjunto de possíveis soluções a qual é submetida a certas transformações com as que se tenta obter novos candidatos e a um processo de seleção dirigido em favor dos melhores candidatos.SERRADA(1996, p.23) (Tradução do Autor)
Um exemplo de aplicação pode ser os inimigos em um jogo de tiro, onde o personagem tenha que enfrentar 30 inimigos em um cenário a cada rodada, sendo que a cada final de rodada os dados sobre o seu desempenho são mostrados e então uma nova rodada se inicia.
Para cada indivíduo seriam determinados valores de comportamento aleatório, por exemplo, quando sobre fogo, alguns se desviam para a esquerda, outros para a
direita, alguns pulam e outros se abaixam, tendo cada um uma técnica para superar o jogador.
No final da rodada o sistema identifica quais inimigos tiveram maior sucesso ou que até mesmo conseguiram superar o jogador, então o sistema pega as informações dos mais bem sucedidos através de um critério pré-determinado e cria a nova rodada de inimigos baseado nestas informações.
A idéia é que a cada rodada somente os indivíduos mais aptos passem suas informações para a próxima rodada e assim a cada rodada se estabelece uma geração de indivíduos mais eficientes em combater.
Em teoria, no final resultaria em inimigos que se esquivam com alguma freqüência para a direita do jogador, pois é mais difícil mover o mouse para a direita e acertar o inimigo do que para a esquerda.
Tal algoritmo pode ser interessante, mas é muito complexo e não corresponde às necessidades do jogo aqui desenvolvido, visto que tal prática torna difícil que o jogador aprenda a dominar seus inimigos, pois eles estariam em metamorfose constante. Neste trabalho, o conceito de “rodada” não pode ser aplicado como uma boa maneira para este algoritmo funcionar apropriadamente.
2.2.1.3 Rede Neural
Os algoritmos de Redes Neurais são inspirados nos Neurônios do Cérebro, ganhando assim o seu nome, as informações que o cérebro administra, como por exemplo, a dor, passa por uma rede de neurônios para que chegue ao seu destino correto. Tal sistema de funcionamento é imitado pela técnica de redes neurais.
Uma técnica interessante que pode ser aplicada em jogos de futebol são as redes neurais. Elas são redes computadorizadas onde a sua estrutura é similar a um cérebro humano, tendo nós de rede (neurônios) e conexões entre os nós. A vantagem de usar uma rede neural é que a rede pode aprender e armazenar conhecimento para uso posterior. FLAUSINO (2008).
Para que um cenário de aplicação de uma rede neural ocorra é basicamente necessário que exista um grupo de indivíduos que necessitam cooperar entre si para chegar a um ou mais objetivos, o que ocorre, por exemplo, em um jogo de futebol.
Em um cenário de jogo de futebol cada jogador pode ser interpretado como um neurônio, ou um nó usando a linguagem da TI e não da biologia. Os nós precisam cooperar entre si para chegar ao seu objetivo que é o gol. Cada jogador possui uma conexão com os jogadores ao redor.
A conexão representa os caminhos pelo qual o jogador pode passar a bola para os demais. Cada nó possui informações particulares que determinam para onde a inteligência artificial poderá passar a bola dependendo da situação e assim o algoritmo constantemente verifica qual é a melhor conexão para passar a bola e quando é a melhor oportunidade baseando-se em critérios pré-estabelecidos.
Seguindo este processo, a inteligência artificial pode chegar ao gol que está no final da rede, passando pelos nós de trás ( zagueiros ) até os nós da frente ( atacantes ).
Tal técnica é bastante usada em jogos, porém não é de fácil implementação, devendo ser utilizada moderadamente, somente em casos em que seja realmente necessário.
Para o jogo aqui desenvolvido, existem duas inteligências artificiais, sendo que fazer o uso de redes neurais para apenas dois nós é desnecessário. Além disso, as inteligências artificiais aqui não se comunicam, elas são independentes, o que as impossibilitam de realizarem movimentos sincronizados e dá ao jogo mais possibilidades para um jogador que adquiriu habilidades explorar o mesmo.
2.2.1.4 A* Pathfinding
Pathfinding significa “encontro de caminho”, ou seja, técnica usada pela inteligência artificial para encontrar o melhor caminho para o seu destino, esta técnica é usada na grande maioria de jogos para vários tipos de ocasiões.
Os personagens precisam criar rotas, e não podem fazer coisas que comprometam seu funcionamento, como, por exemplo, atravessar paredes ou andar em cima de um lago. Por isso, os programadores aplicam algoritmos de path-finding, ou, a definição de caminhos (FLAUSINO 2008).
O amplamente conhecido jogo Pac Man, usa três algoritmos de pathfindig para cada um de seus três fantasmas que perseguem o personagem, sendo aplicado da seguinte maneira:
Fantasma Inteligente: Calcula o caminho mais rápido possível para se chegar ao personagem.
Fantasma Regular: Calcula vários caminhos para se chegar ao personagem e sorteia um deles para seguir.
Fantasma Tolo: Anda aleatoriamente pelo cenário na esperança de se encontrar com o personagem.
Existem muitos usos para uma técnica de pathfinding no ramo de jogos, pois freqüentemente a máquina de estados (ME) tem vários obstáculos no seu caminho e também freqüentemente precisa calcular o melhor de todos.
O jogo desenvolvido aqui não usa um pathfinding suficientemente complexo para ser documentado, o que é raro em jogos. Devido a uma das propostas do design do jogo ser o de fornecer combates caóticos com um grande número de inimigos, a existência de obstáculos no caminho teria um grande potencial para confundir o jogador.
Sem obstáculos pelo caminho, tudo o que os personagens fazem para encontrar o seu caminho é se basear na posição atual do jogador e em seguida se mover para os lados ou ficar parado dependendo da ocasião, sendo desnecessária a sua documentação.
2.5 CONCLUSÕES DO CAPÍTULO
Neste capítulo foram analisadas varias técnicas para vários tipos de problemas técnicos residentes do desenvolvimento de uma engine e de um jogo Side-Scrolling subseqüente. Resumindo, foram escolhidos Bounding Box em conjunto com PixelPerfect para colisão, uma gravidade real e um sistema gráfico de apenas um buffer.
Pode ser observado que em geral não foram escolhidas as técnicas mais robustas existentes no mercado, pelo contrário, ocorreu uma escolha por técnicas modestas e de maior usabilidade.
Tal fator deve-se a falta de eficiência das práticas mais complexas analisando o tipo de projeto de jogo escolhido.
Mais um aspecto observável é que embora para este caso as já citadas técnicas foram escolhidas, não significa que as mesmas são simplesmente melhores que as demais, trata-se apenas do uso adequado para cada caso.
3 MÉTODO
Neste capítulo, será apresentada a metodologia escolhida para a pesquisa e o desenvolvimento do projeto em questão, com o objetivo de facilitar o processo de criação e o entendimento do trabalho.
3.1 ETAPAS METODOLÓGICAS
Cervo e Bervain (1983, p.50) definem a pesquisa como “uma atividade voltada para a solução de problemas, através do emprego de processos científicos”, ressaltando desta forma o papel da pesquisa no desenvolvimento de um projeto científico.
A presente pesquisa é um conjunto de conhecimentos sobre o desenvolvimento de engines para jogos 2D, sendo que as informações adquiridas serão implementadas em um software que comprovará e exemplificará o funcionamento das mesmas. Este procedimento se enquadra no tipo de pesquisa aplicada.
A atribuição do tipo de pesquisa como aplicada também pode ser atribuída ao objetivo da mesma, pois diz respeito a implementação de um software, utilizando as informações coletadas na pesquisa.
Para a melhor compreensão da metodologia de pesquisa aplicada que será abordada, foi elaborada a ilustração através do fluxograma a seguir:
Figura 3: Etapas metodológicas Fonte: Elaboração do autor (2009)
Analisando o fluxograma, pode-se observar que a pesquisa consiste na procura de técnicas viáveis para a criação de engines e suas validações, conforme descrito no segundo capítulo, que trata da revisão bibliográfica.
A revisão dos conceitos é importante para possibilitar o levantamento de pontos positivos e negativos das técnicas apresentadas, e a partir dos dados coletados, tomar uma decisão sobre qual técnica usar.
Como também é apresentado no capítulo 2, o projeto é composto de várias áreas distintas e somente quando uma técnica para cada área for selecionada serão apresentados os fluxogramas das mesmas, seguido de suas implementações.
3.2 PROPOSTA DE SOLUÇÃO
A solução encontrada para o desenvolvimento do projeto pode ser observada no fluxograma a seguir. O conceito de frame nele representado significa uma rodada nos elementos que estão embutidos, sendo assim, o processo do frame se repete sempre que chega ao fim.
Antes de ingressar no frame, a engine carrega as imagens que serão utilizadas em um buffer (memória principal) e em seguida imprime na tela as imagens iniciais, o que evita que a mesma fique preta no início da aplicação.
Nota-se que as três camadas representam a hierarquia de comando dentro da aplicação, mas aqui o apresentado é a ordem em que os principais eventos ocorrerão, tendo em vista a solução, sendo assim as camadas irão se misturar no processo. A seguir está a proposta de solução para este projeto.
Figura 4: Proposta de Solução Fonte: Elaboração do autor (2009)
Após esta etapa, o software entra na roda de frames, sendo a ação inicial a checagem e procedência dos mecanismos primordiais responsáveis por fazer um jogo fluir. O segundo passo é a tomada de ação por parte da engine, caso algo de relevância tenha acontecido, como por exemplo: o personagem foi atingido por um inimigo.
É possível identificar esta ocorrência, devido à checagem de colisão feita anteriormente e que transfere seus dados para a ativação de ação e reação, esta checagem é feita identificando todos os objetos que podem colidir no cenário e verificando a ocorrência do fenômeno em questão.
O primeiro passo do frame também inclui a procedência da inteligência artificial e a captação de movimentos do personagem, caso o usuário tenha executado algum. Com as providências tomadas é feita a execução do passo três do frame, que corresponde a alteração da situação dos dois elementos, caso se aplique à situação.
O terceiro passo também leva em consideração a ação e reação gerada pela física da engine em suas tomadas de decisão.
Sendo assim, baseado nos movimentos do personagem, o Scrolling é ativado, pois representa a “posição da câmera”, indicando que, caso tenha ocorrido uma ordem para o personagem se mover, o cenário precisa ser movido na direção oposta, criando assim a ilusão de que existe uma câmera perseguindo o protagonista.
Após todos os processos lógicos do frame concluídos, é necessário transferir os acontecimentos para a dimensão gráfica, para isso, serão usadas as informações das sprites (imagens) que passaram pelo frame anterior e que devem ser impressas na tela.
Assim, termina um ciclo, sendo que, resumidamente, pode-se dizer que um ciclo consiste na captação dos eventos ocorridos, manipulação dos mesmos e a utilização deles para atualizar as imagens impressas na tela.
3.3 DELIMITAÇÕES
O projeto de um jogo capaz de concorrer no mercado atual pode ser de extrema complexidade e requer conhecimentos aprofundados em diversas áreas, que não são oferecidos pelo curso de ciência da computação. Além deste fator, deve-se considerar a limitação de tempo e de pessoas para a implementação de um projeto complexo.
Considerando estes aspectos, se reforça o intuito didático desta monografia e não o comercial. Tendo em vista tal cenário, é necessário o estabelecimento de algumas limitações para viabilizar o projeto, que estão expressas a seguir.
- O jogo não priorizará “gráficos” de qualidade, apenas o necessário para exemplificar o funcionamento dos processos.
- Pouca interface humano-computador será implementada, devido a não corresponder a programação para jogos, porém simplesmente utilizada em jogos.
- Foi feita a opção por técnicas mais simples de inteligência artificial e manipulação gráfica devido ao baixíssimo ganho de benefício do produto final perante o tempo a mais necessário para implementar técnicas mais complexas.
- A engine criada não será convertida nas formas comuns de editor ou de API, pois tal ação não seria justificada pelo objetivo do projeto em questão.
4 DESCRIÇÃO DOS PROCESSOS
No decorrer deste capítulo, serão apresentadas, através de modelos, as técnicas levantadas na revisão bibliográfica (Capítulo 2). Também outros aspectos do jogo desenvolvido que embora não possuam técnicas com características discriminativas suficientes, são de grande relevância para o projeto como um todo funcionar.
Devido à natureza deste trabalho tratar aspectos não normalmente abordados em instituições de ensino, os fluxogramas além de serem demonstrados visualmente, também serão detalhados em seus aspectos específicos, com o objetivo de uma melhor compreensão do assunto.
Também, nota-se que o desenvolvimento do sistema será demonstrado juntamente com a modelagem, com o intuito de facilitar a leitura do documento.
Devido à proposta inicial do projeto de apresentar as soluções para os problemas básicos do desenvolvimento de jogos digitais, serão apresentados neste capítulo os principais componentes do sistema.
4.1 GAME FLOW
O GameFlow é o modelo mais importante dentre todos de um projeto na área de jogos digitais, e consiste em uma visão geral do software desenvolvido. Ele é quase sempre o único modelo a ingressar no documento GDD ( Game Design Document).
O GDD consiste em um documento no qual toda a concepção do projeto é estipulada e normalmente é feito com a intenção de ser apresentado para um investidor ou produtor.
Tal característica faz com que o GameFlow e seus derivados necessitem ser compreendidos por pessoas sem experiência em programação, como é o caso de designers e artistas.
O GameFlow tem a intenção de apresentar o “curso” do jogo, seguindo os passos que o jogador poderia tomar conforme o seu desenrolar. A figura a seguir representa o GameFlow do projeto, engine e jogo.
É importante observar que para compreender com clareza o fluxograma apresentado e todos que serão apresentados a seguir é necessário ter conhecimento do conceito de frame, introduzido durante o Capítulo 3 e que será melhor exemplificado na seção Timer, deste capítulo.
Observa-se que o início do fluxograma apresenta: “do jogo ou de um frame”, sendo assim todo o fluxograma do GameFlow se repete constantemente, sendo que a freqüência estipulada para este projeto é de 60 vezes por segundo.
Devido a essa característica repetitiva de um jogo, observa-se também que o modelo possui vários pontos onde o processo poderia simplesmente “morrer” e não existe caminhos orientado para onde o processo iria caso isso ocorra.
Quando um processo morre, ele não retorna a algum ponto, ele simplesmente para sua execução e espera o frame acabar, no próximo ele irá tentar completar o seu ciclo novamente.
Isso ocorre devido à característica dinâmica de um jogo, um processo somente pode se completar se o jogador agir de maneira que o complete, ou a ME calcular que deve realizar determinado movimento e outros fenômenos de gênero. A cada segundo dezenas de processos distintos encontram o seu fim e irão esperar um novo frame para recomeçarem.
Figura 5: GameFlow
Fonte: Elaboração do Autor (2010)
Neste fluxograma, se observa as condições de derrota e vitória estipuladas para o jogo, sendo que a condição de derrota é se em algum momento a saúde do personagem atingir a marca “0’.
A condição de vitória consiste em analisar se todas as MEs foram derrotadas e se o personagem está próximo ao limite horizontal do cenário. Considerando que a tela possui 1024 pixels de largura, se ele se encontrar na posição 750 ou superior na diretriz x (horizontal) será o suficiente para satisfazer o requisito.
4.2 GERÊNCIA DE INPUT
A gerência de input visa receptar uma tecla pressionada pelo usuário e agir de acordo com a função dada a ela. A biblioteca gráfica Allegro utilizada aqui já contém funções para verificar a nível de código se determinada tecla está sendo pressionada, sendo assim, cabe ao código reagir de maneira apropriada.
As teclas e ações que o jogador tem liberdade de efetuar estão listadas nos requisitos funcionais do sistema, neste caso será apresentado o algoritmo de movimentação do personagem para a direita.
Em termos de complexidade, os movimentos mais simples são o de se abaixar, seguido pela movimentação esquerda e direita. Os mais complexos são o de pulo e ataque, que exploram a utilização do sistema de colisão.
No caso do pulo, ele também usa o sistema de gravidade mais amplamente e utiliza uma parábola para determinar seu movimento. Ele também força a criação de um estado novo para o personagem, pois enquanto o personagem está no ar, as suas ações devem ficar bastante limitadas.
A seguir, apresenta-se o código utilizado para mover o personagem para a direita.
Quadro 1: Código de movimentação para a direita Fonte: Elaboração do Autor (2010)
Deve ser reparado imediatamente que nenhuma estrutura de laço está sendo usada para a execução deste algoritmo, que não deve ser usado por duas razões: já existe uma grande estrutura de laço circundando todo o jogo e que pode ser usada.
A outra razão seria que se uma estrutura de laço fosse implementada, todo o resto do jogo iria parar a sua execução para que a estrutura finalizasse, o que não funcionaria para uma animação como esta.
Na primeira linha se verifica se a tecla da seta para a direita está sendo pressionada e se nenhuma outra ordem de movimento está sendo executada, com exceção do movimento para a esquerda.
No caso do pulo e ataque é necessário verificar suas respectivas variáveis de estado, no ar e atacando respectivamente, pois estas são seqüências de animações que não devem ser interrompidas.
Na segunda linha são passadas as informações da imagem que será utilizada, que é necessário para o algoritmo de colisão conseguir se localizar.
A terceira linha é a que verifica se a movimentação com a esquerda não vai interferir com a direita, significando 2 para direita e 1 para esquerda. Esta variável é determinada separadamente no início do frame e necessita ser disposta desta maneira, pois deve apenas impedir a animação e a movimentação, mas não deve impedir a contagem da próxima imagem que deve ser disposta.
Em seguida, é efetuado o movimento, a posição da imagem não pode ser simplesmente incrementada, pois eventos onde ela não será possível podem ocorrer, o que acontece devido ao efeito de Scrolling (ver 4.3). A variável “movimento” representa o quanto a imagem deve se mover horizontalmente, no caso ela tem valor de 20 pixels.
Quando o personagem recebe algum dano ele deve piscar para alertar ao jogador de seu momento de imunidade, a checagem da variável flick coordena este processo, somente autorizando a impressão da imagem que está dentro de sua estrutura caso seja permitido.
Em seguida é usada a função da biblioteca Allegro para imprimir imagens na tela.
draw_trans_sprite(buffer,run[Rframe],posx,posy);
Os parâmetros são, respectivamente:
Buffer (onde desenhar): A imagem está sendo desenhada em um buffer, que é uma figura virtual onde todas as imagens são desenhadas. No final do frame o próprio buffer é desenhado na tela criando assim uma impressão na tela limpa, conforme capítulo 2.
Run (Rframe) - imagem BMP: No caso, as imagens que serão aqui impressas, estão em um array junto com as demais imagens que correspondem a sequência de movimento.
Posx: Posição X onde a imagem deve ser impressa, no caso a posx representa a posição onde o personagem deve estar, esta é alterada dentro da função garanteMovimento.
As posições 0 e 1 do arrays são tratadas diferentemente, pois apresentam imagens de transição entre a seqüência de animação onde o personagem está parado e somente respirando para a seqüência de corrida.
Logo abaixo, com a animação efetuada, é necessário indicar que a próxima seqüência pode ser disposta, o que é feito incrementando o valor de Rframe. Sendo assim, no próximo frame, a próxima imagem do array será mostrada na animação.
Por fim, existe uma verificação de que o array da animação chegou ao seu limite, e quando isso ocorre, a animação deve retornar ao ponto de origem, neste caso a posição 0 do array.
É necessário notar que as imagens do array estão em forma de loop, ou seja, a última imagem se enquadra com a primeira de tal forma que se todas forem rodar de maneira repetida, recomeçando sempre do zero, o resultado será o personagem correndo indefinidamente.
4.3 COLISÃO BOUNDING BOX
A matéria que envolve colisão costuma ter característica desafiadora, pois constantemente, mesmo muito depois de finalizada e testada pode apresentar imperfeições no decorrer de um jogo, sendo que as razões da imperfeição podem ser muito variadas.
É comum, mesmo em jogos AAA, que passaram por uma programação de anos sobre uma forte engine já consagrada, apresentar imperfeições na colisão após o lançamento, principalmente em condições onde a física da engine está sobre total controle da cena.
A seguir é apresentado o fluxograma do sistema de colisão e na seqüência a sua fórmula, bem como a maneira como ela é usada.
