Come ho imparato ad usare Unity in 3 semplici passi

GMTK è supportato da Patreon - https://www.patreon.com/GameMakersToolkit

Benvenuti al primo episodio di Developing - una nuova serie in cui creerò un mio videogioco. Inizierò dal primissimo step: scegliere un motore di gioco e imparare ad usarlo!

=== Credits ===

Musica di: LAKEY INSPIRED @ https://soundcloud.com/lakeyinspired
License for commercial use: Creative Commons Attribution 3.0 Unported "Share Alike" (CC BY-SA 3.0) License.
YouTube Audio Library

=== Sottotitoli ===

Contribuisci ai sottotitoli tradotti: https://amara.org/en-gb/videos/bXC4f7nbvQjP/info/which-engine-will-i-use-to-make-my-game/

Ciao.

Sono Mark Brown e sto creando
un mio videogioco.

Quindi, per iniziare, devo imparare come
si creano i videogiochi.

Che rappresenta uno sforzo
e una sfida niente male.

Quindi credetemi quando dico che questa
impresa di creazione videoludica...

beh, è quasi finita
ancora prima di iniziare.

Fatemi raccontare cos'è successo.

Musica

Ma prima facciamo un passo indietro.

Perché per prima cosa ho dovuto scegliere
il motore di gioco.

Il motore di gioco (almeno in questo caso)
è un software che aiuta a creare un gioco

prendendosi carico, essenzialmente, del
lato più difficile e noioso dello sviluppo.

Come il rendering a schermo della grafica,
l'interfacciamento con un controller,

i calcoli per la fisica, e altro.

Inoltre ha molti strumenti utilissimi
specificamente progettati

per gli elementi tipici di un gioco,
come le animazioni e l'UI.

Ora, lì fuori è pieno di motori di gioco.

I più famosi sono Unity, Unreal Engine,
Godot, Pico-8, Game Maker, Construct.

Inoltre ci sono motori per specifiche
tipologie di gioco,

come Twine, RPG Maker,
e Adventure Game Studio.

Ci sono addirittura motori di gioco
per specifici ecosistemi

come Game Builder Garage on Switch,
Dreams su PlayStation 4,

e Roblox nel... Roblox-verso.

Tutti hanno dei pro e dei contro,
ammiratori e detrattori.

ma in definitiva ho dovuto sceglierne uno.

E così, alla fine, ho optato per...

Unity.

Ho scelto Unity per svariate ragioni.

Sembra aver trovato un buon equilibrio
tra l'essere molto potente

e relativamente facile da imparare.

È adatto sia per il 2D che per il 3D,

il che è un bene perché sebbene abbia
intenzione di creare il mio primo gioco in 2D,

potrei decidere in corso d'opera
di passare al 3D

senza dover imparare
un nuovo motore di gioco.

Inoltre, Unity supporta praticamente
ogni piattaforma esistente,

quindi se volessi pubblicare il mio
giochino su PlayStation 5

sarebbe tecnicamente possibile,
anche se finanziariamente avventato.

Ma, a dirla tutta, il miglior argomento
a favore di Unity è la sua popolarità.

Unity è il motore di gioco dietro
Hollow Knight, Cuphead, Fall Guys,

Overcooked, Cities: Skylines
ed Hearthstone.

Al momento è il motore di gioco più
popolare su Steam,

e quando abbiamo svolto l'ultima
GMTK Game Jam

Unity è stato usato più di tutti gli altri
motori di gioco messi insieme.

E per me questa popolarità
è importantissima,

perché significa che ci sono più persone
per aiutarmi ad imparare.

Più tutorial, più risorse,
più asset, più plugin,

più persone a cui potermi rivolgere
quando sono bloccato.

Ad esempio, nel Discord di GMTK ci sono
molte persone che sanno come usare Unity.

Inoltre conosco utenti Unity
di lungo corso

come Noa di BlackthornProd
e Andre di Mix and Jam,

che potranno certamente aiutarmi
ad uscire dalla marmellata.

Questa era davvero pessima.

Okay, questa è la mia decisione.

Mi spiace amici di Godot,
è una questione di Unità.

Il primo passo è fatto: scegliere
un motore di gioco. Fatto.

Ora, passo due: imparare come usarlo.

È la parte difficile!

Ma come ho detto, lì fuori ci sono
molti tutorial per Unity.

Che è stato proprio il mio approccio
quando ho iniziato ad imparare.

Sono andato su YouTube, ho digitato
"Unity tutorials" trovandone alcuni

come quelli di alcuni tizi svedesi che
potevano insegnarmi ad usare il software.

Mi hanno mostrato come creare un gioco,
e io ho diligentemente seguito.

Ogni volta che cliccavano una casella,

io cliccavo quella casella
sulla mia schermata.

E ogni volta che scrivevano
una linea di codice,

io scrivevo la stessa linea di codice.

E in poco tempo ho avuto un gioco
funzionante sul mio computer,

una cosa... super esaltante.

Ma poi, molte settimane dopo, ho deciso
di aprire un nuovo progetto su Unity

per verificare cosa avevo imparato.

E la risposta era... nulla.

Letteralmente nulla.

Come se tutto mi fosse entrato da
un orecchio per uscire dall'altro.

Non riuscivo nemmeno a far apparire e
muovere un personaggio sullo schermo.

È stato terribile!

Ed è stata tutta colpa mia: ricordate il
mio video sui tutorial

in cui parlavo dei giochi di strategia e
le loro frecce "clicca qui", "clicca lì",

totalmente inefficaci
nell'insegnare alcunché?

Beh, ho fatto esattamente
la stessa cosa con Unity.

Mi sono fregato da solo.

Sparato sui piedi. Argh!

In tutta onestà, è stato
davvero demoralizzante.

Mi sono sentito davvero un idiota.

Avevo sprecato settimane della mia vita

senza nemmeno sapere se ero minimamente
tagliato per lo sviluppo dei videogiochi.

Se non sono nemmeno in grado di assorbire
qualcosa da un tutorial,

allora forse non sono portato.

Forse dovrei restare nel mio ambito.

È successo mesi fa.

Stavo pianificando di fare
la serie che state guardando,

e al tempo ho pensato
di lasciar perdere tutto.

Forse non dovrei annunciarla e far finta
che non sia mai successo niente.

È stato... schifoso.

Orribile.

Ma poi ho pensato ad Adobe Premiere.

È il software che uso per creare tutti
i video di questo canale,

un software piuttosto complesso
che però so usare, anche piuttosto bene.

Quindi come ho imparato
ad usare Premiere?

Quando lavoravo su Pocket Gamer, facevamo
delle semplicissime video-recensioni.

E così un collega mi insegnò
le basi di Adobe Premiere:

le conoscenze di base
necessarie per creare un video.

Come importare i filmati,
inserirli nella timeline,

applicare delle semplicissime transizioni,
ed esportare il tutto su YouTube.

Poi ho creato da solo dozzine
di queste video-recensioni.

Ho in pratica dovuto ripetere più e
più volte questi passaggi di base

mentre lentamente si facevano strada
nel mio cervello.

Poi ho creato Game Maker's Toolkit.

A quel punto ho voluto fare video
con elementi più interessanti.

Ho voluto usare maschere, colori, testi,
transizioni, motion graphic

e tutta quella roba divertente.

Avrebbe dovuto essere
molto difficile da imparare.

Ma avevo due frecce al mio arco:

primo, non ho avuto bisogno
di imparare tutto in una volta sola.

Provando ad inserire almeno un nuovo
elemento in ogni video che creavo,

potevo imbastire con calma un repertorio
di effetti e conoscenza.

E secondo: grazie a quelle video-recensioni,
avevo molta familiarità con Premiere.

Ero a mio agio con il software e così ogni
volta che volevo provare qualcosa di nuovo

me la sentivo di sperimentare
e divertirmi.

O, quantomeno, sapevo cosa
digitare su Google

per avere le risposte che mi servivano.

In definitiva, per imparare ad usare Premiere
ho usato un'astuta formula in tre step:

step 1, imparare le basi e niente di più.

Step 2, familiarizzare con quelle basi
attraverso ripetizioni e semplici progetti.

E poi 3, lentamente, nel tempo, imbastire
un repertorio di strumenti in Premiere

mentre accumulavo, accumulavo e accumulavo
la base della mia conoscenza del software.

Ed evidentemente per me ha funzionato
decisamente bene.

Ora so usare Premiere.

So fare praticamente
qualunque cosa voglia.

E penso di aver capito
perché ha funzionato.

Vedete, nella creazione dei video capita
spesso di avere delle idee:

"Non sarebbe fantastico se ora ci fosse
un effetto-pausa in stile VHS?".

Devo quindi capire
come realizzare quell'idea.

Ovvero, come faccio a fermarmi
a quel fotogramma?

E poi che effetti dovrei usare per
abbellire questo effetto?

E poi come ottengo quella linea traballante
che scende lungo lo schermo?

E se ci pensate, c'è un numero infinito
di idee che potrei avere

quindi è fisicamente impossibile imparare
a realizzarle tutte all'inizio.

Posso però imparare ad avere familiarità
con i miei strumenti,

in modo che quando spunta
una di queste idee

io abbia già abbastanza sicurezza
e dimestichezza col software

per sperimentare e trovare
da solo una soluzione.

E conosco il contesto
di funzionamento del software,

quindi so dov'è il problema e quali
termini usare quando mi affido a Google.

O quando chiedo aiuto a qualcuno.

Ditemi se tutto questo non assomiglia
allo sviluppo dei videogiochi.

C'è un infinito numero di idee
che possono spuntare,

ed è impossibile conoscere
ogni approccio.

Quindi l'unica cosa che potete fare è
familiarizzare con gli strumenti,

così da avere delle soluzioni quando
sorgono questi problemi.

Forse posso quindi prendere
la mia struttura in tre step

- basi, familiarità, sperimentazione -
ed applicarla ad Unity.

Assomiglia ad un piano.

Proviamoci.

Fortunatamente non parto davvero da zero
quando si parla di sviluppo di videogiochi.

Ho familiarità con i fondamenti
della programmazione,

o quantomeno è quello che racconta
il mio profilo su Tinder.

Conosco l'istruzione if, il ciclo for,
le funzioni e cose del genere.

E ho giochicchiato con Game Maker, so più
o meno come funziona un motore di gioco.

Circa.

Ma devo capire come funziona Unity.

Si comincia con le basi, ovvero cos'è
questa UI, dove dovrei cliccare,

quali sono le scorciatoie da tastiera,
e cose del genere.

Inoltre devo capire il funzionamento
concettuale di Unity.

Ad esempio, Unity si basa sui GameObject.

Tutto in Unity è un GameObject.

E finché non capirete fondamentalmente
cosa significa, non farete progressi.

Se siete curiosi, un GameObject è
fondamentalmente un contenitore invisibile

descritto da posizione, rotazione e grandezza,

e che potete integrare con dei componenti
per fargli fare qualcosa.

Questo include uno sprite renderer
per dargli un'immagine,

un rigidbody per dargli la fisica,

un collider per farlo scontrare con altri
oggetti, ma soprattutto uno script

dove potete scrivere del codice
di programmazione.

Una volta capito, ho messo insieme una
lista di cose che avrei dovuto conoscere

per creare dei giochi.

Ad esempio, come posso far
comunicare due GameObject?

Come faccio comparire un GameObject
per poi eliminarlo?

Come faccio accadere qualcosa quando due
GameObject collidono?

Come creo l'UI, gli effetti sonori
e le animazioni?

Come si gestiscono i livelli, il game over
e cose del genere?

Ho quindi usato i tutorial, Google e ho
parlato con le persone

per rispondere a queste domande
e capire le basi di Unity.

Certo, probabilmente ci sono molti utenti
di Unity che stanno guardando questo video

e che pensano che non sia
una lista esaustiva.

Che così non andrò molto lontano.

E probabilmente, anzi -
certamente ci sono modi migliori

per fare tutte le cose
che ho appena imparato a fare.

Sì, è vero.

Ma è sufficiente per farmi iniziare.

So far apparire a schermo le cose,
farle muovere, creare collisioni,

generare e far scomparire -

sono gli elementi fondamentali che fanno
funzionare i giochi,

quel genere di cose agnostiche che dovrò
conoscere indipendentemente da come procederò.

Sono le fondamenta, il basamento
sul quale inizierò a costruire.

E così sono al secondo step: provare a me
stesso di aver capito queste cose,

familiarizzare con loro, ripetendomi e
creando semplici progetti.

E nello sviluppo di videogiochi,
il modo migliore per farlo

è attraverso l'antica arte del plagio.

Ovvero copiare giochi molto semplici, come
i giochi arcade, mobile, web, mini-games...

qualsiasi cosa abbia un gameplay
e delle regole davvero basilari.

Copiandoli posso provare a me stesso
di aver capito il funzionamento di Unity.

E penso che questo sia un ottimo
metodo di allenamento

perché si può tralasciare la grafica,
il design, le regole e cose del genere.

È già tutto pronto.

Bisogna concentrarsi solamente sul codice.

E avere un chiaro obiettivo in mente:

posso prendere questo gioco e ricrearlo,
in Unity, da solo?

Il primo gioco con cui ho provato
è stato Flappy Bird:

quel semplicissimo perditempo per iPhone

con quell'uccello obeso
alle prese con la gravità.

Sì, certo, ci sono dei tutorial su come
creare Flappy Bird in Unity.

Ce ne sono a migliaia.

Ma non ho voluto usarli.

Ho voluto fare da solo.

Ho iniziato giocandolo e
capendo come funzionava,

per poi pianificare
come lo avrei ricreato.

Era importantissimo che i passi
fossero il più piccoli possibile:

step uno, un uccello appare a schermo.

Step due, farlo cadere.

Step tre: farlo svolazzare.

Una cosa dopo l'altra, senza esagerare.

E poi ho iniziato a creare.

Ho fatto un GameObject, gli ho dato uno
sprite renderer per l'uccello,

un animation controller per farlo
svolazzare, un rigidbody per farlo cadere,

un box collider affinché
colpisca le colonne,

e uno script che alla pressione
della barra spaziatrice

applichi un po' di velocity
alla base del rigidbody

per far svolazzare in aria l'uccello.

Molto bene!

Poi ho creato le colonne, trasformandole
in un GameObject prefabbricato, o prefab,

che mi permette di generarne un numero
infinito ad altezze diverse.

Ed è qui che ho scoperto un trucco
dello sviluppo di videogiochi.

Vedete, intuitivamente si farebbe volare
l'uccello attraverso le colonne

ma è abbastanza difficile da fare.

È molto più semplice far rimanere fermo
l'uccello facendo scorrere le colonne

per poi cancellarle quando
spariscono dalla schermata.

Credetemi, mi sono sentito un genio
quando ci sono arrivato.

Poi ho dovuto implementare le collisioni

in modo che lo scontro tra l'uccello
e una colonna significasse game over,

mentre il passaggio dell'uccello tra due
colonne innescasse un trigger

che incrementa il punteggio
mostrato nell'UI.

Questo implicava inviare delle informazioni
da un GameObject all'altro:

era il momento di usare quella lezione
fondamentale che avevo imparato.

Ho poi concluso con qualche effetto sonoro

e alcune cose di base come il passaggio
delle nuvole con un effetto parallasse.

Ed è stato... meraviglioso!

So che sembra terribilmente insignificante:
"Complimenti tontolone,

hai rubato il gioco più semplice mai
creato, spero tu sia fiero di te stesso."

Però lo sono!

Lo sono, lo ero, lo sono,
sono fiero di me stesso.

Ho scelto un gioco esistente, l'ho scomposto,
e ricreato da solo in Unity.

Ho dimostrato di sapere come funziona Unity
facendolo funzionare tutto da solo.

È stato grandioso e decisamente migliore
rispetto a quella sensazione demoralizzante

che ho provato approcciando Unity
per la prima volta.

In effetti è stato così bello
che l'ho rifatto,

questa volta col gioco Pop the Lock,

dove una linea ruota attorno ad un cerchio
per collezionare altri cerchi...

anche questo è semplice,
ma davvero coinvolgente.

Il processo è stato
praticamente lo stesso:

giocare, fare della retroingegneria per
avere una sorta di pseudo design-document.

Scomporlo fin nei più piccoli passaggi, come
l'avere un oggetto che ruota per lo schermo,

e crearlo step-by-step.

Ci sono stati dei grossi problemi
perché è basato sulle rotazioni,

e in Unity le rotazioni usano questa
cosa chiamata "quaternions",

una sorta di asse di rotazione
quadridimensionale.

E il cervello mi è fuoriuscito
dalle orecchie

quando ho letto qualcosa a riguardo,
tanto era difficile.

Ma ho scoperto questa bella funzione
nativa di Unity chiamata ".RotateAround'

che permette di ruotare un GameObject
attorno ad un punto,

risolvendo così molti dei miei problemi.

E ora è nei miei banchi di memoria
per il futuro.

Ho anche scoperto questa figata dei
GameObject parent e child,

e anche questo ha risolto molti problemi.

E così, nuovamente, avevo un gioco
funzionante nel mio computer,

e in quel momento è stato fighissimo.

Non posso spiegarlo, ma era una sorta di
"ce l'ho fatta!"

Avevo un obiettivo: creare questo gioco.

E ce l'ho fatta.

E la cosa più importante era che avevo
dimostrato di saper usare Unity

e stavo accrescendo la familiarità
con i suoi strumenti.

I problemi che ho dovuto risolvere
mentre creavo quel gioco

non avrei potuto risolverli all'inizio,
mentre ora sì,

perché so dove cliccare, so dove guardare,
so cosa digitare in Google.

E così in questo momento sono
abbastanza a mio agio con Unity.

Non sono sicuramente un esperto...
ma ho un punto di partenza.

E penso che ora dovrei passare
al terzo step:

iniziare a creare i miei giochi e
iniziare a sperimentare.

Certo, andrò incontro a problemi.

Ci sono cose che non so come fare.

Affronterò dei problemi.

Ma ora ho sicurezza e dimestichezza
con gli strumenti.

Comprendo Unity a livello concettuale.

Comprendo le cose di base
che devo saper come fare,

e così, da questo momento, quando
mi imbatterò in un problema,

sarò probabilmente in grado
di risolverlo, forse.

Perlomeno potrò armeggiare, e quantomeno
saprò cosa digitare in Google.

O saprò come formulare una domanda per
qualcuno che è molto più brillante di me.

Non posso garantire che questo stile di
apprendimento funzioni anche per voi.

Ognuno apprende in modo diverso,

e forse vi piace che qualcuno vi spieghi
le cose con un accento svedese.

Ma per me, qualcuno che si annoia
molto facilmente con i tutorial -

forse soffro di ADHD, non lo so -

che ha bisogno di sperimentare
e armeggiare e fallire

per farsi entrare le cose nel cervello,
questo approccio ha funzionato.

Imparare le basi, familiarizzare con esse,

per poi costruire lentamente un repertorio
nel corso del tempo.

Immagino che vedremo se funziona davvero
nel prossimo episodio di questa serie

quando inizierò a sviluppare il mio gioco
e a creare un prototipo.

Sperò che sarete con me.

Per ora, so che questa non è
una serie composta da tutorial,

ma se guardando
vi capitasse di pensare:

"Cavolo, Mark, mi piacerebbe che
mi insegnassi le basi di Unity",

beh, fatemi sapere nei commenti
se vi sarebbe utile,

e, tempo permettendo, potrei riuscire
a fare un veloce video tutorial

che accompagni questa serie.

Per ora, però, grazie per la visione.

E alla prossima.

La batteria di questa luce
si scaricherà molto presto.

Ma... sono fiero di te.

click