Embed Size (px)
Citation preview
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:
Exemplo (luz):
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
Object
Missile Spaceship Explosion
FriendFoe-Missile
HeatSeeking-Missile
EnemySpaceship
Asteroid
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
data-driven◦ 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
