Passa ai contenuti principali

Aiutare i giovani a lavorare in gruppo per sviluppare un gioco

Insieme ad alcuni amici gestisco un CoderDojo: ci troviamo una volta al mese riunendo i giovani che vogliono creare qualcosa di interessante e divertente con i computer. Usiamo diverse tecnologie, ma soprattutto creiamo piccoli giochi o raccontiamo storie con Scratch e un giorno abbiamo deciso di fare un esperimento.

Un sabato pomeriggio tipico inizia con i mentor che chiedono ai ragazzi cosa vogliono fare, ma al contrario di quanto possa sembrare questo non è un passaggio facile: alcuni di loro non hanno un'idea chiara di quello che vogliono ottenere e la maggior parte tende a lavorare individualmente.

Per superare questi problemi abbiamo pensato di fornire ai ragazzi un foglio con stampate sopra alcune istruzioni e abbiamo chiesto loro di riunirsi in gruppi e prendersi mezz'ora per rispondere alle domande prima di iniziare a programmare. In realtà non tutti i gruppi sono nati spontaneamente: alcuni sono stati suggeriti dai mentor, ma alla fine è andato tutto bene.
Le indicazioni sul foglio erano molto semplici: il loro scopo era quello di portare i ragazzi a descrivere uno schema del gioco che avrebbero programmato subito dopo. I suggerimenti erano:
  • titolo del gioco;
  • regole del gioco;
  • sfondi da usare;
  • personaggi e come si muovono e cosa possono fare;
  • altri elementi e come si muovono e cosa possono fare;
  • come termina il gioco.
All'inizio i ragazzi ci hanno squadrato in malo modo perché di sicuro deve essere sembrato un compito in classe, ma li abbiamo subito rassicurati che non esistevano risposte corrette o sbagliate. A quel punto hanno iniziato a lavorare.
Ovviamente durante i 30 minuti i ragazzi non sono stati lasciati soli: i mentor hanno continuato a muoversi tra i tavoli per rispondere e per porre domande. In realtà il processo richiede ai mentor di porre domande, più che di rispondere; per esempio, quando un ragazzo si è bloccato nel definire il movimento di un personaggio la domanda è stata: il personaggio si muove solo orizzontalmente o solo verticalmente o in entrambe le direzioni? Salta? E così via. In questo modo i ragazzi sono guidati a trovare le risposte da soli.

Il vantaggio che abbiamo notato era duplice. Prima di tutto i suggerimenti hanno aiutato i ragazzi a definire meglio il loro gioco prima di iniziare a programmare e di conseguenza questo evita loro di perdersi durante lo sviluppo. Secondo, i ragazzi hanno discusso in gruppo come strutturare il gioco e questa collaborazione è continuata anche durante lo sviluppo: in alcuni gruppi sono stati assegnati compiti diversi a persone diverse, in altri gruppi ciascuna persona ha lavorato alla propria versione del gioco sul proprio computer, ma sempre scambiandosi opinioni su come procedere.

Nel complesso per noi è stata un'esperienza positiva, anche perché è applicabile anche a contesti diversi da quelli della programmazione: scrivere un semplice schema per l'attività da svolgere e invitare i ragazzi a completarlo può aiutare molto nello stabilire la giusta organizzazione dei gruppi. Di sicuro riproveremo a utilizzare lo stesso approccio in qualche evento in futuro.

Commenti

Post popolari in questo blog

Nuovo sito "Creare programmando" con una sezione per la didattica

Ho organizzato i miei tutorial, fatti con Scratch o altri linguaggi, in un nuovo sito che si chiama "Creare programmando" e che dovrebbe rendere più agevole lo scarico degli stessi. Questo sito contiene anche una sezione dedicata alla didattica tramite il computer in cui voglio raccogliere idee e tutorial che possono trovare applicazione nelle scuole oltre che nei CoderDojo, magari semplicemente perché forniscono degli spunti agli insegnanti sugli argomenti che si possono sviluppare (nel vero senso della parola) tramite il computer. Ho inaugurato la sezione didattica con un nuovo tutorial in Scratch dedicato alle regioni italiane. Cliccate qui per andarlo a vedere.

Un tutorial software per allenarsi all'uso dei sensori hardware

Durante l'ultima sessione di CoderDojo MXP abbiamo proposto ai ragazzi un tutorial che ha lo scopo di impratichirli nei ragionamenti che si rendono necessari quanto ci si trova a dover impostare la traiettoria di una macchinina utilizzando solo un sensore in grado di rilevare il colore della traccia visibile sul pavimento (in scala di grigi). Non avendo (ancora) a disposizione macchinine e sensori "reali" abbiamo iniziato a simulare la situazione disegnando una pista con Scratch utilizzando quattro diversi colori. Il compito dei ragazzi era di riuscire a fare in modo che lo sprite dell'automobilina seguisse la pista senza uscire di strada: le correzioni alla traiettoria avvenivano utilizzando il blocco "sta toccando il colore..." come se ci fosse un sensore in grado di vedere il colore della traccia sotto all'automobile. E se ne sono viste di tutti i colori perché il compito non era facile. Alla fine, per stimolare un po' di competizione tr

Sed: caratteri speciali che si possono usare nel lato destro delle sostituzioni

Il titolo è lungo, ma serve semplicemente per dire che nelle sostituzioni tramite la sed , ovvero quelle realizzate con il comando s/// , è possibile utilizzare alcune sequenze di escape oltre ai soliti backreference dei gruppi "catturati" con le parentesi nell'espressione regolare di sinistra. Nella parte destra dell'espressione (cioè quella dopo la seconda barra /) si possono usare: - \L per trasformare in minuscolo tutto  quello che segue (la L sta per "lowercase"); - \l (è una elle minuscola) per trasformare in minuscolo solo il carattere seguente; - \U per trasformare in maiuscolo tutto  quello che segue (la U sta per "uppercase"); - \u per traformare in maiuscolo solo il carattere seguente; - \E per marcare la fine della trasformazione dei caratteri. Gli "operatori" \L e \U agiscono fino alla fine dell'espressione (delimitata dalla barra / finale) oppure fino alla \E successiva. Quindi, per esempio, per trasformare sol