Vi dico la mia #GlobalGameJam2019 — BARI
Nella mia vita da “forgiatore di materia virtuale” ho partecipato a vari hackathon sparsi per l’Italia, un po’ per divertimento, un po’ per conoscere nuove persone, un po’ per un senso di sfida. La Global Game Jam è quella che mi ha colpito più di tutti.
Vorrei riassumere cosa mi ha colpito e fare un confronto con gli altri generi di hackathon. Infine vorrei anche fare un po’ di retrospettiva e far risaltare alcuni errori, fra i più comuni, che ho notato durante le fasi di sviluppo in un team in un hackathon.
Però prima di addentrarci è doveroso presentare il gioco che ho sviluppato insieme al team formatosi durante l’evento della Global Game Jam 2019: sviluppare un videogioco in 48 ore.
IL GIOCO: THE VALLEY
La nostra casa potrebbe non essere più la nostra casa. Anzi non lo è più. Siamo in cerca di una nuova meta, ma ci sentiamo sperduti. Siamo alla ricerca di un rifugio fisico, ma in realtà ciò che più cerchiamo è un rifugio spirituale. Così vaghiamo verso un luogo dove la nostra anima possa sentirsi in armonia. Il giocatore inizia in una terra a lui estranea, in un ambiente confuso. Non ne comprende i suoni, ma pian piano che incontra, parla e prende confidenza con gli abitanti e i viandanti riesce a comunicare con nuovi linguaggi. Così l’ambiente gli è finalmente più chiaro.
IL BELLO DI QUESTO HACKATHON: La non competitività
Ho sempre messo in primo piano la competitività un po’ in tutto quello che faccio. Sia nei progetti universitari che a lavoro. Questo perché credo che la competitività sia un fattore fondamentale per individuare i propri limiti e superarli. Inoltre, ti dà quel senso di “brio” per cercare di fare le cose al meglio delle proprie possibilità e divertirsi allo stesso tempo. La competizione è sempre stato uno dei fattori principali per cui ho partecipato fino ad oggi agli hackathon.
Tuttavia, a differenza di tanti altri hackathon, la Global Game Jam è NON COMPETITIVA e alla fine dei conti questo ha reso l’hackathon molto più entusiasmante per diversi motivi:
- Forte interattività e scambio di conoscenza tra i diversi team. Infatti succedeva che ad esempio il “nostro” compositore dei suoni o il “nostro” Artist 2D, nei tempi morti, aiutassero anche gli altri team dove magari c’erano delle mancanze. Anche io, a volte, mi sedevo al tavolo di un altro team, per curiosare e magari dare qualche consiglio nel caso li trovassi in difficoltà su alcune meccaniche di implementazione.
In tutti gli altri hackathon a cui ho partecipato non ho mai notato scenari di questo tipo. Ed effettivamente, ora che ci penso, è assurdo perché viene meno una parte fondamentale: portare a casa nuove conoscenze, non solo tecniche ma anche umane. - La giuria [che per fortuna non c’è]. In un classico hackathon competitivo c’è bisogno di una giuria che in genere, per valutare i team, utilizza l’approccio del pitch formato dalle solite slide: Problemi e opportunità; Value Proposition; Business Model; Analisi dei competitor; Prototipo.
Il tutto si traduce per forza di cose in: “progettare una startup in 48 ore”. Il problema è che questo metodo, per forza di cose, non può valutare in 5 minuti la qualità del lavoro che c’è dietro. A ogni modo, questo tipo di esperienza è sicuramente utile per acquisire una visione a 360 gradi di come un progetto può essere messo in moto sotto tutti i vari aspetti. Se un domani si vuol continuare con la propria idea di business e aprire un’azienda, allora ci può anche stare. Ma come forgiatore il mio unico interesse in questi eventi è esprimere la mia massima creatività sperimentando e buttando giù un prototipo che possa piacere e divertire con altre persone di competenze eterogenee . Di quello che sarà il mio prototipo e di tutto il suo ecosistema finanziario non mi interessa. Il punto è che quasi tutti gli hackathon sono ormai fatti in questo stampo in stile “startupparo”.
Beh, per fortuna signori miei la Global Game Jam è diversa. Non c’è giuria e ci si può focalizzare esclusivamente sulla propria creatività. - L’open-source e l’internazionalizzazione. Un’altra cosa fantastica è poter ammirare i progetti degli altri di tutto il mondo attraverso il sito della Global Game Jam. Inoltre si richiede, al momento della pubblicazione del progetto, di rilasciarne il sorgente. Così se qualche gioco ti ha affascinato e sei curioso di capire come gli altri hanno implementato particolari dinamiche puoi spulciare il loro codice sorgente.Tutto questo per incentivare lo scambio della conoscenza. (Anche se fortemente consigliato, ho notato, però, che diversi team non hanno rilasciato il codice sorgente… peccato.)
GLI ERRORI PIU’ COMUNI
Elenco alcuni errori che ho un po’ vissuto sulla mia pelle. Alcuni di questi credo vengano commessi anche nel proprio modo di lavorare. Quindi penso sia utile elencarli per cercare di individuarli e superarli.
Non definire da subito i vincoli della propria idea
Uno degli errori più sottovalutato e più pericoloso è quello di voler strafare. Ma in realtà non è tanto questo, quanto il dare importanza a dettagli totalmente secondari e focalizzarsi su quelli. Per esempio se io sono l’animatore o il modellatore dell’ambientazione magari sono tentato a focalizzare la mia attenzione su dettagli e complessità che potrebbero non avere spazio per poi essere inserite nel gameplay del prototipo. Se non si definisce e non si concorda con il team quello che sarà il prototipo finale vi ritroverete all’ultimo momento con incomprensioni, colli di bottiglia, una demo di scarsa qualità e butterete via molto del lavoro sviluppato dai vostri compagni con pubblicazioni dell’ultimo minuto.
Per superare questo errore il mio consiglio è: prendetevi tutta la prima sera e dopo aver fatto un po’ di brainstorming con carta e penna (o se preferite anche con un tool per disegnare mockup come Sketchup), congiuntamente con tutto il team disegnate su vari fogli l’inizio e la fine della vostra demo con il minimo indispensabile ma con i tutti i dettagli: il gameplay, l’ambientazione, le animazioni necessarie, la lunghezza della colonna sonora, etc.
In questo modo sarà più facile per tutti avere la visione di quello che si andrà a sviluppare, semplificare, gestire in anticipo colli di bottiglia ma soprattutto porrete dei vincoli e delle priorità su quello che non è necessario fare per non arrivare stremati o non avere così neanche il tempo di sperimentare, rilassarvi e divertirvi.
Uno dei nostri errori è stato ad esempio quello di voler centrare il gioco su 2 livelli senza aver chiarito (o dato per scontato) la loro dimensione. Così ci siamo ritrovati con due livelli enormi in cui ci siamo trovati a discutere su come eliminare le parti morte e inserire dinamiche di interattività per non annoiare chi avrebbe giocato con il prototipo.
Non dedicare il giusto tempo al confronto.
Una volta superata la fase di brainstorming, quello che a volte succede è che i vari ruoli all’interno del team tendano a chiudersi e a non discutere delle difficoltà o delle eventuali semplificazioni che potrebbero essere messe in atto in corso d’opera. Questo probabilmente un po’ per imbarazzo con persone che non si conoscono e un po’ perché si tende a isolarsi per concentrarsi su quello che più piace fare. Questo chiaramente porta a una serie di problematiche che invece potrebbero essere risolte fin da subito, con un risparmio notevole di energie e diminuzione dello stress.
Il mio consiglio è quello di girare frequentemente tra i tavoli dei vostri compagni, guardare il loro stato di avanzamento, illustrare il proprio lavoro, chiedere come le cose stiano andando e soprattutto sciogliere qualsiasi dubbio non chiarito.
Non rilassarsi
A differenza degli hackathon precedenti mi sono posto una regola. Dormire :) Infatti una cosa che ho notato ad ogni santissimo hackathon è che quando torno a casa sono sempre distrutto e così ne risento per tutta la settimana. Questo è chiaramente collegato al punto 1. : non aver definito vincoli e semplificazioni alla propria idea. Tornando al nostro problema: se avessimo sviluppato il gioco anche in una sola metà del livello piuttosto che due avremmo raggiunto comunque lo stesso risultato, con più qualità e più ore di sonno per tutti.
Il mio consiglio quindi è di nuovo: ponete vincoli molto stretti alla vostra idea così da avere tutto il tempo per gestire eventuali imprevisti e puntare sulla qualità. Se non vi rilassate un minimo, la prossima volta ad un hackathon probabilmente ci andrete con poca voglia o, peggio ancora, non ci andrete a fatto.
Non sperimentare
Ogni volta che vado ad un hackatlon mi sono sempre ritrovato a fare quello che faccio tutti i santi giorni a lavoro. Questo per dimostrare probabilmente il mio “valore” a qualcuno o per sentirmi più utile per il team. Questa volta però ho voluto cambiare strategia… e lavorare con una tecnologia che non ho mai utilizzato. Il nostro obiettivo infatti non deve essere solo il prodotto finale che sviluppiamo ma anche le nuove conoscenze che portiamo a casa. Credo che queste ultime abbiano un valore maggiore pur rilasciando un prodotto di qualità inferiore. Se si adotta comunque la strategia di voler sperimentare, è sufficiente limitare ulteriormente i confini della propria idea per poter così portare a casa un prototipo più che accettabile.
Nel mio caso particolare ho avuto la fortuna di poter sperimentare Unreal, un game engine di cui ho sempre sentito parlare, ma che non ho mai avuto la briga di sperimentare e di confrontare con il mio amato Unity.
Insomma è stata un’ottima occasione per apprendere una nuova tecnologia grazie anche al supporto del mio insegnante @Emanuele. E’ stato molto utile in questo caso adottare la tecnica del pair programming per accelerare il processo di apprendimento senza intaccare il lavoro.
CONCLUSIONI
Ho voluto riassumervi in breve la mia esperienza di questa mia prima Global Game Jam e confrontarla con le mie esperienze passate.
Spero che questi spunti possano essere di ispirazione sia agli organizzatori dei futuri hackathon e a chi vuole partecipare. La global game jam secondo me ha centrato l’obiettivo del divertimento e della creatività per noi forgiatori di materia virtuale.
