Appunti di migrazione: da AIR ad Unity

0
Share:
Migrazione da AIR ad Unity

Come ho scritto nel mio precedente post, dall’inizio di agosto ho iniziato un percorso di migrazione da AIR a Unity. Piccola premessa, se con AIR in ambiente Animate ero un esperto, qui sono tornato ad essere un semplice studente. Per cui mi scuso in anticipo per eventuali imprecisioni. Magari editerò gli eventuali strafalcioni in un secondo tempo. Ma cominciamo da una domanda per niente banale.

Perché ho scelto proprio Unity?

Prima di tutto, la domanda che bisogna sempre farsi in questi casi è a cosa ti serve la tecnologia che vorresti apprendere? Nel mio caso la risposta è semplice: ho intenzione di realizzare dei giochi 2d per dispositivi mobili. Chiaramente il discorso va contestualizzato. Non voglio (e nemmeno sarei in grado da solo) di realizzare progetti molto corposi. Parliamo di instant game professionali e (si spera) divertenti.
Stabilite le mie necessità, ho diviso le soluzioni in due macro categorie: i linguaggi nativi e le soluzioni ibride. Non ci giriamo attorno, i linguaggi nativi sono inarrivabili sul fronte delle performance e del controllo del dispositivo. Però li ho esclusi quasi subito. Pur prediligendo l’ambiente Android, mi riservo di pubblicare le mie app anche su IOS, e imparare due linguaggi nativi avrebbe comportato troppa carne al fuoco per la mia piccola cucina: doppia curva di apprendimento, doppia specializzazione, doppio ambiente e doppio testing. Purtroppo avendo anche altri impegni non riuscirei ad approfondire la materia come vorrei.
Restano quindi le soluzioni ibride. Meno efficaci, ma molto più versatili. Impari ad usare un singolo ambiente, fai il lavoro una volta sola ed esporti ovunque. Anche qui avevo solo l’imbarazzo della scelta. Ad esempio sono stato tentato da Xamarin. Non è un ambiente pensato per i giochi, ma copre tutti gli aspetti della creazione di un’applicazione. Oltre alla mancata specializzazione, mi ha frenato la fase di transizione che sta attraversando. Proprio in questi giorni si parla di un nuovo ambiente destinato a prendere il suo posto, parlo del tanto atteso “.NET MAUI”. Infatti nei luoghi discussione online il dibattito verte su come migrare o se un neofita farebbe bene ad imparare Xamarin oggi. Per cui ho preferito lasciar perdere.
Un altro programma che per un attimo mi ha tentato è stato GameMaker. Purtroppo non mi ha convinto la resa. I giochi dimostrativi che si vedono in giro, fatte le dovute eccezioni, sono abbastanza deludenti. Non ho capito se si tratta del motore grafico o il tipo approccio progettuale, ma perlopiù non mi hanno convito. Un altro problema riguarda la diffusione. Una volta era molto più popolare, ma adesso sta diventando di nicchia. Aspetto per me non secondario sul quale tornerò tra breve.
Poi ci sarebbe Construct 3. In quel caso sono stato davvero combattuto. Molti giochi mi hanno ricordato quelli fatti in Flash quando il programma era ancora vivo e vegeto.  Io (almeno per adesso) vorrei sviluppare games in 2d e il programma è specializzato in 2d. Tra i linguaggi che conosco meglio c’è JavaScript e il programma si basa su JavaScript. La community è molto vitale, aspetto che per me conta molto. Cosa mi ha fatto desistere? Prima di tutto, ho trovato molto scomodo l’approccio progettuale per quelle che sono le mie abitudini. La scrittura del codice è secondaria rispetto ad un approccio visivo molto più diffuso e documentato. Nasce per il web anche se si adatta bene al mobile: quindi molte funzioni per Android si basano su plugin, alcuni free, altri a pagamento e dopo aver avuto a che fare con gli ANE, ho sviluppato una grave allergia ai plugin. Infine, se cambi idea e vuoi fare qualcosa in 3d, Construct non è adatto. Anche qui ho rinunciato all’idea. Ma passiamo a Unity. Volendo riassumere, ecco i motivi che mi hanno fatto propendere per questo programma:

  • Ha molti aspetti in comune con il mio vecchio ambiente di lavoro. Da vecchio utente di Flash prima e Animate dopo, sono abituato ad un approccio misto tra gestione della grafica e scrittura del codice. E Unity, nonostante tutte le differenze del caso, prevede un flusso di lavoro molto simile.
  • Ha un ottimo approccio con gli store. I giochi vengono pubblicati per i dispositivi mobili in modo intuitivo senza uscire dal programma e senza scaricare l’SDK da Tizio o comprare un plugin da Sempronio (a differenza di certe aziende psicopatiche). Usi Unity, lavori in Unity, resti in Unity. Sembra un cazzata, ma per un ex-flasharo non lo è.
  • Consente di realizzare giochi tridimensionali di tutto rispetto. Chiaramente, nella maggior parte dei casi, il risultato non è paragonabile a certi giochi tripla A realizzati con il codice puro, ma se ti organizzi con un team agile e un budget contenuto, puoi sviluppare giochi 3d di livello medio alto più che dignitosi. 
  • C# è un linguaggio di programmazione che ha molti punti in comune con AS3. Ci sono delle differenze, ma anche moltissime similitudini. 
  • E’ molto popolare. Parliamo del motivo che più di tutti ha influenzato la mia scelta. Il mondo che ruota attorno ad Unity è in continuo fermento. Abbiamo varie community molto attive, libri, tutorial, corsi gratuiti o pagamento e più in generale tantissimi developer che parlano quotidianamente di questo ambiente.  Tutto questo perché l’azienda investe nel suo prodotto, lo aggiorna adeguatamente e lo spinge con convinzione. Se hai de dubbi e chiedi a zio Google otterrai risposte non solo di questo decennio ma addirittura di quest’anno (e a quel punto se prima sviluppavi con quel cadavere di AIR, ti potresti anche commuovere). 

Ci sarebbe anche un ulteriore motivo: un game fatto con Unity può essere pubblicato ovunque. Per esempio, oggi non sono interessato a pubblicare su Steam, ma se mi viene in mente un’idea che sarebbe perfetta per quella piattaforma, devo solo mettermi al lavoro.

Il primo impatto

Tosto. Non parliamo di un programmino da due soldi. Appena ho aperto Unity ho avuto un momento di disorientamento. Per cui ho dovuto applicare i consigli che davo a miei studenti quando insegnavo web design: non farsi spaventare dal numero enorme di pannelli e funzioni, allenarsi quotidianamente e proseguire nella creazione di un progetto un passo alla volta. Se come me siete ex flash developer ci sono buone notizie. Nonostante il diverso approccio e le numerose nozioni da apprendere, abbiamo una serie di conoscenze pregresse che ci aiutano a non partire da zero.

Le differenze

Rispetto ad Animate, Unity non è un coltellino svizzero che fa un po’ di tutto (in alcuni casi maluccio). Parliamo di un programma pensato per creare solo ed esclusivamente giochi. Tutto, dal più piccolo pannello insignificante, al menu di pubblicazione, è stato creato seguendo una logica ben precisa. Questo significa che alcune cose mancano. Non ci sono strumenti di disegno e non possiamo creare elementi grafici da zero. Al massimo ci sono oggetti 2d e 3d preimpostati, ma se, per fare un esempio, volessimo realizzare un pupazzetto in stile Super Mario che corre in un platform, abbiamo solo due possibilità: importare la grafica relativa acquistando quello che ci serve, oppure creandola da zero con un tool apposito prima di importarla.  Analogamente manca una linea temporale evoluta. Se vuoi animare qualcosa all’interno del tuo progetto, hai una serie di strumenti a tua disposizione, ma il programma non è pensato per fare dei veri e propri cartoni animati. Non è quello il suo scopo. 
Ci sono meccanismi preimpostati pensati per simulare la fisica nei videogame: gravità, attrito, inerzia, accelerazione e tanto altro. Questi aspetti prevedono un controllo visuale che si interseca con la programmazione. Se si vuole sfruttare al massimo il programma, vanno studiati con attenzione.

Le similitudini

  • Anche in Unity è possibile suddividere un gioco in varie scene tramite le quali organizzare i vari quadri del gioco. Ogni volta che la scena cambia, gli oggetti della scena precedente vengono distrutti per risparmiare risorse.
  • Al posto della libreria abbiamo due pannelli che si suddividono il compito di gestire le risorse: un pannello Hierarchy che mostra un elenco ordinato di tutti i vari GameObject (oggetti usati nel progetto simili ai MovieClip) e un pannello Projects che contiene una sezione Assets con tutti i file che abbiamo importato.  In pratica, il primo pannello serve per gestire gli oggetti dal punto di vista progettuale e il secondo li organizza in delle vere e proprie sottocartelle. Tra parantesi, come ho imparato facendo le prime prove, anche se sono collocati fisicamente in una sottocartella dell’hard disk, i file vanno gestiti sempre passando per il pannello Assets. Questo perché Unity crea una sorta di cronologia. Per cui se cancelli o modifichi qualcosa senza affidarti al programma, ma manipolando direttamente le cartelle, puoi incappare in dei bug.
  • Ogni volta che selezioni un oggetto, il pannello Inspector si aggiorna in modo contestuale esattamente come il pannello di Ispezione proprietà. Ci sono tante opzioni in più, ma la logica non cambia.
  • Esiste un pannello Game in tutto e per tutto simile alla finestra di Anteprima di Flash/Animate. Per cui, mentre procedi alla creazione del tuo gioco, puoi tranquillamente testare il tutto strada facendo premendo il tasto Play.
  • Il pannello Console è molto simile al pannello di Output e lo puoi usare per testare via codice alcuni valori o semplicemente leggere i messaggi del programma in fase di testing. 
  • Il codice può essere associato ai vari oggetti del tuo gioco (o anche alla main camera) seguendo la logica del vecchio ActionScript. Selezioni l’elemento al quale vuoi associare il tuo codice e poi tramite il pulsante Add Component lo aggiungi. Una volta ultimata la procedura ottieni una classe preimpostata in C# dalla quale partire. Le classi possono dialogare tra di loro con delle opportune istruzioni.
  • Il linguaggio di programmazione C# ha moltissimi aspetti sintattici simili ad AS3. Entrambi si basano sullo standard ECMA. Per la precisione C# su una versione meno obsoleta (ECMA-334), ma che tutto sommato mantiene la stessa logica. Ci sono metodi proprietari e alcuni aspetti che richiedono un pizzico di sforzo, ma il cuore del linguaggio non è dissimile. Ne parlerò approfonditamente nel prossimo articolo.

In conclusione

Se volete migrare non scoraggiatevi. Chi ha lavorato con Flash/Animate sa cosa significa assemblare tutti gli aspetti di un progetto complesso nel rispetto di una precisa sceneggiatura. C’è da lavorare, ma il compito è alla nostra portata. Oltretutto possiamo accedere ad un materiale didattico infinito. Ci sono libri in italiano, in inglese, corsi su youtube… C’è solo l’imbarazzo della scelta. Personalmente sono partito da una guida free in italiano che ho scaricato da questa ottima risorsa: unity3dtutorials.it. Per il resto, ho scovato una marea di tutorial che ho messo nei preferiti e sto seguendo in questi giorni. DAJE! 

Share:

Leave a reply

*