IME - USP

Trabalho de conclusão de cursoAluno:

RAFAEL PARENTE

Orientador:

FLÁVIO SOARES

CORRÊA DA SILVA

Disciplina:

MAC0499 - TRABALHO DE

FORMATURA SUPERVISIONADO

São Paulo3 de dezembro de 2012

Sumário

1 Introdução 31.1 Elementos do jogo . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Conceitos e tecnologias usadas 42.1 Computador e sistema operacional . . . . . . . . . . . . . . . . . 42.2 C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Ogre3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.4 CEGUI e OIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.5 Gimp e Blender . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.6 Grafos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.6.1 Algoritmo de Dijkstra . . . . . . . . . . . . . . . . . . . 92.7 Computação Gráfica . . . . . . . . . . . . . . . . . . . . . . . . 10

2.7.1 Bounding box . . . . . . . . . . . . . . . . . . . . . . . . 102.7.2 Billboarding . . . . . . . . . . . . . . . . . . . . . . . . 102.7.3 Câmera virtual . . . . . . . . . . . . . . . . . . . . . . . 10

2.8 Orientação à objetos . . . . . . . . . . . . . . . . . . . . . . . . 122.8.1 Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.9 Licenças . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.9.1 MIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.9.2 zlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Atividades realizadas 153.1 Definição da parte gráfica . . . . . . . . . . . . . . . . . . . . . . 153.2 Desenvolvimento do projeto do jogo . . . . . . . . . . . . . . . . 163.3 Criação do mundo . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.1 Implementação do mundo . . . . . . . . . . . . . . . . . 173.3.2 Grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3.3 Jogada dos inimigos . . . . . . . . . . . . . . . . . . . . 24

3.4 Criação do gerenciador da nação . . . . . . . . . . . . . . . . . . 253.5 Criação da batalha . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.5.1 Antes da batalha . . . . . . . . . . . . . . . . . . . . . . 273.5.2 A batalha . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1

4 Resultados 29

5 Conclusões 33

6 Desafios e frustrações 33

7 Disciplinas importantes para o trabalho 35

8 Melhoramento do projeto 36

9 Futuro 37

Referências 37

2

1 Introdução

Este trabalho de formatura é sobre a criação de um jogo de estratégia e RPG,baseado no jogo Dragon Force1, em que o jogador joga contra o computador.O jogador deverá escolher uma nação, que possui um território, e o objetivo dojogador será conquistar todos os demais territórios.

O jogo pode ser dividido em três partes principais:

• O mundo: onde o jogador decide algumas ações com relação a seus exérci-tos, como para onde enviar os generais, repor tropas em castelos, etc;

• Os assuntos internos (ou o gerenciador da nação): onde o jogador poderámelhorar as condições de cada general ou castelo, além de conseguir salvaro jogo para voltar a jogar em outro momento;

• A batalha: Onde ocorre o combate entre os generais de duas nações distin-tas, sendo que cada general possui uma tropa;

1.1 Elementos do jogo

Foram criados alguns elementos para modelar os objetos do jogo. Eles são:

• General: São como personagens controlados pelo jogador em jogos de RPGpara videogames, usando rótulos comuns nesses jogos para definir a vida(HP), pontos para usar em técnicas especiais (MP), ataque, inteligência,etc. Para este tipo de jogo foi também criado a condição de "comando",que serve para indicar a habilidade do general em comandar suas tropas,refletindo na probabilidade de acerto das tropas no combate;

• Castelo: Um local onde os generais se recuperam e podem recuperar suastropas. Dominar um castelo oferece vantagem em um combate, tambémmelhorando a probabilidade de acerto das tropas;

• Vilarejos e cavernas: São pontos no mapa assim como os castelos;

1[4]

3

• Grupos: Um grupo é uma coleção de, no máximo, 5 generais e 5 pri-sioneiros. Os grupos são a forma dos generais vagarem pelo mundo e atacarcastelos ou outros grupos;

• Prisioneiros: Generais capturados pelo inimigo;

• Tropas: As tropas que o general pode comandar. Existem 6 tipos de tropas,e cada tropa tem vantagens em relação a alguma outra tropa;

• Semana: Uma semana começa nos assuntos internos e termina quando voltapara os assuntos internos. O jogo sempre começa nos assuntos internos, vaipara o mundo, onde ocorrem batalhas e conquistas de território, e volta paraos assuntos internos;

2 Conceitos e tecnologias usadas

2.1 Computador e sistema operacional

O sistema operacional usado foi o Ubuntu 11.04 - the Natty Narwhal2.Alguns dados do computador usado:

• Usando o comando cat /proc/cpuinfo obtemos os seguintes dados sobre oprocessador:

– model name: Intel(R) Pentium(R) Dual CPU E2220 @ 2.40GHz

– cpu MHz : 2403.000

– cache size : 1024 KB

• A placa de vídeo:

– Intel Corporation 82G33/G31 Express Integrated Graphics Controller;

2Ubuntu é um sistema operacional de código aberto baseado na distribuição Debian[18]

4

2.2 C++

C++ é uma linguagem de programação multi-paradigma3 e de uso geral. A lin-guagem é considerada de médio nível, pois combina características de linguagensde alto e baixo níveis.4

É possível usar herança múltipla, que pode gerar aumento na complexidade eambiguidade em algumas situações.

C++ foi a linguagem usada para a criação do jogo.

2.3 Ogre3D

Ogre 5 é um motor gráfico 63D escrito em C++. Foi projetado para ser mais in-tuitivo para desenvolvedores produzirem aplicações utilizando gráficos 3D, comaceleração por hardware, abstraindo os detalhes de usar bibliotecas como Di-rect3D e OpenGL. É completamente multiplataforma.

Sendo somente um motor gráfico, Ogre valoriza a modularidade. É especia-lizado apenas na parte gráfica e, por isso, são necessárias outras bibliotecas paratratar de outras questões como a entrada, som e física, o que normalmente ummotor de jogo já oferece.

É possível usar scripts para definir alguns recursos, como texturas, o quediminui o código em C++ e torna mais fácil criar modificações, afinal não é pre-ciso recompilar o programa.

Ogre usa um grafo para o gerenciamento das cenas. Assim, é necessário criarum nó para exibir um objeto da cena. Além de objetos, é possível adicionar ou-tros recursos, como a câmera, o que torna mais simples a sua manipulação. Porexemplo, se um jogo tem a opção de usar a visão em primeira pessoa de um dadopersonagem, pode-se adicionar a câmera em algum olho do personagem, assim

3Um paradigma de programação fornece e determina a visão que o programador possui so-bre a estruturação e execução do programa. Por exemplo, em programação orientada a objetos,programadores podem abstrair um programa como uma coleção de objetos que interagem entre si,enquanto em programação funcional os programadores abstraem o programa como uma sequênciade funções executadas de modo empilhado.[9]

4[8]5Ogre significa Object-Oriented Graphics Rendering Engine.[1]6Graphic engine ou rendering engine[2], um tipo de motor de jogo[3] especializado em ren-

derização de cenas 2D e/ou 3D.

5

ela mudaria de acordo com o seu movimento. O que se faz em um nó é propagadopara seus filhos, mas o que se faz nos filhos não afeta os pais.

Os nós podem ter nomes, que servem para recuperar um nó através do geren-ciador de cena, o que é útil quando não há um ponteiro para determinado nó.

Para este trabalho foi usado Ogre 1.7, mas a versão mais atual é a 1.8, lançadaem 2 de setembro de 2012 (durante a realização deste trabalho).

Ogre3D é distribuído com licença MIT.2.9.1

2.4 CEGUI e OIS

CEGUI7 é uma biblioteca para criação de interfaces gráficas para o usuário escritaem C++. Foi criada para ser usada em jogos, mas é possível utilizá-la em outrastarefas. Pode ser personalizado através de imagens, XML8 e ferramentas de ediçãode código.

Para usar imagens, por exemplo, pode-se criar um arquivo em XML com ex-tensão ".imageset"que define um nome, que será usado para identificar a imagem,e a posição da imagem no arquivo de imagem. Assim, é possível construir váriasimagens para se usar no programa a partir de um único arquivo de imagem.

CEGUI é distribuído com licença MIT.2.9.1OIS 9 é uma biblioteca multiplataforma10 que constrói a interação entre o

homem e máquina através de dispositivos de entrada, como mouse, teclado e con-troles de jogos, como joysticks e o Wii Remote.

Tudo o que foi usado sobre OIS foi aprendido através dos tutoriais do Ogre.OIS é distribuído com licença zlib.2.9.2

7Crazy Eddie’s GUI[5].8O XML é um formato para a criação de documentos com dados organizados de forma hi-

erárquica, como se vê, frequentemente, em documentos de texto formatados, imagens vetoriais oubancos de dados.[25]

9OIS significa Object Oriented Input System. Mais informações em [11].10OIS tem suporte para GNU/Linux e Windows, sendo que OS X e FreeBSD são apenas par-

cialmente suportados.

6

2.5 Gimp e Blender

Gimp é uma ferramente de criação e edição de imagens, além de permitir a criaçãode animações através de plug-ins. Possui diversos recursos úteis, como o uso descripts (Script-Fu, Python, Perl e Tcl).

Blender, também conhecido como blender3d, é um programa de computa-dor de código aberto, desenvolvido pela Blender Foundation, para modelagem,animação, texturização, composição, renderização, edição de vídeo e criação deaplicações interativas em 3D, tais como jogos, apresentações e outros, através deseu motor de jogo integrado, o Blender Game Engine.

O programa é multiplataforma, estando portanto disponível para diversos sis-temas operacionais. O Blender implementa ferramentas similares às de outrosprogramas proprietários, que incluem avançadas ferramentas de simulação, taiscomo: dinâmica de corpo rígido, dinâmica de corpo macio e dinâmica de fluidos,ferramentas de modelagem baseadas em modificadores, ferramentas de animaçãode personagens, um sistema de composição baseado em "nós"de texturas, cenase imagens, e um editor de imagem e vídeo, com suporte a pós-produção. Incluisuporte a Python como linguagem de script, que pode ser usada tanto no Blender,quanto em seu motor de jogo. Atualmente, suporta 25 idiomas, incluindo o por-tuguês brasileiro.

2.6 Grafos

Em matemática e ciência da computação, grafo é o objeto básico de estudo dateoria dos grafos. Tipicamente, um grafo é representado como um conjunto depontos (vértices) ligados por retas (as arestas). Um grafo é um tipo especial dedigrafo, também conhecido como grafo não dirigido e grafo não orientado.

Um digrafo consiste em dois conjuntos: um conjunto de vértices (ou nós) e umconjunto de arcos. Cada arco é um par ordenado de vértices. O primeiro vérticedo par é a ponta inicial do arco e o segundo é a ponta final.11

A ponta final de todo arco é diferente de sua ponta inicial. Um arco com ponta

11A palavra digrafo não consta dos dicionários, mas é cômoda e corresponde bem ao termodigraph em inglês, que já está bastante arraigado. Alguns autores descuidados escrevem "dígrafo",com acento; isso não faz sentido algum e deve ser evitado a todo custo.[10]

7

inicial v e ponta final w será denotado por v-w. A presença de um arco v-w éindependente da presença do arco w-v: o digrafo pode ter os arcos v-w e w-v,pode ter apenas um deles, ou pode não ter nenhum deles.

Dizemos que um vértice w é vizinho de um vértice v se v-w é um arco dodigrafo. Dizemos também, nessa circunstância, que w é adjacente a v.

Um caminho num digrafo é uma sequência de vértices com a seguinte pro-priedade: se v e w são vértices consecutivos na sequência então v-w é um arco.Em geral, os vértices de um caminho não são todos distintos.

A origem de um caminho é o primeiro vértice do caminho. O término é oúltimo vértice. Diz-se que um caminho com origem s e término t vai de s a t.

Dizemos que um arco v-w pertence a um caminho se o vértice w é o sucessorde v no caminho. Todos os arcos de um caminho apontam no mesmo sentido, deum vértice para o seu sucessor.

O comprimento de um caminho é o número de termos da sequência menosum. Em outras palavras, o comprimento de um caminho é o número de arcos docaminho.

Em grafos, a existência de caminhos é uma propriedade simétrica: para quais-quer dois vértices s e t, existe caminho de s a t se e somente se existe caminho det a s.

Uma arborescência é um digrafo em que:

• Não existem vértices com grau de entrada12 maior que 1;

• Existe exatamente um vértice com grau de entrada 0;

• Cada um dos vértices é término de um caminho com origem no único vérticeque tem grau de entrada nulo.

Os grafos são muito úteis na representação de problemas da vida real, emvários campos profissionais. Por exemplo, pode-se representar um mapa de estradasatravés dos grafos e usar algoritmos específicos para determinar o caminho maiscurto entre dois pontos, ou o caminho mais econômico. Assim, os grafos podem

12O grau de saída de um vértice v num digrafo é o número de arcos que têm ponta inicial v. Ograu de entrada de um vértice w num digrafo é o número de arcos que têm ponta final w.[13]

8

possuir também pesos (ou custo), quer nas arestas quer nos vértices, e o custo totalem estudo será calculado a partir destes pesos.

2.6.1 Algoritmo de Dijkstra

Seja o problema do caminho mínimo:

• Problema do Caminho Mínimo com Origem e Término Fixos: Dados vér-tices s e t de um digrafo com custos não negativos nos arcos, encontrar umcaminho mínimo simples de s a t.

• Problema dos Caminhos Mínimos com Origem Fixa: Dado um vértice s deum digrafo com custos não negativos nos arcos, encontrar, para cada vérticet que pode ser alcançado a partir de s, um caminho mínimo simples de s a t.

O algoritmo de Dijkstra resolve eficientemente o problema do caminho mín-imo se os custos dos arcos não forem negativos.

No início de cada iteração, temos uma arborescência T com raiz s. Para qual-quer vértice w fora de T, o custo de w em relação a T é, por definição, a distânciade s a w no digrafo T+F, sendo F a franja de T. Aqui, a franja de T é o conjuntode todos os arcos que saem de T. Em outras palavras, o custo de um vértice w queestá fora de T é o custo de um caminho mínimo dentre os que começam em s,terminam em w, e só têm um arco — o último — fora de T. Diremos que o últimoarco de um tal caminho mínimo é o arco-pai de w.

Cada iteração do algoritmo de Dijkstra consiste no seguinte:

se a franja de T não é vazia

então

seja w um vértice fora de T que tem custo mínimo

seja e o arco-pai de w

comece nova iteração com T+e no papel de T

senão

pare

9

2.7 Computação Gráfica

Muitos elementos de computação gráfica são usados de forma mais simples atravésde recursos do Ogre, como manipulação de câmera e de objetos através de nós eo gerenciador de cena. Porém, alguns recursos, como quatérnios, são difíceis deserem usados sem saber o que eles são, ou como eles funcionam.

2.7.1 Bounding box

Em softwares de ilustração e paginação, bounding box13 é uma caixa retangularque surge sobre um objeto selecionado; é formada por quatro ou oito pontos decontrole que são manipulados para distorcer, mover, girar etc. Alguns problemasem arquivos fechados (rotação e corte irregular) podem ser resolvidos alterando-seos valores numéricos associados a esses pontos de controle.

2.7.2 Billboarding

Billboarding14 é uma técnica que ajusta a orientação do objeto para encarar umalvo, o qual pode ser a câmera. É uma técnica muito popular em jogos e aplicaçõesque precisam de um grande número de polígonos.

Billboarding pode ser usado para diminuir o número de polígonos necessáriospara modelar uma cena, trocando geometria por uma textura. Um exemplo clás-sico é uma árvore. Considere quantos polígonos seriam necessários para uma rep-resentação decente de uma árvore. Billboarding permite-nos trocar a geometriacom uma única textura aplicada em um quadrilátero (ou dois triângulos). Assim,é possível criar uma árvore ilusória, apesar de ser possível perceber o que foiusado navegando ao redor da árvore.

No Ogre3D[1] existem estruturas para criação e manipulação de billboard.

2.7.3 Câmera virtual

A câmera virtual possui os seguintes parâmetros:

• Definimos seis parâmetros extrínsecos:13Bounding box significa caixa de contorno.[23]14Billboard também é conhecido como sprite.

10

– C = (Cx, Cy, Cz) - centro de projeção (posição);

– u, v, n - referencial (orientação);

A posição da câmera virtual é dada pelo centro de projeção C quecorresponde ao centro ótico. Para especificar a orientação precisamosdefinir um referencial. Inicialmente definimos o eixo ótico (direçãolongitudinal) da câmera especificando um vetor N chamado vetor do

eixo ótico. Esse vetor juntamente com o centro de projeção C definemum raio r chamado de eixo ótico da câmera.

O plano de projeção Π da câmera virtual é o plano perpendicular aoeixo ótico, situado a uma distancia d do centro de projeção. Portantoo vetor normal do plano de projeção é o vetor do eixo ótico N. Adistância d é chamada de distância focal.

Escolhemos agora um vetor V, não colinear com o vetor do eixo óticoN. Esse vetor é chamado de vetor de inclinação. Os vetores N e Vdeterminam o plano vertical-longitudinal da câmera. (Em termos in-tuitivos, a rotação desse plano em torno do eixo ótico determina ainclinação da câmera em relação ao espaço da cena.)

Usamos agora o vetor do eixo ótico N e o vetor de inclinação V paraconstruir o referencial da câmera virtual. Para isso, normalizamos ovetor do eixo ótico N, obtendo o vetor n = N/||N||. Em seguida obtemosa partir do vetor de inclinação V um vetor unitário v, normal ao vetorn, utilizando o processo usual de orto normalização de vetores (Gram-Schmidt): projetamos V sobre n, subtraímos essa projeção do vetor Ve em seguida normalizamos o vetor obtido. Ou seja:

v = V−<V,n>n|V−<V,n>n|

O vetor v é chamado de vetor vertical do referencial. O último vetoru do referencial da câmera é obtido tomando o produto vetorial15 dovetor do eixo ótico com o vetor vertical:

15Produto vetorial: a⊗ b =

∣∣∣∣∣∣i j k

a1 a2 a3b1 b2 b3

∣∣∣∣∣∣ = [a2 ∗ b3 − a3 ∗ b2, a3 ∗ b1 − a1 ∗ b3, a1 ∗ b2 −

a2 ∗ b1].[24]

11

u = n ⊗ v.

O referencial C, u,v,n define as coordenadas no espaço da câmeravirtual.

• Definimos sete parâmetros intrínsecos:

– d - distância focal;

– Q = (umin, vmin), S = (umax, vmax) − Telavirtual;

– n - distância do plano anterior;

– f - distância do plano posterior;

2.8 Orientação à objetos

2.8.1 Singleton

Singleton16 é um padrão de projeto de software17. Este padrão garante a existênciade apenas uma instância de uma classe, mantendo um ponto global de acesso a seuobjeto.

Muitos projetos necessitam que algumas classes tenham apenas uma instância.Por exemplo, em uma aplicação que precisa de uma infraestrutura de log de dados,pode-se implementar uma classe no padrão singleton. Desta forma existe apenasum objeto responsável pelo log em toda a aplicação que é acessível unicamenteatravés da classe singleton.

Em C++:18

class MyClass

{

private:

// atributo estático da "instância única".

static MyClass *instance = 0;

16O termo vem do significado em inglês quando se resta apenas uma carta nas mãos, num jogode baralho. [22]

17Do inglês Design Pattern.18Retirado da wikipedia.[22]

12

//construtor privado.

MyClass() {}

public:

// Função-membro que retorna sempre a

//mesma instância do objeto.

static MyClass& getInstance()

{

if (!instance) instance = new MyClass();

return *instance;

}

};

2.9 Licenças

2.9.1 MIT

A licença MIT19 é uma licença de software livre permissiva, o que significa quepossui exigências mínimas com relação à como o software é redistribuído. Pode-se usar um software com licença MIT em um software proprietário ou em umsoftware livre. Também é possível modificá-la para atender as necessidades doproprietário do software, pois não há copyright no texto de sua licença.

Uma forma comum da licença MIT é definida abaixo:

Copyright (C) <year> <copyright holders>

Permission is hereby granted, free of charge, to any person obtaininga copy of this software and associated documentation files (the "Soft-ware"), to deal in the Software without restriction, including withoutlimitation the rights to use, copy, modify, merge, publish, distribute,sublicense, and/or sell copies of the Software, and to permit personsto whom the Software is furnished to do so, subject to the followingconditions:

19Mais informações sobre a licença MIT em [7]

13

The above copyright notice and this permission notice shall be in-cluded in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTYOF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOTLIMITED TO THE WARRANTIES OF MERCHANTABILITY, FIT-NESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLD-ERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIA-BILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OROTHERWISE, ARISING FROM, OUT OF OR IN CONNECTIONWITH THE SOFTWARE OR THE USE OR OTHER DEALINGSIN THE SOFTWARE.

2.9.2 zlib

A licença zlib20 é uma licença de software livre permissiva. A licença tem osseguintes pontos a serem considerados:

• Software é usado na base "tal como está". Os autores não se responsabi-lizarão por quaisquer danos decorrentes da sua utilização.

• A distribuição de uma versão modificada do software está sujeita às seguintesrestrições:

1. A autoria do software original não deve ser desvirtuada;

2. versões originais alteradas não devem ser deturpados como sendo osoftware original;

3. O anúncio da licença não deve ser removido da distribuição de origem.

Os termos da licença são:

Copyright (c) <”year”> <”copyright holders”>

20Mais informações sobre a licença zlib em [17].

14

This software is provided ’as-is’, without any express or implied war-ranty. In no event will the authors be held liable for any damagesarising from the use of this software.

Permission is granted to anyone to use this software for any purpose,including commercial applications, and to alter it and redistribute itfreely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you mustnot claim that you wrote the original software. If you use this softwarein a product, an acknowledgment in the product documentation wouldbe appreciated but is not required.

2. Altered source versions must be plainly marked as such, and mustnot be misrepresented as being the original software.

3. This notice may not be removed or altered from any source distri-bution.

3 Atividades realizadas

3.1 Definição da parte gráfica

A parte gráfica poderia ser implementada através de Ogre3D, que é um motor grá-fico para C++, ou Panda3D, que é um motor de jogo para Python. Usando apenasos exemplos que vieram junto com cada biblioteca foi possível notar a diferençade desempenho entre as duas. Ogre3D, mesmo usando melhores efeitos, comosombra e mais iluminação, com objetos mais complexos, conseguia manter a taxade quadros por segundo mais estável que o Panda3D. Além disso, os exemplos doOgre3D também produziam melhores imagens.

Os códigos fonte dos exemplos do Panda3D eram muito mais simples e maiscurtos em relação aos do Ogre3D.

Para a escolha pesou mais a utilidade a longo prazo e o desempenho. O jogocriado neste trabalho poderia ser criado em Panda3D com menos trabalho, masOgre3D parecia ser mais útil e claramente era mais rápido.

15

Outras bibliotecas existentes que poderiam ser utilizadas são Irrlicht e Unity.Unity não possui versão para GNU/Linux.21

3.2 Desenvolvimento do projeto do jogo

Foi decidido isolar os recursos importantes em classes separadas, mas que se co-municavam. Como era necessário apenas uma instância de algumas classes, edeveria ser possível acessar essa instância de diferentes pontos do programa, foidecidido usar singleton. Assim, o programa tem algumas classes importantes, quepodem ser acessadas de diferentes pontos do programa:

• O sistema gráfico, onde é tratado a inicialização do Ogre e CEGUI, além dedar informações com relação a exibição de gráficos (como a taxa de quadrospor segundo);

• O gerenciador de telas, que é o local onde ficam todas as cenas. Ogrechama as funções membro dessa classe para atualizar a cena sendo usada.Também é possível acessar uma cena através dele. Para cada quadro, ogerenciador de telas chama o sistema de entrada para atualizar os eventosdo mouse e teclado;

• O sistema de entrada, que serve para gerenciar os eventos de teclado emouse, guardando também os tipos de mouse e teclado de cada cena. Re-cupera alguma cena através do gerenciador de telas quando é necessário, enormalmente usar o gerenciador de eventos para voltar a tela de título aopressionar ESC;

• O gerenciador de eventos (ou eventos de jogo), que guarda o evento atuale muda quando é requisitado. Além disso, guarda informações para as fasesdo jogo, como a batalha;

• A classe de dados, que serve para armazenar e dar fácil acesso a todasas informações dos elementos do jogo, como generais, castelos e grupos.

21Unity 4.0 foi confirmado ter suporte nativo para GNU/Linux, mas ainda não foi lançado. Noperíodo da criação deste trabalho Unity estava na versão 3.5.[6]

16

Além disso, dá informações sobre o jogador, como quantas vitórias foramatingidas ou em qual semana o jogo está;

3.3 Criação do mundo

O mundo é onde o jogo progride. Aqui, os generais sempre estão em grupos oudentro de um castelo. Se um grupo de generais encontrar outro grupo ou castelode uma nação diferente da sua, um combate acontece.

3.3.1 Implementação do mundo

O mundo foi implementado como um grafo2.6, onde os nós são os lugares (caste-los, vilarejos e cavernas) e os caminhos são suas arestas. Para isso foram criadosarquivos de texto onde estão definidos os lugares, condições importantes e suaslocalizações. Como o castelo pode aumentar de nível, é importante ter uma estru-tura fora do programa para facilitar o sistema de salvar/carregar jogo.

Os castelos inicialmente foram desenvolvidos usando o Blender2.5, mas oplug-in para exportar os arquivos gerados para o formato que o Ogre aceita (mesh)não funcionou adequadamente. Então foi decidido criar as estruturas dentro doprograma usando o ManualObject22, que tornou esta parte do trabalho mais fácil.ManualObject foi usado para criar todas as estruturas do jogo, com exceção dopiso.

Talvez por limitação de hardware, não foi possível usar o sistema de terrenosdo Ogre. O motivo de se cogitar "limitação de hardware"foi que mesmo os exem-plos dos tutoriais do Ogre não funcionaram completamente (aparecia algo quetalvez fosse parte do terreno, mas mudava a cor depois de pouco tempo, além deproduzir exceções no relatório do Ogre). Assim, foram usados planos para definiro terreno.

CEGUI2.4 foi usado para a criação dos menus. O problema do CEGUI é comrelação aos seus tutoriais e documentação, ainda que usá-lo tenha sido razoavel-mente simples.

22ManualObject é uma classe do Ogre que possui uma interface simplificada para a criação deobjetos manualmente.

17

Foram produzidas as faces dos generais usando o Gimp2.5, que possui umscript23 que facilita a criação de imagens e imagesets para o CEGUI. O scriptproduz o arquivo de imagem e o arquivo .xml para as faces baseado nas camadasda imagem original.

Os menus foram feitos em XML usando um editor de texto comum (gedit).Há programas para a criação dos arquivos de layouts de forma visual, mas nãofuncionaram corretamente.

O objetivo com relação à câmera era que ela pudesse ver todos os lugares comfacilidade, mas que não ultrapassasse uma certa distância e nem invadisse o chão.Usando os nós do Ogre isso foi alcançado com certa facilidade, mas a câmeraapresentava uma distorção caso a direção para onde ela olha era paralela à vertical.Isso acontece possivelmente porque o vetor vertical da câmera fica paralelo ao seuvetor de eixo ótico. Para corrigir esse problema foi necessário, inicialmente, fazercom que a câmera não olhasse para cima ou para baixo, adicionar a câmera emnós do Ogre e, através deles, girá-la. Isso faz com que toda a estrutura da câmeragire também.

A seleção de objetos foi feita através de ray querys24, que captam os objetosque o atravessam. Os objetos podem ser encontrados pelo raio através de duasformas diferentes:

• Faces do objeto: Pode-se testar cada triângulo da malha do objeto e verse o raio passou por ele. É um método custoso e mais complicado (maiscódigo). Para o jogo, não teria um custo grande pois uma consulta é feitasempre após um clique do mouse, o que paralisa o jogo e chama os menus;

• Bounding box2.7.1: A outra forma é através de bounding box. É rápidoe Ogre usa esse tipo de consulta por padrão, além do próprio Ogre gerarbounding box automaticamente para cada objeto da cena. O problema destemétodo é quando a caixa gerada é exageradamente grande, como é o casoquando é criado billboards (que é grande possivelmente para garantir quequalquer rotação do plano do billboard continue dentro do bounding box).

23O script pode ser encontrado neste endereço: http://registry.gimp.org/node/612824Ray query é como uma reta, que retorna os objetos que atravessa, na cena dada.

18

Figura 1: Um bounding box de um billboard. O billboard é o retângulo branco eo bounding box são as retas brancas que formam uma caixa ao redor do billboard.Este bounding box foi diminuído.

Foi escolhido o bounding box pela facilidade e velocidade, mas foi necessáriolimitar seu bounding box, o que era necessário pois, quando era criado um ob-jeto da cena que usava um billboard, ficava praticamente impossível selecionarqualquer coisa ao seu redor.

Ogre disponibiliza algumas estruturas para a manipulação de bounding box

com facilidade.Para melhorar o desempenho foi decidido não usar "dynamic_cast"quando

fosse necessário converter ponteiros, e em seu lugar usar "static_cast"com algumidentificador.

As comparações foram feitas usando o comando time no seguinte programaescrito em C++:

using namespace std;

class Base

19

Tabela 1: Comparações entre static_cast e dynamic_cast

Número de ponteiros static_cast dynamic_cast10 0 0

100 0 01000 0 010000 0 0

100000 0 0.0041000000 0 0.028

10000000 0 0.232100000000 0 2.228

{

public:

virtual int Val() = 0;

virtual string Classe(){return "base";}

};

class D1 : public Base

{

public:

virtual int Val() {return 1;}

virtual string Classe() {return "D1";}

};

class D2 : public Base

{

public:

virtual int Val() {return 2;}

virtual string CLasse() {return "D2";}

};

class D3 : public D1

{

public:

20

virtual int Val() {return 3;}

virtual string Classe() {return "D3";}

};

volatile D3* d3;

void DynamicCastTest (int n)

{

Base* base = new (D3);

for (int i = 0; i < n; i++)

{

d3 = dynamic_cast <D3*> (base);

}

delete base;

}

void StaticCastTest (int n)

{

Base* base = new (D3);

for (int i = 0; i < n; i++)

{

d3 = static_cast <D3*> (base);

}

delete base;

}

int main (int argc, char* argv[])

{

if (argc < 3)

21

return 0;

switch (argv[1][0])

{

case ’d’:

DynamicCastTest(atoi(argv[2]));

break;

case ’s’:

StaticCastTest(atoi(argv[2]));

break;

default:

break;

}

cout << "Terminado" << endl;

return 0;

}

3.3.2 Grupos

Os lugares do mundo são posições fixas, então basta carregá-los no início de cadajogo. Castelos podem aumentar ou diminuir o nível, mas tudo que é feito é trocarsua forma. Ao contrário dos lugares, os grupos não são objetos fixos e são cria-dos através de ações do jogador, além de possuir ações como andar e entrar emcastelos.

As ações do grupo são:

• Entrar no castelo: Os generais entram no castelo se todos os prisioneirospodem ser guardados. Caso não exista espaço para todos os generais, apenasalguns entram no castelo e o restante permanece no grupo; 0

• Parar: Se um grupo ganhar uma luta, ele ficará parado por um tempo;

22

• Andar: É selecionado um destino e o grupo anda até ele, com a possibilidadede encontrar um grupo ou castelo de uma nação adversária;

• Esperar do lado de fora: Grupos que esperam do lado de fora de um castelo,sem entrar nele, são os primeiros a lutar quando um castelo é invadido;

As ações são colocadas em uma lista de ações de cada grupo. Assim, quandouma ação acaba, basta ir para a próximo, destruindo a antiga.

Para a ação de andar é necessário conhecer um caminho para o destino. Oalgoritmo de Dijkstra2.6.1 fornece uma forma de encontrar o caminho mais curtopara um digrafo, se não existirem arestas com custo negativo. No caso do mundo,o custo é a distância entre dois lugares, então sempre será positivo.

Dijkstra é usado no início do jogo, encontrando os caminhos mais curtos earmazenando em uma matriz, consultada toda vez que um grupo for andar paraalgum lugar. Assim, se um grupo deseja ir para um lugar x, ele consultará a matrizcom o resultado de Dijkstra, armazenará em uma lista de ações e andará seguindoo caminho.

Os grupos são representados por billboards2.7.2, sendo que mantem a coor-denada y constante, mas as demais são modificadas de modo que sempre encarama câmera (há uma opção para isso no Ogre).

Para andar, a cada quadro uma lista de caminhos ativos, que são caminhos quepossuem pelo menos um grupo, é percorrida. Cada um desse caminhos ativos, queé uma lista de grupos, também é percorrido, de modo que os grupos do caminhofaçam suas ações.

Os caminhos são dados em uma matriz, sendo que metade dela não é usada.Por exemplo, se existe um caminho do lugar 0 para o 3 ou do 3 para 0, existeuma lista de grupos na posição da matriz (3,0), mas na posição (0,3) não há nada.Grupos são adicionados no fim ou no começo da lista de grupos do caminho, eexecutam suas ações. Quando há uma colisão, o grupo anda somente até a posiçãode impacto. Se a colisão for entre dois objetos de nações diferentes, começa umabatalha, caso contrário, os grupos apenas trocam de lugar na lista caso estejamandando em sentidos contrários.

Grupos que estão "esperando do lado de fora"não estão em um caminho. Nestecaso, fazem parte de uma lista de grupos de um lugar e não são atualizados a cada

23

quadro.Grupos que entram em um castelo e ficam vazios são destruídos quando forem

atualizados, assim como grupos que estão esperando do lado de fora e recebem aordem de entrar.

Quando há uma batalha, os seguintes eventos podem ocorrer:

• O grupo vence a batalha contra um castelo: Alguns generais inimigos queforem enfraquecidos na batalha se tornarão prisioneiros do grupo e o restantedos generais inimigos formarão um grupo e irão para outro lugar vizinho aoatual. O grupo entrará no castelo vazio;

• O grupo vence a batalha contra um outro grupo: O grupo vencedor ficaráparado por algum tempo;

• O grupo perde a batalha: Ele passa a percorrer o caminho no sentido con-trário, caso ainda exista algum general no grupo. Se não existir nenhumgeneral, nada é feito e quando este grupo for se mover, será destruído (oobjeto, que contém o billboard e será destruído pelo gerenciador de cena);

3.3.3 Jogada dos inimigos

A jogada do computador precisava:

• Ser rápida: O jogo não poderia ficar mais lento por causa que o oponenteestava pensando;

• Razoavelmente correta: O inimigo tem que fazer jogadas que pelo menosfazem algum sentido. Por exemplo, não enviar grupos para algum lugarquando não há chance de vitória;

A primeira ideia foi usar uma thread para cada nação e uma para aqueles quenão fazem parte de uma. Ao usar threads, os inimigos poderiam pensar enquantoo jogo ocorre.

Um problema ao usar threads é com relação às regiões críticas. Uma threadnão poderia, por exemplo, bloquear o acesso a um castelo e seus generais pormuito tempo, pois talvez outra nação precise consultá-lo. Outro problema é que

24

o jogo muda constantemente, então uma estratégia sendo desenvolvida pode serinvalidada a qualquer momento.

A jogada do computador usada foi a seguinte:

• Baseada em castelos, e não em nações: Os castelos que possuem generaisinimigos olham para seus vizinhos, e decidem suas ações baseado em umvalor dado para cada vizinho. Este valor é dado as características do lugar(como o número de generais de um lugar);

• Não usa threads: Não existe risco de bloquear o acesso a algo importantepor muito tempo;

• Grupos tentam ir para um castelo aliado ou vão para algum castelo quetenham alguma chance de vitória;

• Às vezes joga aleatoriamente;

O inimigo joga rapidamente e melhor do que se fosse completamente aleatório,mas ainda não joga bem. É possível ver que os inimigos podem, às vezes, ficarindo e voltando para o mesmo castelo, pois ao formar um grupo o castelo antigoacaba sendo um bom lugar para voltar. A jogada aleatória evita que isso sempreocorra.

3.4 Criação do gerenciador da nação

O gerenciador da nação aparece depois de um tempo enquanto no evento domundo. No gerenciador (conhecido no jogo como assuntos internos), pode-sefazer buscas nos castelos, recrutar generais capturados, equipar itens e salvar ojogo.

Para realizar as ações foram usados menus implementados usando CEGUI.As ações do jogador nesta parte são:

• Equipar ou usar itens: Um jogador pode selecionar um item e, caso a classedo general permita, ele pode ser equipado ou usado. Um item usado desa-parece, e um item equipado é adicionado ao general, substituindo um itemantigo, se existir. A classe de dados tem a quantidade de itens que a naçãodo jogador possui, então eles modificados nesta ação;

25

• Buscas em um castelo: Um general pode fazer buscas em um castelo de-pendendo de sua inteligência. Aqui pode-se obter os itens. Ao selecionaresta opção um general "fez seu trabalho", e não pode ser selecionado paraoutra ação, como fortalecer os castelos. A busca, na verdade, olha não só ocastelo em que ela é realizada, mas também os vizinhos vilarejos ou caver-nas. Os itens obtidos são definidos no arquivo de entrada dos lugares, assimcomo a probabilidade de obtê-los;

• Fortalecer castelos: Um castelo possui um nível, que pode diminuir quandoé invadido. O nível do castelo define a quantidade de recrutas que ele temdisponível, e estes recrutas são usados para recuperar as tropas dos generais.Como na busca no castelo, um general que fortalece um castelo também"faz seu trabalho", e assim não pode fazer outra busca ou fortalecer mais ocastelo enquanto não passar pela fase do mundo novamente;

• Recrutar prisioneiros: É possível recrutar generais para sua nação. Um testeé feito usando a lealdade, que é uma característica do general, e um númeroaleatório. Quanto menor a lealdade, mais fácil é recrutá-lo;

• Aumentar as tropas: É possível aumentar as tropas do general caso ele tenhaalguma medalha, que podem ser obtidas ao derrotar um general inimigo.Qualquer general da nação pode ter suas tropas aumentadas, a não ser queelas já estejam em seu nível máximo ou o general não tenha o controle datropa dada;

3.5 Criação da batalha

O combate entre dois grupos de generais acontece no evento de batalha. Os gen-erais lutam um de cada vez contra um outro general do grupo oponente.

A batalha acontece da seguinte forma:

• Duelo entre duas tropas: os generais ficam parados, distantes um do outro,e quem anda pelo cenário são suas tropas. As tropas lutam entre si e tentamalcançar o outro general. O jogador dá instruções para sua tropa sobre comodevem se comportar (avançar, recuar, parar ...);

26

• Duelo entre dois generais: não há mais tropas, então um general deve lutarum contra o outro diretamente;

Além do combate em si, existe o menu de seleção de generais ou da ação dogrupo (fugir, lutar, etc).

A batalha entre duas nações controladas pelo computador acontece baseadanas características dos generais dos grupos ou castelos envolvidos. Somam-se ascaracterísticas que podem dar a vitória, e quem ficou com uma pontuação maiorganha. Pertencer a uma nação também é um fator positivo para a vitória.

3.5.1 Antes da batalha

Como no gerenciador da nação, o recurso mais usado foi o CEGUI, para sele-cionar generais e as ações do grupo.

Generais selecionados para a batalha são enviados para o gerenciador de even-

tos, onde a cena de batalha os recupera e produz suas informações para o eventode batalha.

Existem as opções:

• Lutar: Vai para onde os generais podem ser escolhidos, e assim começar abatalha;

• Falar: O inimigo avalia o grupo do jogador. Se ele tem chance de vencer,o evento de batalha continua. Caso contrário, a luta acaba em empate(ninguém perde nada);

• Fugir: O jogador perde a batalha, podendo perder parte de sua tropa e pri-sioneiros. Se o jogador estiver em um castelo, o castelo é conquistado peloinimigo e grupos do jogador são formados, indo para algum vizinho docastelo;

3.5.2 A batalha

Os elementos da batalha são:

• O campo de batalha: Tem o propósito de mostrar para todos no campo ondeestão os outros elementos do campo. Implementado como uma matriz;

27

• Os soldados: Soldados são as unidades da tropa de um general. Cada tipo detropa possui soldados com alguma vantagem ou desvantagem com relaçãoa outra tropa;

• Os generais: Existem dois generais no campo de batalha: o general inimigoe o general do jogador. Suas barras de vida (HP) ficam no topo da tela, equando alguma delas fica vazia um general é derrotado;

• Os projéteis: Criados por alguns soldados. Atravessam o campo e, caso sechoquem com algum inimigo, o eliminam se as condições de acerto foremcumpridas;

• Ataques especiais: Percorrem o campo, destruindo o que esta em seu cami-nho e/ou afetando o general adversário;

Os soldados são separados em 4 listas: 2 listas (uma para o jogador e outra parao computador) com soldados que irão seguir instruções dadas pelo jogador/computador,e 2 com soldados que ficarão na defesa. Estes soldados da defesa não aceitarão or-dens e apenas ficarão rodeando o general, de modo a defendê-lo de outras tropas.

A cada quadro os soldados olham o campo de batalha e decidem suas ações,que podem ser atacar algum soldado inimigo ou seguir alguma instrução. Asinstruções são dadas pelo computador ou jogador. Algumas instruções são:

• Avançar: Ir até o general inimigo;

• Recuar: Ir na direção oposta do general inimigo;

• Reagrupar: Soldados para o centro (em relação a profundidade, ou a coor-denada z) do campo de batalha;

• Dispersar: O contrário de reagrupar - ir para os cantos do campo de batalha,em relação à coordenada z;

• Esperar: Os soldados ficam parados;

Cada uma das ações dos soldados são implementados tendo como referênciaum dos generais ou alguma posição do campo de batalha. Para andar, é testado se

28

não há ninguém no destino. Em caso positivo, o soldado vai começar a caminharpara aquela posição. Todo quadro ele se atualiza até chegar a posição desejada.

Antes de seguir uma instrução, o soldado testa se na matriz do campo debatalha há alguém a sua frente ou atrás. Se tiver, ele começa o ataque. Casoo inimigo tenha saído daquela posição quando o ataque realmente for feito, eletermina a animação do ataque e ninguém é destruído.

O ataque de um soldado acerta dependendo do "comando"25 do general. Aprobabilidade de acerto depende também da tropa inimiga e do lugar onde acon-tece a batalha.

Generais agem de forma similar aos soldados, porém não aceitam instruções enão se movem. O objetivo é derrotar o general adversário, e cada general tentaráse defender. No duelo, os generais ficam frente a frente e se atacam até que umseja derrotado, ou seja, seus pontos de vida ficarem iguais a zero.

A batalha possui duração de no máximo 100 segundos. Se um resultado nãofor alcançado neste tempo (ou ir para o duelo), a luta termina em empate.

Sobre os resultados de uma batalha, um general que é derrotado fica sem suaface na seleção de generais, antes da luta. Os resultados são guardados em umvetor booleano, e comunicados através do gerenciador de eventos.

4 Resultados

A forma básica do jogo está pronta. Alguns recursos, como salvar o jogo, acabaramnão sendo implementados e faltaram alguns gráficos para representar alguns ob-jetos (como alguns itens e tropas).

O computador no mundo tenta expandir seu território e, na maioria das vezes,de forma segura. Porém, o computador da batalha apenas faz com que suas tropasataquem, o que os tornam oponentes fáceis de serem derrotados.

O jogador pode escolher sua nação no início do jogo, organizar grupos, con-quistar castelos e recrutar novos generais para sua nação. Na batalha, o jogadorpode dar ordens para suas tropas e, caso não exista mais tropas, pode optar porperder o combate ou ir para o duelo. Nos assuntos internos, é possível equipar

25Comando é uma das características do general, que define parte da probabilidade de acerto desuas tropas.

29

Figura 2: O mundo.

Figura 3: O mundo, em outra posição.

30

Figura 4: O mundo, em outra posição.

Figura 5: A janela de seleção de generais no mundo.

31

Figura 6: Assuntos internos.

Figura 7: A batalha. Na parte de cima, a barra de HP de cada general e suas faces,a tropa que ainda resta para cada general e o tempo para o fim da luta. Na parte debaixo temos uma barra de "poder", que quando preenchida permitiria ao generalusar habilidades especiais, se tiver MP, que são os números em branco.

32

itens, aumentar tropas caso o jogador tenha ganho alguma batalha, fazer buscasem castelos e melhorar castelos.

Nos combates, todas as tropas apenas atacam inimigos que estão a sua frente.A ideia é que arqueiros, por exemplo, pudessem atacar inimigos a longa distância.

O jogo não possui uma história, ainda que fosse fácil adicioná-la no jogo. Nãofoi adicionada por falta de tempo. Basicamente a história andaria quando um líderinimigo fosse capturado, e no fim haveria um único inimigo que, se derrotado,levaria ao final do jogo.

O jogo é jogável, tem suas principais funções que foram definidas na proposta,mas faltam os recursos mencionados.

O jogo roda em torno de 60 quadros por segundo (normalmente variando entre55 a 60).

5 Conclusões

O planejamento de cada fase foi importante para o desenvolvimento do jogo, poispermitiu facilmente adicionar e testar novas funcionalidades.

Como este jogo foi baseado em um jogo existente26, alguns recursos forammais fáceis de definir, como a forma dos menus e onde eles apareceriam.

O uso de um motor gráfico permitiu, após aprender a utilizá-lo, criar recursoscom maior facilidade. Além disso, Ogre é rápido. CEGUI possui alguns proble-mas que estão sendo corrigidos a cada nova versão, mas é muito útil e produz bonsresultados.

Apesar dos pontos que faltaram na implementação, o jogo é jogável.

6 Desafios e frustrações

Durante o curso de ciências da computação eu sempre pensei sobre o tema de meutrabalho de formatura, mas não cheguei em alguma conclusão sobre o que queriafazer. Eu havia gostado de várias disciplinas que fiz e por isso não encontrava

26Dragon Force. [4]

33

uma área em especial para produzir um trabalho, e também não consegui pensarem um projeto.

O tempo passou e fui obrigado a escolher. Pensei sobre o que eu queria fazernaquele momento (no início de 2012) e a resposta foi processamento de imagens.Gostaria de usar algoritmos que havia aprendido em outras disciplinas (como emgeometria computacional ou programação linear) para fazer algum tratamento ouclassificação de imagens, ou pelo menos estudar outros algoritmos para esse fim.

Fui atrás dos professores que havia tido aula e que falaram algo sobre o as-sunto, mas eles estavam ocupados com alunos da pós-graduação. Um professorme disse que alguns outros colegas já o haviam procurado e imaginei que talvezessa área estivesse cheia. Pensei em computação gráfica mas, pelo que vi, eramos mesmo professores.

Alguns colegas me disseram sobre a possibilidade de fazer um jogo, que eraalgo que não sabia que era possível. Durante as férias eu sempre começava afazer um jogo, mas sempre parava em algum ponto. Pensei que seria uma boaoportunidade de tentar fazer um até o fim e também ter a experiência de usar ummotor de jogo ou gráfico. Assim procurei o professor Flávio e ele aceitou a minhaproposta para o jogo.

O jogo foi muito mais trabalhoso do que eu havia pensado. No início Ogrenão foi algo muito trivial de se usar e tive alguns problemas com CEGUI, porqueapesar de ser fácil criar um layout em XML, é também fácil errar algo e váriasvezes não havia indicação sobre onde havia ocorrido o problema. Além disso,existe muita informação errada sobre Ogre e CEGUI pela internet.

Algumas ferramentas, como aquelas indicadas para se criar layouts dos menus,não funcionaram. Ao buscar alguma solução, vi que outras pessoas tambémtiveram os mesmos problemas. No caso do criador de layouts/imagesets do CEGUI,a resposta foi que o criador havia abandonado o projeto e uma nova ferramentafoi desenvolvida, que também possuía erros e, assim, não foi utilizada.

Imagens são um problema, porque muitas vezes os seus donos não deixammuito claro onde você pode usá-las. Eu acabei usando imagens que diziam quepoderiam ser usadas em qualquer lugar, imagens que vieram com o Ogre e CEGUIe imagens que eu mesmo criei.

Por fim, eu não fiz a disciplina de orientação a objetos. Acabei lendo sobre

34

ela, mas acredito que o projeto do jogo teria sido melhor se a tivesse feito.

7 Disciplinas importantes para o trabalho

• Introdução à Computação, Princípios de Desenvolvimento de Algoritmos,

Estruturas de Dados;

Disciplinas importantes para aprender o básico sobre programação, além deestruturas de dados muito importantes que são usadas durante todo o cursoe neste trabalho.

• Laboratório de Programação;

Onde temos as primeiras ideias sobre organização de código, além de desen-volvermos um projeto maior (quando comparados a um exercício-programa).Também temos uma introdução a linguagens de script.

• Laboratório de Programação II;

As primeiras ideias sobre orientação a objetos e mais sobre linguagens descripts.

• Algoritmos em Grafos;

Onde é aprendido a criação de grafos e algoritmos que os usam. Importantepara a criação do mundo (com relação as vizinhanças e castelos) e o algo-ritmo de Dijkstra resolve o problema de encontrar um caminho entre doiscastelos.

• Programação Orientada a Objetos;

Ogre e CEGUI usam orientação a objetos, assim como o jogo desenvolvido.Também importante com relação aos padrões de projeto.

• Engenharia de Software;

Importante para a criação do projeto do jogo.

• Direito e Software Livre;

Onde aprendi sobre algumas licenças e sobre leis com relação a software.

35

• Computação Gráfica;

Ogre abstrai boa parte do que é aprendido nesta disciplina, mas graças a elaque é possível realmente entender como tudo acontece, além de facilitar oentendimento de alguns conceitos. Além disso, foi graças a esta disciplinaque eu consegui corrigir alguns erros.

8 Melhoramento do projeto

• Som: Gostaria de ter adicionado som ao projeto e sei o que é necessário;

• Terreno: Não há rios no mundo. Também o chão é apenas um plano;

• Melhores modelos 3D e imagens: Foi evitado usar recursos disponíveispela internet e, por isso, acabei fazendo algumas imagens e modelos 3D.Gostaria de substituí-los no futuro;

• Algumas otimizações e melhor codificações de algumas partes;

• Jogada do computador no mundo: o problema é que o jogador teria quejogar bem, porém rápido. Esta parte do trabalho acabou ficando fraca porfalta de tempo;

• Jogada do computador na batalha: o computador acabou apenas enviandosuas tropas em direção ao inimigo. O ideal seria que cada tropa tivesse umaestratégia, seja na formação ou nas instruções, dependendo das condiçõesdo general;

• Ataques especiais: a barra inferior da luta e o "MP"acabaram ficando inú-teis. Alguns ataques especiais deveriam destruir a tropa do oponente queestá em alguma parte do campo, como o centro, e outros atacar diretamenteo general inimigo;

• Soldados com ataque de longa distância: Todos os soldados atacam apenasquem está a sua frente. Gostaria de adicionar disparos e flechas;

• Salvar o jogo;

36

• História no jogo: acabou não sendo colocada no jogo. De modo geral, ahistória para esse tipo de jogo é mais uma desculpa para fazer as ações, eacabei deixando de lado por causa que havia outras partes mais importantesdo trabalho a serem feitas. Basicamente seria colocar uma janela do CEGUIpara textos e ler um texto de um arquivo de texto, e atualizar cada vez queo botão esquerdo do mouse fosse pressionado. A história seria contadasempre na fase de "assuntos internos", em especial quando algum líder deoutra nação fosse capturado.

• Criar um executável em outros sistemas operacionais;

O jogo pode ser expandido, seja adicionando novas tropas ou nações, comotambém adicionar novas funções, como explorar as cidades e cavernas.

9 Futuro

Ainda existe no jogo algumas possibilidades de expansão. Gostaria de melhoraro código em algumas partes e adicionar o que é dito em 8, em especial a história,ataques especiais e salvar o jogo, já que eu gostaria de ter adicionado no jogoantes da entrega deste trabalho.

Sobre a jogada do computador, penso em criar alguma linguagem simples paraque um usuário possa criar um inimigo mais inteligente. Porém, preciso estudarmais sobre o assunto.

De qualquer forma, a criação do jogo me permitiu aprender vários recursospara a criação de um jogo, como o Ogre e CEGUI, além de outros que não foramusados no projeto, como um motor para física. Durante o desenvolvimento doprojeto tive várias ideias que gostaria de tentar e alguns recursos que gostaria deexplorar.

Referências

[1] Ogre3D. About. Disponível em: http://www.ogre3d.org/about. Acesso em:27 de agosto de 2012.

37

[2] Wikipédia. Motor gráfico. Disponível em:http://pt.wikipedia.org/wiki/Motor_gráfico. Acesso em: 27 de agostode 2012.

[3] Wikipedia. Game engine. Disponível em:http://en.wikipedia.org/wiki/Game_engine Acesso em: 27 de agostode 2012.

[4] Wikipedia. Dragon Force. Disponível em:http://en.wikipedia.org/wiki/Dragon_Force Acesso em: 27 de agostode 2012.

[5] Wikipedia. CEGUI. Disponível em: http://en.wikipedia.org/wiki/CEGUIAcesso em: 02 de setembro de 2012.

[6] Wikipedia. Unity (game engine). Disponível em:http://en.wikipedia.org/wiki/Unity_(game_engine). Acesso em: 15 desetembro de 2012.

[7] Wikipedia. MIT License. Disponível em:http://en.wikipedia.org/wiki/MIT_License. Acesso em: 15 de setembro de2012.

[8] Wikipedia. C++. Disponível em: http://pt.wikipedia.org/wiki/C++. Acessoem: 15 de setembro de 2012.

[9] Wikipedia. Paradigma de programação. Disponível em:http://pt.wikipedia.org/wiki/Paradigma_de_programação. Acesso em:15 de setembro de 2012.

[10] Paulo Feofiloff. Grafos. Disponível em:http://www.ime.usp.br/∼pf/algoritmos_para_grafos/aulas/graphs.html.Acesso em: 15 de setembro de 2012.

[11] Wikipedia. Object Oriented Input System. Disponível em:http://en.wikipedia.org/wiki/Object_Oriented_Input_System. Acessoem: 17 de setembro de 2012.

38

[12] Wikipedia. Grafos. Disponível em: http://pt.wikipedia.org/wiki/Grafo.Acesso em: 12 de novembro de 2012.

[13] Paulo Feofiloff. Digrafos. Disponível em:http://www.ime.usp.br/∼pf/algoritmos_para_grafos/aulas/digraphs.html.Acesso em: 12 de novembro de 2012.

[14] Paulo Feofiloff. Dijkstra. Disponível em:http://www.ime.usp.br/∼pf/algoritmos_para_grafos/aulas/dijkstra.html.Acesso em: 12 de novembro de 2012.

[15] Paulo Feofiloff. Arborescência. Disponível em:http://www.ime.usp.br/∼pf/algoritmos_para_grafos/aulas/arborescences.html.Acesso em: 27 de novembro de 2012.

[16] António Ramires Fernandes. Billboarding Tutorial. Disponível em:http://www.lighthouse3d.com/opengl/billboarding/. Acesso em: 16 denovembro de 2012.

[17] Wikipedia. Licença zlib. Disponível em:http://pt.wikipedia.org/wiki/Licença_zlib. Acesso em: 16 de novembrode 2012.

[18] Wikipedia. Ubuntu (operating system). Disponível em:http://en.wikipedia.org/wiki/Ubuntu_(operating_system). Acesso em:27 de novembro de 2012.

[19] Wikipedia. Blender. Disponível em: http://pt.wikipedia.org/wiki/Blender.Acesso em: 27 de novembro de 2012.

[20] GOMES, J.; VELHO, L.. Fundamentos da Computação Gráfica. 1 ed. Riode Janeiro: Instituto Nacional de Matemática Pura e Aplicada - IMPA, 2008.

[21] GAMMA, E.; HELM, R.; JOHNSON, R.E.; VLISSIDES, J.M.. Design

Patterns: Elements of Reusable Object-Oriented Software. 1 ed. EstadosUnidos: Addison-Wesley, 1995.

39

[22] Wikipedia. Singleton. Disponível em: http://pt.wikipedia.org/wiki/Singleton.Acesso em: 30 de novembro de 2012.

[23] Augusto Schwartz. Glossário-Termos Gráficos. Disponível em:http://augustoschwartz.blogspot.com.br/2008/05/glossrio-termos-grficos.html. Acesso em: 30 de novembro de 2012.

[24] Wikipedia. Produto vetorial. Disponível em:http://pt.wikipedia.org/wiki/Produto_vetorial. Acesso em: 2 de dezem-bro de 2012.

[25] Wikipedia. XML. Disponível em: http://pt.wikipedia.org/wiki/XML.Acesso em: 2 de dezembro de 2012.

40