UM MODELO ORIENTADO A OBJETOS PARA JOGOS EM COMPUTADOR

Transcrição

1 UNIVERSIDADE FEDERAL FLUMINENSE UM MODELO ORIENTADO A OBJETOS PARA JOGOS EM COMPUTADOR POR LUIS VALENTE Monografia apresentada ao Departamento de Ciência da Computação da Universidade Federal Fluminense como parte dos requisitos para obtenção do Grau de Bacharel em Ciência da Computação Orientador: Prof. Luiz Carlos Castro Guedes D.Sc. PUC-RJ Departamento de Ciência da Computação Niterói, Agosto de 2002

2 UM MODELO ORIENTADO A OBJETOS PARA JOGOS EM COMPUTADOR LUIS VALENTE Monografia apresentada ao Departamento de Ciência da Computação da Universidade Federal Fluminense como parte dos requisitos para obtenção do Grau de Bacharel em Ciência da Computação Avaliada em Agosto de 2002 Banca Examinadora Prof. Luiz Carlos Castro Guedes D.Sc. PUC-RJ Prof ª. Aura Conci D.Sc. PUC-RJ Prof. Luiz Carlos Montez Monte D.Sc. COPPE-UFRJ Niterói, 2002

3 i Resumo Programação de Jogos é uma área da Ciência da Computação que abrange uma grande quantidade de conhecimento, como Computação Gráfica, Programação de dispositivos de entrada, Programação de hardware para som, Redes de Computadores, Inteligência Artificial, Engenharia de Software e Concorrência (threads). O desenvolvedor de jogos precisa conhecer (senão dominar) boa parte dessas áreas, além de utilizar tecnologias que estão em constante evolução. Este projeto propõe uma ferramenta, conhecida como Máquina de Jogos (engine), com propósito de abreviar o tempo de desenvolvimento ao oferecer recursos diversos de alto nível, que englobem algumas dessas tecnologias necessárias. A Máquina de Jogos, que aplica paradigmas como Orientação a Objetos e Gestão Automatizada de Recursos, é destinada ao desenvolvimento de aplicações para o Sistema Operacional Windows e emprega tecnologias como OpenGL e DirectX.

4 Lista de Figuras Figura 4.1: Diagrama de classes para um Estado...15 Figura 4.2: Associação entre Estado e Máquina de Estados...17 Figura 4.3: Oráculo e suas especializações...21 Figura 4.4: Diagrama de classes para manipulação de janelas...24 Figura 4.5: Diagrama de classes relacionadas à biblioteca COM...25 Figura 4.6: Diagrama de classes relacionadas a recursos do Sistema Gráfico...28 Figura 4.7: Diagrama de classes para uma câmera...29 Figura 4.8: Diagrama de classes para representação de uma textura...31 Figura 4.9: Diagrama de classes relacionadas a modelos tridimensionais...34 Figura 4.10: Diagrama de classes para uma entidade...38 Figura 4.11: Diagrama de classes para o Sistema de Dispositivos de Entrada...41 Figura 4.12: Classe para representação de efeitos sonoros...43 Figura 4.13: Diagrama de Relacionamentos para a Máquina de Estados...44 Figura 4.14: Diagrama de Relacionamentos para objetos móveis, modelos 3D e texturas...45 Figura 4.15: Aplicação em execução...46 Figura 5.1: Visualização da cena...54 Figura 5.2: Cena com todos os efeitos gráficos aplicados...55 ii

5 Índice 1. Introdução Desenvolvimento de Jogos Módulo Gráfico Módulo de Sons Módulo de Dispositivos de Entrada Módulo de Física Módulo de Inteligência Artificial Módulo de Conectividade Máquinas de Jogos Exemplos de Máquinas de Jogos T3DLib Ack-3D OGRE Fly3D Conclusões Vantagens Desvantagens Uma Máquina de Jogos Gestão Automatizada de Recursos Objetos Automáticos Exemplo Exemplo Máquina de Estados Fluxo de Execução de Jogos Definição de Estado Associação entre Estados e Máquina de Estados Funcionamento da Máquina de Estados Comunicação entre Estados e Ambiente Exterior Ferramentas Utilizadas Ferramentas Disponíveis Sistema Windows Criação de Janelas Biblioteca COM Sistema Gráfico Câmeras Texturas Modelos 3D Sistema de Entidades Sistema de Dispositivos de Entrada Sistema de Som Diagrama de Relacionamentos da Máquina de Jogos Exemplo State.h State.cpp Resultados Experimentais Métricas de Desempenho Ambiente de Execução Propriedades da Simulação Orientação da Cena Efeitos Especiais Cenário Câmeras Projéteis Jogador...56 iii

6 Inimigos Efeitos Sonoros Dados Experimentais Resultados Obtidos Implementação do Estado State.h State.cpp Conclusões Trabalhos Futuros Anexo A State.h State.cpp Cage.h InputHandler.h InputHandler.cpp ActionMap.h ActionMap.cpp Main.cpp Anexo B: Gestão Automatizada de Recursos Funcionalidades Existentes em Algumas Linguagens de Programação Java C Fundamentos Objetos Automáticos Construtores Destrutores Escopo Construtor + Destrutor + Escopo = Objeto Automático Regra Primeira de Aquisição Propriedade Sobre Recursos Estudo de Caso: Memória Transferência de Recurso Estudo de Caso: Contadores de Referências Conclusões Anexo C: Termos Relacionados Referências Bibliográficas iv

7 1 1. Introdução Este trabalho discute tópicos em Programação de Jogos e apresenta ferramentas para desenvolvimento de aplicações do gênero. Programação de Jogos é uma área da Ciência da Computação que abrange uma grande quantidade de conhecimento, como Computação Gráfica, Programação de dispositivos de entrada, Programação de hardware para som, Redes de Computadores, Inteligência Artificial, Engenharia de Software e Concorrência (threads). O desenvolvedor de jogos precisa conhecer essas áreas (entre outras) e as várias tecnologias utilizadas que são relacionadas a elas. As ferramentas implementadas aplicam paradigmas como Orientação de Objetos e Gestão Automatizada de Recursos para oferecer ao desenvolvedor interfaces de alto nível sobre algumas das tecnologias necessárias, de modo a abreviar o tempo de desenvolvimento. A Gestão Automatizada de Recursos tem como propósito minimizar erros de programação e aumentar a confiabilidade das aplicações. São empregadas tecnologias como OpenGL e DirectX, para o desenvolvimento de aplicações em Windows. No capítulo 2 deste trabalho, são relatados alguns problemas encontrados na área de Programação de Jogos para computadores. No capítulo 3, são descritos exemplos de Máquinas de Jogos e os problemas resolvidos por elas. No capítulo 4, é apresentada uma proposta de Máquina de Jogos. Os conceitos utilizados e a implementação são detalhados. No final do capítulo é descrito um exemplo simples de uso da Máquina de Jogos especificada. No capítulo 5, são relatados os resultados obtidos pela execução de uma aplicação demonstrativa que utiliza todos os serviços oferecidos pela Máquina de Jogos apresentada. A implementação do estado correspondente encontra-se no anexo A. O anexo B apresenta Gestão Automatizada de Recursos com mais detalhes, enquanto o anexo C descreve um glossário de termos relacionados ao projeto. As conclusões sobre o projeto são apresentadas no capítulo 6.

8 2 2. Desenvolvimento de Jogos Este capítulo discute alguns tópicos existentes em desenvolvimento de jogos, sob o ponto de vista do programador. Existem vários gêneros de jogos, ao mesmo tempo com alguns problemas comuns e outros bastante diferentes entre si. Segundo André LaMothe [ALA 1999], um jogo deve possuir alguns dos seguintes módulos: Gráficos (o que se vê), Sons (o que se ouve), Dispositivos de entrada (Input) (como interagir com o jogo), Física (interação entre os objetos do jogo e o ambiente aproximando o que ocorre no mundo real, conforme as Leis da Física) e Inteligência Artificial (IA) (como os objetos controlados pelo jogo se comportam). Pode ser acrescentado também o módulo de Conectividade (conexão em rede entre dois ou mais jogadores) Módulo Gráfico O desenvolvedor pode optar por utilizar gráficos em duas (2D) ou três dimensões (3D). Atualmente, devido à evolução do hardware de vídeo (para PC), é comum o uso de gráficos 3D. Os tipos de cenas representados estão diretamente ligados aos gêneros dos jogos. Qualquer que seja o gênero do jogo, é possível classificá-los em duas categorias: Primeira Pessoa: São jogos em que o ponto de vista utilizado é o do usuário. Os ambientes caracterizados são totalmente tridimensionais, contribuindo para a imersão do usuário no cenário; Terceira Pessoa: O usuário acompanha a ação à distância. Jogos deste tipo podem fazer uso de gráficos 2D ou 3D. Os gêneros de jogos, podem se enquadrar em uma das classificações ou em ambas ao mesmo tempo, podem ser divididos nas seguintes categorias, segundo [ALA 1999] e [BSA 1996]: Tiro em primeira pessoa: Estilo popularmente conhecido como First Person Shooter (FPS), simula cenas tridimensionais em grandes ambientes internos (ou labirintos), geralmente. Como o próprio nome sugere, o ponto de vista utilizado é o de primeira pessoa, para gerar uma sensação de imersão no ambiente. Exemplos: Quake, Unreal; Esportes: Utilizam gráficos 2D ou 3D e podem oferecer vários pontos de vista. O cenário limita-se àquele onde é praticada a modalidade (uma quadra, por exemplo). As animações podem ser avançadas para acomodar os possíveis movimentos de um atleta. Exemplos: FIFA Soccer, NBA Live; Luta: Ambientam-se em um cenário restrito ao local da luta. No caso de jogos 2D, a ação é visualizada lateralmente. Caso sejam usados gráficos 3D, podem ser oferecidos vários pontos de vista. Podem ser utilizadas animações ou modelos tridimensionais para representar os personagens. Exemplos: Mortal Kombat, Street Fighter, Tekken; Side Scroller: Tradicionalmente são utilizados gráficos 2D, com visão lateral. Possuem um grande cenário que é visualizado por partes. O usuário controla um objeto que percorre este cenário, por rolamento (scrolling). É possível, entretanto, utilizar gráficos 3D para representar o cenário e ao mesmo tempo manter as características do gênero. Exemplos: Super Mario Bros, Sonic The Hedgehog; Arcade: Utilizam gráficos 2D. Correspondem aos primeiros jogos existentes, em que a ação é visualizada lateralmente ou por cima. O cenário é fixo, não possuindo rolamento (scrolling). Exemplos: Pac-Man, Asteroids; Simulação mecânica: Abrange simulações de corrida, vôo, et cetera. Utilizam gráficos 3D, com visão em primeira ou terceira pessoa. Exemplos: Microsoft Flight Simulator, The Need for Speed;

9 3 Estratégia/RPG 1 /Guerra: Utilizam gráficos 2D ou 3D. Os cenários geralmente possuem grande extensão, podendo representar ambientes externos ou internos. O ponto de vista pode ser localizado bem acima do local onde estão os objetos, de modo que o usuário possa ter uma ampla visão da área focalizada. O usuário participa de simulação como um espectador que tem o poder de interferir na simulação, ou seja, ele não controla um objeto especificamente. Exemplos: Diablo, Final Fantasy, SimCity, The Sims; Quebra-cabeças/Tabuleiro/Cartas: Geralmente são os estilos de jogos mais simples e usam gráficos 2D. Entretanto, podem utilizar gráficos 3D para criar alguns efeitos gráficos, mas a essência do gênero é mantida. Exemplos: Tetris, Blockout, Monopoly, Solitaire; Shooter: Correspondem aos jogos em que o usuário controla algum tipo de aeronave e percorre um cenário por rolamento (scrolling). A visão é em terceira pessoa e a direção do rolamento do cenário pode ser horizontal, vertical ou diagonal (isométrica), em 2D ou 3D. Exemplos: Galaga, Zaxxon Módulo de Sons Sons são utilizados em jogos para dois fins: Efeitos sonoros; Música. Efeito sonoro é definido como um som de curta duração, que é reproduzido em resposta a algum evento. Música pode ser definida como uma longa melodia de fundo. Para representar efeitos sonoros, podem ser utilizados arquivos de som que definem um formato de onda. Um dos formatos mais populares é aquele utilizado em sistemas Windows, cujo arquivo possui extensão.wav [WLR 1995]. Para representar músicas, podem ser utilizados arquivos MIDI, trilhas de CD ou outros formatos de áudio como MP3. É interessante observar que arquivos de formato de onda também poderia ser utilizados para representar sons, mas isto não acontece na prática porque estes arquivos ocupam muito espaço em disco e memória. Os arquivos de tipo MIDI [WLR 1995] são utilizados para produzir música sintetizada, pois eles contêm apenas uma descrição do som (como uma partitura) que é enviada para que um sintetizador efetivamente o reproduza. De acordo com o Fraunhofer IIS [MP3 2001], MP3 é um formato de áudio que utiliza uma alta taxa de compressão, ao mesmo tempo mantendo uma qualidade comparável a existente em trilhas de CD. Desta forma, o uso deste formato de arquivo para músicas de fundo é viável. A única desvantagem é que o arquivo tem que ser descomprimido em tempo real, e isto pode gerar problemas de desempenho para a aplicação Módulo de Dispositivos de Entrada Computadores pessoais possuem pelo menos dois tipos de dispositivos padrões: um teclado e um mouse. Jogos para computador podem, entretando, fazer uso de outros dispositivos como controles de jogo (joysticks). Um controle de jogo pode ser definido como qualquer dispositivo que não seja teclado nem mouse [ALA 1999]. A escolha de qual dispositivo é utilizado é dividida entre o desenvolvedor e o usuário. Alguns jogos podem requerer que algum tipo específico de dispositivo esteja disponível para tornar a simulação mais realista ou simplesmente porque o determinado tipo de dispositivo é mais adequado à situação. Por exemplo, simuladores de vôo podem utilizar manches e jogos de corrida podem utilizar 1 Role Playing Games

10 4 volantes e pedais. Existem, ainda, dispositivos que são capazes de reagir a certos eventos. Estes dispositivos são conhecidos como dispositivos force-feedback. Eles possuem motores em seu interior que são capazes de produzir forças como resistência ou puxões, conforme forem programados Módulo de Física Neste módulo são feitos todos os cálculos para a simulação de Física da interação entre os objetos do jogo e o ambiente onde eles são posicionados. É comum a utilização da Física Newtoniana para modelar o comportamento de todas estas entidades. A complexidade dos cálculos depende do quão próximo da realidade se quer que o jogo esteja. Algumas aplicações para Física em jogos: Simulação de gravidade; Simulação de movimento de objetos, atrito, amortecimento, et cetera; Sistemas de partículas (simulação de fogo, fumaça, explosões, et cetera); Detecção e resposta a colisões Módulo de Inteligência Artificial A função da IA é produzir um comportamento para os objetos controlados pela aplicação de modo que seja convincente ao usuário e que torne o jogo interessante. Como exemplificado em [ALA 1999] e [BSA 1996], IA pode ser utilizada em jogos para alguns destes fins: Oponentes inteligentes: Objetos que representam algum desafio ao jogador, ou seja, o usuário precisa derrotá-los de alguma maneira para prosseguir no jogo; Objetos inteligentes não controlados pelo jogador: Objetos que cooperam com o jogador ou que apenas estão presentes no mesmo ambiente deste, alheios à ação (mas com vida própria); Ambientes ou sistemas inteligentes: Ambientes que reagem a eventos executados pelo jogador ou conjunto de objetos que se comunicam entre si para executar algum tipo de estratégia. Entre algumas técnicas de IA existentes que podem ser aplicadas, podem ser citadas: Algoritmos determinísticos (comportamentos pré-determinados ou pré-programados); Aplicação de padrões (comportamentos determinados por uma série de padrões, que podem ser implementados através de roteiros ou scripts); Planejamento e árvores de decisão; Redes neurais; Lógica Fuzzy; Algoritmos genéticos; Aprendizado e memória; Cálculo de rotas (Path-finding); Sistemas Especialistas.

11 Módulo de Conectividade Segundo Ben Sawyer [BSA 1996], uma sessão de jogo em que dois ou mais jogadores estão conectados remotamente pode ser classificada em uma das seguintes categorias: Conexão modem a modem : Duas pessoas com duas máquinas diferentes conectam-se diretamente uma à outra com uso de modems ; Conexão em rede local (LAN): Duas ou mais pessoas utilizam uma rede local para compartilhar uma sessão de jogo. É utilizado algum protocolo de rede como IPX ou NetBios; Conexão a servidor remoto: Nesta configuração, existe um servidor e vários programas clientes. O servidor tem a função de receber os dados dos clientes e repassá-los aos outros. Geralmente, estas sessões de jogos ocorrem através da Internet, utilizando-se o protocolo TCP/IP. Web Games: Correspondem a jogos que são executados através de um programa navegador pra Internet (web browser). Podem ser implementados em Java (applets) ou com tecnologias tais como Macromedia Flash e Macromedia Shockwave.

12 6 3. Máquinas de Jogos Máquinas de jogos (engines) são coleções de uma ou mais bibliotecas de software que oferecem serviços e/ou entidades de alto nível (abstrações), com o objetivo de automatizar o máximo possível de tarefas para que o desenvolvedor possa se concentrar no conteúdo ou lógica da aplicação. Uma questão pertinente: o que deve ser automatizado? Um jogo é uma aplicação que utiliza alguns módulos bem definidos (Gráficos, Sons, Dispositivos de entrada, Física, Inteligência Artificial ou Conectividade). Uma Máquina de Jogos deve implementar alguns desses módulos e oferecê-los como um serviço para o desenvolvedor. Os estilos de jogos determinam quais módulos são necessários e o quão complexos eles são. Sendo assim, o grau de especialização de uma engine depende do comprometimento com um estilo ou estilos para os quais ela foi escrita (se for o caso). As engines podem também prover certas ferramentas para a manipulação de suas abstrações. Por exemplo, uma engine poderia propor um modelo para as cenas que ela exibe (ex: um mapa). Nesse caso, ela poderia oferecer uma ferramenta de construção de cenas, de forma que o usuário possa lidar com estas abstrações sem se preocupar com a sua real implementação Exemplos de Máquinas de Jogos A seguir são apresentados alguns exemplos de Máquinas de Jogos, para ajudar na compreensão de suas aplicações T3DLib Desenvolvida por André LaMothe [ALA 1999], é uma engine simples, escrita com C++ sobre DirectX, usada para o desenvolvimento de aplicações para sistemas Windows. Ela provê finas camadas de abstração (conhecidas como wrappers) para os módulos Gráfico, Física, Dispositivos de Entrada e Som. Esta engine é destinada para jogos 2D. Podem-se destacar os seguintes itens: Ack-3D Possibilita o uso de arquivos Bitmap do Windows (BMP); Implementação de sprites, chamados de BOBs (Blitter objects) pela engine. Estes objetos podem ter uma ou mais sequências de animações. Os quadros (frames) das animações são organizados em um arquivo do tipo Bitmap, e as sequências de animações são simplesmente índices sequenciais para os quadros. São oferecidos algoritmos para detecção de colisão entre BOBs; Contém uma biblioteca para lidar com linhas e polígonos em 2D. Existem operações básicas sobre polígonos (translação, rotação, escala) e para desenho (sólido ou wireframe); Leitura de dados do teclado, mouse e joystick, através do DirectInput; Reprodução e leitura de arquivos de som do tipo formato de onda do Windows (arquivos que possuem normalmente extensão.wav) e músicas MIDI. Esta engine foi desenvolvida por Larry Myers [LLM 1995] para jogos 3D do tipo POV (Point of view) em mente. Neste tipo de simulação, o cenário é desenhado utilizando-se técnicas de ray casting, e o resultado final é que o usuário visualiza as cenas em primeira pessoa. (Exemplo de jogos do gêneros: Doom e Wolfenstein 3D). Embora esta engine tenha 3D no nome, comumente ela não seria classificada como tal [JDG 1996]. O uso da técnica de ray casting resulta em cenas que simulam 3D a partir de princípios

13 7 2D, e não 3D real. Por esta razão, engines que usam essa implementação são ditas 2.5D por não serem totalmente 3D. Existem implementações para DOS (C) e Windows (C++). Sua funcionalidade permite o uso dos módulos Gráfico, Física e Dispositivos de Entrada. Entre os serviços oferecidos, pode-se destacar: OGRE Implementação de algoritmos para ray casting exclusivamente por software (não é utilizada aceleração por hardware, até porque na época de desenvolvimento da engine esses recursos ainda não estavam disponíveis); Utilização de arquivos Bitmap (PCX, BBM 2 e LBM 3 ); Movimentação do ponto de vista (câmera) e detecção de colisão com o ambiente; Renderização ou construção de cenas a partir de um ponto de vista. Estas cenas (que podem conter paredes, portas e outros objetos definidos pelo desenvolvedor), são representadas por arquivos de mapas. Elas podem ser desenhadas com sombreamento e texturas; Leitura de dados do teclado e mouse 4 ; Implementação de objetos (sprites) estáticos e dinâmicos com animação (chamadas de object sequences na engine) e detecção de colisão; Editor de mapas. OGRE (acrônimo para Object Oriented Graphics Rendering Engine) é uma engine orientada a cenas desenvolvida em C++ sob o modelo open source, desenvolvida por OGRE Team [OGR 2002]. Uma das premissas no desenvolvimento de OGRE é a qualidade do código e projeto. Para os desenvolvedores desta engine, a API oferecida ao usuário deve ser a mais simples e intuitiva possível, deixando otimizações e truques para quando forem realmente necessários. Conceitos encontrados em sistemas comerciais (design patterns, análise e projeto com UML, uso de outras bibliotecas de software para agilizar o desenvolvimento) são amplamente utilizados. Sua implementação faz uso de técnicas de programação orientadas a objeto (encapsulamento, overloading, herança, et cetera). O projeto da engine não foi desenvolvido para um tipo específico de aplicação; sua interface genérica pode ser extendida dinamicamente através do uso de plugins (dlls). Esses plugins implementam gerentes de cena (scene managers) que se comunicam com o cerne da engine, que não precisa ser modificado. OGRE possui apenas o módulo Gráfico. Esta engine oferece os seguintes serviços (entre outros): Interface orientada a objetos construída com independência de API 3D (i.e. poderiam ser usados Direct3D, OpenGL, et cetera). Existem implementações para Windows e Linux; Importação de modelos do 3D Studio (possui também arquivo de descrição de modelos com formato próprio); Uso de diversos tipos de arquivos de imagem (TGA, PNG e JPEG) para texturas, com geração automática de mipmaps. Alguns efeitos sobre texturas (environment mapping, multitexturing em um ou mais passos, entre outros) podem ser aplicados; Implementação de objetos móveis (chamados de entidades). Não oferece detecção de colisão entre estes objetos; 2 Formato usado pelo programa Deluxe Paint II. [LLM 1995] 3 Formato usado pelo programa Deluxe Paint II. [LLM 1995] 4 Na versão para DOS, são implementados algoritmos para lidar com esses dispositivos diretamente por hardware. Já a versão para Windows, usa as ferramentas padrões já disponíveis para programas Windows. Não é possível utilizar joysticks em nenhuma versão.

14 Fly3D Tipos diversos de luzes (spot lights, point lights); Sistemas de partículas (particle systems), inclusive com definição por scripts de texto; Billboarding para representar sprites; Definição dos materiais dos objetos através de scripts de texto; Framework (i.e. template) para novos programas clientes. Fly3D 5 é uma engine desenvolvida em C++, orientada a plugins desenvolvida por Paralelo Computação [FLY 2002]. Os plugins têm papel fundamental na concepção da engine, pois qualquer extensão se faz a partir deles. Uma extensão da engine podem ser classes utilitárias, um frontend ou até uma nova aplicação. O objetivo disso é prover uma interface generalizada e deixar as especializações a cargo dos plugins, ao mesmo tempo evitando-se recompilar todo o cerne da engine quando se quiser adicionar uma nova funcionalidade. A parte central da engine (chamada de backend) é formada por quatro módulos: DirectX, renderização, matemática e a engine propriamente dita. O módulo de renderização guarda toda a configuração da parte gráfica, cuida de estruturas de dados afins e oferece comandos de alto nível (desenhar texto na tela, alterar modo de vídeo, et cetera) que lidam com a API 3D nativa, que é OpenGL. O módulo de matemática oferece várias classes que representam entidades matemáticas como vetores, matrizes e quaternions, que são usadas ao longo do processamento na engine. O módulo DirectX oferece leitura de dados de dispositivos de entrada (teclado e mouse), carregamento, gestão e reprodução de arquivos de som (Windows.wav) e conectividade. O módulo da engine propriamente dita é aquele que integra os outros três e que supervisiona a comunicação entre eles e os plugins. Fly3D também provê várias ferramentas adicionais (que são os frontends), como editores de cenas, servidores para jogos em rede, extensões para o uso na Web (ActiveX), entre outras. Fly3D oferece soluções para os módulos Gráfico, Dispositivos de Entrada, Som, Física, Redes e Inteligência Artificial. Podem-se ainda destacar algumas características desta engine : Utiliza árvores BSP como estrutura principal no processamento de cenas; Possui uma série de formatos de arquivo próprios, usados para armazenar estruturas como árvores BSP, lightmaps, geometria para objetos estáticos ou animados, entre outros. Para trabalhar com esses tipos de arquivos, são oferecidas ferramentas (frontends) e plugins para programas de modelagem 3D; Possui vários plugins que oferecem uma série de objetos ou entidades de alto nível e efeitos especiais. Como exemplos, encontram-se nesse pacote sistemas de partículas, explosões, projéteis, câmeras, objetos controlados pela IA (chamados de robôs pela engine), abstração para jogador (chamado de pessoa ), entre vários outros; Leitura de dados do teclado e mouse, através do DirectInput; Implementação de detecção e tratamento de colisão entre objetos e o ambiente; Possui algoritmos de baixo nível para implementação de Inteligência Artificial; Implementa jogos em rede em um esquema cliente/servidor; Todas as aplicações criadas com a engine são executadas através de um frontend especial. Esse frontend possui algumas opções para alterar o comportamento da renderização e para carregar e visualizar arquivos de cenas. 5

15 Conclusões Os exemplos apresentados são apenas uma pequena amostra da grande quantidade de engines encontradas hoje em dia (basta fazer uma busca na Web para encontrar vários outros exemplos). Podem-se encontrar engines das mais variadas complexidades, desde algumas que apenas encapsulam alguma API nativa ou partes desta (DirectX, por exemplo), quanto àquelas que provêm soluções altamentes especializadas como renderização de terrenos com níveis de detalhe variados, implementação de Inteligência Artificial através de roteiros (scripts) e outros problemas avançados. Entre os exemplos citados, pode-se observar uma variedade de tecnologias. Na parte gráfica, as mais recentes utilizam aceleração por hardware, através de APIs como Direct3D, DirectDraw e OpenGL. A aceleração por hardware em placas de vídeo é comum hoje em dia, seja para 2D ou 3D. O resultado disso é que os desenvolvedores podem acessar as funções disponíveis em hardware anexo e aproveitar o processador central para implementar outras tarefas. Na parte de som e dispositivos de entrada, a implementação é a mínima necessária para que esses módulos funcionem, não existindo maiores abstrações. Finalmente, o próprio conceito de engine pode ser confundido com o conceito de biblioteca de software, mas as diferenças são sutis. Uma máquina de jogos que não apresente um comprometimento com um determinado estilo de jogo poderia ser confundida com uma biblioteca porque ela apenas oferece ferramentas para o programa (i.e. a aplicação), ou seja, o programa usa os serviços da máquina mas esta não possui uma autonomia (i.e. a máquina em si é apenas um conjunto de serviços e objetos que são acessíveis a um programa). Por outro lado, uma máquina altamente especializada poderia ser configurada através de parâmetros (um programa que executasse essa máquina, roteiros ou scripts, et cetera) para que um novo jogo pudesse ser produzido. Isso quer dizer que a máquina funcionaria como um molde (ou template), com uma certa automonia (ou seja, a máquina aceitaria parâmetros e funcionaria por si própria). Embora existam engines tão diferentes entre si, pode-se citar algumas vantagens e desvantagens em relação ao uso: Vantagens Uma engine com alto nível de especialização pode proporcionar uma plataforma de desenvolvimento rápido de aplicações, sendo necessário apenas alterar os parâmetros de funcionamento. O desenvolvedor não precisa se preocupar em criar/testar código para lidar com problemas de nível mais baixo, porque isto já foi feito antes. O código pode ser reutilizado em vários projetos diferentes. O reuso em vários projetos diferentes proporciona oportunidades para novos testes, o que contribui para a robustez da engine. O desenvolvedor (cliente) não necessariamente precisa ter todo o conhecimento necessário para implementar (ou entender a implementação) da engine. Esta pode apresentar uma interface de nível mais alto de modo que se possa utilizá-la sem se preocupar com detalhes irrelevantes para a aplicação em desenvolvimento. Além do mais, se a engine for projetada com orientação a objetos em mente, ela pode apresentar uma interface comum para um determinado tipo de tarefa e deixar as especializações definirem a implementação. Nesse caso, o desenvolvedor (cliente) será beneficiado porque o tempo de aprendizado para usar a engine será menor (porque usa uma interface comum para realizar várias tarefas). Pode proporcionar independência de API e sistema operacional. A engine poderia ser desenvolvida utilizando objetos ou entidades de nível de abstração mais alto (ex: efeito sonoro, polígono, sistema gráfico, gerente de cenas, et cetera). Desta forma, a engine poderia ter a implementação modificada, se assim fosse necessário, e as aplicações clientes não sofreriam alterações significativas. Pelo mesmo motivo, o uso da aplicação em sistemas operacionais diferentes é facilitado.

16 10 Economizam-se recursos (tempo, dinheiro) ao pular etapas de desenvolvimento Desvantagens Nenhuma engine resolve todos os problemas. Nesse caso, o desenvolvedor tem duas escolhas: usar outra engine ou tentar extender a atual para adequá-la ao seu caso. Engines desenvolvidas para um único tipo de jogo possuem uma estrutura rígida e sua flexibilidade é pequena; isto é uma desvantagem se o desenvolvedor trabalha com vários estilos de jogos. Por outro lado, pode ser uma vantagem significativa se o desenvolvedor só se preocupa com o estilo em questão, pois a implementação da engine pode ser bastante otimizada (e/ou mais completa) ao assumir que somente um estilo de jogo será usado. A questão aqui é o confronto entre flexibilidade e otimização. Engines não são muito diferentes de outros sistemas de software. Com o tempo, novos recursos podem ser adicionados, aumentando a complexidade geral. Sem estratégias de desenvolvimento e manutenção adequadas, a engine pode passar de solução a problema.

17 11 4. Uma Máquina de Jogos Neste capítulo é apresentada uma máquina de jogos (Glib) com os seguintes objetivos: Prover uma funcionalidade mínima para a criação de jogos e programas de demonstração multimídia; Facilidade de uso; Criação de camadas de alto nível sobre as APIs nativas, com a finalidade de automatizar tarefas repetitivas (como por exemplo, inicialização de sistemas) e agilizar o desenvolvimento dos aplicativos; Gestão automatizada de recursos. Esta máquina de jogos é implementada em C++ e utiliza tecnologias como OpenGL e DirectX para realizar as suas tarefas. É destinada para o desenvolvimento de aplicações em ambiente Windows Gestão Automatizada de Recursos Um recurso pode ser definido como algo que deve ser requisitado ao Sistema Operacional, quando necessário, e que deve ser devolvido a este após o uso. Esta definição é abstrata o bastante para englobar exemplos como memória, arquivos, sockets, et cetera. O principal problema em relação a recursos é que o programador deve explicitamente devolvêlos ao Sistema Operacional quando não são mais necessários. Quando isto não é feito, uma série de problemas podem se manifestar, como perda de recursos (resource leaks), deadlocks, bugs aleatórios (um defeito que é difícil de se reproduzir), acessos inválidos à memória, exaustão do Sistema Operacional (i.e. os recursos do Sistema Operacional estão esgotados), entre outros, dependendo do tipo do recurso. Linguagens de programação 6 como C++ não possuem funcionalidade padrão para tratar do problema. Entretanto, a gestão de recursos pode ser automatizada utilizando-se a estrutura nativa desta linguagem Objetos Automáticos Toda classe em C++ possui duas funções especiais: um construtor e um destrutor. O construtor é chamado quando o objeto é criado, e o destrutor é chamado quando o objeto sai do escopo onde ele foi definido, sempre. Desta forma, é possível encapsular recursos utilizando-se classes. Uma instância da classe passa a ser proprietária do recurso (porque passa a ser responsável por sua devolução); este é alocado no construtor e devolvido ao Sistema Operacional através do destrutor. É importante notar que todos os recursos encapsulados dessa forma são automaticamente devolvidos ao Sistema Operacional, se acontecer algum desses casos: Um objeto declarado em um bloco de código (uma função, por exemplo) será criado (i.e. terá o seu construtor executado) quando o fluxo de programa entrar no escopo do bloco. Quando o fluxo de programa deixar o bloco 7, o objeto será destruído (i.e. terá o seu destrutor executado); 6 Linguagens como Java fornecem coletores de lixo para gestão automática de memória. A coleta de memória não utilizada é feita periodicamente pela Máquina Virtual Java, processo que em determinadas circunstâncias pode ocorrer somente ao término da aplicação [BEC 2000]. 7 Saída normal (break, goto, return) ou por exceção (throw).

18 12 Um objeto A é declarado como campo de um outro objeto B. Nesse caso, o objeto A será construído quando o objeto B for contruído. Da mesma forma, o destrutor de A será executado pelo destrutor de B, quando este for destruído. Em ambos os casos, o escopo de uso do objeto é bem definido, e por isso o compilador pode automatizar todo o processo 8. Existe, porém, o caso em que o recurso é alocado dinamicamente (ex: memória). O escopo de uso deste recurso não é bem definido, e a linguagem não cuida da devolução deste ao Sistema Operacional de maneira automática. A solução para o problema é utilizar um objeto que tenha um escopo bem definido para encapsular o recurso. Este objeto passará a ser o proprietário do recurso encapsulado. Essa cadeia de objetos que encapsulam recursos ou outros objetos acaba no programa principal, que é o nível mais alto. Estas idéias, acrescidas da noção de propriedade sobre recursos, formam a base para o paradigma de Gestão de Recursos (Resource Management), apresentado por Bartosz Milewsky [BMI 2001]. Este paradigma define uma única regra, chamada Regra Primeira de Aquisição (First Rule of Acquisition), que diz: Obtenha recursos em construtores e devolva-os usando os destrutores correspondentes. Como exemplos ilustrativos, podem-se citar a alocação de memória e sincronização entre threads através de semáforos Exemplo 1 A STL 9 oferece uma classe utilitária para cuidar de memória alocada dinamicamente, chamada auto_ptr. Uma instância desta classe, ao ser criada, recebe o ponteiro para a memória obtida do sistema. Quando a instância é destruída, ela devolve a memória ao Sistema Operacional, automaticamente : int main (int argc, char* argv[]) std::auto_ptr <int> p (new int); return 0; No exemplo acima, o objeto auto_ptr passa a ser proprietário do recurso obtido e irá devolvê-lo ao Sistema Operacional quando o programa se encerrar Exemplo 2 Sincronização entre threads em Windows é feita utilizando-se regiões críticas ou exclusivas (Critical Sections). Para informar ao Sistema Operacional que vai entrar em uma região exclusiva, uma thread deve chamar a função EnterCriticalSection() 10, e para sair, ela deve chamar LeaveCriticalSection() 11. O problema é que a saída da thread da região exclusiva (para que outras threads possam utilizá-la) não é garantida, porque deve-se chamar explicitamente uma função para que isto aconteça. Uma solução simples para esse problema é fornecida a seguir: 8 A exceção que pode desqualificar a regra é o uso das funções exit() e abort(), que provocam término abrupto do programa. Quando essas funções são usadas, destrutores de objetos locais não são executados. 9 Standard Template Library. 10 API do Windows. 11 API do Windows.

19 13 class CriticalSection friend class Lock; private: CRITICAL_SECTION _criticalsection; void Enter () ::EnterCriticalSection (&_criticalsection); void Leave () ::LeaveCriticalSection (&_criticalsection); public: CriticalSection () ::InitializeCriticalSection (&_criticalsection); ~CriticalSection () ::DeleteCriticalSection (&_criticalsection); ; A classe CriticalSection apenas encapsula a estrutura de dados usada pela API do Windows. Esta classe, por si só, não garante que todo objeto que entrar em uma região exclusiva saia dela automaticamente. Por isso, seus métodos são acessíveis apenas a uma classe em especial e invisíveis para todas as outras. Esta classe privilegiada (Lock) será a proprietária do recurso estado da região exclusiva, e irá garantir que todo cliente que entrar em uma região exclusiva irá deixá-la automaticamente: class Lock ; private: CriticalSection & _zone; public: Lock (CriticalSection & criticalsection) : _zone (criticalsection) _zone.enter(); ~Lock () _zone.leave(); Um exemplo de uso de ambas:

20 14 class Shared private: CriticalSection _criticalsection; ; public: void Update () Lock guard (_criticalsection); // todo o processamento aqui É possível observar que clientes que entrarem na região exclusiva sairão dela no término de execução da função. Mais detalhes sobre a metodologia de Gestão de Recursos (como noções de transferência de propriedade) podem ser encontrados em [BMI 2001] Máquina de Estados O modelo proposto de Máquina de Jogos utiliza uma Máquina de Estados que possui os seguintes objetivos: Prover uma estrutura autônoma para todas as aplicações. Estrutura autônoma aqui significa que a Máquina funcionará com o uso de parâmetros, e que ela não terá que sofrer modificações para que uma novo programa seja feito; Isolar partes da aplicação que são comuns e implementá-las como parte da Máquina. Entre estas partes comuns, encontram-se tarefas como configurar sistemas diversos (Sistema Gráfico, por exemplo). Com isso, o desenvolvedor ganhará tempo ao pular estas etapas Fluxo de Execução de Jogos Um fluxo de execução típico de um jogo, segue a seguinte ordem [ALA 1999]: 1. Inicialização da Aplicação 12 ; 2. Ciclo Principal; 3. Finalização da Aplicação 13. O Ciclo Principal divide-se em: A) Leitura de dados dos dispositivos de entrada; 12 Inicialização de estruturas de dados, obtenção de recursos do Sistema Operacional, et cetera. 13 Devolução de recursos usados ao Sistema Operacional, restauração de variáveis anteriores dos subsistemas (como modo de vídeo, por exemplo), et cetera.