Lo sviluppo diEdge Guardian

Alcune note tecniche

Partendo da zero

● Realizzare un MVP videludico in pochi mesi○ Quali sfide tecniche?○ Vediamo qualche esempio

Partendo da zero

● Rendering stereoscopico○ Low level rendering○ Setup della telecamera

■ Distanza interoculare■ Convergenza

● Tracking○ Librerie di basso livello per l’acquisizione○ Interpolazione e smoothing dei dati di tracking○ Gestione dei tracked device

Integrazione con Unity3D

Uso di Unity con HTC Vive:

● SteamVR (architettura open source)○ OpenVR (libreria open source)

● VRTK (VR Tool Kit)○ Nato dalla community○ Grezzo all’inizio

■ Alcune integrazioni sono state necessarie○ Evoluto moltissimo in pochi mesi

Le vere sfide

Iterazioni brevi:

● Mercato nuovo ed in fermento ○ Necessità di essere disponibili al pubblico il prima possibile

Ottimizzazione:

● Vive richiede(va) 90fps obbligatori○ Ogni hiccup risulta estremamente fastidioso○ Cali prolungati di framerate portano nausea

○ Problema parzialmente superato di recente con ATW (Asynchronous reprojection)

Comportamenti emergenti

All’inizio erano le sfere:

● Non erano troppo interessanti

Comportamenti emergenti

Rendere i nemici più “intelligenti”:

● Avvicinamento convincente● Capacità di evitare gli attacchi● Non rimanere bloccati dietro ostacoli o nel paesaggio● Movimento fluido● Evitare comportamenti “robotici”

Comportamenti emergenti

Soluzioni:

● Behaviour trees?● Flocking behaviours?● Reti neurali?● Forse meglio partire da un approccio semplice…

○ Physics based○ Un unico movimento base: reach point○ Guidato da una FSM○ Meccanismo di evitamento

Comportamenti emergenti

Risultato finale:

● Difficile veder finire una partita senza almeno una parolaccia

○ Good job!

Resa estetica

● Effetti di post processo○ Fondamentali per la resa

estetica○ Molti sono inadatti alla VR

■ Avvengono in screen space

Resa estetica

● Stereoscopia:

I post processi avvengono qui

Resa estetica

● Necessari molti esperimenti:○ Esclusi

■ Nebbia volumetrica■ Ambient occlusion■ Tilt shift■ ...

○ Utilizzati■ Antialiasing■ Bloom

Resa estetica

Ottimizzazioni

● Questione di applicare fin dall’inizio alcune best practices

○ Pooling per evitare instanziazione○ Paradigma 90/10

■ Problema “a thousand updates”■ Gestione dei cicli

○ I test, anche su macchine relativamente low end, hanno dato risultati incoraggianti

“Debolezze” di Unity da conoscere ed aggirare

Ottimizzazioni

● Pooling degli oggetti○ Istanziazione di un nuovo oggetto: operazione dispendiosa○ Ondate di centinaia di nemici in contemporanea○ Pool di nemici istanziati in startup

■ Offscreen■ Diverse categorie■ Configurabili■ Un manager che ne gestisce il ciclo di vita

Ottimizzazioni

● “A thousand updates” (https://blogs.unity3d.com/2015/12/23/1k-update-calls/)

○ Unity si basa sul paradigma entità/componenti○ Ogni componente possiede vari “hook”

■ Alcuni, come Update(), vengono richiamati ad ogni ciclo

OverheadChiamata Update()

Ottimizzazioni

● “A thousand updates”○ Con molti oggetti interattivi in contemporanea, l’overhead può essere

un grosso problema○ Soluzione:

■ Di nuovo il manager pattern● Un solo oggetto che abbia i riferimenti a tutti gli oggetti

di una categoria● Una chiamata ad Update()...● ...che aggiorna tutti gli oggetti in un ciclo

Ottimizzazioni

● Garbage collection e gestione dei cicli○ Unity scripting backend: Mono 2.6.5 (circa .NET 2.0)○ Gestione automatica della memoria e GC

■ GC non generazionale■ Ogni passaggio del GC causa fps hiccups

○ .NET possiede classi collection generiche molto utili■ List<>, Queue<>, Stack<>, Dictionary<>, …■ MA

■ L’utilizzo del pratico costrutto foreach su di essi genera garbage

● (bug di Mono 2.6.5)

Ottimizzazioni

● Garbage collection e gestione dei cicli○ Rimanendo nel paradigma 90/10 esistono due soluzioni

■ Utilizzare for al posto di foreach■ Riscrivere l’enumeratore per le classi interessate

Grazie a tutti per l’attenzione!