• Non ci sono risultati.

3.4 Client

4.1.2 Horde

Item. In tal modo, il codice degli oggetti utilizzabili come power-up è stato ridotto, evi-tando duplicazione di codice, che altrimenti avrebbe reso più probabile la presenza di bug.

La modalità di "consumazione" di un Item cambia in funzione del sistema di Mixed Reality:

a) Oculus Rift + Oculus Touch: l’utente "immerge" il controller nell’oggetto virtuale con cui vuole interagire e preme un apposito tasto.

b) HoloLens + Clicker: l’utente, che deve trovarsi al di sotto di una distanza predefinita, punta all’oggetto con lo sguardo e preme il tasto del clicker.

Medkit Uno degli elementi tipici dei videogiochi appartenenti al genere sparatutto, in particolare degli arena-shooter, è la presenza di Medkit, o oggetto analogo, che permette ai giocatori di rigenerare l’energia vitale. Nel gioco proposto i partecipanti possono trovare, distribuiti in tutta la mappa, dei Medkit opportunamente disposti dal designer.

Ammunition Alcuni videogiochi mettono a disposizione del giocatore armi con muni-zioni infinite, ma per il gioco qui discusso si è preferito dare al giocatore munimuni-zioni limitate, in modo da costringerlo a tenere conto di questo aspetto, e indurlo a esplorare l’ambiente alla ricerca di munizioni.

La classe Ammunition deriva da Item e implementa la funzione di ricarica della pistola.

Figura 4.2. I mostri alieni che i giocatori sono chiamati a distruggere.

Nel momento in cui l’Enemy è generato dall’ApplicationMode, se non sono presenti ostacoli nel percorso che lo porta fuori dal tunnel, esso si porta fuori dal tunnel e, da que-sto momento, può decidere se sparare a un target, o muoversi per evitare di essere colpito in un raggio prefissato a partire dal centro del tunnel. Sia la velocità di spostamento, che la distanza massima dal centro del tunnel sono parametri di creazione dell’Enemy.

Per far sì che due o più nemici non si sovrappongano durante gli spostamenti, per ogni cammino possibile, scelto in modo casuale, si fa un test di collisione per accertarsi che non ci siano altri oggetti sul percorso candidato; se il test ha esito positivo, nel percorso è disposto un collider, al fine di "occupare" quel volume che sarà attraversato dall’entità.

Tale operazione, così come la maggior parte dei calcoli per le altre entità, è effettuata sul server, in modo tale da ridurre il carico computazionale che i client devono sostenere.

Ondate e generazione dei nemici

Dopo alcuni secondi dall’inizio della sessione, l’ApplicationMode (o, più correttamente, classe Horde derivata da ApplicationMode) genera la prima ondata di nemici, nel pun-to specificapun-to dal designer al momenpun-to della costruzione della mappa di gioco. Per ogni ondata, il numero, la velocità e il raggio di azione dei nemici cambiano, aumentando la difficoltà man mano che i giocatori avanzano nel gioco.

Se un nuovo nemico deve essere generato, l’ApplicationMode fa un controllo che il tunnel sia libero; in caso positivo, genera l’Enemy, altrimenti attende un po’ prima di

eseguire nuovamente il controllo.

Quando un Enemy viene distrutto, l’ApplicationMode, che è in ascolto dei messaggi inviati dalle entità, riceve un messaggio di tipo DespawnMessage, che viene interpreta-to come entità distrutta. A quesinterpreta-to messaggio l’ApplicationMode determina se è stainterpreta-to distrutto l’ultimo nemico dell’ondata corrente e se deve generare una nuova ondata (o terminare la sessione se tutte le ondate sono state affrontate).

Indicatori delle ondate Al fine di guidare l’utente verso l’obiettivo, sono state poste sul pavimento delle frecce virtuali lampeggianti che indicano dove si trova il punto di generazione dell’ondata corrente (si veda la figura4.3).

Figura 4.3. Le frecce verdi, poste a 10 cm dal pavimento, indicano dove si trovano i nemici.

Caso d’uso e test

In questo capitolo sono discussi dettagliatamente il caso d’uso e i test condotti per valutare la validità del framework sviluppato nell’ambito della presente tesi. Si parte con la descri-zione del caso d’uso, quindi segue la presentadescri-zione dei test, giustificando le metodologie e discutendo, infine, i risultati ottenuti.

5.1 Finalità dei test

Lo scopo dei test è valutare diversi aspetti del framework e del videogioco sviluppato, con particolare attenzione rivolta a ciò che distingue le applicazioni AR/VR da quelle tradi-zionali, cioè l’interfaccia utente tridimensionale, il sistema di tracciamento e le modalità di interazione. Inoltre, poiché grande importanza riveste la funzionalità multiutente, si è ritenuto importante analizzare le variabili principali che caratterizzano le reti di calcolatori utilizzate, al fine di avere un quadro generale del sistema complessivo testato.

Altri aspetti del framework che si sarebbe voluto giudicare sono la semplicità nello sviluppo di un’applicazione, l’adattabilità a diversi tipi di applicazione, e la ricchezza di strumenti e funzioni offerti, ma ciò avrebbe richiesto l’esecuzione di test infattibili per un progetto di tale entità. Infatti, sarebbe stato necessario organizzare delle sessioni di sviluppo coinvolgendo un gruppo di programmatori e ingegneri informatici, a cui spiegare dettagliatamente la struttura del framework e le sue funzioni; quindi, ogni programmatore, dopo aver realizzato un’applicazione, avrebbe dovuto dare una valutazione del framework.

A causa del tempo richiesto da test di tale portata, ci si è limitati a valutare gli altri aspetti precedentemente indicati.

Metodologia

Poiché una misurazione quantitativa diretta della bontà del framework e dell’applicazione realizzata non è possibile per molte delle caratteristiche di interesse, uno degli strumenti utilizzati per valutare il lavoro svolto per questa tesi è il questionario; per valutare l’in-terfaccia utente e le modalità di interazione, ma anche l’aspetto sociale dell’esperienza, o

la capacità dell’applicazione di raggiungere il suo obiettivo1, ai tester sono state poste un certo numero di domande che toccano gli aspetti citati e non solo.

Gli aspetti che, al contrario, si prestano per misurazioni quantitative, sono stati valutati raccogliendo dati oggettivi nel corso dei test. Tra questi possiamo citare il funzionamento del sistema di tracciamento e la dinamica e l’approccio al gioco degli utenti.

Un sistema di tracciamento è caratterizzato principalmente dalla precisione della stima della posizione, dalla robustezza e dal volume dell’area in cui è possibile muoversi. È possibile che, in condizioni particolari, un sistema di tracciamento non sia più in grado di stabilire dove si trovi l’oggetto tracciato, a ciò ci si riferisce con l’espressione di perdita del tracciamento2. Quando ciò accade può essere utile sapere dove si trovava l’utente e in quale direzione stesse guardando; inoltre, sarebbe interessante sapere anche quanto tempo è impiegato dal sistema di tracciamento per recuperare dallo stato di inattività.

Tra i dispositivi testati, che saranno discussi più avanti, l’HoloLens è quello che pre-senta maggiori criticità in un contesto come quello qui discusso, in quanto il dispositivo non è stato progettato per scenari in cui l’utilizzatore deve allontanarsi per oltre 5 metri dall’origine della scena virtuale. Al fine di studiare la robustezza del sistema di traccia-mento di HoloLens, sono stati raccolti i dati di posizione e orientatraccia-mento dell’utente e il tempo necessario affinché il sistema di tracciamento fosse di nuovo in grado di tracciare correttamente l’utente.

Infine, per quanto riguarda la dinamica e l’approccio al gioco dei partecipanti, si è pensato di raccogliere i dati sulla posizione nell’area di gioco in ogni istante, al fine di capire da cosa i tester fossero attratti; ad esempio, dai tracciati degli spostamenti (si vedano le figure5.2e5.3), è possibile capire se i partecipanti utilizzano gli item disponibili (Medkit e munizioni), o anche dove tendono a posizionarsi in relazione ai nemici.

Documenti correlati