UNIVERSITÀ DEGLI STUDI DI TRENTO
FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALI
Corso di Laurea Triennale in INFORMATICA
Elaborato Finale
SVILUPPO DI UN SERIOUS GAME PER LA SCUOLA
DI BASE CON IMPIEGO DI WIIMOTE
QUALE NUOVA METAFORA D’INTERAZIONE
Relatore:
prof. Alberto Montresor
Correlatori: dott. Raffaele de Amicis
dott. Gabrio Girardi
Candidato:
Silvia Bordin
ANNO ACCADEMICO
2008 - 2009
2
Indice
1
Introduzione
1
2
Motivazioni e riferimenti teorici
4
2.1 Perché un serious game? . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2 Digital natives e digital immigrants . . . . . . . . . . . . . . . . . .
6
2.3 Efficacia dei videogames per l’apprendimento: la sperimentazione DANT 6
3
Il controller Wii Remote
4
Strumenti di sviluppo: Unity3D
4.1 Caratteristiche principali di Unity3D . . . . . . . . . . . . . . . . . .
4.2 Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Il plugin UniWii . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 Funzioni impiegate . . . . . . . . . . . . . . . . . . . . . . .
4.3 Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Glossario . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.2 Funzioni principali . . . . . . . . . . . . . . . . . . . . . . .
4.3.3 Differenze tra C# e JavaScript . . . . . . . . . . . . . . . . .
4.3.4 Istruzione yield . . . . . . . . . . . . . . . . . . . . . . . .
4.3.5 Coroutines . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.6 Compilazione degli script e comunicazione fra linguaggi diversi
14
15
15
16
17
19
19
20
20
21
22
24
5
Storyboard
5.1 Le novità introdotte . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Storyboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Il primo microgame . . . . . . . . . . . . . . . . . . . . . . .
5.2.2 Il secondo microgame . . . . . . . . . . . . . . . . . . . . .
5.2.3 Il terzo microgame . . . . . . . . . . . . . . . . . . . . . . .
5.2.4 Il quarto microgame . . . . . . . . . . . . . . . . . . . . . .
5.2.5 Il quinto microgame . . . . . . . . . . . . . . . . . . . . . .
5.3 Gestione del movimento della pallina a partire dai dati letti dal WiiMote
26
26
27
32
33
34
35
36
38
8
i
6
Activity diagrams
40
7
Difficoltà incontrate
7.1 UniWii non supporta la Balance Board . . . . . . . . . . . . . . . . .
7.2 Unitron non prevede debugger . . . . . . . . . . . . . . . . . . . . .
7.3 Scarsa documentazione tecnica reperibile per WiiMote . . . . . . . .
52
52
53
53
8
Sviluppi possibili
8.1 Sviluppi tecnici . . . . . . . . . . . . . . . . . . .
8.1.1 Il multiplayer . . . . . . . . . . . . . . . .
8.1.2 Versione per dispositivo mobile . . . . . .
8.2 Sviluppi contenutistici . . . . . . . . . . . . . . .
8.2.1 Struttura flessibile . . . . . . . . . . . . .
8.2.2 Raccolta statistiche . . . . . . . . . . . . .
8.3 Sviluppi metodologici: questionario di valutazione
55
55
55
56
56
56
57
57
9
Nota conclusiva
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
58
Bibliografia
58
ii
Capitolo 1
Introduzione
Questa tesi è il risultato dell’ampliamento e dell’approfondimento di quanto appreso e sperimentato durante lo stage presso la Fondazione GraphiTech di Trento. Tale
opportunità mi ha permesso di accostarmi alle realizzazioni nell’ambito della computer
graphics del gruppo di lavoro della stessa azienda; il mio percorso è quindi approdato
alla costruzione di un prototipo di serious game rivolto agli alunni della scuola di base.
L’impiego dei videogiochi nell’ambito formativo ed educativo, non solo ludico, è
sempre più esteso e specializzato: la parola chiave che spiega questo crescente successo è edutainment, un neologismo anglosassone che fonde i due termini educational ed
entertainment: imparare giocando. Numerose sperimentazioni e ricerche hanno dimostrato che il learning e il play possono fondersi attraverso le tecnologie dando vita ad
un circolo virtuoso in cui ci si diverte imparando e si impara divertendosi.
Naturalmente, accanto agli entusiasti dei serious games ci sono coloro che, invece, ne sottolineano gli aspetti negativi (riduzione dell’istruzione ad intrattenimento,
disattenzione e disorientamento cognitivo): molti studi, comunque, rilevano che ormai
l’approccio alla conoscenza dei digital natives – non lineare, simultaneo, iconico –
non può prescindere dai videogiochi. Il problema è come collocare nel contesto scolastico, strutturato piuttosto per un tipo di apprendimento tendenzialmente frontale e
riproduttivo, il videogioco, identificando quali stimoli susciti e quali specifiche abilità
consenta di esercitare meglio di altri strumenti.
1
Oggi la letteratura sull’apprendimento tramite videogiochi è ricca e varia e molti
sono stati i lavori di ricerca sperimentale condotti in diversi ambiti, da quello militare
a quello della finanza, della scienza, delle attività produttive, delle relazioni sociali,
della scuola.
In questa tesi mi soffermo su un segmento di quest’ultimo settore, quello della
scuola primaria: dopo alcuni brevi riferimenti teorici sulle ragioni pedagogiche e didattiche dell’impiego dei serious games, riassumo i contenuti e i risultati del progetto
dell’IPRASE di Trento denominato “DANT”, una sperimentazione curricolare durata
quattro anni, attentamente monitorata e validata, che ha visto un gruppo di ricercatori
realizzare dei videogiochi bidimensionali che hanno contribuito a migliorare le conoscenze matematiche e linguistiche dei bambini della scuola primaria.
Passo quindi a sottolineare gli aspetti tecnici e le novità del prototipo che ho costruito: un serious game tridimensionale con utilizzo di WiiMote in sostituzione di
mouse e tastiera. Scopo del gioco, intitolato L’isola di Wii, è far correre una biglia
lungo un percorso che si snoda in un’isola e risolvere i microgames di argomento matematico in cui ci si imbatte lungo tale percorso.
L’ultima sezione della tesi ipotizza quali sviluppi tecnici e metodologici si potrebbero apportare a L’isola di Wii: dalla sperimentazione sul campo ad una maggiore
configurabilità dei microgames.
2
Ho scelto di sviluppare un videogioco da proporre in ambito scolastico in seguito
ad uno stimolante colloquio con il prof. Romano Nesler, coordinatore del progetto
DANT, e con alcuni insegnanti della scuola primaria che avevano utilizzato in classe i
videogiochi.
Dopo aver letto il rapporto sull’attività di ricerca e sperimentazione del progetto
DANT e la convincente presentazione del prof. Antinucci – studioso molto critico nei
confronti del tradizionale modo di apprendere su cui si fonda la scuola ed autore di un
testo dal titolo eloquente, La scuola si è rotta [21] –, ho chiesto ad alcune maestre un
parere su questa nuova modalità di insegnamento / apprendimento: queste sono state
concordi nel sottolineare l’efficacia dei giochi da loro utilizzati, sia per consolidare
nell’alunno concetti già trattati, sia nell’apprendimento per scoperta, cioè come primo
approccio ai contenuti. Mi hanno inoltre riferito che i bambini si esercitavano volentieri anche a casa con i giochi proposti e consideravano le lezioni con il computer come
un vero e proprio premio, un’ora di divertimento.
Il prof. Nesler, in base alle sue esperienze e ai risultati delle sue indagini, mi ha indirizzato nella scelta della disciplina su cui impostare il nuovo gioco, la matematica, e
sui contenuti da privilegiare: calcolo mentale rapido, calcolo scritto, tavola pitagorica,
addizioni e sottrazioni.
3
Capitolo 2
Motivazioni e riferimenti teorici
2.1
Perché un serious game?
Durante il mio tirocinio presso la Fondazione GraphiTech ho avuto modo di entrare
in contatto con alcune ricostruzioni virtuali di beni culturali ed archeologici: in particolare, il team di GraphiTech ha lavorato al progetto NETConnect [1], che ha coinvolto
diverse università europee con l’obiettivo di promuovere il patrimonio culturale ed artistico attraverso la ricostruzione virtuale di tre importanti siti archeologici presenti in
Italia, Germania e Polonia.
Ho potuto constatare che per realizzare progetti di questo tipo è necessaria la collaborazione interdisciplinare di figure professionali diverse, dallo storico all’archeologo,
dall’informatico all’esperto di pedagogia e di didattica. Il prodotto finale, oltre che il
risultato di una riuscita integrazione di diversi linguaggi e tecnologie, è un ottimo mezzo di divulgazione culturale.
Questa esperienza, che ha immediatamente suscitato il mio interesse, mi ha dato l’opportunità di ampliare le mie conoscenze sulle ricostruzioni virtuali di ambienti
storici ed artistici: consultando vari siti ed articoli sul tema, ho notato che spesso, per
avvicinare i giovani all’apprendimento dell’arte e della storia, si ricorre ai videogiochi,
una forma di comunicazione ludica a loro particolarmente gradita e congeniale (The
forbidden city sviluppato da IBM [2], Rome Reborn sviluppato dall’Università della
Virginia [3], Travel in Europe promosso dall’Unione Europea [4], VeGame a cura dell’Università di Genova [5]).
La diffusione dei serious games come strumento di apprendimento è giustificata
da varie ragioni: il gioco è un’attività coinvolgente e motivante, accresce sia la com-
4
petizione che la collaborazione tra pari e può migliorare lo sviluppo di alcune abilità,
soprattutto nella generazione dei digital natives.
5
2.2
Digital natives e digital immigrants
La fortunata espressione digital natives, coniata da Marc Prensky [35], indica la
prima generazione interamente digitale, che padroneggia come una lingua madre il linguaggio del computer, di Internet, dei telefoni cellulari; essa, esposta fin dall’infanzia
ad un apprendimento visivo ed iconico in cui la qualità della grafica riduce l’importanza del testo, ha modalità di apprendimento diverse da quelle dei digital immigrants,
cioè di coloro che hanno appreso in età adulta ad utilizzare tecnologie digitali e sulle
quali hanno trasferito il loro atteggiamento ancora “gutenberghiano” [6].
Questi ultimi apprendono in modo sequenziale, privilegiano il testo scritto e considerano le immagini un corollario, stampano i documenti digitali per revisionarli, telefonano al destinatario della mail per avere conferma della ricezione. I digital natives,
invece, apprendono le informazioni da fonti multiple, hanno sviluppata una naturale
propensione per processi definiti “multitasking”, ovvero svolgono più attività contemporaneamente (ad esempio, mentre rispondono al cellulare fanno zapping con la TV e
nello stesso tempo sono attivi in una chat); hanno più attenzione per l’immagine che
per il testo scritto, imparano ad usare un software istintivamente e senza leggerne prima il manuale di istruzioni [35].
Risulta evidente la distanza tra i sistemi di apprendimento tradizionali e quelli delle nuove generazioni; si spiega altresı̀ perché i serious games siano considerati da
molti pedagogisti strumenti innovativi congeniali allo stile di apprendimento dei digital natives e, quindi, siano utilizzati anche a scuola, all’interno delle normali attività
didattiche.
2.3
Efficacia dei videogames per l’apprendimento: la
sperimentazione DANT
Il progetto DANT (Didattica Assistita dalle Nuove Tecnologie), rivolto soprattutto
alla scuola primaria e promosso dall’IPRASE del Trentino, è stato realizzato da un
gruppo di docenti coordinato dal prof. Romano Nesler con la supervisione scientifica
del prof. Francesco Antinucci dell’Istituto di Scienze e Tecnologie della Cognizione
del CNR di Roma.
La ricerca ha preso l’avvio da quanto emerso nel VI rapporto del Comitato di Valutazione del sistema scolastico trentino: nel 2001 il 20% degli alunni trentini usciva
dalla scuola primaria con carenze nei contenuti fondanti della matematica e dell’italiano. Attraverso la sperimentazione DANT si è voluto dimostrare che l’utilizzo di
6
videogiochi a supporto della didattica ordinaria aumenta la motivazione degli alunni e
le loro prestazioni.
Il progetto DANT, condotto dall’anno scolastico 2001/02 all’anno scolastico
2004/05, ha coinvolto 1865 docenti e 35000 alunni in tutto il territorio nazionale ed
ha prodotto 101 giochi relativi a varie materie. Tali giochi, sperimentati per almeno
tre anni, hanno subito numerose revisioni in base ai suggerimenti e alle proposte dei
docenti sperimentatori. Essi sono tutti disponibili sul sito dell’IPRASE [7]: si possono
scaricare gratuitamente (versione per Windows), oppure fruire direttamente (versione
per browser); entrambe le versioni del software sono realizzate a partire dallo stesso
codice sorgente Flash. Ad ogni gioco è associata una scheda informativa che ne riporta
il titolo, una breve descrizione della dinamica di funzionamento, il contenuto, l’età del
bambino a cui è rivolto, le possibilità di configurazione e note tecniche.
Per la metodologia utilizzata dal gruppo degli sperimentatori (circa trenta persone:
esperti di grafica, comunicazione, tecnologie e molti insegnanti) rinvio alla dettagliata
esposizione del prof. Nesler contenuta nel rapporto sul quadriennio della sperimentazione DANT [34].
Il monitoraggio sulla sperimentazione ha prodotto una notevole quantità di dati riguardanti l’efficacia dei giochi, le modalità di utilizzo da parte dei docenti e i risultati
ottenuti [34]. Tali dati hanno confermato le due ipotesi fondanti del progetto: i serious games sono capaci di migliorare i risultati di apprendimento e di aumentare la
motivazione degli alunni.
Per questo il progetto DANT da attività di tipo sperimentale è diventato prassi
didattica quotidiana. I giochi si sono rapidamente diffusi dall’ambiente scolastico ad
altri contesti e cosı̀ sono diventati risorse per la comunità educante nel suo complesso
e non solo per la scuola in sé [34].
7
Capitolo 3
Il controller Wii Remote
Una delle componenti che differenzia L’isola di Wii dagli altri serious games presi
in esame durante la fase di ricognizione dello stato dell’arte è l’impiego del controller
Wii Remote (altrimenti detto WiiMote) come metafora d’interazione.
Figura 3.1: La console Nintendo Wii
8
Il WiiMote è il controller principale per la console Nintendo Wii. La caratteristica
più innovativa del dispositivo è la sua capacità di rilevare i movimenti grazie all’impiego di un accelerometro a tre assi, in grado di misurare le accelerazioni lungo ciascuno
degli assi cartesiani; unitamente al design simile a quello di un telecomando, questa
feature rende l’esperienza di gioco tramite WiiMote più intuitiva e coinvolgente, in
quanto si richiede al giocatore di simulare effettivamente dei gesti anziché limitarsi a
premere dei pulsanti. L’utente, dunque, sperimenta immersivamente il gioco in prima
persona, invece di osservare semplicemente il movimento del proprio personaggio.
Figura 3.2: Il controller WiiMote
9
Figura 3.3: Il controller WiiMote all’interno
10
Il WiiMote è anche in grado di rilevare le rotazioni lungo i tre assi cartesiani, come
illustrato in figura 3.4. Il controller presenta inoltre vari pulsanti e ha la possibilità di
vibrare in corrispondenza di particolari azioni.
Figura 3.4: Assi e rotazioni del WiiMote
11
Le capacità del WiiMote non si limitano però al solo “motion sensing”: il controller, infatti, comprende anche un sensore ottico che, insieme alla cosiddetta Sensor
Bar, ne consente l’uso anche come dispositivo di puntamento. La Sensor Bar presenta
cinque Led a ciascuna estremità e va posizionata sopra o sotto lo schermo verso cui
punterà il WiiMote. Il sensore a infrarossi integrato nel WiiMote è in grado di rilevare
la luminosità dei Led e di calcolare, a partire da essa, a quale distanza il controller
stesso si trovi rispetto alla Sensor Bar e di quanto esso sia ruotato rispetto al terreno;
ciò consente quindi un puntamento efficace.
Figura 3.5: La Sensor Bar
Il WiiMote prevede inoltre una porta di espansione alla quale possono essere collegati diversi devices aggiuntivi, in modo da estendere le funzionalità del controller. È
utile citare il Nunchuk , in quanto è l’espansione di default, nonché quella utilizzata in
L’isola di Wii: si tratta di un controller più piccolo ed ovoidale, provvisto di un joystick
analogico, due pulsanti e un accelerometro analogo a quello del WiiMote. Il Nunchuk
completa il controller principale, permettendo al giocatore di utilizzare entrambe le
mani per interagire con i giochi per Wii.
12
Figura 3.6: L’espansione Nunchuk
Più avanti, nel paragrafo 7.1, verrà menzionata anche la Wii Balance Board , un’estensione del tutto simile ad una bilancia pesapersone che, contenendo quattro sensori di pressione, può essere utilizzata per rilevare baricentro e peso del giocatore e
controllare dunque le azioni di gioco tramite gli spostamenti corporei.
Figura 3.7: La Wii Balance Board
13
Capitolo 4
Strumenti di sviluppo: Unity3D
Unity3D [8] è un game development tool multipiattaforma per lo sviluppo di contenuti 3D interattivi, quali videogames, ricostruzioni di ambienti o animazioni. Come
i più diffusi game engines (quali Torque, per citare uno dei più celebri), prevede un
ambiente grafico integrato che costituisce il mezzo principale attraverso il quale realizzare il design del gioco.
Figura 4.1: Il logo di Unity3D
La prima versione di Unity3D risale al giugno 2005 ed era funzionante unicamente su sistema operativo Mac OS. Nel corso degli anni sono state rilasciate versioni
compatibili anche con Windows, fino a giungere alla versione 2.5, che è quella da me
impiegata nella realizzazione di questo progetto: essa, in base al tipo di licenza acquistata, è in grado di sviluppare videogames per Mac OS X, Windows (XP e Vista),
browser, Wii ed iPhone.
14
4.1
Caratteristiche principali di Unity3D
• Unity3D prevede, come detto sopra, un editor grafico, i cui componenti principali sono un property inspector gerarchico (da cui è possibile modificare facilmente, e soprattutto tramite drag-and-drop, le proprietà degli oggetti inseriti
nelle varie scene) e una finestra di preview del gioco;
• i programmi sviluppati con Unity3D sono fruibili da numerose piattaforme e
browser;
• è possibile importare facilmente modelli tridimensionali realizzati con i più comuni applicativi dedicati, quali Maya, 3DStudio Max, Blender;
• gli Assets, ossia i files e risorse che costituiscono un progetto, vengono automaticamente importati ed aggiornati sia che vengano modificati internamente che
esternamente all’editor;
• il motore grafico può utilizzare sia DirectX che OpenGL che API proprietarie,
garantendo cosı̀ il funzionamento dei software sviluppati sul maggior numero
possibile di sistemi operativi e schede grafiche;
• la fisica è gestita automaticamente dal physics engine PhysX [9], sviluppato da
Ageia ed ora acquisito da Nvidia;
• Unity3D consente la creazione di script in C#, JavaScript e Boo: i tre linguaggi
vengono indifferentemente compilati in codice nativo di rapida esecuzione. I
tre linguaggi sfruttano tutti un’implementazione open source della piattaforma
.NET, Mono [10].
4.2
Plugins
Esistono vari tipi di licenza per Unity3D: alcuni sono dedicati allo sviluppo per
particolari piattaforme, come iPhone o Nintendo Wii, ma i due principali [11] sono
relativi allo sviluppo di applicativi per Mac e Windows. Unity Indie è la versione “base”, con la quale è comunque possibile realizzare videogames di tutto rispetto; alcuni
aspetti avanzati, però, come il supporto per plugins scritti in C, C++, Objective C, richiedono invece l’utilizzo della licenza Unity Pro. Questo è anche il caso di L’isola di
Wii, che è dunque stato realizzato proprio sotto quest’ultimo tipo di licenza in quanto
la comunicazione con il WiiMote avviene tramite un plugin.
I plugins devono essere copiati all’interno di una directory dedicata (Assets/Plugins), che contiene anche la maggior parte degli script. Includendo sia il file .bundle
15
che il file .dll per uno stesso plugin, Unity3D si occupa automaticamente di scegliere
il plugin adatto alla piattaforma su cui si sta correntemente eseguendo l’applicativo
(rispettivamente Mac OS X o Windows): la realizzazione di software cross-platform è
dunque molto semplice.
Quando le funzioni offerte dal plugin devono essere impiegate all’interno di uno
script in C#, è necessario dichiararle esplicitamente all’inizio del file:
Listing 4.1: Dichiarazione di funzioni offerte da plugins esterni
1
2
[ DllImport ( ' ' PluginName ' ' ) ]
p r i v a t e s t a t i c e x t e r n v o i d PluginFunction ( ) ;
4.2.1
Il plugin UniWii
UniWii [12] è il plugin per Unity3D che ho impiegato per realizzare la comunicazione con il WiiMote. Inizialmente disponibile solo per Mac e recentemente sviluppato
anche per Windows, UniWii si appoggia al framework DarwiinRemote [13] per connettere via Bluetooth il controller al computer e leggere da esso i dati di movimento
rilevati; il plugin espone poi un’interfaccia che consente di manipolare facilmente tali
dati.
DarwiinRemote è basato su un modello event-driven, ma Unity3D non è in grado di rilevare eventi che accadano al di fuori dell’engine stesso: la lettura di dati dal
WiiMote, dunque, è effettuata tramite polling. In particolare, le funzioni rese disponibili dall’interfaccia vengono sempre chiamate all’interno di metodi quali Update()
o OnTriggerStay(), che per loro natura vengono eseguiti ciclicamente.
UniWii supporta gli accelerometri e i pulsanti sia del WiiMote che del Nunchuk,
oltre ai sensori a infrarossi e alla vibrazione: non è però in grado di gestire la Balance
Board.
Da prove preventivamente eseguite in GraphiTech, inoltre, è emerso che il funzionamento di UniWii con la Sensor Bar presenta delle fastidiose pecche: ad esempio,
succede che la direzione del movimento rilevata si inverta improvvisamente. Abbiamo ritenuto, quindi, di sfruttare piuttosto il Nunchuk per ottenere un puntamento più
preciso.
In generale, comunque, anche i dati che UniWii riporta dagli accelerometri sono
ancora imprecisi: ad esempio, non è stato possibile riuscire a distinguere un movimento orizzontale da uno verticale tramite la sola lettura dei dati relativi al WiiMote.
16
Questo ha inevitabilmente posto delle limitazioni alla gestualità rilevabile e quindi alle
tipologie di microgames implementabili.
4.2.2
Funzioni impiegate
Segue una descrizione delle funzioni offerte da UniWii impiegate in L’isola di Wii.
Listing 4.2: Funzioni di avvio e spegnimento dei WiiMote
1
2
3
4
5
[ DllImport ( ' ' UniWii ' ' ) ]
p r i v a t e s t a t i c e x t e r n v o i d wiimote_start ( ) ;
[ DllImport ( ' ' UniWii ' ' ) ]
p r i v a t e s t a t i c e x t e r n v o i d wiimote_stop ( ) ;
La prima funzione rileva i WiiMote accesi e si occupa di instaurare la connessione
Bluetooth fra essi e il computer; la seconda spegne i WiiMote al termine del gioco.
Listing 4.3: Calcolo del numero di WiiMote
1
2
[ DllImport ( ' ' UniWii ' ' ) ]
p r i v a t e s t a t i c e x t e r n i n t wiimote_count ( ) ;
Restituisce il numero di WiiMote rilevati e connessi.
Listing 4.4: Rilevamento espansioni
1
2
[ DllImport ( ' ' UniWii ' ' ) ]
p r i v a t e s t a t i c e x t e r n b o o l wiimote_isExpansionPortEnabled ( i n t which ) ;
Restituisce true se il WiiMote individuato dall’indice passato come parametro ha un’espansione (un Nunchuk) collegata alla propria porta.
Listing 4.5: Lettura dei dati forniti dall’accelerometro di un WiiMote
1
2
3
4
5
6
7
8
[ DllImport ( ' ' UniWii ' ' ) ]
p r i v a t e s t a t i c e x t e r n b y t e wiimote_getAccX ( i n t which ) ;
[ DllImport ( ' ' UniWii ' ' ) ]
p r i v a t e s t a t i c e x t e r n b y t e wiimote_getAccY ( i n t which ) ;
[ DllImport ( ' ' UniWii ' ' ) ]
p r i v a t e s t a t i c e x t e r n b y t e wiimote_getAccZ ( i n t which ) ;
Rilevano il valore registrato dall’accelerometro di un dato WiiMote lungo un certo asse
cartesiano.
17
Listing 4.6: Lettura del roll
1
2
[ DllImport ( ' ' UniWii ' ' ) ]
p r i v a t e s t a t i c e x t e r n f l o a t wiimote_getRoll ( i n t which ) ;
Rileva il valore di roll (cioè l’oscillazione lungo l’asse Y) di un dato WiiMote.
Listing 4.7: Lettura dei valori ottenuti dalla leva del Nunchuk
1
2
3
4
5
[ DllImport ( ' ' UniWii ' ' ) ]
p r i v a t e s t a t i c e x t e r n b y t e wiimote_getNunchuckStickX ( i n t which ) ;
[ DllImport ( ' ' UniWii ' ' ) ]
p r i v a t e s t a t i c e x t e r n b y t e wiimote_getNunchuckStickY ( i n t which ) ;
Rileva i valori di spostamento della leva del Nunchuk collegato ad un dato WiiMote.
Listing 4.8: Lettura degli accelerometri di un Nunchuk
1
2
[ DllImport ( ' ' UniWii ' ' ) ]
p r i v a t e s t a t i c e x t e r n b y t e wiimote_getNunchuckAccZ ( i n t which ) ;
Rileva il valore che l’accelerometro contenuto nel Nunchuk collegato ad un dato WiiMote legge lungo l’asse Z (verticale).
Listing 4.9: Rilevamento della pressione dei pulsanti di un WiiMote
1
2
3
4
5
6
7
8
9
10
11
[ DllImport ( ' ' UniWii ' ' ) ]
p r i v a t e s t a t i c e x t e r n b y t e wiimote_getButtonA ( i n t which ) ;
[ DllImport ( ' ' UniWii ' ' ) ]
p r i v a t e s t a t i c e x t e r n b y t e wiimote_getButtonPlus ( i n t which ) ;
[ DllImport ( ' ' UniWii ' ' ) ]
p r i v a t e s t a t i c e x t e r n b y t e wiimote_getButtonMinus ( i n t which ) ;
[ DllImport ( ' ' UniWii ' ' ) ]
p r i v a t e s t a t i c e x t e r n b y t e wiimote_getButtonHome ( i n t which ) ;
Restituiscono true fintantoché il pulsante considerato di un dato WiiMote resta premuto.
Listing 4.10: Rilevamento della pressione dei pulsanti di un Nunchuk
1
2
[ DllImport ( ' ' UniWii ' ' ) ]
p r i v a t e s t a t i c e x t e r n b o o l wiimote_getButtonNunchuckZ ( i n t which ) ;
Restituisce true finché il pulsante Z del Nunchuk collegato ad un dato WiiMote resta
premuto.
18
4.3
Scripting
Come accennato in 4.1, Unity3D supporta la creazione di script in tre linguaggi
diversi: C#, JavaScript e Boo. Durante lo sviluppo del progetto, ho impiegato principalmente C#; JavaScript è stato invece riservato alla gestione delle coroutines, come
verrà spiegato più dettagliatamente in seguito (paragrafo 4.3.5).
4.3.1
Glossario
Introduciamo innanzitutto un breve glossario che illustra la terminologia di base
riguardante Unity3D.
• MonoBehaviour: classe base da cui ereditano tutti gli script, in qualsiasi linguaggio essi siano scritti.
• GameObject: classe base per tutti gli oggetti che compaiono in una scena; consente l’accesso a proprietà comuni come la posizione, la rotazione,
i Components associati.
• Component: un qualunque oggetto “figlio” di un GameObject, cioè associato
ad esso: quindi, un Component è anche un GameObject, ma un GameObject che
funge da root di una gerarchia di oggetti non è un Component.
• Rigidbody: Component che si occupa della gestione della fisica applicata al
GameObject cui è associato.
• Collider: componente che fa sı̀ che il GameObject cui è associato rilevi le collisioni con altri corpi. Esso prevede una proprietà detta IsTrigger: se questa
è impostata a true, le collisioni non vengono più rilevate dal rigidbody, bensı̀
generano tre tipi di messaggio:
OnTriggerEnter: generato quando un Collider entra nel trigger;
OnTriggerStay: generato una volta per ogni frame fintantoché un Collider permane all’interno del trigger;
OnTriggerExit: generato all’uscita di un Collider dal trigger;
tali messaggi vengono ricevuti da funzioni dedicate eventualmente presenti negli
script associati ai due GameObject coinvolti nella collisione.
Ciascuno script, per funzionare, dev’essere associato come Component ad un
GameObject.
19
4.3.2
Funzioni principali
Vediamo ora le principali funzioni di cui è previsto l’override in uno script Unity3D:
• Start(): comprende tutte le azioni di inizializzazione che devono essere compiute al momento del caricamento dello script e comunque prima che la funzione
Update() venga chiamata per la prima volta;
• Update(): funzione che viene automaticamente chiamata all’inizio di ogni
frame e che dunque contiene la maggior parte del codice;
• OnGUI(): funzione che viene anch’essa chiamata automaticamente all’inizio
di ogni frame e che si occupa di gestire gli eventi e gli oggetti relativi alla GUI;
• OnTriggerEnter(): quando un Collider entra nel trigger che circonda un
GameObject, tale funzione viene chiamata sia nello script associato al GameObject che ha generato la collisione sia nello script associato al
GameObject che è stato urtato;
• OnTriggerStay(): questa funzione viene chiamata automaticamente una
volta per ogni frame fintantoché un Collider rimane nel trigger che circonda un
GameObject; essa viene invocata sia nello script associato al GameObject che ha
generato la collisione sia nello script associato al GameObject che è stato urtato;
• OnTriggerExit(): quando un Collider esce dal trigger che circonda un
GameObject, tale funzione viene chiamata sia nello script associato al GameObject che ha generato la collisione sia nello script associato al GameObject che
è stato urtato.
4.3.3
Differenze tra C# e JavaScript
Le differenze salienti tra tali due linguaggi sono le seguenti:
• Ereditarietà da MonoBehaviour: MonoBehaviour è la classe base da cui
tutti gli script devono ereditare. In JavaScript l’ereditarietà è implicita, mentre
in C# dev’essere specificata esplicitamente.
Listing 4.11: Ereditarietà esplicita in C#
1
2
3
4
p u b l i c c l a s s StarScript : MonoBehaviour
{
// ...
}
20
• Inizializzazione: ogni script in JavaScript è una raccolta di variabili e funzioni,
mentre ciascuno script in C# costituisce invece una classe a sé stante. Pertanto,
il codice di inizializzazione va posto al di fuori di tutte le funzioni in JavaScript,
in Start() o Awake() nel caso di C#.
Listing 4.12: Inizializzazione in C#
1
2
3
4
5
6
7
8
v o i d Start ( ) {
wiimote_start ( ) ;
/ / a v v i a l a c o n n e s s i o n e con i l WiiMote
fader = GameObject . Find ( ” F a d i n g S c r i p t ” ) ;
DontDestroyOnLoad ( fader ) ;
/ / i m p e d i s c e che l ' o g g e t t o i n c a r i c a t o d i a p p l i c a r e i l f a d i n g
/ / venga d i s t r u t t o d u r a n t e i l c a r i c a m e n t o d e l l i v e l l o s u c c e s s i v o
}
• Nome del file: in C#, ogni classe dev’essere rinominata manualmente con lo
stesso identificativo del file che la contiene.
• Diversa sintassi delle coroutines: in C#, una coroutine deve avere IEnumerator
come tipo di ritorno e dev’essere esplicitamente avviata, come vedremo più
dettagliatamente in seguito.
4.3.4
Istruzione yield
Di per sé, Unity3D presuppone che il comportamento di un oggetto venga descritto frame per frame. Si consideri, ad esempio, la funzione principale di ogni script,
cioè Update(): essa viene richiamata una volta per ciascun frame. In alcuni casi,
però, può essere necessario descrivere un comportamento lungo un arco di tempo che
occupa vari frame: diventa allora conveniente impiegare l’istruzione yield. Si tratta
di un tipo particolare di istruzione return, che fa in modo che la funzione di cui fa
parte riprenda la propria esecuzione dall’istruzione successiva a quella di yield la
prossima volta che è richiamata.
Un utilizzo particolare di yield prevede l’introduzione di WaitForSeconds(),
istruzione che ritarda l’esecuzione di Update() di un numero di secondi passati
come parametro ad essa.
Listing 4.13: Utilizzo di WaitForSeconds()
1
yield WaitForSeconds ( 2 . 0 ) ; / / s o s p e n d e l ' e s e c u z i o n e p e r due s e c o n d i
Yield può essere impiegata in due modi:
• avvia un thread parallelo, ma continua immediatamente l’esecuzione della funzione chiamante;
21
Listing 4.14: Thread parallelo che non sospende l’esecuzione principale (JavaScript)
1
2
3
4
5
6
7
8
9
10
11
12
13
print ( ” Tempo d i i n i z i o : ” + Time . time ) ;
WaitAndPrint ( ) ;
print ( ” C o n c l u s i o n e : ” + Time . time ) ;
f u n c t i o n WaitAndPrint ( ) {
yield WaitForSeconds ( 2 . 0 ) ; / / s o s p e n d e l ' e s e c u z i o n e p e r due s e c o n d i
print ( ” W a i t A n d P r i n t : ” + Time . time ) ;
}
//
//
//
//
l ' output e ` i l seguente :
Tempo d i i n i z i o : 0 . 0
Conclusione : 0.0
WaitAndPrint : 2.0
• avvia un thread figlio e ne attende la terminazione prima di riprendere l’esecuzione della funzione principale.
Listing 4.15: Thread parallelo di cui si attende la terminazione (JavaScript)
1
2
3
4
5
6
7
8
9
10
11
12
13
4.3.5
print ( ” Tempo d i i n i z i o : ” + Time . time ) ;
yield WaitAndPrint ( ) ; / / n o t a r e l ' u s o d i y i e l d
print ( ” C o n c l u s i o n e : ” + Time . time ) ;
f u n c t i o n WaitAndPrint ( ) {
yield WaitForSeconds ( 2 . 0 ) ; / / s o s p e n d e l ' e s e c u z i o n e p e r due s e c o n d i
print ( ” W a i t A n d P r i n t : ” + Time . time ) ;
}
//
//
//
//
l ' output e ` i l seguente :
Tempo d i i n i z i o : 0 . 0
WaitAndPrint : 2.0
Conclusione : 2.0
Coroutines
L’impiego delle coroutines, la cui esecuzione può essere sospesa in qualsiasi momento proprio da un’istruzione yield, è diverso in JavaScript e C#. Ad esempio, nel
primo linguaggio l’avvio delle coroutines è eseguito implicitamente dal compilatore,
mentre in C# è necessario chiamare esplicitamente l’istruzione StartCoroutine:
tale funzione ritorna immediatamente, ma è possibile passare il suo risultato all’istruzione yield per attendere la terminazione della coroutine prima di proseguire con
l’esecuzione della funzione principale. Ecco infatti come si presentano gli esempi
precedenti in C# anziché in JavaScript:
22
Listing 4.16: Thread parallelo di cui si attende la terminazione (C#)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
v o i d Start ( ) {
print ( ” I n i z i o : ” + Time . time ) ;
StartCoroutine ( WaitAndPrint ( ) ) ;
print ( ” C o n c l u s i o n e : ” + Time . time ) ;
}
IEnumerator WaitAndPrint ( ) {
yield r e t u r n new WaitForSeconds ( 2 . 0 ) ;
print ( ” W a i t A n d P r i n t : ” + Time . time ) ;
}
//
//
//
//
l ' output e ` i l seguente :
Tempo d i i n i z i o : 0 . 0
Conclusione : 0.0
WaitAndPrint : 2.0
Listing 4.17: Thread parallelo che non sospende l’esecuzione principale (C#)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
IEnumerator Start ( ) { / / i l t i p o d i r i t o r n o non \ `{ e } p i \ `{ u} v o i d
print ( ” I n i z i o : ” + Time . time ) ;
yield r e t u r n StartCoroutine ( WaitAndPrint ( ) ) ; / / n o t a r e l ' u s o d i y i e l d r e t u r n
print ( ” C o n c l u s i o n e : ” + Time . time ) ;
}
IEnumerator WaitAndPrint ( ) {
yield r e t u r n new WaitForSeconds ( 2 . 0 ) ;
print ( ” W a i t A n d P r i n t : ” + Time . time ) ;
}
//
//
//
//
l ' output e ` i l seguente :
Tempo d i i n i z i o : 0 . 0
WaitAndPrint : 2.0
Conclusione : 2.0
La gestione delle coroutines e l’impiego dell’istruzione yield sono risultati piuttosto macchinosi in C#, soprattutto perché una coroutine non può essere avviata dall’interno di Update() ed è invece necessario chiamare un’altra funzione, il cui tipo
di ritorno dev’essere IEnumerator, che contenga a sua volta l’istruzione di yield.
Ho ritenuto perciò opportuno realizzare in JavaScript tutti gli script in cui era necesario sospendere l’esecuzione di una funzione, come per gli effetti di fading o per il
movimento di comparsa e scomparsa degli animali nel terzo microgame.
Listing 4.18: Fade in
1
2
3
4
5
6
7
f u n c t i o n fadeIn ( ) {
f o r ( i = 0 . 0 ; i<=1.0; i + = 0 . 0 1 ) {
alpha = 1.0 −i ;
yield ;
}
alpha = 0 . 0 ;
}
23
4.3.6
Compilazione degli script e comunicazione fra linguaggi diversi
Tutti gli script, in qualunque linguaggio (C#, JavaScript, Boo) siano scritti, vengono compilati da Unity3D in librerie .dll di .NET: tali librerie vengono poi a loro volta
compilate just-in-time a runtime. Ciò consente un’esecuzione degli script notevolmente rapida.
Gli script che vengono compilati per primi sono quelli contenuti nella cartella Plugins, seguiti da quelli che si trovano al di fuori di essa (nel caso di L’isola di Wii, in
OtherScripts). Gli script di quest’ultimo tipo hanno accesso a quelli che si trovano in
Plugins, ma non viceversa.
Questa caratteristica torna utile qualora si voglia realizzare la comunicazione fra
script di linguaggi diversi. Consideriamo, ad esempio, FadeInOutScript, dedicato a realizzare gli effetti di fading tra una scena e l’altra e ad eseguire, nel frattempo,
le operazioni di caricamento e setup dei vari livelli: esso è scritto in JavaScript e si
trova nella cartella OtherScripts. È allora possibile che un’istruzione come la seguente
venga eseguita correttamente:
Listing 4.19: Comunicazione da JavaScript verso C#
1
v a r sbs = pallina . GetComponent ( ” S p h e r e B e h a v i o u r S c r i p t ” ) ;
Nell’esempio precedente, SphereBehaviourScript è uno script in C# collocato
nella cartella Plugins, dedicato a gestire il movimento della biglia.
Un caso particolare di comunicazione fra script è quello in cui sono coinvolti script
associati allo stesso GameObject, indipendentemente dal linguaggio in cui essi sono
scritti. Esiste infatti la possibilità di inviare un messaggio in broadcast, passando come
primo parametro una stringa; il messaggio verrà ricevuto da tutti gli script associati
al GameObject, che eseguiranno la funzione eventualmente presente in essi avente lo
stesso nome della stringa parametro. Vediamo un esempio tratto dal quinto microgame,
in cui l’utente deve inserire l’operatore mancante in un’addizione o sottrazione:
Listing 4.20: Comunicazione tramite messaggi
1
SendMessage ( ” w i i m o t e ” ) ;
L’istruzione descritta nel listato 4.20 fa parte di OperatorScript: tale script è
scritto in C# e il codice in esso contenuto rileva il sollevamento del WiiMote e del
Nunchuk e associa a tali movimenti rispettivamente un “+” o un “-”. Associati allo
stesso GameObject, ci sono altri due script:
24
• GUIistrQuintoGiocoScript, che contiene il codice per la realizzazione
delle schermate di inizio e fine del microgame;
• GUIQuintoScript, che contiene invece il codice per la realizzazione della
GUI del microgame vero e proprio.
GUIistrQuintoGiocoScript non contiene una funzione chiamata wiimote()
e dunque ignora il messaggio ricevuto da OperatorScript. GUIQuintoScript,
invece, contiene la seguente funzione:
Listing 4.21: Comunicazione tramite messaggi
1
2
3
4
5
6
7
f u n c t i o n wiimote ( ) {
i f ( ! imp )
{
imp = t r u e ;
cambiaOperatore ( 1 ) ;
}
}
Essa, sostanzialmente, imposta la GUI in modo da inserire un “+” nell’operazione visualizzata.
SendMessage può anche accettare più di un parametro: il primo resta sempre il nome della funzione da chiamare, gli altri diventano i parametri da passare a
quest’ultima.
25
Capitolo 5
Storyboard
5.1
Le novità introdotte
Come detto a pagina 1, lo sviluppo della presente tesi è iniziato durante il mio periodo di tirocinio presso GraphiTech. La Fondazione utilizza abitualmente Unity3D
per la realizzazione di ricostruzioni tridimensionali: è stato quindi naturale pensare
da subito L’isola di Wii in ottica 3D. L’impiego del WiiMote quale nuova metafora
d’interazione ha costituito poi un ulteriore elemento di innovazione: la maggior parte
dei serious games presi in esame, infatti, presenta una grafica bidimensionale, adatta
soprattutto alla fruizione via web; inoltre, la metafora d’interazione è solitamente rappresentata dalla combinazione di mouse e tastiera, e ciò consente un coinvolgimento
indubbiamente più limitato di quello ottenibile tramite il WiiMote.
26
5.2
Storyboard
Una volta avviato L’isola di Wii, la prima schermata che compare invita l’utente ad
assicurare correttamente il laccio del WiiMote intorno al proprio polso e a premere i
pulsanti “1” e “2” posti sul controller stesso.
Figura 5.1: La schermata di avvio
27
Quando i due pulsanti vengono premuti contemporaneamente, i Led del WiiMote
iniziano a lampeggiare e la connessione Bluetooth con il computer viene avviata. Una
volta che la connessione è instaurata, viene verificato che il Nunchuk sia collegato al
WiiMote: se l’estensione è presente, viene chiesto all’utente di premere il pulsante “A
” per proseguire, altrimenti viene visualizzato un messaggio informativo.
Figura 5.2: Connessione avvenuta
28
Compare ora una nuova schermata, dalla quale è possibile scegliere il colore della
biglia che costituirà poi l’avatar dell’utente durante tutto il gioco. L’utente può scegliere una fra le tre textures disponibili premendo rispettivamente “- ”, “Home ” o “+
”: quando viene premuto uno di questi pulsanti, la texture corrispondente viene evidenziata. L’utente può quindi iniziare effettivamente il gioco premendo il pulsante “A
”.
Figura 5.3: La scelta della texture per la biglia
29
La scena successiva è ambientata su di un’isola, lungo la quale si snoda una pista
tracciata sul terreno: il giocatore deve far rotolare la propria biglia attraverso tale pista,
imprimendo il movimento e la rotazione tramite gesti effettuati con il WiiMote.
Figura 5.4: L’isola
30
Lungo il percorso si trovano alcuni hot spots: quando la biglia entra in contatto
con uno di essi, viene caricato un microgame; l’utente visualizza le istruzioni relative
e preme il pulsante “A”, posto sul WiiMote, per iniziare a giocare.
Figura 5.5: Un hot spot
31
5.2.1
Il primo microgame
Su di un prato sono sparse alcune coppie di funghi, ad ognuna delle quali è associata un’addizione; ogni volta che scade un timer, la distribuzione dei funghetti sul
terreno cambia. Il giocatore sposta la propria pallina sul prato muovendo la leva del
Nunchuk: quando la pallina si avvicina ad una coppia di funghetti, questa viene evidenziata applicandovi una texture di colore verde acceso e l’addizione ad essa associata viene mostrata su di un’etichetta apposita. Se il risultato dell’operazione è 10,
il giocatore deve avvicinare ancora di più la pallina ai funghetti fino a urtarli e quindi
“raccoglierli”: altrimenti, deve evitarli. Se il giocatore urta i funghetti, questi scompaiono; se se ne allontana, essi riprendono il colore rosso originale e l’etichetta che
mostra l’addizione ad essi associata viene nascosta.
Il giocatore guadagna dei punti se raccoglie i funghetti per i quali l’addizione associata dà come risultato 10, mentre ne perde se raccoglie gli altri. Il microgame termina
con un messaggio quando sono state raccolte tutte le coppie di funghetti che danno un
punteggio positivo; il giocatore preme allora il pulsante “A ” posto sul WiiMote per
tornare all’isola.
Figura 5.6: Il primo microgame
32
5.2.2
Il secondo microgame
L’ambientazione è un laghetto in cui nuotano dei polipi: per ogni round, al giocatore viene proposta un’addizione da risolvere. Simulando con il WiiMote il lancio
di una lenza, il giocatore deve muovere la propria pallina come se questa fosse un
galleggiante tramite il Nunchuk, fino ad avvicinarsi ad uno dei polipi: l’animaletto si
evidenzia in giallo e comincia a ruotare vorticosamente su se stesso. Il giocatore deve
allora “pescarlo ” traendo a sé il WiiMote; quando ritiene di aver pescato tanti polipi
quanti indicati dal risultato dell’operazione proposta, deve premere il pulsante “Z ”
posto sul Nunchuk. Se il risultato è effettivamente corretto, il giocatore guadagna dei
punti, altrimenti subisce una penalità.
Viene generata una nuova operazione da risolvere ogni volta che il pulsante “Z ”
viene premuto, fino a quando non sono stati completati tutti i round previsti. A quel
punto compare un messaggio conclusivo e l’utente può ritornare all’isola premendo il
pulsante “A ” sul proprio WiiMote.
Figura 5.7: Il secondo microgame
33
5.2.3
Il terzo microgame
In un orto sbucano dal terreno vari animaletti, ad ognuno dei quali corrisponde un
numero. Il giocatore muove un mirino tramite il Nunchuk e lo posiziona sull’animaletto contrassegnato dal numero 0; l’animaletto inizia a tremare e l’utente deve “colpirlo
”, simulando con il WiiMote un colpo di martello, prima che esso si ritiri di nuovo
sotto terra o che il numero che lo etichetta cambi. Scopo del microgame è colpire gli
animaletti secondo un ordinamento crescente, da quello cui è associato il numero 0 a
quello cui è associato il numero 9; colpire l’animaletto corretto secondo l’ordinamento
fa guadagnare dei punti al giocatore e distrugge l’animaletto in questione, colpirne uno
non corretto applica una penalità.
Il gioco termina quando tutti gli animaletti sono stati colpiti (e distrutti): anche qui,
compare un messaggio conclusivo e l’utente può ritornare all’isola premendo “A ” sul
proprio WiiMote.
Figura 5.8: Il terzo microgame
34
5.2.4
Il quarto microgame
All’inizio del microgame, al giocatore viene assegnato un certo fattore. Utilizzando il Nunchuk, il concorrente muove la propria biglia all’interno di un labirinto.
Lungo il percorso, si imbatterà in varie stelle, ognuna etichettata con un numero: il
giocatore dovrà “saltare ” (avvicinandosi alle stelle e sollevando contemporaneamente
WiiMote e Nunchuk) solo in corrispondenza delle stelle etichettate con un multiplo del
fattore assegnatogli in precedenza, pena la perdita di alcuni punti. Il giocatore dovrà
cercare di raccogliere il maggior numero possibile di stelle contrassegnate da un multiplo del fattore assegnatogli prima di raggiungere l’uscita: a questo punto, al giocatore
verrà assegnato un bonus ed egli potrà ritornare all’isola premendo il pulsante “A ” sul
proprio WiiMote.
Figura 5.9: Il quarto microgame
35
5.2.5
Il quinto microgame
Il concorrente deve cercare di inserire l’operatore mancante nel maggior numero
possibile di operazioni presentate. In ciascuna operazione, il giocatore può inserire
un “+ ” sollevando il WiiMote, un “- ” sollevando il Nunchuk. Se l’operatore inserito è quello corretto, il giocatore guadagna dei punti; altrimenti, l’operazione viene
evidenziata in rosso e il punteggio viene decrementato.
Il microgame termina allo scadere del conto alla rovescia, cioè dopo trenta secondi.
Figura 5.10: Il quinto microgame
36
Al termine di quest’ultimo microgame, compare una schermata conclusiva di congratulazioni; premendo il pulsante “A ” sul WiiMote, si esce dall’applicazione.
Figura 5.11: Il messaggio conclusivo
37
5.3
Gestione del movimento della pallina a partire dai
dati letti dal WiiMote
Di seguito, un frammento di codice posto in SphereBehaviourScript: esso
è dedicato al rilevamento dei dati letti dal WiiMote e alla loro conversione in forze da
applicare alla biglia per muoverla lungo il percorso.
Listing 5.1: Gestione del movimento della pallina a partire dai dati letti dal WiiMote
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
v o i d FixedUpdate ( ) / / f u n z i o n e i n v o c a t a ad o g n i frame , ma con un f r a m e r a t e f i s s o
{
i n t c = wiimote_count ( ) ; / / c o n t a i WiiMote c o l l e g a t i
i f ( c > 0 ) / / s e vengono r i l e v a t i d e i WiiMote
{
f o r ( i n t i = 0 ; i <= c − 1 ; i++)
/ / c i c l a s u i WiiMote ( i l c o d i c e e ' a d a t t a b i l e a m u l t i p l a y e r )
{
i f ( IsWiimoteActive ( ) )
{
/ / WIIMOTE
/ / r i l e v a l ' a c c e l e r a z i o n e lungo l ' asse Y
y = wiimote_getAccY ( i ) ;
/ / r i l e v a l a r o t a z i o n e lungo l ' asse Y
f l o a t roll = Mathf . Round ( wiimote_getRoll ( i ) ) ;
i f ( y > X11_JUMP )
/ / s e l ' a c c e l e r a z i o n e l u n g o Y e ' s u p e r i o r e ad una c e r t a s o g l i a
{
i f ( y > maxy ) maxy = y ;
}
i f ( maxy > y )
/ / s e i l v a l o r e a p p e n a l e t t o e ' un p i c c o
/ / ( un movimento v e r s o l ' a l t o e ' r a p p r e s e n t a b i l e come un ' onda
/ / d a l p u n t o d i v i s t a d e l l ' a c c e l e r a z i o n e l u n g o Y)
{
f l o a t val = CalcComponent ( X11_JUMP , X12_JUMP , X21_JUMP , X22_JUMP ,
maxy ) ;
/ / i l valore di picco viene scalato ;
/ / dal r i s u l t a t o s i r i ca v a n o l e componenti d e l l a f o r z a
/ / da a p p l i c a r e a l l a b i g l i a p e r m u o v e r l a i n a v a n t i
V e c t o r 3 f = new V e c t o r 3 ( Mathf . Sin ( transform . rotation . eulerAngles .
y * Mathf . Deg2Rad ) * val , 0 , Mathf . Cos ( transform . rotation .
eulerAngles . y * Mathf . Deg2Rad ) * val ) ;
rigidbody . AddForce ( f ) ;
maxy = −1000;
}
i f ( roll >= X11_RIGHT && roll <= X12_RIGHT )
{
/ / i l WiiMote e ' r u o t a t o v e r s o d e s t r a
rotationX +=
CalcComponent ( X11_RIGHT , X12_RIGHT , X21_RIGHT , X22_RIGHT ,
roll ) ;
rotationX = ClampAngle ( rotationX , −360F , 360F ) ;
/ / i l valore l e t t o viene scalato
Quaternion xQuaternion =
Quaternion . AngleAxis ( rotationX , V e c t o r 3 . up ) ;
transform . localRotation = originalRotation * xQuaternion ;
38
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
Freccia . transform . localRotation = originalRotation * xQuaternion ;
/ / la rotazione viene applicata sia a l l a b i g l i a
/ / c h e a l l a f r e c c i a c h e ne i n d i c a l ' o r i e n t a m e n t o
}
e l s e i f ( roll >= X11_LEFT && roll <= X12_LEFT )
{
/ / i l WiiMote e ' r u o t a t o v e r s o s i n i s t r a
rotationX +=
CalcComponent ( X11_LEFT , X12_LEFT , X21_LEFT , X22_LEFT , roll ) ;
rotationX = ClampAngle ( rotationX , −360F , 360F ) ;
/ / i l valore l e t t o viene scalato
Quaternion xQuaternion =
Quaternion . AngleAxis ( rotationX , V e c t o r 3 . up ) ;
transform . localRotation = originalRotation * xQuaternion ;
Freccia . transform . localRotation = originalRotation * xQuaternion ;
/ / la rotazione viene applicata sia a l l a b i g l i a
/ / c h e a l l a f r e c c i a c h e ne i n d i c a l ' o r i e n t a m e n t o
}
}
/ / NUNCHUCK
i f ( IsNunchuckActive ( ) )
{
/ / a l l ' i n t e r n o d i a l c u n i m i c r o g a m e s devono e s s e r e r i c h i a m a t e
/ / f u n z i o n i a u s i l i a r i e c h e g e s t i s c o n o i l movimento d e l l a b i g l i a
/ / i n b a s e a i d a t i l e t t i d a l Nunchuk
i f ( IsFirstMicrogame ( ) ) First ( i ) ;
e l s e i f ( IsSecondMicrogame ( ) ) Second ( i ) ;
e l s e i f ( IsFourthMicrogame ( ) ) Fourth ( i ) ;
}
}
}
}
39
Capitolo 6
Activity diagrams
Di seguito, gli activity diagrams che descrivono le fasi di setup e movimento e i
microgames.
40
Figura 6.1: Connessione del WiiMote e selezione del colore da assegnare alla biglia - parte 1
41
Figura 6.2: Connessione del WiiMote e selezione del colore da assegnare alla biglia - parte 2
42
Figura 6.3: Conversione dei gesti eseguiti con WiiMote in movimento della biglia
43
Figura 6.4: Esempio di caricamento di un microgame
44
Figura 6.5: Il primo microgame
45
Figura 6.6: Il secondo microgame - parte 1
46
Figura 6.7: Il secondo microgame - parte 2
47
Figura 6.8: Il secondo microgame - parte 3
48
Figura 6.9: Il terzo microgame
49
Figura 6.10: Il quarto microgame
50
Figura 6.11: Il quinto microgame
51
Capitolo 7
Difficoltà incontrate
7.1
UniWii non supporta la Balance Board
Come detto sopra, nel paragrafo 4.2.1, il plugin UniWii non prevede il supporto per
estensioni diverse dal Nunchuk e dunque non è in grado di gestire la Balance Board.
All’inizio dello sviluppo del progetto, però, abbiamo lungamente tentato di aggirare
questo inconveniente.
WiimoteLib [14] è una libreria in C# sviluppata da Brian Peek; essa rileva e gestisce sia il WiiMote che le sue varie estensioni (Nunchuk, Classic Controller, chitarra e
batteria per Guitar Hero e cosı̀ via), tra cui appunto la Balance Board.
Compilata sotto Visual Studio 2008, la libreria funzionava perfettamente ed offriva
numerose funzioni di interfaccia. Il mio tutor mi ha dunque suggerito di compilare la
libreria e copiare il risultante file .dll all’interno del progetto in Unity3D: la .dll avrebbe quindi dovuto occuparsi esternamente di gestire la comunicazione con il WiiMote
e le sue estensioni, riportando poi a Unity3D solo i valori rilevati, in modo del tutto
trasparente all’applicazione.
Sfortunatamente, l’operazione non è andata a buon fine. WiimoteLib fa transitare la comunicazione verso il WiiMote su di un file stream: proprio sull’apertura
di tale oggetto Unity3D generava un’eccezione, impedendo cosı̀ l’instaurarsi della
comunicazione con il controller.
Dopo un lungo e attento lavoro di debugging, sono giunta alla conclusione che le
piattaforme .NET, su cui si appoggia Visual Studio 2008, e Mono [10], su cui invece
si appoggia Unity3D, gestiscano i file stream in maniera differente. Ho ugualmente
approfondito lo studio del caso, informandomi su come Mono trattasse i file stream a
livello di codice (questo è stato reso possibile dal fatto che Mono sia una piattaforma
open source). Ho tentato di scrivere un’implementazione personalizzata della classe
52
File Stream da far utilizzare a Unity3D e che prevedesse solo le azioni che mi sarebbero state effettivamente utili nella comunicazione con il WiiMote; man mano che
proseguivo nel lavoro, però, diventava chiaro che l’onere sarebbe stato eccessivamente
gravoso e che soprattutto mi avrebbe distolta completamente dallo sviluppo di L’isola
di Wii, che restava invece il mio obiettivo principale e per me più interessante.
In conclusione, ho deciso di rinunciare a sfruttare la Balance Board e di realizzare l’interazione con il serious game solo tramite WiiMote e Nunchuk, sfruttando le
funzionalità offerte da UniWii.
7.2
Unitron non prevede debugger
L’editor che Unity3D fornisce di default si chiama Unitron ed è davvero spartano:
prevede il syntax highlighting ma non l’indentazione automatica e l’autocompletion
è poco maneggevole. La problematica principale è però il fatto che Unitron, essendo
poco più che un editor di testo, non comprende un debugger: essendo io abituata a
lavorare in NetBeans, questa mi è sembrata una forte limitazione.
Va detto che Unity3D consente comunque di specificare il proprio editor esterno
preferito, sostituendolo a Unitron: mentre sviluppavo il progetto sotto Windows, ho
infatti utilizzato SharpDevelop [15]; gran parte del progetto, però, è stata sviluppata
sotto Mac OS, piattaforma per la quale, al momento, non sembrano essere disponibili
editor gratuiti per C#: in questa situazione, Unitron era una scelta obbligata.
7.3
Scarsa documentazione tecnica reperibile per WiiMote
La documentazione tecnica disponibile per il WiiMote è poca e difficilmente reperibile: non sono riuscita a trovare, nemmeno sul sito di Nintendo, informazioni
pubbliche riguardanti il funzionamento del controller (come delle indicazioni circa
i valori letti dall’accelerometro). Suppongo che questo dipenda dal fatto che l’azienda
è molto restrittiva nel concedere l’autorizzazione allo sviluppo di giochi per Wii, e che
di conseguenza non ritenga necessario divulgare le specifiche del controller o della
console.
È stato quindi necessario dedicare un periodo di studio alle caratteristiche del WiiMote, prima di iniziare lo sviluppo effettivo de L’isola di Wii. In particolare, sono stati
realizzati dei piccoli progetti di testing atti a capire i valori che UniWii trasmetteva
53
a Unity3D in corrispondenza dei vari gesti compiuti con il WiiMote (in verticale, in
orizzontale, le rotazioni lungo i vari assi).
Fra le cose interessanti emerse, è risultato che UniWii riceve dall’accelerometro gli
stessi valori sia per un gesto compiuto in orizzontale che per uno compiuto in verticale.
Questo ha comportato una riprogettazione del quinto microgame: inizialmente, infatti,
avevo pensato che il giocatore avrebbe potuto inserire l’operatore mancante tracciando
in aria con il WiiMote un “+ ” o un “- ”. Dato però che i gesti da compiere sarebbero risultati indistinguibili, ho deciso piuttosto di effettuare l’inserimento di ciascun
operatore in corrispondenza del sollevamento del WiiMote o del Nunchuk.
54
Capitolo 8
Sviluppi possibili
Il prototipo realizzato si presta a varie possibilità di miglioramento ed evoluzione, sia da un punto di vista contenutistico che tecnico. Ne espongo alcune, anche
alla luce di quanto emerso dai colloqui con il prof. Nesler e dalle rilevazioni della
sperimentazione DANT.
8.1
8.1.1
Sviluppi tecnici
Il multiplayer
Un tipico esempio dell’impiego di UniWii, descritto anche nella pagina web dedicata al plugin [12], è il seguente:
Listing 8.1: Utilizzo di UniWii
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
using
using
using
using
UnityEngine ;
System ;
System . Collections ;
System . Runtime . InteropServices ;
p u b l i c c l a s s UniWiiCheck : MonoBehaviour {
[ DllImport ( ” UniWii ” ) ]
p r i v a t e s t a t i c e x t e r n v o i d wiimote_start ( ) ;
[ DllImport ( ” UniWii ” ) ]
p r i v a t e s t a t i c e x t e r n v o i d wiimote_stop ( ) ;
[ DllImport ( ” UniWii ” ) ]
p r i v a t e s t a t i c e x t e r n i n t wiimote_count ( ) ;
p r i v a t e String display ;
v o i d OnGUI ( ) {
i n t c = wiimote_count ( ) ;
55
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
i f ( c>0) {
display = ” ” ;
f o r ( i n t i = 0 ; i<=c−1; i++) {
display += ” Wiimote ” + i + ” f o u n d ! \ n ” ;
}
}
e l s e display = ” P r e s s t h e ' 1 ' and ' 2 ' b u t t o n s on y o u r Wii Remote . ” ;
GUI . Label ( new Rect ( 1 0 , Screen . height−100 , 5 0 0 , 1 0 0 ) , display ) ;
}
v o i d Start ( )
{
wiimote_start ( ) ;
}
v o i d OnApplicationQuit ( ) {
wiimote_stop ( ) ;
}
}
Il codice riportato in 8.1 rileva i controller attivi e, ad ogni frame, stampa su GUI una
stringa per ciascun WiiMote individuato.
Si noti come il ciclo for predisponga già il codice del prototipo ad essere modificato per offrire anche la possibilità di un gioco multiplayer. UniWii, infatti, è in grado
di gestire vari WiiMote, contrassegnandoli ognuno con un indice: tutte le funzioni che
fanno parte della libreria e che rilevano i dati da un controller richiedono quindi come
parametro proprio l’indice che lo caratterizza.
8.1.2
Versione per dispositivo mobile
Unity3D consente anche di realizzare progetti per iPhone: tale piattaforma è versatile ed accattivante nell’interazione, e sarebbe dunque interessante realizzare una
versione di L’isola di Wii anche per essa. Sarebbe cosı̀ possibile confrontare il grado
di interazione e coinvolgimento ottenuto con iPhone e con WiiMote.
8.2
8.2.1
Sviluppi contenutistici
Struttura flessibile
Innanzitutto, il gioco può essere esteso con l’inserimento di altri microgames, non
necessariamente di argomento matematico. Una prospettiva stimolante, a mio avviso,
è quella di costituire una raccolta di microgames multidisciplinari, tramite i quali il
bambino possa esercitarsi nelle varie materie pur sfruttando un’unica piattaforma.
56
Un ulteriore vantaggio dell’avere una struttura modulare e variabile è quello di poter mantenere alta l’attenzione e la motivazione anche in giocatori ormai “esperti” e,
nel contempo, evitare che i principianti siano frustrati da esercizi di difficoltà superiore
al livello delle abilità fino ad allora possedute.
8.2.2
Raccolta statistiche
Agli insegnanti che intendano utilizzare L’isola di Wii nella scuola di base potrebbe essere utile configurare il livello di difficoltà dei microgames o il tempo massimo
da dedicare a ciascun gioco, e poi registrare il tempo di utilizzo globale e quello effettivamente impiegato per risolvere ciascun gioco; l’analisi di questi dati potrebbe
aiutarli ad individuare gli argomenti non ben assimilati dagli alunni e a calibrare meglio gli interventi di recupero da effettuare. (Questo punto era già stato evidenziato
dai questionari di valutazione della sperimentazione DANT). L’isola di Wii, o una sua
versione estesa, potrebbe dunque trovare applicazione nel consolidamento, a scuola o
a casa, delle abilità di calcolo elementare.
8.3
Sviluppi metodologici: questionario di valutazione
Per garantire validità scientifica al lavoro e capire efficacemente in quali punti migliorarlo, sarebbe necessario sottoporre il software ad un campione di allievi dei primi
anni della scuola di base e, attraverso un questionario, raccogliere opinioni, percezioni
e dati di apprendimento utili per migliorare il gioco e le sue modalità di utilizzo; in base ai risultati del questionario di valutazione, si potrebbe poi procedere alla revisione
del prototipo.
In sintesi, questi potrebbero essere gli ulteriori sviluppi de L’isola di Wii:
• ampliare gli ambiti disciplinari;
• rendere possibile la personalizzazione del contenuto da parte del docente;
• consentire la regolazione del livello di difficoltà da parte del giocatore;
• somministrare un questionario di valutazione.
57
Capitolo 9
Nota conclusiva
Ormai nessuno discute più sull’opportunit di utilizzare le TIC (Tecnologie dell’Informazione e della Comunicazione) a scuola: che il computer sia uno strumento utile
per l’apprendimento è un dato di fatto condiviso dagli esperti sia di pedagogia che di
didattica. Più dibattuta è invece la questione su quali materiali e strategie usare per
rendere più efficace e piacevole l’apprendimento mediato dalle TIC.
Con la realizzazione del prototipo de L’isola di Wii ritengo di aver dato un contributo a questa discussione, non solo documentando le fasi di realizzazione del gioco
in quanto prodotto software, ma anche mostrando alcune innovazioni introdotte dal
WiiMote, componente ancora poco esplorata nell’ambito dei serious games.
La fisicità espressa attraverso l’interazione con il WiiMote può offrire una marcia
in più per mantenere alto il livello di interesse e di coinvolgimento del bambino, che
può anche rischiare di annoiarsi quando ha utilizzato il gioco per un certo tempo. A
questo obiettivo è legata anche la scelta di realizzare un “contenitore” per microgames:
lo sviluppo di più giochi mi ha consentito di sperimentare l’impiego di varie gestualità, di capire quali fossero implementabili (per lo meno con il game development tool
utilizzato) e, fra queste, quali potessero attirare maggiormente l’attenzione dell’utente
e spingerlo a mettersi, per l’appunto, “in gioco”. Con il WiiMote anche un feedback
negativo può essere accolto simpaticamente e stimolare a riprovare il percorso del gioco con più entusiasmo, attenzione ed energia.
In conclusione, penso che il controller WiiMote potrà rivelarsi un mezzo per un apprendimento senso-motorio più persistente (nonché più coinvolgente) di quello simbolicoriproduttivo tipicamente sfruttato dai metodi di insegnamento pi tradizionali.
58
Bibliografia
[1] NETConnect project — http://www.netconnect-project.eu.
[2] The Forbidden City — http://www.beyondspaceandtime.org.
[3] Rome Reborn — http://www.romereborn.virginia.edu.
[4] Travel In Europe — http://www.tieproject.eu.
[5] VeGame — http://www.elios.dibe.unige.it/showroom/vegame/index.html.
[6] La scuola digitale — http://scuoladigitale.blogspot.com/.
[7] Giochi della sperimentazione DANT — http://www.iprase.tn.it/prodotti/software didattico/giochi
[8] Unity3D game development tool — http://unity3d.com.
[9] PhysX, physics engine — http://www.nvidia.it/object/nvidia physx it.html.
[10] Mono, framework open source per .NET — http://mono-project.com/Main Page.
[11] Licenze per Unity3D — http://unity3d.com/unity/licenses.
[12] UniWii plugin — http://www.unifycommunity.com/wiki/index.php?title=UniWii.
[13] Darwiin Remote — http://sourceforge.net/projects/darwiin-remote/.
[14] WiimoteLib — http://www.codeplex.com/WiimoteLib.
[15] SharpDevelop editor — http://www.icsharpcode.net/OpenSource/SD/.
[16] Wikipedia, Unity3D — http://en.wikipedia.org/wiki/Unity (game engine).
[17] Raccolta di giochi 3D per web browser realizzati con Unity3D —
http://www.wooglie.com/.
[18] Community degli utenti di Unity3D — http://www.unifycommunity.com.
59
[19] Forum degli utenti di Unity3D — http://forum.unity3d.com.
[20] Imparo
Giocando,
a
cura
http://www.iprase.tn.it/giocando.asp.
di
IPRASE
Trentino
—
[21] Francesco Antinucci. La scuola si è rotta. Perché cambiano i modi di apprendere.
Laterza, Roma, 2001.
[22] Antonio Calvani. Educazione, comunicazione e nuovi media. UTET, Torino,
2005.
[23] Antonio Calvani. Rete, comunità e conoscenza. Erickson, Trento, 2005.
[24] Antonio Calvani. Teorie dell’istruzione e carico cognitivo. Erickson, Trento,
2009.
[25] Anna Carletti e Andrea Varani, editor. Ambienti di apprendimento e nuove
tecnologie. Erickson, Trento, 2007.
[26] Guillaume Denis e Pierre Jouvelot. Motivation-driven educational game design:
applying best practices to music education. In Proc. Int. Conf. on Advances in
Computer Entertainment Technology. ACM Press, 2005.
[27] Paolo Ferri e Susanna Mantovani, editor. Digital kids. Fondazione IBM Italia,
Etas, Milano, 2008.
[28] Paolo Ferri. La scuola digitale. Bruno Mondadori, Milano, 2008.
[29] Jessie Herz. Il popolo del joystick. Feltrinelli, Milano, 1998.
[30] Rita Teso Italo Tanoni. Il curricolo tecnologico. Erickson, Trento, 2009.
[31] Gianpiero Lotito. Emigranti digitali. Bruno Mondadori, Milano, 2008.
[32] Roberto Maragliano. Joystick. Pedagogia e videogame.
Company Italia S.p.A., Milano, 2003.
The Walt Disney
[33] Romano Nesler, editor. Didattica assistita dalle nuove tecnologie. IPRASE
Trentino, Trento, 2004.
[34] Romano Nesler. Imparo giocando. Videogiochi e apprendimento. IPRASE
Trentino, Trento, 2007.
[35] Mark Prensky. Digital natives, digital immigrants. On the horizon, 9(5), 2001.
60
[36] Mark Prensky. Mamma non rompere, sto imparando! Multiplayer.it Edizioni,
Perugia, 2007.
[37] Kurt Squire.
Video games in education.
International
Journal
of
Intelligent
Simulations
and
Gaming,
2003.
http://www.cyberfest.us/Education/Video Games in Education-MIT Study.pdf.
[38] Italo Tanoni. Videogiocando si impara. Erickson, Trento, 2003.
61