Sono passati dieci anni tondi tondi da quando ho proposto al Cattid un sistema per realizzare simulazioni (ancora non si usava il termine “serious game"): i Learning Brick. Non un editor, ma qualcosa di diverso che possiamo chiamare “sistema", “framework" o “architettura".
Si tratta di:

• un insieme di moduli software (i brick, appunto) che come i mattoncini Lego possono essere riusati tutte le volte che serve;
• un modo di progettare e lavorare.

Quando si costruisce un serious game, un metodo efficace è quello che parte dagli obiettivi formativi, lasciando in secondo piano gli aspetti tecnici, per poi porsi alcune domande:

• Che tipo di mondo (simulato) vogliamo costruire? Qual è la sua storia? E quali le sue regole?
• Quali sono le forze in campo? E i personaggi?
• Quali sono i compiti del fruitore? Quale ruolo impersona?
• Cosa può fare (effettuare scelte, rispondere a domande, acquisire informazioni, muoversi in diversi ambienti, dialogare con i personaggi, ecc.)?
• A cosa è collegato il punteggio? O preferiamo costruire un profilo con molte variabili?

Dopo di che al progettista piace (o piacerebbe) dare per scontato che tecnicamente si può fare qualunque cosa. Sì, ma come?
Programmare tutto ex novo è fuori discussione, perché i costi e i tempi sarebbero proibitivi. E poi, scoprire ogni volta l’acqua calda non è una buona idea.
A questo tipo di esigenze, il mondo dell’e-learning ha risposto proponendo quasi solo “sistemi autore" sempre più raffinati ed efficaci, fino a Storyline che oggi è uno standard di fatto nel settore.
Ma efficaci per fare cosa? É questo il punto. Perché tutti i sistemi autore commerciali servono per produrre al meglio dei libri multimediali da “sfogliare" cliccando “avanti" e “indietro". Sono, in fondo, versioni raffinate di PowerPoint.
Ma le simulazioni sono un’altra cosa: non sono, o non sono sempre, narrazioni lineari. E nemmeno strutture ad albero, né ipertesti. Sono “mondi", sono storie interattive, sono sistemi complessi guidati da regole. Regole che di solito fanno parte degli obiettivi di apprendimento. Detto in un altro modo: il fruitore deve imparare dall’esperienza a muoversi in quel mondo, per fare in modo di raggiungere i suoi obiettivi.
Tutto questo non si può realizzare, se non al prezzo di compromessi inaccettabili, con un sistema autore che “ragiona" per pagine e implementa la metafora di una narrazione lineare.
In realtà, qualcosa di diverso è stato realizzato in alcuni progetti di ricerca. Sono editor, abbastanza facili da usare, che però consentono simulazioni sempre dello stesso tipo.
I Learning Brick seguono una filosofia radicalmente diversa, che si può descrivere con una nuova metafora: la creazione di mondo virtuale effettuata da un “architetto" che costruisce, con una sorta di Lego digitale, gli spazi e le regole per abitarli.
Spazi e regole che sono l’essenza di un serious game.

Come è fatto un serious game: spazi e regole

In un serious game, gli spazi sono immediatamente percepibili: ambienti grafici, che riproducono un luogo di vita o di lavoro (dagli uffici direzionali alla cabina di pilotaggio di un’astronave), popolati da un numero virtualmente illimitato di personaggi e altri oggetti interattivi.
Le regole definiscono:

• cosa può fare l’utente (passare da un ambiente all’altro, leggere documenti scritti, effettuare scelte, dialogare con i personaggi, vedere filmati, ascoltare elementi audio, rispondere a domande, inserire testi e via dicendo);
• come il sistema risponde alle sue azioni.

Tecnicamente, queste regole sono costruite attraverso due componenti:

• una serie di variabili (da poche unità a migliaia);
• un certo numero di istruzioni (scritte con un linguaggio di programmazione – ieri Action Script di Flash, oggi Javascript) che collegano le variabili con costrutti logico-matematici.

La principale caratteristica progettuale dell’architettura Learning Brick è che ogni oggetto che popola lo spazio è “agganciato" a una sola variabile. Modificando il valore di questa variabile cambiano lo stato dell’oggetto (per esempio, compare o scompare) e/o il suo comportamento (per esempio, se si tratta di un personaggio, parla).
In questo modo, un oggetto non dipende direttamente da nessun altro e questo consente di ridurre la complessità. Significa che è possibile aggiungere o togliere oggetti in modo relativamente “indolore".
In concreto, un oggetto della simulazione è costituito da:

• Un modulo software che ne definisce il tipo, e quindi a cosa serve e come funziona (sono questi i brick, ciascuno dei quali, tornando alla metafora, corrisponde a un tipo di mattoncino del Lego). I brick sono stati sviluppati una volta per tutte (si fa per dire: in realtà evolvono continuamente) e devono essere solo richiamati tutte le volte che servono.
• Un file esterno (di tipo “xml") che descrive lo specifico comportamento di quel determinato oggetto.

Esistono al momento una dozzina di brick differenti: Personaggio, Documento con informazioni e/o test, Immagine, Calendario, Orologio, Cruciverba, ecc. In più un modulo base gestisce automaticamente il tracciamento Scorm, i pulsanti per fermare e riprendere la simulazione, uscire, ricominciare da capo, ecc. più  diverse funzioni di servizio.

Costruire con i Learning Brick

I Learning Brick, a differenza dei sistemi autore, non consentono di sedersi davanti a un editor che fa tutto.
Possiamo considerarli, piuttosto, gli attrezzi di un banco di lavoro in cui il progettista è chiamato a un lavoro artigianale, quasi un bricolage. È un lavoro di montaggio che utilizza ampiamente parti “prefabbricate", ma lascia la più ampia libertà creativa.
La prima fase del lavoro è puramente progettuale e consiste nella stesura di uno storyboard, un documento che contiene:
una descrizione sintetica dello scenario e degli elementi salienti della storia;

• l’elenco degli ambienti di gioco (che riproducono uffici, laboratori, stanze, spazi aperti, ecc.);
• l’elenco dei personaggi delle loro caratteristiche;
• l’elenco dei documenti e dei loro contenuti;
• il ruolo del fruitore (chi è e quali sono i suoi obiettivi);
• la descrizione dei dialoghi;
• le possibili scelte dell’utente;
• le conseguenze di queste scelte (assegnazione di punti o penalità e reazioni dell’ambiente);
• la sequenza degli eventi (se ce n’è una).

Ne risulta un documento piuttosto lungo (anche decine di pagine) da far approvare al cliente.
La seconda fase del lavoro consiste nel trasformare lo storyboard in un learning object. Un lavoro in tre mosse.
Mossa uno: registrazione dei file audio (o video) e disegno degli ambienti dei personaggi, delle immagini, dei pulsanti e di tutte le componenti "visibili".
Mossa due: produzione di un certo numero di file "xml" che descrivono l’aspetto statico del sistema. Si fa "a mano" o, con gli oggetti più complessi, con un editor apposito.
Alcuni di questi file hanno carattere generale:

• la descrizione dell’ambiente di gioco;
• l’elenco delle variabili;
• l’elenco degli oggetti, indicando per ciascuno il tipo (Personaggio, Immagine, Documento, ecc.), la variabile a cui è agganciato, il collegamento tra valori della variabile e comportamenti, l’ambiente in cui compare, la sua posizione, ecc.

Gli altri file sono riferiti ciascuno a uno specifico oggetto e ne dettagliano il comportamento. Per esempio, quello relativo a un determinato personaggio definisce:

• L’elenco delle pose con cui si presenta (in piedi, seduto, a braccia conserte, a braccia aperte e chi più ne ha più ne metta).
• La sequenza di azioni che deve effettuare ogni volta che la variabile a cui è agganciato assume un certo valore. A sua volta, ogni azione comprende un file audio da attivare, una posa da assumere ed eventualmente un comando di comparsa, scomparsa o sposamento.

Mossa tre: stesura di un programma che descrive l’aspetto dinamico. In concreto, si tratta di definire come sono collegate le variabili tra loro e di impostare la sequenza degli eventi. Questa è l’unica parte del lavoro che richiede la conoscenza di un linguaggio di programmazione (oggi, come dicevo, è Javascript, l’unico che viene interpretato dai browser in modo diretto, senza richiedere l’installazione di plugin.
Per esempio, posso decidere che se aumenta il valore della variabile "prezzo" di un prodotto, cambia la variabile "soddisfazione" del cliente. E personaggio "cliente" il cui comportamento è agganciato a questa variabile, manifesterà la sua approvazione o dirà sdegnato "Questa roba non la comprerò mai più!"

Mi rendo conto che un esempio come questo rischia di banalizzare le cose.
Perché in realtà un serious game può essere tremendamente complicato, quando consentiamo al fruitore di effettuare molte scelte diverse in più fasi, quando gli oggetti sono decine e decine, quando facciamo accadere una serie di eventi (alcuni determinati dal comportamento del fruitore, altri no) in base alla storia che vogliamo raccontare.
Ma tra gli obiettivi dei Learning Brick non c’è la semplificazione di una realtà complessa (che ne risulterebbe snaturata). Si tratta, piuttosto, di:

• costruire serious game che replicano (per il fruitore) la complessità della realtà che vogliamo simulare,
• trasformando (per il progettista) questa complessità in complicazione
• e senza dover mai dire al nostro committente "Mi dispiace, ma questo non si può fare".

E se capita sia qualcosa che al momento non è previsto?
A quel punto è possibile modificare qualche brick o idearne di nuovi. È un lavoro aggiuntivo, che però resta. Ed è proprio soddisfacendo esigenze particolari, e anche a prima vista bizzarre, che i Learning Brick sono cresciuti per dieci anni e, presumibilmente, continueranno a farlo.

Infografia

• Apprendere/pensare-Learning brick 3 <http://www.vindice.it/pagine/bricks.htm>
• Vindice Deplano, 2009, "Learning bricks: oggetti riusabili per simulazioni efficaci", Je-LKS, n. 2. < http://www.vindice.it/materiali/Learning_bricks.pdf>
• Vindice Deplano, 2014, Apprendere da una macchina, Palinsesto.