Do Reaktor ao D4MD Rui Pires Tiago Rodrigues Miguel Dias

Resumo ● Visão geral do processo de desenvolvimento de jogos ● Projecto Reaktor ● Projecto D4MD

Desenvolvimento de Jogos ● Antigamente uma pessoa sozinha conseguia desempenhar todas as tarefas de desenvolvimento de um jogo. ● Hoje em dia o desenvolvimento de um jogo comercial envolve um elevado numero de pessoas, especializadas em areas diferentes – Programadores – Artistas – Testers – Game designer – Game Producer

Desenvolvimento de Jogos ● Jogos amadores normalmente têm equipas mais reduzidas – Projectos académicos ou Hobby’s – Tem geralmente por objectivo mostrar as capacidades dos autores ● Empresas nunca contratam ninguém sem experiência – Os projectos amadores servem como port-fólio

Desenvolvimento de Jogos ● Fases no desenvolvimento de um jogo – Design do jogo ● Pode começar com uma ideia bem definida ● Ou como uma série de experiências com novas ideias ou tecnologia – Criação de um protótipo ● Serve como proof of concept – Produção ● Normalmente dura entre 1 e 3 anos (num jogo comercial) ● Crunch time

Desenvolvimento de Jogos ● Um jogo normalmente tem por componentes – Motor gráfico – Motor de física – componentes de som, carregamento de modelos, input, etc – Ferramentas de desenvolvimento criadas “in- house” e outras

Reaktor ● Enquadramento – Projecto final para a cadeira de Computação Gráfica e Multimédia (4º ano, ETI-ISCTE) – O tempo disponível para o projecto era cerca de 1 mês

Reaktor ● Objectivos: – Ter um FPS funcional – Ganhar experiência – Ganhar sensibilidade aos problemas associados com o desenvolvimento de jogos – Aplicar os conhecimentos adquiridos na cadeira de CGM de uma maneira interessante

Reaktor ● Motor Gráfico – Foi desenvolvido de raiz, utiliza OpenGL para desenho – Divisão espacial : BSP-Tree – Carrega mapas de Quake3 (não compilados) ● Parsing e processamento do mapa ● Criação da BSP

Reaktor ● Motor de Física – Feito de raiz – Apenas dinâmica da translação – Integração de Euler – Algoritmo de detecção de colisão suporta colisões entre : ● Ponto-Esfera, Ponto-Elipsoide, Esfera-Esfera, Esfera- Elipsoide, Elipsoide-Elipsoide, Esfera-Poligono e Elipsoide-Poligono

Reaktor ● Suporte de Rede – Desenvolvido de raiz – Garantir o sincronismo entre as várias instâncias dos objectos do jogo – Arquitectura cliente/servidor – Objectos distribuídos pelos diversos utilizadores ● Objectos locais / Objectos Remotos – Um objecto criado localmente impõe o seu estado aos seus objectos remotos correspondentes – Entre actualizações de estado os objectos remotos são tratados como objecto locais

Reaktor ● Conclusões – Com um desenho cuidado, e utlização de APIs portáveis, é relativamente fácil suportar várias plataformas (no nosso caso, Win32 e Linux) – A “arte” do jogo é muito importante para os jogadores. – Reacções físicas menos realísticas não assustam os utilizadores. – Ambiência é muito importante (sons, nevoeiro, aspecto geral...)

Reaktor ● Conclusões (2) – Hoje em dia não é viável a uma empresa desenvolver um jogo comercial completamente de raiz – Tendência para comprar “Game-Engines” e desenvolver os conteúdos – Cada vez mais, surgem empresas especializadas no desenvolvimento de de middleware

D4MD (de-for-md) ● Enquadramento: – Nosso TFC (trabalho final de curso) – Jogo de simulação de condução, com ênfase na deformação de geometria (em resultado de choques) e simulação mecânica dos veículos – Tirar partido da experiência obtida do Reaktor – Usar middleware existente como motores gráficos e motores de física de modo a permitir a concentração do esforço nas características específicas do projecto

D4MD ● Motor Gráfico – Existem diversas alternativas open-source de grande qualidade: – OSG - – Irrlicht - – Ogre3D - – Foi escolhido o Ogre3D – Elevada qualidade da documentação – API OO (c++) simples e extensivel – Multiplataforma, independente do sistema de renderização (OpenGL/D3D) e acesso fácil a programação com Shaders CG e GLSL – Comunidade bastante activa e actualizações frequentes

D4MD ● Motor de Física – Poucas opções open-source: – ODE - – Algumas opções grátis para projectos não comerciais: – Tokamak - – True axis - – Newton Game Dynamics - – NovodeX -

D4MD ● Motor de Física – Escolhemos o NovodeX – API C++ – Robustez e desempenho muito elevado com formas primitivas – Determinístico – Boa documentação e forum de suporte técnico – Se é bom para o motor Unreal 3, também é bom para o nosso jogo!

D4MD ● Deformação em jogos: – Embora existam muitos exemplos de jogos que incluam deformação, a informação sobre as técnicas utilizadas é pouca ● Exemplos: – NFSU 2 – GTA3 – CARMAGEDDON 2

D4MD ● Técnicas de deformação mais utilizadas – Técnicas com base física – Mola-Massa – Especialmente indicada para corpos 2D (ex: pano) – Corpos com deformação contínua – FEM (Finite Element Method) – Resultados muito realistas – Requisitos de processamento e memória muito elevados – Técnicas com base geométrica – FFD (Free Form Deformation) – Deformação do espaço : independência em relação à geometria

D4MD ● Exemplo Mola-Massa: – Arranjo 3D usando molas orientadas

D4MD ● Exemplo FEM: – Subdivisão FEM de um modelo complexo origem: M. Muller, Physically-Based Simulation of Objects Represented by Surface Meshes

D4MD ● Exemplo FFD: – Manipulação directa de um cubo através de FFD

D4MD ● Sistema de deformação – D4M: – Deformação intantânea de objectos com características metálicas – Uso da técnica DFFD (direct manipulation FFD) – Reconfiguração automática dos controlos através de um ou mais deslocamentos no espaço – Deformações com resultados visuais agradáveis usando B-Splines cúbicas uniformes – Controlo da relação qualidade/desempenho através da distribuição de pontos de controlo – A independência em relação à geometria de deformação permite o uso de formas físicas simples para simular a dinâmica dos corpos

D4MD Sistema de deformação – D4M

D4MD ● Simulação mecânica dos veículos: – Curvas de momento angular – Momento aplicado às rodas e força consequente aplicada no solo vai influenciar o motor. – Veículos são bastante parametrizaveis – curva de Torque – mudanças e suas eficiências – pesos e sua distribuição – Eficiências : Transmissão, Travões, Diferencial, …

● Simulação mecânica dos veículos (2) – Rodas são simuladas com raios, que vão ter o comportamento de molas (as suspensões) – solução mais eficiente para o motor de física – muito comum neste tipo de jogos – A simulação completa da rodas impõe vários problemas para os motores de física, que assim são facilmente evitadas – Instabilidade devido ao elevado numero de “constraints” implicados D4MD

● Modo multijogador / Interface imersiva – Estamos igualmente a desenvolver um modo multijogador, que permitirá o jogo em rede – Tirar partido das características determinísticas do motor de física – Simulação paralela em cada um dos clientes – O servidor apenas controla o relógio global e o sincronismo de frame – Usar o modo de rede para para permitir o uso de uma interface imersiva 3D – CAVE

● Cave: – Permite a visualização de um mundo 3D através da imersão do utilizador numa estrutura de visualização e uso de óculos especiais

D4MD

● Conclusões: – Hoje em dia é quase impossível desenvolver um motor de jogo todo de raiz – Existem bastantes alternativas open-source para os vários componentes: motores de física, motores gráficos, bibliotecas de som, etc.. – Usar middleware existente, ajuda bastante na obtenção de resultados com qualidade superior, no entanto o tempo necessário para aprender a lidar com as suas APIs e integrar diversos módulos que não foram pensados para trabalhar em conjunto pode ser igualmente elevado. – A experiência é muito importante na industria dos jogos, como nenhuma empresa recebe pessoas sem experiência é muito dificil entrar, no entanto ter trabalho feito na área, mesmo que feito de forma amadora, ajuda.