Game Engine

Game Engine Framework

Daniele Bellavista

Università di Bologna, Seconda Facoltà di Ingegneria Informatica Magistrale

10 dicembre 2011

Daniele Bellavista (Università di Bologna) Game Engine Framework 10 dicembre 2011 1 / 39

Outline
1 Introduzione al Game Engine
Componenti principali
2 Scene Manager

Scene Graph
Geometric State
Render State
3 Physic Engine

Corpi Rigidi
Corpi Molli
Physic Engine Esterni
4 Parallelization Support

Parallel Pattern
5 Artiﬁcial Intelligence

Pseudosense
Behaviour
Path Finding
6 Lista di GameEngine
7 Reference

Game Engine: Introduzione I

Astrazione dalla tecnologia
Interagendo con le API della graphic pipeline, è possibile costruire
qualunque applicazione grafica. Tuttavia le funzioni disponibili, le librerie
e le classi dipendono dalle API utilizzate.
Il Game Engine è un middlelayer che separa la “game logic” dalla
tecnologia, l’implementazione e la piattaforma su cui si poggia la “graphic
logic”.

Separazione delle competenze
Per progetti molto grandi, il team di lavoro tende a diversificarsi (AI
developer, physic developer, grafici, compositori, sceneggiatori, . . . ).
Il Game Engine fornisce API in grando di suddividere la resposabilità
delle entità del sistema.


Game Engine: Introduzione II


Game Engine: Introduzione III

Obiettivi
Un videogioco è un sistema real-time, da eseguire su normali pc.
Occorre trovare il giusto compromesso fra estetica e giocabilità.
Un Game Engine innovativo deve fornire supporti ed effetti di qualità
garantendo una ﬂuidità accettabile per lo stato attuale dell’hardware.
Ad esempio idTech 5 mette a disposizione una tecnica di Radiosity per la
pre-generazione delle light map o per il render delle cinematics, e
Shadow Map per le (poche) componenti dinamiche.


IdTech4 (Doom 3): Gameplay con Volume Shadow

Figura:
http://upload.wikimedia.org/wikipedia/en/0/07/Doom3shadows.jpg

IdTech5 (Rage): Gameplay con Shadow Map e Light Map

Figura: http://www.capsulecomputers.com.au/wp-content/uploads/
rage-screenshot-021.jpg


IdTech5 (Rage): Cinematic con Radiosity

Figura: Rage cinematic screenshot


Game Engine: Componenti principali I

Componenti principali di un Game Engine
Scene Manager: gestione gerarchica dei modelli, memorizzando informazioni
geometriche, di renderer e di animazione.
Physic Engine: gestione di collisioni e reazioni, gravità, dinamica corpi rigidi e
molli, moto di fluidi, sistemi particellari.
Parallelization Support: gestione dell’esecuzione concorrente per sfruttare
appieno le architetture multi-core.
Artificial Intelligence: supporto per avvicinare alla realtà le reazioni
comportamentali delle entità pensanti.
Game Middlelayer: astrazione rispetto allo Scene Manager, fornisce strutture
dati con semantica indipendente dalle problematiche di grafica.


Game Engine: Componenti principali II


Scene Manager

Scene Manager
Il cuore del Game Engine. Memorizza tutte le informazioni necessarie per
rendere i modelli del gioco. È un componente con un basso livello di
astrazione, poiché contiene concetti geometrici e graﬁci; per questo motivo un
buon Game Engine dovrebbe fornire un ulteriore layer sopra lo Scene
Manager (tipicamente il Game Middlelayer).

Organizzazione ed Ottimizzazione
Motivazioni principali:
Trasformazioni gerarchiche (il personaggio sale a cavallo, il cavallo si
muove e il personaggio lo deve seguire).
Ottimizzazione del clipping (il personaggio uccide un mostro e si volta: il
cadavere rimane alle sue spalle, non visibile).
Model sharing (in una stanza stesso candelabro, diversa posizione).


Scene Manager - Scene Graph I

Scene Node
Elementi del gioco sono dei “nodi” di
scena.
Ad ogni nodo è associato un
Geometric State e un Render State.
Il Geometric State memorizza
informazioni geometriche (tipologia
geometrica, trasformazioni, bounding
box, . . . ).
Il Render State memorizza
informazioni necessarie alla fase di
rendering (alpha, materiali, texture,
...)


Scene Manager - Scene Graph II

Scene Graph
Rappresentazione della scena come
un albero.
Gli stati del padre sono condivisi con i
ﬁgli.
Due o più nodi possono condividere
lo stesso modello.
La radice dell’albero è il nodo root,
che non è reso su schermo.


Scene Manager - Geometric State I

Geometric State
Ogni nodo dello Scene Graph ha un proprio Geometric State, contenente
informazioni quali:
Struttura Geometrica (point, polyline, mesh, particelle).
Vertex e Index Buffer.
Trasformazioni.
Bounding Box.


Scene Manager - Geometric State II

Geometric State - Trasformazioni
Trasformazioni gerarchiche: ogni nodo a parte il root subisce 3
trasformazioni.
1 Trasformazione del padre
2 Trasformazione dell’arco (in che posizione del padre si trova il ﬁglio).
3 Trasformazione locale
Ad esempio, nello scene manager precedente si ha che la spada subisce
3 trasformazioni: Wknight · Aknight −sword · Lsword ; dove Wknight è la matrice di
trasformazione totale del cavaliere (posizionamento al centro del sistema
di riferimento cavaliere), Aknight −sword è il posizionamento della spada in
una certa posizione del cavaliere (ad esempio sulla schiena) e Lsword è la
trasformazione locale della spada (ad esempio il rimbalzo causato dal
movimento del cavallo).


Scene Manager - Geometric State III

Geometric State - Bounding Box
Lo scopo dei bounding box è quello di migliorare
le performance globali sempliﬁcando il view
frustum culling e il collision detection.
Si utilizzano dei bounding semplici e convessi
come sfere, cilindri e poliedri.

Bounding Box - Collision Detection
Determinazione rapida delle intersezioni, sia fra
oggetti che con il mouse (3D picking).
Intersezione con il mouse calcolata castando un
ray che parte dalle coordinate in screen space del
mouse e attraversa il view frustum.


Scene Manager - Geometric State IV

Bounding Box - Pre-Culling
Ottimizzazione del View Frustum Culling,
2D Frustum View
testando se il bounding box di un oggetto è
all’interno del view frustum.
Molto più conveniente rispetto al testing di tutti i
triangoli.
Si utilizza un algorimo veloce, non perfetto, in
grado di eliminare velocemente gran parte degli
oggetti che non sono all’interno del view frustum,
risparmiando il calcolo alla GPU. 1,2,3 Not Culled
Se un bounding box è all’esterno di almeno un 4 Culled
piano del frustum, allora non lo si rende.


Scene Manager - Render State

Render State
Contiene tutte le informazioni associate al modello geometrico
necessarie per il rendering.
Alcuni esempi di render state:
Alpha: abilitazione o disabilitazione canale alpha nelle texture
Sencil Buffer: abilitazione ed uso per vari scopi dello Stencil Buffer
Wireframe: modalità Wireframe.
Texture: parametri necessari per l’utilizzo di texture.
Materials: parametri del materiale dell’oggetto.
Culling: metodologia di culling (es: NONE, BACK_FACE, ALL).
Light: tipologia e parametri di luce.


Physic Engine I

Physic Engine
Un simulatore di ﬁsica realistico deve simulare molti aspetti, dalla gravità
al moto dei ﬂuidi, dal collision detection alla dinamica di corpi molli.
I videogiochi sono sistemi real-time, che richiedono al minimo 30 frame al
secondo (circa 30 ms di computazione per frame).
Il physic engine di un videogioco deve fornire strumenti veloci, ottimizzati
e approssimati in modo non da sembrare realistica, ma da dare una
percezione di correttezza.


Physic Engine II

Features di un Physic Engine per sistemi Real-Time
Collision detection: tramite bounding box sferici o convex-hull.
Sistemi Particellari: illustrati nel talk di Luca Mella.
Dinamica Corpi Rigidi: reimplementazione matriciale delle equazioni del moto
newtoniane.
Dinamica Corpi Molli: mass-spring model, nurbs surface e sistemi particellari.


Physic Engine - Corpi Rigidi I

Dinamica Corpi Rigidi
La ﬁsica più semplice da implementare (disponibile in tutte le GPU moderne),
basata sulle equazioni del moto newtoniane.
   −1 
X˙ m P
˙ 
q  ω q /2
 = 
˙
P  F 
L˙ τ

m: mass τ : momento angolare della forza.
q (t ): Quaternione rappresentante la ˙
L(t ): velocità di cambiamento del
matrice di rotazione. momento angolare.

ω(t ): Quaternione rappresentante la P(t ): quantità di moto del corpo.
velocità angolare. ˙
X(t ): variazione dello spostamento
F: forza applicata al corpo. del corpo.


Physic Engine - Corpi Rigidi II

Figura: http://www.youtube.com/watch?v=zwqedhWO_5Q


Physic Engine - Corpi Molli

Dinamica Corpi Molli
Si utilizza un modello chiamato Mass-Spring System.
Oggetti rappresentati come array 1/2/3D, dove gli elementi sono masse
particellari, collegate fra loro da molle governate dalla legge di Hooke.

Figura: http://www.youtube.com/watch?v=qOvb3WLAX0E


Physic Engine come componente esterno

Physic Engine Esterni
Una alternativa allo sviluppo di un proprio Physic Engine, è quello di
utilizzare un Physic Engine esterno, da integrare con il proprio Game
Engine.
Un esempio è l’Havok Game Dynamics SDK, che ha fatto il suo debutto
con Max Payne 2: The Fall of Max Payne.
Esistono ovviamente Physic Engine open source, come Open Dynamic
Engine e SOFA (Simulation Open Framework Architecture) che supporta
anche le deformazioni di corpi molli.

Havok: una dimostrazione
Havok Cloth: http://www.youtube.com/watch?v=daZoXzBGea0
Havok Destruction:
http://www.youtube.com/watch?v=a06hAe747Do


Parallelization Support I

Parallelization Support
La frequenza massima delle CPU si è da tempo fermato ad un limite
ﬁsico intorno ai 3.5 GHz.
Si ha dunque un limite al numero di operazioni eseguibili
sequenzialmente in un certo lasso di tempo.
Il multi-core è diventato il nuovo standard architetturale per i processori
dei PC e tutti i moderni videogiochi richiedono come requisito minimo
almeno un dual-core.


Parallelization Support II

Case Study: tempo computazionale necessario a IdTech 5
Animation blending: ≈ 2ms
Collision detection: ≈ 4ms
Obstacle avoidance: ≈ 4ms
Transparency sorting: ≈ 2ms
Virtual texturing: ≈ 8ms
Misc processing: ≈ 4ms
Rendering: ≈ 10ms
Audio: ≈ 4ms
Totale: 38ms.
FPS minimo per la giocabilità: 30, allora bisogna produrre un frame almeno
ogni 33ms.


Parallelization Support III

Verso un Parallel Game Engine Framework
Parallelizzazione dei lavori, sfruttando tutti i core disponibili nel sistema.
Chiamate bloccanti da eliminare.
Gestione non banale della sincronizzazione: evitare le attese per
l’accesso a risorse condivise (replicazione e aggiornamento dei dati).
Creazione di un thread di sistema per ogni core, ma utilizzo di un proprio
task manager (aumento della scalabilità).


Parallelization Support IV

Figura: Execution State http://software.intel.com/en-us/articles/
designing-the-framework-of-a-parallel-game-engine/


Artificial Intelligence

Artificial Intelligence System
Un sistema di AI è uno strumento praticamente essenziale per i
videogiochi moderni, per garantire un comportamento quasi-reale agli
NPC.
Richiesto in tutte le tipologie di videogame, ad esempio:
Board Game: la “classica” intelligenza artificiale.
RTS, TBS, RPG: strategia di attacco/difesa anche variabile, risposta alle
mosse dell’avversario, meccanismi di aiuto verso gli alleati.
First Person Shooter: strategie di guerriglia, utilizzo dell’ambiente, amici
e nemici “fair”.
Alcune fra le più importanti features di un AI system sono:
Pseudo-sense.
Realistic Behaviour.
Path Finding.


Artiﬁcial Intelligence - Pseudosense

Pseudo-sense
I giocatori fanno uso dei propri sensi per reagire alle situazioni.
Gli NPC, per fare lo stesso, richiederebbero una potenza computazionale
troppo elevata.
Si ricorre al “cheating”: l’NPC può chiedere al game engine la posizione
del player che deve uccidere o dei compagni che deve aiutare.
“Design cheating”: tag inseriti in fase di design per sempliﬁcare il
riconoscimento di determinati pattern (es: coperture, pareti sfondabili,
ecc. . . )
Ovviamente queste tecnicha deve essere compensata da una
attenuazione delle reali potenzialità dell’NPC.


Artiﬁcial Intelligence - Behaviour I

Simulare un behaviour reale: planning system
L’uso massiccio di scripts porta ad un comportamento “robots-like”.
L’implementazione di una macchina a stati è proibitiva per le funzionalità
richieste.
Sistemi multi-agenti: la percezione del mondo avviene leggendo gli stati
di uno State Space comune.
Gli agenti devono risolvere certi goal pianiﬁcando le proprie action
disponibili.


Artiﬁcial Intelligence - Behaviour II


Artificial Intelligence - Path Finding I

Path Finding
Problema di AI, spesso offerto anche dai Physic Engine.
Richiede molta potenza computazionale, spesso troppa per un real-time.
Semplificazione dell’algoritmo: da 3D a 2D.
Agevolazione effettuata inserendo dei tag in fase di modellazione.

Path Finding - Navigation Mesh
Tecnica di tagging per path finding: in fase di modellazione, si aggiungono
alle mappe delle mesh che delimitano le superfici attraversabili.
Le singole mesh possono essere taggate per identificare il tipo di
attraversabilità, ad esempio: oggetto scavalcabile, scalabile, . . .
Algoritmo A* per la determinazione del percorso (quasi)ottimo.
Possibile ottimizzazione per evitare movimenti “robot-like”.


Artiﬁcial Intelligence - Path Finding II

Figura: https://developer.valvesoftware.com/wiki/Navigation_Meshes


Artiﬁcial Intelligence - Path Finding, A* Example


Lista di Game Enigne

Game Engine Commerciali
idTech 5, motore della idSoftware. Utilizzato per il videogioco Rage.
CryENGINE 3, motore della CryTek: produttori di Crysis.
UnrealEngine 3, motore utilizzato in titoli come Mass Effect, BioShock e
Gears of War.

Game Engine OpenSource
idTech 4, motore della idSoftware.
Ogre 3D, graphic engine. Scritto in c++, per PC.
Irlicht, game engine. Scritto in c++, e disponibile anche per .NET.
jMonkey, java game engine.
UNiGiNE, game engine professionale a pagamento.


Reference I

Game Engine Structure, Scene Manager, Physic Engine
David H. Eberly, 3D Game Engine Design - A pratical approach to
real-time computer graphics Second Edition, Morgan Kaufmann, 2007,
Parallel Game Engine
http://software.intel.com/en-us/articles/
designing-the-framework-of-a-parallel-game-engine/
idTech 5: Virtual Texturing, Parallelization
J.M.P. van Waveren, Beyond Programmable Shading, Talk at SIGGRAPH
2009.
http://s09.idav.ucdavis.edu/talks/05-JP_id_Tech_
5_Challenges.pdf
Artiﬁcial Intelligence
Bourg Seemann; AI for Game Developers, O’REILLY, 2004
http://silverspaceship.com/src/svt/


Reference II

Navigation Mesh
https://developer.valvesoftware.com/wiki/
Navigation_Meshes
http://udn.epicgames.com/Three/
NavigationMeshReference.html
AI in Left 4 Dead
Booth Micheal, The AI Systems of Left 4 Dead, Artiﬁcial Intelligence and
Interactive Digital Entertainment Conference at Stanford, Valve 2009.
http://www.valvesoftware.com/publications/2009/
ai_systems_of_l4d_mike_booth.pdf
Multi-Agent Systems in Videogames and leearing tecnhique
Thore Graepel, Ralf Herbrich, Adi Botea; Video Games and Artiﬁcial
Intelligence; Microsoft Applied Game (APG) group.
http://research.microsoft.com/en-us/projects/
ijcaiigames/

Reference III

Planning and A.I. in F.E.A.R.
Jeff Orkin, Three States and a Plan: The A.I. of F.E.A.R., Monolith
Production, M.I.T. Media Lab, Cognitive Machines Group, GDC 2006.
http://web.media.mit.edu/~jorkin/
Planning System
Ben Hardwidge, How AI in Games Works, 2009
http://www.bit-tech.net/gaming/2009/03/05/
how-ai-in-games-works/3


Game Engine

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to Game Engine

Similar to Game Engine (20)

Recently uploaded

Recently uploaded (9)

Game Engine