Rpg Maker MV vs Unity: due engine molto differenti…

Come alcuni di voi avranno saputo, da circa una settimana ho deciso di chiudere il mio capitolo con Rpg Maker e iniziarne uno nuovo con Unity. Anche Our Hero! Hyper Sword, il mio ultimo gioco in sviluppo che ha ricevuto il Greenlight su Steam, sarà sospeso e completamente rifatto in Unity.

Dopo dieci anni di sviluppo videogiochi in cui ho esclusivamente utilizzato Rpg Maker (passandomeli tutti, dal 2k, all’XP, al VX, Vx Ace ed MV per concludere) si esplorano nuove strade e nuove possibilità, cosa che il più delle volte blocca e spaventa.

> Scopri di più su Rpg Maker e Unity, due engine per creare videogiochi.

Ma da cosa è nata questa forte necessità di cambiare? Perché l’ho sentito così necessario? Quali sono le caratteristiche di questi due engine, molto diversi fra loro e dagli scopi altrettanto diversi? Ora, che mi trovo ancora nella fase di cambiamento in corso e ho una visione generale di entrambi i tool, mi piacerebbe spendere due parole a riguardo di questo particolare argomento.

La conclusione a cui sono arrivato è davvero incredibile e non posso fare a meno di parlarne (a fine articolo).

Perché cambiare engine?

Rpg Maker, come è noto, grazie alla sua semplicità permette di avvicinare tantissime persone al mondo dello sviluppo dei videogiochi. Un gran bene, considerando che si può ritenere come un ottimo punto di partenza per fare di una passione una possibile futura professione. Risorse grafiche e audio già pronte, un editor di mappe semplice e un sistema ad eventi facile da padroneggiare, affiancato dalla possibilità di espandere le sue funzionalità grazie all’integrazione di plugin (o RGSS script nelle versioni precedenti ad MV). La possibilità di esportare per browser e mobile (con l’ultima versione) l’ha inoltre reso finalmente un po’ più al passo coi tempi.

Nonostante questo, come è noto, Rpg Maker, proprio per la sua caratteristica di essere alla portata di tutti, ha alcune limitazioni che negli anni si è sempre portato dietro e ha dovuto rispettare. Una, è che è strettamente orientato a sviluppare giochi di ruolo; un’altra, è che il proprio gioco non potrà che avere esclusivamente una visuale “ortografica” (con visione dell’alto, in stile Suikoden 2 o Pokémon, per intenderci).

Abbiamo già parlato di come si possano ampliare le funzionalità dell’engine, aggiungendo script e plugin propri, oppure realizzati da terze parti. Tuttavia, questo spesso potrebbe non essere abbastanza (risulta difficile in Rpg Maker sviluppare giochi platform 2D, o comunque con oggetti molto dinamici che rispettino le leggi della fisica). Anzi, il più delle volte potrebbe essere controproducente, se non addirittura deleterio. Continua a leggere e capirai meglio cosa sto cercando di dire.

Unity, un ambiente di sviluppo orientato agli oggetti

Unity, ovviamente, si differenzia da Rpg Maker per diversi aspetti, ma forse una delle caratteristiche principali è che tutto quello che facciamo in Unity è gestito da Oggetti (ovvero, un qualsiasi elemento di gioco, che sia il nostro personaggio, un alleato, un bottone di un menu, la telecamera di gioco, è un oggetto), a differenza di Rpg Maker, dove ogni cosa è un Evento. Qual è la differenza principale?

Gli eventi sono contenitori in cui ci possiamo buttare dentro una serie di comandi da eseguire in sequenza ad una determinata condizione.

Gli oggetti sono invece elementi di gioco, a cui possono essere associati dei componenti (Components) per “caratterizzarli” e qualsiasi funzione vogliamo che venga svolta su o da quell’oggetto. Se vi sembra interessante, spieghiamoci meglio ed entriamo un po’ più nel dettaglio, analizzando le finestre principali che abbiamo davanti quando installiamo ed avviamo Unity per la prima volta (così che non ci spaventino più troppo).

NOTA: l’interfaccia di Unity è completamente personalizzabile: possiamo spostare le finestre dove più ci piace, chiuderle, riaprirle, aprirne nuove e addirittura aggiungere Assets che espandono il nostro ambiente di sviluppo e integrano dei veri e proprio piccoli “programmini” all’interno dell’editor. Un esempio, possiamo aggiungere un Asset per integrare un tileset editor stile Rpg Maker (dato che di base una cosa di questo genere non c’è in Unity. Un’alternativa è utilizzare software esterni come Tiled e poi importare la “mappa” come immagine/i sprite in Unity).

NOTA 2: di Assets (gratuiti o a pagamento sull’Asset Store) ce ne sono davvero un milione. Questo non ci deve spaventare (provando a mettermi nei panni di chiunque e confrontando la mia prima esperienza, uno dei miei primi pensieri è stato “oddio quanti assets, non troverò mai quello giusto che fa per me e non saprò mai tutti gli assets di cui ho bisogno per fare il mio gioco”). La verità è che gli assets vanno visti solo come dei “miglioramenti” e spesso sono più materiali utili a chi sviluppa videogiochi in 3D. Il più delle volte, quindi, Unity da solo (ovviamente) è già in grado di fare tutto ciò di cui abbiamo bisogno, soprattutto se siamo nuovi e vogliamo innanzitutto cimentarci in progetti non troppo ambiziosi per imparare l’arte.

La Hierarchy

Appena dentro l’editor, sulla sinistra, vediamo la Hierarchy. La Hierarchy (gerarchia) è essenzialmente la lista di tutti gli oggetti che sono presenti nella nostra Scena. Nel nostro progetto possiamo creare tutte le scene che vogliamo (ad esempio per creare più livelli per il nostro gioco) e, al momento della build, starà a noi decidere quali scene includerci all’interno. In ogni caso, la nostra scena è infinita: potremmo creare il nostro intero gioco in un’unica scena (anche se probabilmente la performance ne risentirebbe, quindi non è proprio un’ottima idea!)

La Hierarchy è una delle finestre più importanti: qui possiamo infatti prendere gli oggetti e trascinarli nella scena o nella finestra Project, dove c’è la nostra cartella delle risorse. Trascinandoli nella cartella della risorse creeremo un nuovo Prefab, una delle cose più belle e utili in Unity.

Inoltre, trascinando un oggetto sopra un altro lo collegheremo all’oggetto principale, cioè sigfnifica che abbiamo reso Child l’oggetto minore che ora fa parte di un “gruppo di oggetti”. Questo ci è utile per raggruppare insieme più oggetti di uno stesso tipo (ad esempio i singoli tiles per costruire una mappa possono essere raggruppati sotto l’oggetto “Map 1”, come fossero file di una cartella), oppure per creare un Prefab costituito da più oggetti! Spostando un gruppo di oggetti nella cartella risorse creeremo infatti un singolo Prefab costituito da quell’insieme di oggetti e che ora potrà essere trattato come oggetto unico (ad esempio i nostri tiles per creare la mappa “Map 1” diventeranno una singola immagine). Mi soffermo ora un attimo per spiegare in sostanza cosa sono i Prefab e perché possono facilitarci sicuramente lo sviluppo del gioco.

Cosa sono i Prefab?

I Prefab sono oggetti comuni, che possiamo decidere di rendere Prefab. I Prefab diventano quindi oggetti che possono essere duplicati inserendoli nelle nostre scene, per creare oggetti dello stesso tipo che condividono le stesse identiche caratteristiche fra di loro (ad esempio, possiamo creare un Prefab “Enemy” per gestire tutti i nemici del nostro gioco, dato che probabilmente condivideranno caratteristiche comuni, come il movimento o un eventuale script per calcolare il danno quando attaccano l’eroe). Il punto forte è che quando avremo bisogno di apportare una modifica a tutti quegli oggetti, potremo agire direttamente sul Prefab: le modifiche si trasferiranno su tutti i nostri oggetti già presenti nelle scene del gioco! Non solo, possiamo creare cloni di un oggetto principale (il Prefab) che condivide quindi le medesime caratteristiche con tanti altri oggetti, ma a cui possiamo anche apportare noi modifiche specifiche solo su quel determinato oggetto (ad esempio se abbiamo bisogno di modificare il colore o la dimensione di un solo determinato nemico).

La Scene

La finestra Scene è la grande finestra centrale che abbiamo nel bel mezzo di Unity. Consiste, in poche parole, dell’ambiente in cui costruiremo il gioco, ovvero dove andremo a collocare gli oggetti, come la telecamera di gioco, il player, eventuali nemici, mappe (sia che siano costituite da singoli tiles sia che si tratti di una sola unica grande immagine), ma anche, ad esempio, animazioni. Le animazioni infatti sono elementi particolari da richiamare ad una determinata condizione su un oggetto (ad esempio l’animazione di camminata del nostro personaggio, o di attacco nel momento in cui premiamo un determinato tasto) e che non dovrebbero essere quindi di principio presenti nella scena, se non nel caso di animazioni di oggetti statici (come, ad esempio, un fuoco). Per creare una nuova animazione possiamo infatti selezionare (dalla finestra delle risorse) la sequenza di sprites che costituiscono l’animazione di un determinato oggetto e trascinarle nelle scena per creare l’animazione vera e propria.

Nel menu in alto, selezionando GameObject, potremo comunque visualizzare tutti gli oggetti di gioco che possiamo inserire all’interno di una scena. Un oggetto particolare da prendere in considerazione sono, ad esempio, le UI. Le UI sono immagini, testi, bottoni o qualsiasi altro elemento che apparirà sullo schermo in “primo piano” fisse e indipendemente dalla posizione in cui si trova la nostra Camera nella scena. Per avere un riferimento, sono le Pictures di Rpg Maker, ma più potenti. Abbiamo infatti la possibilità di collocare testi dinamici (che cambiano coi contenuti che vogliamo noi, tramite script) e immagini o qualsiasi altro elemento per creare efficaci menu e interfacce di gioco (come barre dell’energia, contatori di punti, menu di gioco ecc).

Di fianco alla Scene abbiamo la finestra Game: è qui che, quando avvieremo il test del nostro gioco, daremo vita e potremo vedere e provare tutto quello che abbiamo creato e messo in scena.

La finestra Project

In Project, di default situato in basso, vediamo tutte le cartelle e le risorse che creiamo o buttiamo dentro alla nostra cartella principale del progetto. Vediamo di default la cartella Assets, in cui è buona norma creare delle sottocartelle in cui dividere i vari elementi che costituiranno il nostro gioco (ad esempio, una cartella “Resources” per i file grafici, una cartella “Scripts”, una per i file audio, una per le animazioni, una per i prefab, ecc).

La Console

Sempre in basso, proprio di fianco a Project, abbiamo la Console. La Console ci restituirà qualsiasi errore derivante dall’attività del nostro gioco, come ad esempio errori negli script. Possiamo anche usare la Console per stampare valori o testo nel momento in cui stiamo creando i nostri script (ad esempio un Debug.Log(“Hello World!”); ci scriverà nella Console il testo Hello World!. Ci risulterà molto utile consultarla e averla sempre a portata di mano.

L’Inspector

Eccoci arrivati alla finestra più a destra nell’editor e fra le più importanti: l’Inspector. L’Inspector è il luogo in cui vedremo eventuali opzioni di settaggio (come le impostazioni di audio, di grafica, di input ecc. relative al nostro gioco), ma non solo; è anche il luogo in cui soprattutto vedremo tutte le caratteristiche di un oggetto e tutte le componenti che lo caratterizzano nel momento in cui lo andremo a selezionare. Cosa significa “tutte le componenti che lo caratterizzano”?

Gli oggetti, come abbiamo detto, sono gli elementi principali che compongono il nostro gioco in Unity. Un oggetto, di base, senza componenti che lo caratterizzano sarebbe indistinguibile, uguale identico a qualsiasi altro oggetto. Aggiungendo ad un oggetto dei Components diremo all’oggetto di essere in un certo modo e di comportarsi in un certo modo. Ciò significa che se, ad esempio, volessimo creare l’oggetto Player (per rappresentare il nostro giocatore in game) potremmo volergli assegnare due Components principali: un RigidBody e un Collider (a forma di Box, Circle, Polygon…). Il RigidBody renderà il nostro oggetto (nel nostro caso il Player) soggetto alle leggi della fisica, mentre il Collider gli darà la facoltà di interagire (tramite interazione) con qualsiasi altro oggetto di gioco. Ottimo! Un’altra buona idea sarebbe aggiungergli alcuni script, come ad esempio uno per farlo camminare con la pressione di determinati tasti. Già, perché tutto ciò che vogliamo far accadere in Unity bisogna scriverlo nel nostro programma (il gioco) tramite script.

Perché non conoscere la programmazione non ci deve spaventare?

Alcune settimane fa, nel momento in cui ho deciso di lasciare perdere Rpg Maker e passare a Unity (essenzialmente perché in Rpg Maker era ormai una lotta continua a superare i limiti del tool e a risolvere malfunzionamenti derivanti da questo approccio, più che un avere il piacere di creare il gioco) non conoscevo neanche un po’ la programmazione (o comunque molto poco). In teoria, io pensavo questo e così sarebbe dovuto essere. In pratica, “programmavo” già da anni, tramite il semplicistico sistema di eventi di Rpg Maker: già solo per creare un menu ad eventi, un title personalizzato, o un sistema di battaglia personalizzato, c’era dietro la cosa principale: la logica, e anche in un certo modo un uso base della sintassi (come l’uso di if, cicli e variabili). Questa è, in sostanza, la programmazione: logica e conoscere la sintassi del determinato linguaggio che si sta utilizzando. Nonostante questa sia un’ottima base per capire che non è nulla di completamente sconosciuto a noi, è opportuno conoscere qualcosa di più.

Unity come linguaggi di scripting utilizza il C# e il Javascript. Oggi il C# è di gran lunga più utilizzato e troverete una marea di tutorial a riguardo su come fare cose in Unity che utilizzano il C#. Io, personalmente, ho deciso di cominciare a studiarmi il C#. Conoscere il linguaggio di programmazione di cui fa uso il proprio engine di sviluppo è importante per capire e per sviluppare quella mentalità che ci permette di ragionare e fare tutto ciò che desideriamo fare nel modo migliore e più efficace possibile relazionato alla nostra personale situazione.

Ciò che conforta è che per essere in grado di fare un buon gioco non c’è bisogno di conoscere la programmazione approfonditamente: quello di cui necessiteremo, la maggior parte delle volte, sarà avere ben chiaro come chiamare i metodi di cui abbiamo bisogno. Un esempio veloce potremmo farlo analizzando come far muovere un oggetto in Unity: sapendo che ogni oggetto che andremo a creare in Unity avrà obbligatoriamente un componente fisso: il componente Transform. Il Transform gestisce tre parametri fondamentali posseduti da ogni oggetto: la sua posizione nella scena, la sua -eventuale- rotazione e la sua scala (grandezza/dimensione).

Se vogliamo quindi far muovere un oggetto, come ad esempio il nostro giocatore, dovremmo andare ad agire sulla sua Position ogni volta che premiamo un tasto. Se premiamo il tasto per farlo spostare verso sinistra, dovremo togliere valori dall’asse X, se vogliamo muoverlo verso destra dovremo invece aggiungerne, premendo i tasti per farlo muovere verso l’alto e verso il basso dovremo rispettivamente sottrarre e aggiungere valori all’asse Y. Questi “valori” possono essere rappresentati da una variabile che conterrà un numero: a logica, più questo numero sarà alto, più sarà rapido il movimento (lo spostamento sull’asse da un punto all’altro).

Non c’è nessun concetto paranormale o così complicato da capire, è solo opportuno imparare una “nuova lingua”, quella del linguaggio di programmazione, che comunica attraverso classi, chiamate ai metodi (o funzioni), var, if, else, while, ecc (oltre l’inglese, abbastanza fondamentale).

Conclusione

Finalmente, dopo tanti dilungamenti (non pensavo che mi sarei soffermato così tanto su Unity, ma mi è piaciuto fare un quadro abbastanza dettagliato di cosa offre il programma) sono giunto a ciò a cui principalmente volevo arrivare con questo articolo.

Imparare un nuovo engine può spaventare, è giusto, essendo un’ambiente del tutto nuovo (e sapendo che non muovendoci ci aspetta il nostro confortante programma che già conosciamo bene), ma esiste un paradosso che ho trovato straordinario: sono tre settimane che giorno dopo giorno guardo tutorial di Unity, faccio i passaggi che propongono, consulto la documentazione ufficiale e sperimento su Unity (facendo queste cose imparerete sostanzialmente bene ad usare Unity, e probabilmente funzionerà anche per apprendere altre cose e altri programmi; inoltre, se proprio volete esagerare, potete fare come me e acquistare uno splendido corso dedicato su Udemy). Quindi, imparare ad utilizzare un programma così completo come Unity richiede un po’ di tempo e impegno iniziale, questo è vero. Il bello però arriva poi: dopo l’impegno iniziale c’è la libertà, la libertà di creare il gioco che più piace ed esattamente come si vuole. Questo renderà lo sviluppo del gioco addirittura più semplice e soprattutto piacevole, piuttosto al cercare di aggirare le limitazioni di un programma. Invece che cercare il modo di superare i limiti imposti dall’engine (in questo caso sto chiaramente riferendomi ad Rpg Maker), avrete modo di andare diretti a fare esattamente ciò che desiderate fare. Questo, almeno per me (ma spero che potrà esserlo anche per voi), ha reso più semplice utilizzare Unity piuttosto che Rpg Maker. Questo è ciò di cui mi sono accorto e che ho trovato incredibilmente bello (e per arrivare a questo mi sono impegnato tanto da scrivere un articolo di 2829 parole!)

Okay, questo era partito come un normale articolo, ma è diventato un romanzo. Nonostante ciò, spero davvero tanto che questo articolo vi sia piaciuto, vi abbia coinvolto e, chissà, possa esservi stato in qualche modo d’aiuto e d’ispirazione.

Buon Making! 🙂