Erick Baptista Passos
[email protected]


Introdução: Scene graph
JMonkeyEngine
◦ Hello Game
◦ Tutorial

Arquitetura de Engines
◦ GameObjects
◦ Data-Driven Components

Conteúdo voltado a programadores.
◦ O objetivo da aula de hoje é mostrar os padrões de
projeto usados para criar engines de jogos
◦ Diferenciação entre bibliotecas, frameworks e
engines
◦ Ao final os alunos saberão como criar e manter um
framework (ou até uma engine) para seus jogos
usando o paradigma orientado a objetos
◦ Em última instância, serão feitas comparações
visando mostrar onde esses padrões são aplicados
em engines específicas grandes como: Unreal,
CryEngine, GameStudio, Torque, entre outras

Biblioteca
◦ Conjunto de classes, funções para auxiliar a
resolver problemas comuns
◦ Seu código instancia, invoca, chama...

Framework
◦ Esqueleto de aplicação pronto para ter a lógica de
negócio implementada e acoplada
◦ Seu código implementa ganchos (hooks, callbacks)
que são instanciados, invocados, chamados pelo
framework

Engine
◦ Conjunto de bibliotecas e frameworks para tarefas
comuns em desenvolvimentos de jogos como:
gráficos, física, rede, IA, integrados em um
ambiente de desenvolvimento produtivo
◦ Inclui ferramentas visuais para manipulação das
cenas (fases) do jogo e seus GameObjects (será
explicado em detalhes)
◦ Normalmente são específicas para um gênero!
 Discussão

Estrutura de dados que organiza uma cena
3D hierarquicamente
◦ Nós podem ser:
 Geometrias simples ou modelos 3D
 Um nó de agrupamento
◦ Nós têm atributos que se propagam pelo grafo




Posicionamento, rotação e escala
Atributos sobre iluminação
Outros atributos da máquina de estados OpenGL
Normalmente de um nó para seus filhos

Exemplo:
Raiz
Terreno
Casa
Personagem
HUD
Life
Points

Exemplo (luz):
Raiz
Terreno
HUD
(Luz)
Casa
Personagem
Life
Points

Porque um scene graph não é uma árvore?
◦ Podem existir nós (folhas ou não) com mais de
um “pai”
◦ Um exemplo são geometrias compartilhadas para
aceleração


Framework pra jogos escrito em Java
É a mais completa e mais rápida engine em
Java atualmente, além de ter uma
comunidade extremamente ativa
◦ Na pior das hipótese é uma ótima plataforma
para se aprender desenvolvimento de engines

Apoiada por diversas empresas
◦ SUN, NCSoft, JadeStone, Three Rings




Scene graph
Completamente OO
Usa OpenGL nativo
Abstrai o desenvolvedor de lidar com a
maioria das operações de baixo nível

Todo jogo é uma simulação controlada por
um loop infinito semelhante ao seguinte:
◦ Checagem por controles
 Teclado, mouse, joystick
◦ Atualização da cena
 Reposicionamento de nós
 Atualização de audio
 Atualização dos agentes de IA
◦ Desenho da cena na tela
 Percorrer o scene graph e desenhar todos os objetos
visíveis

JMonkeyEngine traz essas funcionalidades
de forma flexível e customizável
◦ Game loop
◦ Checagem por controles
◦ Um scene graph

Montagem de um scene graph e as regras
de negócio do jogo
◦ O nosso exemplo irá explorar incrementalmente
essa abordagem

Exemplo mínimo que usa uma classe Básica
que representa um jogo:
◦ SimpleGame


Adiciona apenas uma caixa 3D à cena
A versão baseada em StandardGame é a
forma mais apropriada de se desenvolver um
jogo
◦ GameStates representam sub-cenas ou mesmo
níveis diferentes do jogo



Separa o loop principal do jogo
(StandardGame) das diferentes cenas que
podem compor este último (gameStates).
A idéia é que criemos GameStates para a
cena principal, outro para um µmenu, outro
para o menu de pausa, etc.
No jogo Dirty Racers foram usados 7
diferentes GameStates
◦ Menu, InGameMenu, TrackChooser, CarChooser,
Racing, Loading e Creditos

Lições abordando o desenvolvimento do jogo
de forma incremental
◦ Cena básica com um terreno e iluminação
◦ Personagem do jogo com animação importado de
uma ferramenta de modelagem 3D
◦ Personagem que atira balas explosivas
◦ Incluindo barris para serem destruídos



O que está errado com o tutorial?
Apesar de ser bem simples e usar as classes
disponíveis para organizar a cena, não existe
uma taxonomia que permita abstrair o que
compõe um jogo genérico
Precisamos abstrair o processo de criação de
jogos em uma arquitetura mais flexível que
se adeque a mais de um jogo
◦ Engenheiros são lentos (voltaremos a isso)

Os principais conceitos ligados a jogos em
geral são:
Jogo
Cenário
Personagens
Demais objetos (estáticos e dinâmicos)
Comportamento ligado a certos objetos e/ou
eventos
◦ Término da partida/nível
◦ HUD e menus intermediários (interface)
◦
◦
◦
◦
◦

Uma forma de agrupar esses conceitos de
forma ainda mais geral seria:
◦ Game
 Meu jogo
◦ GameObjects




Cenário
Personagens
Demais objetos (estáticos e dinâmicos)
HUD e menus intermediários (interface)
◦ Callbacks discretos
 Comportamento ligado a certos objetos e/ou eventos
 Término da partida/nível

A chave para a arquitetura de um jogo é o
paradigma da orientação a objetos
◦ Poucos domínios são tão facilmente mapeados para um
paradigma

GameObject
◦ Representa qualquer entidade estática ou dinâmica em
jogos
◦ Classe abstrata (ou concreta quando baseada em
componentes)
◦ Possui atributos como geometria, posicão, etc.
◦ Também inclui o comportamento daquele objeto
◦ Subclasses especificam tipos diferentes de objetos como
NPCs, player, objetos estáticos
GameObject
DynamicObject
Character
Player
StaticObject
Boat
NPC
TrigerObject
Object
Missile
FriendFoeMissile
HeatSeekingMissile
Spaceship
Explosion
Asteroid
EnemySpaceship



O trabalho do programador agora se resume
a criar classes que representam os tipos
especiais de GameObjects do seu jogo
Compor os níveis consiste em definir que
objetos devem ser instanciados e seus
atributos
Um exemplo de implementação...

Qual o problema dos game objects?
◦ Estrutura rígida de herança
◦ Game design prevê muitas mudanças no
comportamento e estrutura dos jogos
◦ Engenheiros são lentos
◦ Apenas permitir que se especifique o
comportamento em linguagens de script é pouco

É preciso abstrair não só os atributos e
comportamento, mas também a estrutura dos
GameObjects
◦ Tratar dados como dados, o resto não importa...

Existem várias maneiras de decompor os
GameObjects em uma estrutura de herança
◦ Estão TODOS errados
◦ Obviamente não INICIAM errados

Jogos mudam constantemente
◦ Designer decidem independentemente das
estruturas de tipos dos engenheiros
◦ Eles VÃO pedir coisas que atravessam as amarras
da hierarquia

Isto é um banco de dados
◦ (um problema muito bem entendido)
◦ “The data is important, nothing else matters”


…mas continuamos hard-coding everything
Para lidar com mudanças de design, não
adianta criar uma ferramenta para alterar
propriedades apenas (editor), e sim uma que
permita COMPOR a estrutura desses
GameObjects

Cada componente é um peça auto-cotida de
lógica de jogo
◦ Modelo, física, inventário, arma, terreno, textura,
shader


Encaixe componentes para montar um
GameObject
Especificação dessa montagem deve ser datadriven
◦ XML, script, etc… Manipulável no editor

Basicamente TODAS as engines comerciais
são baseadas em uma dessas duas estruturas
ou uma mescla de ambas
◦ GameStudio – GameObjects
◦ Torque e Unreal – mescla mais próxima de
GameObjects
◦ Cryengine e DS (Dungeon Siege) – Component
system

Os editores de nível nos permitem manipular
os atributos e estrutura (quando existente),
que são mantidos persistentes através de
script, XML (cryengine), entre outras formas


Isso foi apenas uma amostra MUITO pequena
das funcionalidades da JMonkeyEngine e de
como se organiza uma engine
Assuntos não explorados mas que podem ser
discutidos depois:
◦
◦
◦
◦
Dependência entre objetos e componentes
Criação de editores de nível
Content pipeline
Aplicação dessas técnicas com Actionscript 3.0
(flash), XNA ou Ogre3D, entre outras ferramentas

Mais informações em:
◦ www.jmonkeyengine.com
◦ Revista Mundo Java edição 24
 Página 30
◦ Game Programming Gems 6, artigo Game Object
Component System
◦ http://Sertao3d.blogspot.com - meu blog