Ora apri il menu a tendina e seleziona l’oggetto mazzafrusto
Laboratorio di Videogiochi è uno dei tanti esperimenti di Nintendo, che va ad unire due concetti che già ha esplorato in sedi diverse. Labo era il suo kit di creatività che univa il mondo fisico a quello informatico, sfruttando oggetti di cartone da 2 soldi per comandare con un feedback fisico maggiore giochi da 2 soldi.
Di quell’esperimento, come non ricordare i bellissimi tutorial passo passo per montare tutta l’attrezzatura. Successivamente, Nintendo introdusse il Toy Con Garage. Sì, lo so, vi siete scordati praticamente tutti della sua esistenza. Sopra trovate il trailer come riferimento. Eppure Laboratorio di videogiochi riprende a piene mani da questa esperienza precedente. Sia in termini di design, che in termini di programmazione. Perché Nintendo non butta via nulla e lo sappiamo.
Laboratorio di videogiochi riprende quindi queste idee e le espande al videogioco completo. Non solo un subset incentrato su un franchise come Mario Maker, non un software per vendere cartone. Ma qualcosa di più completo e complesso, che punta a vette più alte. Ma riuscirà ad essere il Dreams di Nintendo?
Com’è giusto che sia, ognuno di noi filtra l’esperienza del gioco in base al proprio background e propria indole. Molti nel settore per osmosi imparano qualcosa di programmazione. Qualcuno può anche aver sperimentato nel realizzare qualcosa, per sfizio. Pochi lo sono di professione. Nel mio lavoro professionale programmo macchine automatiche. E Laboratorio di Videogiochi ha risvegliato in me ricordi e idee interessanti. Cercherò di fare un discorso un po’ più d’ampio respiro per contestualizzare.
Quando spesso si parla di programmazione, l’immaginario comune vede delle persone sedute davanti a muri di codice da scrivere. Come se si stesse scrivendo un tema, solo in una lingua sconosciuta e complicata. Indecifrabile ad una prima occhiata. E per molti tipi di programmatori, questa è anche la realtà. Qui sotto una classica schermata “muro di codice”.
Ma questo non è l’unico modo di programmare un qualcosa. Esiste una strada non testuale. I linguaggi di programmazione che permettono di creare un codice manipolando i dati graficamente e non attraverso del testo sono molto diffusi oggigiorno e sono uno dei motivi per la democratizzazione della programmazione.
Un esempio molto famoso nel mio campo applicativo è il cosiddetto Diagramma a scala, meglio conosciuto con la denominazione inglese di Ladder Logic. Nel mondo dell’automazione si è sempre preferito un approccio semplice alla programmazione per adattarsi alle figure professionali a disposizione. Prima dell’avvento dell’elettronica programmabile moderna, le macchine automatizzate avevano documenti che ne indicavano la struttura elettrica, che permetteva attraverso numerosi interruttori di avere una sorta di programmazione automatica.
Questi schemi si sono trasformati nei diagrammi ladder, che andavano ad integrare in un linguaggio di programmazione grafico gli interruttori elettrici. Questo permetteva ai numerosi periti elettrotecnici di evolversi in programmatori per le macchine automatiche. Con il tempo questo codice si è evoluto ed impreziosito, andando ad aggiungere blocchi in grado di eseguire operazioni via via sempre più complesse. Da un semplice blocco che prende due segnali in ingresso e li tratta come un operatore logico, a sistemi di addizione, moltiplicazione o blocchi per gestire la comunicazione TCP-IP tra diverse centraline nella stessa rete.
Oggigiorno, questi sistemi sono sfruttati all’interno di tutti i grandi nomi dell’automazione industriale, da Siemens ad Omron, passando per Beckoff e Rockwell. Questi sistemi si sono poi impreziositi di un linguaggio non grafico, il testo strutturato, Structured Text, e si può usare in combinazione con una struttura ladder per organizzare al meglio il flusso del programma. Labview, usato in migliaia di applicazioni scientifiche e ingegneristiche (del quale ero uno sviluppatore CLAD) è un altro sistema famoso per la sua programmazione visiva e la sua completezza.
Il mondo dei videogiochi invece, si è evoluto dal mondo dell’informatica, non dell’elettrotecnica. Pertanto le prime persone che si misero all’opera erano programmatori, combattenti e pionieri, non operai che non potevano buttare via anni di formazione ed esperienza nel dimenticatoio. Pertanto, all’inizio erano tutti muri di testo.
Con l’evoluzione del media nacque un’esigenza di semplificare quanto possibile in processo di programmazione. Uno dei motivi è legato al quantitativo di professioni che creare un videogioco richiede. Avere una barriera di approccio più bassa ed una curva di apprendimento meno ripida, permette anche ai non programmatori di professione di contribuire alla creazione del videogioco in modo più efficiente.
Allo stesso modo, una barriera di ingresso più bassa permette a più persone di creare videogiochi. Ecco quindi che interi motori grafici sono nati con al centro un linguaggio di programmazione grafico. Forse l’esempio più famoso di tutti è Game Maker. Il suo linguaggio DnD, Drag and Drop, permette la creazione di tutti gli elementi e la logica del gioco in modo visivo.
Il suo metodo di sviluppo permise a molti programmatori alle prime armi di approcciare il mondo di sviluppo in modo molto meno intimidatorio rispetto ad altri motori grafici. Ricordiamo che Hyper Light Drifter e Undertale sono stati realizzati con questo motore.
Questo sistema è stato implementato sui motori grafici più blasonati. L’Unreal Engine ha il Blueprint, Unity ha il suo sistema Bolt, il Cryengine ha il Flowgraph. Anche motori non a disposizione del grande pubblico, come lo Snowdrop della Ubisoft ad esempio, ha il suo linguaggio visivo di scripting.
Questo sistema va a creare delle mappe di processo, dove il segnale viaggia all’interno di dei collegamenti ed è possibile vedere a colpo d’occhio chi muove cosa e le relazioni tra tutti i suoi elementi. Se non si è abituati a programmare in modo “classico”, è un’enorme semplificazione del carico verso il nostro cervello.
Ecco quindi che Laboratorio di Videogiochi si inserisce in questo contesto, andando a prendere la sua struttura composta da nodi che rappresentano oggetti di gioco che devono essere tra di loro collegati e la rielabora in un lungo tutorial. Una piccola pallina blu di nome Bob vi guiderà nella creazione di 7 giochi.
Questi giochi non sono affatto esperienze complete. Si tratta di piccole stanze, con obiettivi semplici e dalla complessità elementare. Mano a mano che si procede nei tutorial tale complessità aumenterà si passerà dal 2D alle tre dimensioni e verranno introdotti concetti più elaborati nel tempo.
Tra un tutorial e l’altro ci saranno dei checkpoint, dove dovrete saper dimostrare di aver capito quel che avete appena finito di imparare per risolvere dei mini rompicapo. Dopo aver completato i 7 tutorial, avrete una quarantina di rompicapo nei quali cimentarvi qualora vogliate affrontare l’esperienza come una sorta di puzzle game.
Dal punto di vista didattico ci sono molte cose da metabolizzare. Ci sono sia trovate geniali che trovate pessime, le contraddizioni tipiche di Nintendo.
Tutte le fasi tutorial iniziano con un video che mostra il progetto finale, il punto di arrivo dell’esercizio. Questo è un buon modo di iniziare in generale. Lanciarsi in programmare senza sapere dove si vuole arrivare non è mai una buona cosa da fare. Le conoscenze da acquisire servono per perseguire un obiettivo.
Successivamente, si procederà per step dove verranno completate le varie componenti del gioco. All’inizio il gioco guida molto il giocatore nei menu, andando ad evidenziare praticamente ogni cosa che deve essere premuta al di fuori di ogni altra. Nei tutorial più avanzati ci sono sempre delle restrizioni per evitare di uscire dal canovaccio, ma la rigidità sull’interfaccia è rilassata e lascia al giocatore il compito di navigare i menu, andando quindi a stimolare la sua componente mnemonica nel trovare gli strumenti di sviluppo.
In fondo si dice spesso che per imparare a programmare basta imparare un linguaggio. Per capire la logica, che cosa deve pensare il cervello. Poi ogni linguaggio grossomodo si comporta in modo simile, con lo scoglio principale capire come riadattare la memoria muscolare legata all’uso di una certa sintassi o ad utilizzare certe scorciatoie.
Immaginatelo come passare spesso tra giocare ad Xbox e Switch. Dove A,B e X,Y sono invertiti. Immediatamente subito dopo il cambio piattaforma, la memoria vi farà spesso sbagliare ma poi ci si adatta.
Il sistema di tutorial a mio avviso esegue due “manovre” molto importanti. La prima è quella di controllare dopo ogni piccolo step l’effetto delle proprie modifiche, specialmente all’inizio. Uno degli sbagli più grandi che si possono commettere è quello di partire a programmare a muso duro, creare un sistema complesso e poi spendere ore per risolvere un bug che si fa fatica a replicare.
SEMPRE suddividere un grosso problema in tanti piccoli problemi e risolvere quelli. Poi è possibile combinarli a mente leggera. La seconda “manovra” si collega alla prima. Vedere il proprio lavoro incompleto. Un tutorial potrebbe andare a darvi tutti i comandi necessari a realizzare una feature e vedere solo il risultato finale completo al 100%. Laboratorio di Videogiochi invece mostrerà sempre elementi che non funzionano, cose che non vanno, sistemi incompleti.
Questo per cercare di attivare pensiero critico sui passaggi che si stanno compiendo e rafforzare come arrivare al percorso finale.
Quindi Bob fa un buon lavoro nel guidare il giocatore. C’è un grosso “ma” in tutto ciò. Esiste una seconda figura aiutante, Alice, che entrerà in gioco nei checkpoint puzzle tra i vari giochi e nel tutorial finale. Lei ha un carattere molto diverso da Bob ed un modo di spiegare molto diverso. Va più a fondo.
Suo infatti è il manuale di riferimento, liberamente consultabile per avere spiegazioni in dettaglio di ogni blocco funzionale a disposizione del giocatore. Però mi chiedo quanto una divisione così netta sia effettivamente utile.
Nei vari tutorial ci si ritrova spesso a combinare molti blocchi per eseguire operazioni matematiche. Personalmente non ho mai avuto difficoltà nel seguire il filo logico, ma mi è sempre sembrato mancasse qualcosa per i meno avvezzi. Ecco quindi che per magia nell’ultimo tutorial, Alice si ferma e spiega, evidenziando i collegamenti, le operazioni matematiche eseguite ed il loro effetto, in modo chiaro e puntuale.
Questo tutorial sarebbe dovuto essere presente molto prima, la prima volta che Bob ci diceva di costruire strutture simili. Non si tratta di informazioni avanzate, che solo un programmatore “esperto” può capire. Sono alla base della comprensione di sistemi complessi.
Questo è il punto di maggior debolezza della produzione Nintendo. Dare informazioni più precise nei punti di maggiore complessità, andando spesso a perdere più passaggi su elementi più semplici, ma che richiederebbero attenzione maggiore perché sono i blocchi di partenza, le fondamenta.
Una volta completati i tutorial, si rimane nello stesso stato molto comune. “Ed ora? Cosa faccio?“. Ho avuto modo di leggere in giro una lamentela un po’ diffusa tra stampe nostrane ed internazionali. Ovvero che questo tutorial non insegni “perché” ma solo “come”. Su questo punto c’è in effetti molto da discutere.
Normalmente la vita di un programmatore è divisa in questo modo. Da se stessi o da un input esterno arriva un obiettivo da raggiungere. Nel mio caso potrebbe essere “Quando il pezzo da lavorare è in posizione, devono partire le macchine utensili per la lavorazione.”, in altri “voglio realizzare un programma che calcola il valore delle carte di Pokémon da una fotografia della carta“.
A questo punto si inizia a pensare a come realizzare l’obiettivo finale. C’è chi parte subito dall’editor del codice, io preferisco scrivere su carta la macrostruttura del problema ed iniziare a pensare a cosa mi serve prima di battere del codice. Poi arriva quel momento dove non hai la più pallida idea di come fare qualcosa. E quindi ecco che si passa metà della propria esistenza su stackoverflow, sui videotutorial creati da gentili utenti random su YouTube, immersi nei manuali o al telefono con centri supporto o altri specialisti o colleghi.
Laboratorio di videogiochi si inserisce in questa fase. Esattamente come tutti i tutorial di strumento. Quel che forse si chiedeva a Nintendo era di fare il passo più lungo della gamba. Quello di insegnare come diventare Nintendo. Di provare ad insegnare il game design. Di provare a formare una nuova generazione di designers, di provare a far nascere la passione.
Non ho idea che idea avessero in mentre altre persone da un software di 30€. E dopo aver parlato di queste cose, c’è una domanda che aleggia sempre su questo generi di prodotti. Ed ora la sua ombra è diventata così grande da sovrastare tutto il resto.
Laboratorio di Videogiochi è utile? Perché spendere soldi e tempo ad imparare qualcosa qui, quando potrei dedicare lo stesso tempo su Game Maker o Unreal Engine e produrre qualcosa di più nobile?
Può essere un modo per invogliare un pubblico più giovane rispetto ai tool ufficiali? A mio avviso no. Se la grafica ed il tono è più fanciullesco ed universale, i passaggi che occorre fare nei giochi tutorial finali ed in generale il ragionamento da programmatore dietro non è dissimile da quello professionale. Quindi qualcuno troppo giovane potrebbe trovarsi troppo spaesato, mentre chi ha più testa dovrebbe virare già su altro.
Eppure si tratta di tipi di programmi che trovano sempre persone che li supportano. Perché danno l’idea di poter esprimere se stessi senza “responsabilità” che un editor vero possa comportare. E questo ha la sua forza.
A questo punto ho cercato di sfidare me stesso. Tempo fa, dopo che il progetto al quale stavo partecipando come scrittore naufragò brutalmente, decisi di rimaneggiare gli asset per provare Game Maker Studio 2. Ho impiegato 4-5 pomeriggi di coding, sfruttando al 90% lo stile schema a blocchi DnD ed un 10% di codice “classico”, seguendo un tutorial del sito ed espandendolo con mie idee. Da completo inesperto del motore, era la prima volta che lo usavo.
Come potete vedere è tipo la cosa più grezza esistente, ma la struttura base c’è. Due navi con specifiche diverse, effetti sonori, musica, schermata di game over, punteggio, power up, super arma, nemici con diversi punti vita e diversi comportamenti di inseguimento del giocatore.
Perché non ricreare qualcosa di simile su Laboratorio di Videogiochi allora?
Ecco, la partenza non fu delle migliori, in quanto non riuscivo a capire come creare un twin stick shooter. In Gamemaker ricordo che non ci volle molto per agganciare il verso dell’oggetto al puntatore del mouse o ad uno dei due stick di un controller. In Laboratorio ho perso un numero di minuti tali da farmi desistere sul momento. Ho quindi deciso di cambiare genere. Praticamente ho già perso la sfida con me stesso. BENE. Un semplice sidescroller, un’avventura da punto A a punto B, con in mezzo qualche ostacolo completamente a caso.
In questo modo sono potuto partire da uno dei tutorial già affrontati nel gioco con una sorta di bozza del progetto. Esattamente come in GameMaker.
Seguendo solo il mio istinto, ho potuto notare con più facilità i limiti ed i pregi di Laboratorio di Videogiochi, anche se la mia esperienza non è da potersi definire omnicomprensiva, assolutamente.
La prima parte, molto ovvia, è la facilità con la quale si arriva ad avere oggetti su schermo in uno stato semi-funzionale così da poter testare. I comandi via touchscreen sono i preferibili, precisi a sufficienza e “smart”. Se volete usare questo software in docked, sappiate che è in grado di ricevere input da un mouse usb e sarebbe il metodo da usare.
Il difetto del linguaggio di programmazione visivo è quando ho bisogno di eseguire operazioni che coinvolgono un elevato numero di elementi. E nel mio giochino mi sono ritrovato in diverse situazioni di sovraffollamento. Parliamo di calcoli matematici concatenati per variare la velocità dell’avanzamento della telecamera e della sovrapposizione di molti ostacoli ed effetti.
Questo problema è limitabile solo in parte, in quanto i nodi hanno anche un significato spaziale e la loro posizione nella schermata di lavoro è direttamente correlata alla posizione nel mondo di gioco. Anche l’organizzarsi ed avere zone libere per essere riempite di calcoli, non sarà mai come scrivere l’equazione in una semplice riga in codice.
Per questo l’approccio misto, dove in mezzo ad una struttura visiva è possibile inserire blocchi di codice quando questo risulta essere più potente, è la strada maestra per la programmazione.
Un altro grosso problema che ho riscontrato in Laboratorio è l’incapacità di controllare le variabili numeriche in modo semplice. In uno dei tutorial in realtà questo tema viene toccato, con l’attivazione di contatori su schermo per il tempo utile per fare debug. Però mano a mano che la complessità sale, si dovrebbe avere a schermo semplicemente troppa roba e sarebbe più confusionario che di beneficio. Negli editor professionali, anche lavorando a singolo schermo, ho trovato questo processo più immediato.
Quindi dopo dell’intenso lavoro ho prodotto “labotte” e qui sotto potete provare per voi questo mio embrione di livello. Ha esplosioni, yeti arrabbiati, oggetti rotanti, un cambio di personaggio giocante ed altre esplosioni.
Che dire quindi di Laboratorio di Videogiochi? Quel che c’è è buono. Interessante. Una volta che si prende mano con il software si riesce a portare a casa l’obiettivo anche se molti passaggi non sono proprio il massimo dell’intuitività.
Però, se devo spendere energie per creare un gioco qui dentro, perché farlo?
Sembra che i risultati possibili da questo editor siano tutti “giochini da cellulare”. Ovviamente sarò smentito da persone infinitamente più dedite al progetto di me. Però manca quella possibilità di creare “experience” che invece comunica Dreams fin da subito.
La mancanza di focus come un Mario Maker, che concentra le energie creative in dare vita a “livelli di Mario e basta”, e le limitazioni di rimanere vincolati agli strumenti di condivisione della piattaforma, lo rendono un software divertente ed interessante ma del quale bisogna liberarsi per fare qualcosa che abbia davvero senso e peso nel mondo videoludico.
