Revista Eletrônica da Faculdade Metodista Granbery http://re

1
Revista Eletrônica da Faculdade Metodista Granbery
http://re.granbery.edu.br - ISSN 1981 0377
Curso de Sistemas de Informação – N.14, JAN/JUN2013
COMPONENTES DE GAME ENGINES
Fillipe Martins Van Keulen1
Marcos Vinicius Grossi de Mattos2
Sérgio Muinhos Barroso Lima3
Vítor Daniel Rosa Cabral4
RESUMO
O mercado de jogos eletrônicos vem apresentando um crescimento significativo nos últimos
anos. O desenvolvimento da tecnologia e da própria engenharia de software tem permitido a
criação de ferramentas que agilizam e aumentam a qualidade do processo de desenvolvimento
de jogos, dentre elas, as game engines. Como resultado, surgem jogos com qualidade cada vez
maior, oferecendo uma experiência cada vez mais realista, tornando-se mais atrativos para
pessoas de diversas faixas etárias. Este artigo apresenta a estrutura básica das game engines.
PALAVRAS-CHAVE:
Componentes
de
Game
Engines,
Jogos
Eletrônicos,
Desenvolvimento de Jogos, Ferramentas para Jogos, Máquinas de Jogos.
ABSTRACT
The game market is showing a significative growing on the last years. The technology and
engineering advances are supporting the development of tools that increase the speed and
quality of game development, among them, starring, the game engines. As result, are
appearing several games with high quality, offering stunning and realistic experiences, being
1
Bacharel em Sistemas de Informação, Faculdade Metodista Granbery, [email protected].
Bacharel em Sistemas de Informação, Faculdade Metodista Granbery, [email protected].
3
Mestre em Ciência da Computação, UNICAMP, [email protected].
4
Bacharel em Sistemas de Informação, Faculdade Metodista Granbery, [email protected].
2
2
more attractive to the people of several ages. This work presents the main game engine
components.
KEY-WORDS: Game Engine Components, Eletronic Games, Game Development, Game
Tools, Game Engines.
1 - INTRODUÇÃO
Desde o início do processo de desenvolvimento de software, o avanço da
tecnologia vem possibilitando, aos seres humanos, reproduzir nas máquinas situações do
mundo real. Essa evolução contribuiu para a melhoria dos sistemas, que passaram a ser mais
interativos e a simular, cada vez melhor, situações reais com as quais os usuários poderiam se
deparar. Logo, as máquinas passaram a reproduzir fenômenos como força da gravidade,
aceleração centrífuga, efeitos de iluminação (luz, sombras, etc.), sons e começaram a surgir
softwares com grupos de funcionalidades específicas para domínios específicos, como, por
exemplo, as bibliotecas de funções matemáticas, ou físicas. Surgiam assim as engines.
A palavra engine significa motor, em português, e, de acordo com o dicionário
Priberam da Língua Portuguesa (PRIBERAM, 2012), tem por definição “que dá movimento;
aquilo que induz ou instiga”.
Na área do desenvolvimento de sistemas, engines podem ser comparadas a
grandes bibliotecas que agrupam funcionalidades de um mesmo contexto. À medida que o
conhecimento envolvido neste contexto evolui, pode ser necessário alterar essas bibliotecas,
para acrescentar funcionalidades, por exemplo, e, por isso, as engines também estão sujeitas a
princípios de engenharia de software, como os padrões de projetos (EBERLY, 2005).
A utilização de engines agiliza o processo desenvolvimento de aplicações para
contextos específicos, pois concentra todas ou a maior parte das funcionalidades que são
inerentes a esse contexto.
Muitas aplicações (inclusive outras engines) são desenvolvidas através da
combinação de funcionalidades de várias engines distintas. Esse trabalho aborda a estrutura
básica de game engines, conceitos básicos relacionados ao desenvolvimento de jogos e
exemplos de ferramentas que podem ser utilizadas no desenvolvimento de jogos utilizando
um tipo especial de engine resultante da combinação de várias engines: as game engines.
3
2 - GAME ENGINES
A cada dia que passa, o público gamer vem crescendo mais e mais. Segundo
pesquisa realizada pela empresa de auditoria PriceWaterhouseCoopers, esse setor
movimentou cerca de US$1,3 bilhões em 2011 somente na América Latina, e a previsão é de
que, em 2016, esse valor aumente para aproximadamente US$1,8 bilhões. Diversas pessoas
das mais variadas idades e gostos se tornam parte desse público em busca de jogos que se
encaixem nos seus perfis (PÍCOLO, 2012).
As produtoras de jogos, que não medem esforços para conquistar os clientes,
tentam atrair e satisfazer essa exigente e diversificada clientela. Dentre os principais recursos
dos quais elas dispõem para aprimorar e melhorar ao máximo seus jogos estão as game
engines. Antes de analisar mais a fundo o que são e como funcionam as game engines, é
interessante entender o processo de surgimento dessas “ferramentas milagrosas”.
De acordo com Nilson e Söderberg (2007), antes do surgimento da programação
orientada a objetos, o paradigma de desenvolvimento de software era a programação
estruturada. Seguindo esse modelo de desenvolvimento, os jogos eram escritos em poucos
arquivos, talvez um ou dois, compilados e rodados. Caso a empresa ou desenvolvedor
quisesse escrever outro jogo dando sequência ao primeiro, eles teriam duas opções: criar todo
o código a partir do zero ou copiar o código do primeiro jogo e editá-lo com as características
do novo jogo (como é possível notar, nenhuma das duas opções é prática ou produtiva).
Com a chegada do paradigma da orientação a objetos, a situação começou a
melhorar: a possibilidade de reaproveitamento de código aumentou a manutenibilidade do
código-fonte. Esse novo modelo, composto de objetos autônomos interagindo entre si em um
sistema, estimulou o desenvolvimento de ferramentas que agilizaram o processo de
desenvolvimento de jogos. Os códigos-fontes seriam mais limpos, organizados e,
consequentemente, mais fáceis de dar manutenção. (NILSON, SÖDERBERG, 2007)
Com o passar do tempo percebeu-se que várias funções se repetiam durante o
desenvolvimento de jogos distintos. Assim, decidiu-se agrupá-las em grupos de funções que
acabaram dando origem às engines específicas. A necessidade de funções de diferentes
engines em um mesmo jogo condicionou o desenvolvimento de ferramentas, ambientes de
desenvolvimento, que tivessem várias dessas funções ao mesmo tempo. A evolução dessas
ferramentas deu origem às game engines. (EBERLY, 2005)
4
A primeira engine utilizada foi a Freescape, da Incentive Software, que ajudou
nos processos de divulgação e popularização de dos jogos no estilo FPS5. Mais tarde, com o
estouro de jogos como Doom, Wolfstein 3D e Quake, outras empresas começaram a lançar
jogos inspirados nesses três primeiros. A partir de então, as engines foram se tornando cada
vez mais populares e logo começaram a ser utilizadas em vários outros gêneros de jogos. A
área mostrou-se tão propícia que outras empresas passaram a produzir e comercializar novas
engines. (KLEINA, 2012)
De acordo com Zerbst (2004), também conhecidas como 3D engines, as game
engines são um tipo específico de engine utilizadas principalmente para o desenvolvimento de
jogos. São compostas por várias sub-engines que possuem as funcionalidades necessárias para
o desenvolvimento de jogos. Ao optar pelo desenvolvimento de jogos utilizando game
engines, os desenvolvedores não precisam se importar sobre como a engine trata arquivos de
áudio, ou ainda como se comunica com a placa de vídeo. Eles precisam apenas saber qual
função da game engine realiza o processo desejado, como e onde utilizá-la.
Game engines não estão fortemente ligadas a um jogo, plataforma ou projeto
específico, ou seja, seu código é completamente separado do código dos projetos que serão
desenvolvidos utilizando a game engine e deve ser reutilizável (ZERBST, 2004).
Embora a utilização de game engines no desenvolvimento de jogos ajude a
abstrair os conceitos de baixo nível relacionados a este processo, é importante ressaltar que,
sem tal conhecimento, o desenvolvedor fica preso aos recursos disponibilizados pela game
engine (EBERLY, 2005). Por isso, há no mercado grandes empresas que adotam game
engines em seus projetos de desenvolvimento e, mesmo assim, possuem pessoas
especializadas em programação de baixo nível em suas equipes.
Segundo Jesse Schell (2011), ao jogar um jogo, o jogador passa por uma série de
percepções, sentimentos e reações que juntos acarretam o fenômeno conceituado por Schell
como experiência. Ele defende que a experiência provocada no jogador está entre os fatores
que o fazem querer continuar em seu jogo ou abandoná-lo logo no começo. O papel das game
engines nessa história é fornecer, à equipe de desenvolvimento, meios para estimular ou
melhorar a experiência do usuário durante o jogo.
Como mencionado anteriormente, as game engines devem fornecer uma estrutura
completa (mesmo que com funcionalidades básicas) para que as equipes de desenvolvimento
sejam capazes de desenvolver seus jogos. Assim, há algumas funcionalidades básicas
5
Sigla para First Person Shooter, em português Tiro em Primeira Pessoa.
5
esperadas de uma game engine como, por exemplo, funções que implementem inteligência
artificial, simulem forças da gravidade ou ainda, como citado em exemplo acima, manipulem
o áudio do jogo deixando para a equipe apenas a responsabilidade de saber como usá-las. A
seguir será abordada a estrutura básica de uma game engine.
2
- COMPONENTES DE GAME ENGINES
Game engines são compostas por engines, ou subsistemas, que interagem entre si
e têm responsabilidades específicas e bem definidas. Pode-se dizer que as principais engines
que compõem uma game engine são: graphics engine (engine gráfica), physics engine (engine
de física), script engine (engine de programação ou desenvolvimento), audio engine (engine
de áudio), AI engine (engine de inteligência artificial), network engine (engine de rede) e
input engine (engine de entrada).
A partir da ilustração 1 é possível ter noção de como esses componentes se
relacionam.
Ilustração 1 - Representação abstrata da arquitetura de uma game engine.
Fonte: (NILSON, SÖDERBERG, 2007)
A classe Renderer representa a engine gráfica, responsável por cuidar da parte
visual do jogo. A Audio representa a engine de áudio, responsável por cuidar do tratamento e
gerenciamento de áudio do jogo. A classe Physics representa a engine de física, responsável
6
por cuidar dos efeitos relacionados aos fenômenos físicos (deslocamento, rotação, gravidade,
geração de partículas e etc.) aplicados aos objetos do jogo. A classe AI representa a engine de
Inteligência Artificial, responsável por cuidar do comportamento das personagens e objetos
do jogo não controlados pelo jogador. Na ilustração 1, essas classes foram agrupadas (acima
da caixa core) porque são as classes que executam as operações mais complexas e custosas,
ou seja, exigem maior poder de processamento (NILSON e SÖDERBERG, 2007).
A classe Input representa a engine de entrada, responsável por implementar as
formas de acesso (e gerenciá-las) que o jogador tem para utilizar o jogo (mouse, teclado,
joystick, touchscreen e etc.). A classe Network representa a engine de rede, responsável pela
comunicação de rede do jogo. A classe Scripting representa a script engine, responsável por
fornecer aos desenvolvedores meios de acessar os recursos oferecidos pela engine. Na
ilustração 1, essas classes foram agrupadas (abaixo da caixa core) porque elas representam a
interface do usuário com a game engine (NILSON e SÖDERBERG, 2007).
É importante notar que nenhuma das classes se comunica diretamente. Qualquer
informação que trafegue de uma classe para a outra passa antes pela classe Core. Essa classe
representa os recursos da máquina que gerenciam a troca de informações e chama diretamente
os recursos solicitados pelas outras classes, como, por exemplo, o processador. É a classe
central de processamento. (NILSON, SÖDERBERG, 2007)
Nas próximas seções serão abordadas essas engines com um nível maior de
detalhe.
3.1 - GRAPHICS ENGINE
A engine gráfica, também conhecida por renderer engine, é responsável por
cuidar da parte gráfica/visual do projeto e, talvez por esse motivo, é a parte mais conhecida,
passando às vezes a ser confundida com a própria game engine (NILSON e SÖDERBERG,
2007). Geralmente construída com base em API’s gráficas como OpenGL ou Direct3D, esse
tipo de engine é implementada para desenhar todos os objetos na tela.
OpenGL é um software de interface para hardware gráfico que permite aos
desenvolvedores utilizar os recursos necessários para produzir imagens de alta qualidade de
objetos 2D ou 3D (KHRONOS, 2012). Largamente conhecida por sua versatilidade e por ser
multiplataforma, a biblioteca do Khronos Group se encontra na versão 4.1 e disputa o
mercado de gráficos tridimensionais com a Direct3D (GUGELMIN, 2010).
7
O Direct3D é uma parte específica para jogos da biblioteca gráfica DirectX, da
Microsoft. Ficou famosa pela alta qualidade dos gráficos gerados, mas só roda em sistemas
Microsoft. Está na versão 11.1 (somente para Windows 8) e é programada para utilizar os
recursos de hardware gráfico de forma a minimizar o trabalho da CPU (TECHTERMS.COM,
2012).
As API’s gráficas manipulam o hardware gráfico (responsável pela parte gráfica),
reduzindo, no lado do programador, a necessidade de construir uma engine gráfica a partir do
zero, pois os métodos contidos nessas API’s já implementam grande parte dos métodos
necessários para o processo de renderização (principal função das engines gráficas). Há
situações nas quais o hardware em que o sistema irá rodar não oferece suporte à API’s.
Justamente por causa desse tipo de situação, não é sensato assumir que o uso de API’s elimina
a necessidade de conhecimento gráfico em baixo nível. (ZERBST, 2004)
Efeitos visuais de alta qualidade prendem muito a atenção do jogador, pois
aumentam nele a sensação de realismo, o que maximiza sua experiência e o mantém imerso
no contexto do jogo. Devido à alta qualidade dos recursos disponíveis, é possível simular
diversos tipos de ambientes, desde paisagens até interiores de escritórios, com alto nível de
detalhe. Porém, quanto maior o nível de detalhe exigido na cena (mundo ou ambiente onde se
passa o jogo), maior a quantidade de objetos que a engine gráfica tem que renderizar. Isso
pode resultar em pequenos delays (travamentos), que acabam prejudicando o aproveitamento
da experiência por parte do jogador. É preciso então que a engine gráfica saiba definir “o que
deve ser renderizado em qual hora” (ERBERL, 2005).
De acordo com Eberly (2005), para lidar com esse tipo de problema as engines
gráficas funcionam sob dois importantes conceitos: scene graph (grafo de cena) e scene graph
management (gerenciamento do grafo de cena).
O grafo de cena é composto por todos os componentes de uma cena e suas
relações, conforme exemplo da ilustração:
8
Ilustração 2 - Exemplo de grafo de cena (adaptado pelos autores)
FONTE: (NOKIA, 2005)
O grafo da ilustração 2 retrata uma cena composta por alguns meshes6, um
sprite3D7, uma câmera e uma luz. O nó Mundo representa a cena em si e contém todos os
elementos nela contidos. Os nós Group representam, como o nome sugere, agrupamentos de
objetos na cena e permitem à aplicação tratar mais de um nó com um único objetivo (um
exemplo de aplicação é a replicação de uma alteração realizada em um objeto, em todos os
outros objetos do grupo). O nó Sprite 3D representa imagens bidimensionais com uma
posição tridimensional (é, basicamente, a conexão do objeto que o usuário vê na tela com o
objeto 3D). Os nós Mesh, Morphing Mesh e Skinned Mesh representam as formas geométricas
dos objetos visíveis, sendo que os dois últimos referem-se às formas de objetos animados. O
nó Câmera representa câmeras na cena, ou seja, pontos de vista na cena. E o nó Luz
representa pontos de luz na cena (NOKIA, 2005).
Gerenciamento de grafo de cena é o processo em que, baseada no grafo de cena, a
engine executa diversos procedimentos (entre eles a definição de visibilidade dos objetos)
para selecionar os objetos da cena que serão enviados ao renderizador, a fim de diminuir a
6
Termo utilizado na área de desenvolvimento de jogos para se referir a objetos 3D.
Termo utilizado para se referir à tradução de uma imagem 3D para 2D, de modo que esta
possa ser exibida nas telas.
7
9
carga de trabalho do mesmo. Com base nesses conceitos, as engines gráficas conseguem
equilibrar da melhor maneira possível a qualidade visual do jogo com a quantidade de
trabalho exigida no renderizador (EBERLY, 2005).
Segundo Zerbst et al (2004), uma renderer engine tem que ser fácil de usar e
flexível, porém esses conceitos geralmente andam em sentidos opostos. Uma engine que
realiza uma série de operações com apenas uma chamada de método é definitivamente fácil
de usar, mas não é flexível, pois as operações de manipulação de vídeo são executadas dentro
deste método, que por sua vez já está predefinido e não pode ser modificado (ou é difícil de
ser modificado). À medida que a engine vai sofrendo customizações para se tornar mais
flexível (vai sendo desmembrada para que seja possível adicionar eventos entre as operações
que ela desempenhava inicialmente), mais funções são acrescentadas a ela e torna-se maior a
quantidade de métodos que o usuário deve dominar para utilizá-la. Neste caso, a engine
ganhou flexibilidade, mas perdeu facilidade de utilização, exige mais de seu usuário.
3.2 - PHYSICS ENGINE
Outro fator que ajuda muito a estimular a sensação de realidade no usuário é a
inserção, no jogo, de regras, fenômenos e até mesmo leis existentes no mundo real. Nas game
engines, a engine que cuida especificamente de reproduzir os fenômenos físicos presentes no
mundo real é a chamada physics engine.
Assim como em qualquer outra área do desenvolvimento de software, para que o
computador possa reproduzir um evento do mundo real, é necessário escrever tal evento de
forma que o computador o entenda. Uma das maneiras de fazer isso é construir um algoritmo
lógico aritmético para ser processado pelo computador de forma que, baseado nas instruções
fornecidas pelo algoritmo, ele possa tomar decisões e executar ações (o que resulta na
simulação do fenômeno descrito pelo algoritmo) (EBERLY, 2005).
As physics engines geralmente exigem alto poder de processamento, pois
executam cálculos muito complexos por unidade de tempo, ou seja, numa cena simples de um
jogo de tiro, ao disparar de uma arma, as physics engines têm que calcular a propagação do
som e o movimento do projétil (deslocamento espacial e variação de velocidade). Tudo isso
em tempo hábil, sem delays. (LIMA, 2008)
Dentre os fenômenos que as physics engines se encarregam de simular, estão a
emissão e controle de partículas. Através desse sistema, é possível simular situações e efeitos
especiais envolvendo fogo (incêndios, fogueiras, explosões), água (rios e mares, cachoeiras,
10
chuva), areia (praias, tempestade de areia, ampulhetas), fumaça, neblina, neve com ótima
qualidade, como é possível observar nas ilustrações 3 e 4.
Ilustração 3 - Exemplo de simulação de fogo na game engine Unity 3D
FONTE: (MANUAL, 2012)
Ilustração 4 - Exemplo de simulação de neblina na game engine Unity 3D
FONTE: (HIGGINS, 2012)
De acordo com Lima (2008), os sistemas de partículas recebem alguns
parâmetros, como um emissor para as partículas (um objeto ou ponto na cena), uma
quantidade máxima de partículas a ser gerada, tempo de vida, cor, tamanho, vetor de
velocidade inicial das partículas para que possa realizar a simulação. Com base nesses
parâmetros, o sistema de partículas inicia a simulação dos efeitos aplicando as leis de Newton
sobre as partículas e fazendo-as entrar em loop até o fim de seu tempo de vida.
11
Implementado por várias game engines, o conceito de deformable bodies (corpos
deformáveis) contribui muito com o realismo dos jogos. Deformable bodies são corpos cuja
superfície é deformável (como sugere o nome), como, por exemplo, tecidos que se amassam,
uma bola que se comprime ao colidir com uma parede, uma goma de mascar que se estica ao
produzir uma bola, a contração de um músculo ou um simples passo do caminhar de uma
personagem. Todos esses efeitos ajudam a despertar os sentidos do jogador, o tato, por
exemplo, dando noção da textura, espessura dos objetos na cena.
Eberly (2005) afirma que processar um modelo que implemente os princípios de
deformação requer um alto poder de processamento para aplicações em tempo real. Para
contornar tal requisito ele propõe alternativas menos dispendiosas para implementar as
deformações. Uma delas é a implementação de uma classe que represente as superfícies e
suporte as modificações dos vértices, auxiliada por um sistema de colisões, para evitar que
haja vértices sobrepostos após a deformação (resultando em formas estranhas).
Rigid bodies (corpos rígidos) são os objetos da cena que possuem tamanho,
orientação, posição, velocidade e forças a ele aplicadas. As partículas citadas anteriormente
são exemplos de rigid bodies sem tamanho e orientação. Geralmente representados por
poliedros nas aplicações, os rigid bodies são posicionados e orientados no ambiente 3D por
um sistema de coordenadas. As physics engines aplicam as Leis de Newton sobre esses
corpos, produzindo seus movimentos, calculando suas velocidades e rotações. A classe que
representa os rigid bodies nas game engines implementam métodos que permitem alterar e/ou
recuperar a massa, estado de inércia, orientação, posição, velocidade angular e linear desses
corpos (EBERLY, 2005).
3.3 - SCRIPT ENGINE
Uma das funções de uma game engine é facilitar o desenvolvimento de jogos,
cuidando para o desenvolvedor dos assuntos de baixo nível. Ainda assim, é necessário para o
desenvolvedor se comunicar com a game engine de forma que ele consiga dizer a ela o que
ele quer fazer e quando isso deve ser feito. Para que esta comunicação aconteça as game
engines oferecem suporte a alguns linguagens de script. Através dessas linguagens, os
desenvolvedores conseguem usufruir das funcionalidades oferecidas pela game engine
(NILSON, SÖDERBERG, 2007).
12
Geralmente usadas para animação e lógica de jogo (game play logic), as
linguagens de script são escolhidas pelos fabricantes de game engines, e desenvolvedores de
jogos, devido à sua aparência mais amigável, que permite melhor leitura e organização do
código (CODEPLEA, 2009).
Neste trabalho os exemplos estão focados nas linguagens C#, JavaScript e Boo,
que são as linguagens suportadas pela Unity 3D, game engine tema principal do trabalho.
C# é uma linguagem orientada a objetos derivada do C, atualmente mantida pela
Microsoft. Conhecida por ser fácil de entender, possui sintaxe parecida com as das linguagens
C, C++ e Java. Suporta métodos, tipos genéricos e iteradores que permitem criação de
comportamentos de iteração personalizados. Também suporta herança, polimorfismo e
encapsulamento. Dentre as linguagens suportadas pela Unity 3D, é a mais usada com esta
ferramenta no mercado (MICROSOFT, 2012).
A partir da Unity, uma variável pode ser declarada em C# informando-se os
pacotes que serão utilizados pelo script, declarando-se o método onde a variável se encontra,
seguido da palavra Monobehaviour (esta palavra refere-se à classe base da qual derivam todas
as classes na Unity 3D) e, por fim, declarando-se a variável memberVariable, pública e do
tipo float (UNITY, 2012). Os comandos da para declaração são bem semelhantes aos
comandos Java utilizados para declaração de variáveis.
using UnityEngine;
using System.Collections;
public class example: MonoBeahvior{
public float memberVariable = 0.0F;
}
JavaScript é uma linguagem de script orientada a objetos, desenvolvida pela
Netscape8, à parte da plataforma Java. É muito utilizada para desenvolvimento de WebPages,
mas também pode aplicada em projetos “fora do browser” (por exemplo ApacheCouchDB9,
desenvolvimento de jogos) (MOZZILA, 2012).
8
Empresa americana de serviços de informática fundada em 1994, que ficou famosa
pelacriação do navegador Netscape Navigator.
9
Projeto de banco de dados para web com armazenamento de dados utilizando
documentos JSON e acesso aos dados via HTTP, mantido pela Apache.
13
Programando em JavaScript na Unity 3D, a mesma declaração variável mostrada
anteriormente fica da seguinte maneira:
var mermerVariable = 0.0;
Um ponto interessante a ser observado é que, ao desenvolver scripts em
JavaScript com a Unity 3D, não é necessário informar quais os pacotes utilizados pelo script
nem a criação de classes, como mostrado utilizando C#. Devido a essa simplicidade, o
JavaScript é o mais utilizado em livros e outros materiais destinados àqueles que não têm
experiência alguma com programação ou desenvolvimento de jogos (GOLDSTONE, 2009).
Boo é uma linguagem orientada a objetos, estaticamente tipada, surgida por volta
de 2003 com objetivo de utilizar, no Python, o suporte para Commom Language
Infrastructure (CLI)10 para Unicode, internacionalização e aplicações Web (OLIVEIRA,
2004). Sua sintaxe é inspirada no Python. A declaração de variáveis utilizando Boo é similar
ao C#. A diferença principal é a utilização da palavra as. Ela é utilizada porque em Boo não é
necessário especificar o tipo de uma variável. Ao associar um valor de um determinado tipo a
uma variável, o compilador associa o tipo desse valor à variável. Assim, quando se utiliza a
sintaxe acima, o compilador apenas checa se o valor recebido corresponde ao tipo designado
(OLIVEIRA, 2005).
import UnityEngine;
import SystemCollections;
class example(MonioBehaviour)
public memberVariable as single = 0.0F;
3.4 - AUDIO ENGINE
Tão importantes quanto os gráficos e a simulação de fenômenos físicos são os
sons utilizados em um jogo. Eles ajudam a aumentar a realidade dos jogos, prendendo a
atenção do jogador e maximizando sua experiência, assim como na vida real o sentido da
10
Padrão internacional segundo o qual aplicações escritas em várias linguagens de alto
nível possam ser executadas em diferente ambientes sema necessidade de reescrevê-las
para cada ambiente específico. (ECMA, 2012)
14
audição é muito importante para os seres humanos, pois ajuda em sua orientação no espaço e
na sua compreensão do ambiente em que se encontra. Nas game engines a parte responsável
por cuidar do áudio do jogo é a audio engine. Em alguns casos, além de fornecer áudio de
qualidade, elas oferecem aos jogadores a possibilidade de interagir com o jogo e com outros
jogadores por meio de sons. O uso de microfones em jogos multiplayer é ótimo um exemplo
dessa interação (NILSON e SÖDERBERG, 2007).
Assim como nas engines citadas anteriormente, as audio engines fazem uso de
API’s para interagir com o hardware de áudio. Zerbst (2004) sugere o uso do componente
DirectSound da API DirectX, da Microsoft, para o desenvolvimento de uma audio engine.
O DirectSound fornece suporte para captura de sons a partir de dispositivos de
entrada, para execução de sons através de diversos dispositivos de saída, utilizando efeitos de
posicionamento tridimensional avançados (MICROSOFT, 2012).
As audio engines fornecem uma interface que permite aos desenvolvedores de
jogos inicializar e desligar componentes de áudio, e a carregar, executar e parar de executar
arquivos de áudio. As próprias API’s oferecem as estruturas (estruturas de dados) necessárias
para armazenar e lidar com arquivos de áudio, inclusive áudio 3D11 (ZERBST, 2004).
Durante a inicialização do componente de áudio, a string com o nome do arquivo
de áudio é convertida para o formato que a API utilizada trabalha. Depois os arquivos de sons
recém-carregados são comparados com os que já estavam carregados, para garantir que
nenhum arquivo de som seja rodado mais de uma vez acidentalmente. Uma vez carregado um
arquivo de áudio, a engine carrega todos os instrumentos e cria um canal para ele. Por fim ela
cria um buffer de áudio utilizando a API para este canal recém-criado. O som está carregado e
pronto para ser executado (ZERBST, 2004).
Na interface, a função que executa um determinado arquivo de áudio, cujo
identificador (geralmente um ponteiro) é recebido via parâmetro, verifica se este sofre alguma
mudança. Em caso afirmativo, ela salva (recalcula alguns atributos desse arquivo de áudio) as
mudanças nesse arquivo e seta o seu atributo indicador de mudança para falso. Então ela
executa o áudio como buffer secundário (ZERBST, 2004).
A função que interrompe (parar) a execução do arquivo de áudio faz exatamente o
que seu nome sugere: para a execução do arquivo de áudio. Mesmo nas classes internas da
audio engine que interagem diretamente com o hardware de áudio (lembrando que os
desenvolvedores de jogos não têm acesso a estas classes, mas somente à interface) o método
11
Áudio no universo 3D, que contém posição, alcance e orientação.
15
para a interrupção do áudio é simples, pois apenas chama um ou dois comandos já prontos da
API. (ZERBST, 2004)
É interessante para uma audio engine oferecer métodos que permitam aos
desenvolvedores manipular os atributos do áudio 3D (posição, orientação e alcance) a fim de
melhor situá-lo no universo 3D (ZERBST, 2004).
3.5 - ARTIFICIAL INTELIGENCE ENGINE
Por se tratar de uma atividade multimídia, os jogos exigem uma equipe com
conhecimentos em diversas áreas, como artes gráficas, música, programação, inteligência
artificial (IA). A evolução da inteligência artificial vem permitindo a criação de aplicações
cada vez mais interativas e jogos que proporcionem maior nível de entretenimento,
melhorando a qualidade da experiência do jogador (FARIA, 2011).
A capacidade de interação que um jogo apresenta em diferentes situações é outro
fator que, a cada dia, ganha mais importância no mundo dos jogos. As reações apresentadas
pela máquina diante das decisões e atitudes do jogador aumentam a sensação de realismo, nos
jogadores, (realismo esse já muito presente graças às engines físicas, gráficas), fazendo com
que este pense melhor seus movimentos e aja como se estivesse enfrentando um ser humano.
A sub engine que permite aos desenvolvedores implementar comportamentos mais realistas
nos jogos é a artificial inteligence engine (AI engine) (NILSON e SÖDERBERG, 2007).
De acordo com Nilson e Söderberg (2007), a maior dificuldade enfrentada pelos
desenvolvedores de IA para game engines deve-se ao fato de que o conjunto de técnicas de IA
aplicáveis varia para cada jogo. Diferente das engines gráficas e de física, em que se aproveita
praticamente tudo para vários jogos, as AI engines não são tão reutilizáveis assim devido à
especificidade de cada jogo, e fazer uma AI engine com todos os algoritmos passíveis de
utilização em jogos resultaria em uma ferramenta muito lenta, pesada. Tendo esse problema
em vista, constroem-se, então, AI engines menores, com funções para resolver alguns tipos de
problemas, busca de caminhos, por exemplo, e cada desenvolvedor implementa os algoritmos
de inteligência artificial que melhor se adaptar em seu jogo.
16
3.6 - NETWORK ENGINE
A evolução dos meios de comunicação, principalmente a internet, permitiu a
criação de um novo conceito no mundo dos jogos: as partidas multiplayer. A possibilidade de
interagir com outros jogadores via jogo elevou a experiência dos jogadores a um novo
patamar (NILSON e SÖDERBERG, 2007).
“Hoje, não se pode levar um jogo para PC ao mercado se ele não oferece um
modo network para permitir aos jogadores jogarem juntos no mesmo mundo virtual”
(ZERBST e DÜVEL, 2005).
Nas game engines o subsistema responsável por oferecer aos desenvolvedores
condições para implementação do modo network em seus jogos é a network engine (NILSON,
SÖDERBERG, 2007).
Network engines devem fornecer suporte, basicamente, para dois tipos de
arquitetura de comunicação em redes: peer-to-peer12 (ponto-a-ponto) e client/server13 (cliente/
servidor). Devem também seguir o padrão proposto pelo modelo OSI e permitir a utilização
dos dois protocolos mais utilizados na área de jogos: UDP14 e TCP/IP15.
Zerbst (2004) sugere a utilização de três API’s para utilização do hardware de
comunicação em rede: Berkeley Sockets, Windows Sockets(WinSock) e DirectPlay.
Desenvolvida pela Universidade da California, Berkeley, a Berkeley Sockets é indicada para
utilização de protocolos de comunicação e é utilizada em sistemas Unix e Linux como API
padrão para programação de aplicações de rede. A API Winsock é parte do sistema
operacional Windows e além de implementar os mesmos padrões que a Berkeley Sockets,
oferece algumas funcionalidades adicionais para facilitar a programação para redes no
Windows. De acordo com Zerbst (2004), a Winsock foi construída com base na Berkeley
Sockets. DirectPlay é um dos componentes do DirectX 9.0, da Microsoft. A DirectPlay foi
12
Arquitetura de sistemas distribuídos, em que as máquinas (nós) de uma rede estão
ligadas diretamente umas às outras, todas exercendo função tanto de servidor quanto de
cliente.
13
Arquitetura de rede em que os clientes estão ligados a um nó central que fornece serviços
(comunicação com outros clientes, processamento) a esses clientes.
14
Sigla de User Datagram Protocol. Trata-se de um protocolo de comunicação não
orientado à conexão, muito útil para envio rápido de requisições para espalhar mensagens
pela rede.
15
Sigla de Transfer Control Protocol. Trata-se de um protocolo de comunicação orientado a
conexão que lida com envio de pacotes entre os dois pontos da conexão. Muito útil em
situações em que é necessário garantir que o receptor receba todos os pacotes enviados.
17
construída com foco no desenvolvimento de aplicações de redes utilizadas em jogos e,
atualmente, já é considerada obsoleta.
A interface de interação do desenvolvedor com o hardware de rede deve oferecer
estrutura para que o desenvolvedor consiga armazenar as mensagens recebidas da rede
(geralmente filas com algumas implementações adicionais, de acordo com as funcionalidades
que a game engine pretende oferecer) e manipular sockets (criação de conexões, recebimentos
de pacotes, aceitação de clientes, definição de servidor, entre outros). Essa interface deve
também permitir que o desenvolvedor manipule tanto situações em que o servidor enviará
informações para os clientes quanto situações em que os clientes enviarão informações, ou
requisições, para o servidor (ZERBST, 2004).
3.7 - INPUT ENGINE
A input engine é responsável por cuidar da interação do jogador com o jogo,
oferecendo suporte à comunicação com dispositivos de entrada externa, como mouse, teclado,
joystics, para tornar essa interação possível (NILSON e SÖDERBERG, 2007). Para os
desenvolvedores, ela abstrai os comandos e operações de baixo nível e permite aos
desenvolvedores identificar eventos como clique de um botão do mouse, o apertar de um
botão do teclado ou joystick, entre outros, através de simples chamadas de métodos. Para
tanto, as input engines fazem uso de API’s (a DirectInput, por exemplo) escolhidas de acordo
com os dispositivos que a game engine oferecerá suporte e com as plataformas para as quais a
game engine permitirá desenvolver jogos (vídeo games, tablets, celulares, desktops)
(ZERBST, 2004).
DirectInput é uma API componente do DirectX, da Microsoft (assim como o
Direct3D, citado na seção das graphics engines). Ele permite que uma aplicação recupere
dados de dispositivos de entrada dos mais variados tipos sem precisar saber quais são os
dispositivos que estão sendo usados para gerar esses dados (MICROSOFT, 2012).
Segundo Zerbst (2004), uma das formas de construir uma input engine é criar uma
interface (contendo métodos como GetPosition, IsPressed e IsRelesead) para a classe Input de
sua game engine, que abstraia tarefas como, por exemplo, consultar as entradas externas
através da API utilizada. Os métodos dessa interface serão implementados pelas classes que
representam os dispositivos suportados pela game engine. Essas classes estendem uma
superclasse base, que estabelece a comunicação com o hardware através da API.
18
O método Init, serve para inicializar um dispositivo através da API utilizada (por
exemplo, se ela está sendo implementada na classe de teclado, ela inicializa um teclado). O
método Update consulta o estado atual do dispositivo e o compara com o último armazenado,
para ver se alguma tecla foi pressionada ou liberada. Os métodos IsPressed e IsReleased
verificam, respectivamente, se a tecla ou botão recebido como parâmetro estão pressionados
ou se foram liberados. Eles verificam a situação das teclas (ou dos botões) no estado
recuperado pelo método Update. O método HasJoystick permite aos desenvolvedores
verificar se há um joystick conectado e disponível (vale lembrar que os desenvolvedores têm
acesso às classes que implementam a interface). O método GetPosition verifica e retorna para
o desenvolvedor a posição do cursor do mouse na tela (se estiver sendo implementada na
subclasse mouse) ou as coordenadas x,y do botão de movimentação (se estiver sendo
implementada na subclasse de joystick). O método Release é chamado pelo destructor da
superclasse base que implementa a interface (citada anteriormente) e serve para limpar todos
os atributos dessa classe. E o método IsRunning indica se a engine está rodando ou não
(ZERBST, 2004).
A partir de arquiteturas como essa, as input engines permitem aos
desenvolvedores construir aplicações com as quais os usuários possam interagir.
4 - O MERCADO DE TRABALHO
Conforme visto nas seções anteriores, produzir uma game engine não é uma tarefa
fácil e nem barata. É necessário conhecimento em diversas áreas, e fazer com que essas áreas
interajam harmoniosamente tem um grau de complexidade muito elevado. Diante deste
cenário há muitas empresas que se arriscam a produzir suas próprias game engines, enquanto
outras se conformam em adquirir licenças de uso das que estão disponíveis no mercado. Em
2009, a IGN Entertainment publicou uma lista com as 10 melhores game engines do mercado,
que são: RAGE Engine, Cry Engine, Naughty Dog Game Engine, The Dead Engine, Unreal
Engine, Avalanche Engine, IW Engine, Anvil Engine, EGO Engine e Geo-Mod Engine
(STEAD, 2005).
O preço para se adquirir uma licença de uso de uma dessas game engines varia de
acordo com os pacotes de funcionalidades oferecidos pelas empresas. Além disso, existem
também as licenças para estudantes, geralmente mais limitadas e destinadas ao público que
está começando no ramo de desenvolvimento de jogos utilizando game engines.
19
O mercado de trabalho para o desenvolvimento de jogos com game engines ainda
não é muito grande no Brasil, principalmente devido ao pequeno número de empresas
desenvolvedoras de jogos, mas vem melhorando bastante depois da aprovação da Portaria nº
116, de 20 de novembro de 2011, que passou a reconhecer os jogos eletrônicos como
segmento cultural para recebimento de doações e patrocínios conforme o estabelecido na Lei
8.313, de 23 de dezembro de 1991, a "Lei Rouanet" (EXAME, 2011).
A Lei Rouanet institui o Programa Nacional de Apoio à Cultura (Pronac), com
intuito de captar e canalizar recursos para o segmento cultural nacional (COLLOR, 1986).
Essa lei permite que empresas, ou mesmo pessoas físicas que produzem jogos, possam captar
recursos e deduzi-los totalmente do imposto de renda (EXAME, 2011).
No exterior a situação já é um pouco diferente. Basta apenas pesquisar na web
para ver um grande número de oportunidades para se trabalhar com jogos e especificamente
com o desenvolvimento em game engines. Até mesmos nas redes sociais (LinkedIn, por
exemplo), é possível encontrar páginas e perfis de grandes empresas de jogos (como Ubisoft,
Activision, Konami, Rockstar) oferecendo oportunidades de trabalho nas mais diversas áreas
de jogos.
5 - CONCLUSÃO
A partir dos temas abordados ao longo deste artigo, é possível perceber que as
game engines são ferramentas muito complexas, pois abrangem várias áreas de conhecimento
que exigem um esforço muito grande para serem desenvolvidas. Além de profissionais
especialistas nas linguagens e plataformas nas quais a game engine permitirá produzir jogos,
são necessários, também, profissionais especialistas em cada um dos subsistemas (vistos
anteriormente) que comporão a ferramenta. Devido ao alto custo gerado pela produção de
uma ferramenta de tamanha complexidade, há empresas no mercado que preferem comprar
licenças e utilizar as game engines já existentes no mercado, adaptando-as se necessário.
Essas ferramentas são projetadas para facilitar o trabalho dos desenvolvedores de
jogos, pois abstraem conhecimentos de baixo nível necessários para utilizar o hardware
específico utilizado em cada área de um jogo. Assim, elas permitem que os desenvolvedores
com conhecimentos básicos em cada uma dessas áreas possam desenvolver seus jogos sem
precisar se preocupar muito em aprofundar seus conhecimentos em cada área. No entanto, é
importante ressaltar que, embora sejam muito úteis, as game engines não substituem a
20
necessidade de possuir conhecimento específico nas áreas inerentes aos jogos. Quando esse
conhecimento é ausente à equipe de desenvolvimento, esta fica limitada às funcionalidades
oferecidas pela game engine utilizada.
É possível perceber que as game engines são ferramentas muito úteis, pois
agilizam e "simplificam" o processo de desenvolvimento de jogos. Devido à sua
complexidade (abrange muitas áreas do conhecimento distintas), seu custo de produção é
muito elevado, o que faz com que algumas empresas optem por adquirir uma dentre as
licenças de utilização das game engines disponíveis no mercado. O uso de game engines, no
entanto, não substitui o conhecimento específico nas áreas abordadas por essas ferramentas,
pois a ausência deste conhecimento limita a equipe de desenvolvimento e a qualidade do
produto final às funcionalidades disponíveis na ferramenta escolhida. Há no mercado diversos
tipos de licenças e preços, que variam de acordo com as funcionalidades disponíveis em cada
licença.
Como extensões futuras, sugere-se a exploração mais detalhada de cada
funcionalidade das game engine, os estudos de caso práticos, a implementação de jogos
ilustrativos, bem como a exploração das ferramentas de modelagem gráfica. Enfim, o presente
trabalho abre rico espaço para experimentação e estudos no excitante campo do
desenvolvimento de jogos eletrônicos.
REFERÊNCIAS BIBLIOGRÁFICAS
COLLOR, Fernando. LEI Nº 8.313, DE 23 DE DEZEMBRO DE 1991. Presidência da
República,
23
de
dezembro
de
1991.
Disponível
em:
<
http://www.planalto.gov.br/ccivil_03/leis/L8313cons.htm >. Acesso em: 25 de outubro de
2012.
EBERLY, David H. 3D Game Engine Architecture: Engineering Real-Time Applications
with Wild Magic. Elsevier, 2005.
ECMA. Standard ECMA-335: Common Language Infrastructure (CLI). ECMA
International,
2012.
Disponível
em:
<
http://www.ecmainternational.org/publications/standards/Ecma-335.htm >. Acesso em: 24 de novembro de
2012.
EXAME. Jogos eletrônicos entram na Lei Rouanet. Exame, 12 de dezembro de 2011.
Disponível em: < http://exame.abril.com.br/tecnologia/noticias/jogos-eletronicos-entram-nalei-rouanet >. Acesso em: 25 de outubro de 2012.
21
FARIA, Fernando Antônio Batista de. Inteligência Artificial Aplicada a Jogos Eletrônicos.
Dissertação (artigo), Faculdade Metodista Granbery, Curso de Bacharelado em Sistemas de
Informação, Juiz de Fora, Minas Gerais, 2011.
GOLDSTONE, Will. Unity Game Development Essentials. Packt Publishin, 2009.
GUGELMIN, Felipe. Confira as novidades da versão 4.1 do OpenGL. TecMundo, 28 de
julho de 2010. Disponível em: < http://www.tecmundo.com.br/programacao/4689-confira-asnovidades-da-versao-4-1-do-opengl.htm >. Acesso em: 1º de novembro de 2012.
HIGGINS, Mark. Fourth Year Honours Project: Unity 3D. Behance. Disponível em: <
http://behance.vo.llnwd.net/profiles20/656461/projects/2195057/589e4f057d1785ea2fa7cc44
4c726cb2.jpg >. Acesso em: 22 de outubro de 2012.
KHRONOS, Group. OpenGL - The Industry's Foundation for High Performance
Graphics. Khronos Group, 2012. Disponível em: < http://www.khronos.org/opengl/ >.
Acesso em: 18 de novembro de 2012.
KLEINA, Nilton. O que é engine ou motor gráfico? TecMundo, 2011. Disponível em: <
http://www.tecmundo.com.br/video-game/9263-o-que-e-engine-ou-motor-grafico-.htm
>.
Acesso em: 20 de novembro de 2012.
LIMA, Edirlei Everson Soares de. 3D Game Builder: Uma Game Engine para a Criação
de Jogos 3D. Dissertação (artigo), Universidade do Contestado, Curso de Ciência da
Computação, Porto União, Santa Catarina, 2008.
MANUAL,
Unity.
Particle
Systems.
Unity.
Disponível
em:
<
http://docs.unity3d.ru/Images/manual/comp-ParticlesGroup-0.jpg >. Acesso em: 22 de
outubro de 2012.
MICROSOFT. Introdução à linguagem C# e o .NET framework. MSDN Microsof, 2012.
Disponível em: < http://msdn.microsoft.com/library/vstudio/z1zx9t92.aspx >. Acesso em: 23
de outubro de 2012.
MOZZILA.
JavaScript.
Mozzila
Developer
Network.
Disponível
em:
<
https://developer.mozilla.org/en-US/docs/JavaScript >. Acesso em: 23 de outubro de 2012.
NILSON, Björn; SÖDERBERG, Martin. Game Engine Architecture. Artigo, 2007.
NOKIA. J2ME: Class World. Nokia Corporation, 2005. Disponível em: <
http://www.j2megame.org/j2meapi/JSR_184_Mobile_3D_Graphics_API_1_1/javax/microedi
tion/m3g/doc-files/World-scenegraph.png >. Acesso em: 15 de outubro de 2012.
PÍCOLO, Guilherme Gouvêa. Mercado de games atinge crescimento recorde no Brasil,
diz PWC. Superdownloads, 11 de julho de 2012. Disponível em: <
http://www.superdownloads.com.br/materias/mercado-de-games-atinge-crescimento-recordeno-brasil-pwc.html >. Acesso em: 10 de outubro de 2012.
22
PRIBERAM. Dicionário Priberam da Língua Portuguesa. Disponível em: <
http://www.priberam.pt/DLPO/default.aspx?pal=motor >. Acesso em: 24 de novembro de
2012.
STEAD, Chris. The 10 Best Game Engines of This Generation. IGN, 15 de julho de 2005.
Disponível em: < http://www.ign.com/articles/2009/07/15/the-10-best-game-engines-of-thisgeneration >. Acesso em: 25 de outubro de 2012.
ZERBST, Stefan; Düvel, Oliver. 3D Game Engine Programming. Thomson Course
Technology PTR, 2004.