Sei sulla pagina 1di 82

Unity 3D – 01 – Cos’è Unity?

Piuttosto doveroso iniziare con qualcosa del genere, no? Certo, molti di voi già sanno (o comunque
immaginano) cosa sia Unity3D. Ma dato che vorrei prendermela con calma per potervi offrire una
guida piuttosto completa sotto vari ambiti, questo primo “capitolo” della guida sarà dedicata a
spiegarvi nel dettaglio cos’è Unity, cosa ci potete fare, cosa non ci potete fare e quali sono le sue
caratteristiche più importanti.

Unity3D è un ambiente di sviluppo creato appositamente per la creazione di giochi. In passato


le cose erano leggermente diverse, ma oggi si adatta perfettamente a tutte le soluzioni di cui avete
bisogno: giochi in 2D, 3D, per PC, Mac, iPhone e addirittura per Nintendo Wii, senza tralasciare
Xbox360 e Sony Playstation 3. Un ambiente completo, il cui obiettivo è semplice: fornire degli
strumenti affidabili per togliere molto del lavoro “sporco” al
designer/programmatore/creatore/semidio, per consentirgli di concentrarsi molto di più su aspetti
come la creatività, le idee e tutti questi aspetti altamente importanti nella realizzazione di un titolo
effettivamente di successo.
Ok, dopo questa pomposa introduzione già vi starete chiedendo: “va bene, ora abbiamo una mezza
idea… ma cosa offre di preciso questo ambiente di sviluppo?”. Dunque, come tale gli strumenti che
vengono offerti sono molti: innanzitutto abbiamo un potente engine di supporto grazie al quale i
nostri giochi girano.
Il motore in questione, sviluppato ovviamente dai ragazzi di Unity Technologies, offre il supporto
completo per tutti quegli aspetti vitali di un gioco: rendering grafico, effetti di luce, creazione di
terrain, simulazioni fisiche, implementazione dell’audio, funzionalità di rete per il proprio gioco
(quindi per consentire eventuali partite in multiplayer) e come giusto che sia, un sistema di
scripting.
A quei pochi che non ne siano a conoscenza: per scripting intendo tutte le funzionalità legate alla
personalizzazione del codice del gioco. Grazie allo scripting infatti costruiremo la logica legata ad
ogni aspetto del nostro prodotto finale. Menù, schermate di gioco e caricamenti: tutto avviene
secondo quello che gli script dicono al motore di gioco.
Oltre ad offrire un engine particolarmente efficiente (a breve guarderemo in dettaglio tutti gli
aspetti) vengono offerti svariati tool adatti a realizzare qualsiasi tipo di lavoro: per esempio un
costruttore di mondi oppure un tool per gestire l’audio di gioco. Il progetto può essere inoltre
“agevolato” grazie a piccole feature di qualità, come per esempio la cosiddetta “live preview”,
ovvero la preview dal vivo di quello che si sta creando, con un solo click. Il tutto ovviamente
accompagnato da un ottimo sistema di gestione delle risorse da usare nel gioco (parlo dei modelli
3D, immagini, file audio o tutto ciò che può essere “creato” all’esterno).
Giusto per rendervi conto, ecco un po’ di liste di formati di file supportati dall’engine.
Modelli 3D:
• Maya
• 3D Studio Max
• Cheetah
• Cinema 4D
• Blender
• XSI
• Lightwave
• Wavefront Obj
• Carrara
• SketchUp
Per quanto riguarda le immagini, invece, i formati supportati sono JPEG, PNG, GIF, BMP, TGA,
IFF e PICT. Anche a livello di audio il sistema si difende piuttosto bene: abbiamo il supporto per
MP3, Ogg Vorbis, AIFF, WAV. Per i video, infine, abbiamo il supporto per MP4, MPG, AVI,
MOV, ASF e MPEG.
Ad essere sincero, quando l’ho scoperto ho pensato “di editor in passato ne ho provati, ma i risultati
non è che mi siano mai piaciuti un granché”. Sarà perché sono un viziato per certe cose, chi lo sa.
Fatto sta che per farmi un’idea ho dato uno sguardo alla gallery delle varie immagini… devo dire
che il risultato mi ha lasciato decisamente soddifatto!
Ecco due esempi di immagini: in una potete ammirare l’efficienza del generatore di terrain, mentre
nell’altra c’è un ottimo esempio di quello che il motore può fare per quanto riguarda il rendering e
l’illuminazione.
Per essere gratuito non è male vero? Ah si, quasi scordavo di dirlo… Unity3D è gratuito,
ovviamente. Ci sono alcuni costi da sostenere, in alcuni casi (lo spiegherò tra qualche lezione) ma
per quello che faremo noi non ci sarà nessun costo.
Prima di concludere questa brevissima introduzione per passare quindi ad analizzare un po’ le varie
soluzioni e i costi, c’è da parlare anche della grande facilità di pubblicazione del prodotto creato con
questo ambiente di sviluppo. Senza troppi problemi, infatti, permette di pubblicare con pochi
click il proprio gioco su più piattaforme: parlo di PC, Mac, iPhone e tutti quelli precedentemente
menzionati. Senza parlare ovviamente del Web: la Unity Technologies ha sviluppato un player da
inserire direttamente nella propria pagina web. Con un computer abbastanza performante, quindi,
potremo giocare ad uno sparatutto direttamente dal nostro browser.
Le distinzioni ovviamente sono a livello di codice, tramite alcuni blocchi condizionali ben definiti.
Altre funzionalità implementate, invece, permettono l’adattamento automatico di texture, modelli e
audio in base alla piattaforma di destinazione: su iPhone quindi il nostro gioco occuperà molto
meno senza dover fare lavori di compressione e ridimensionamento.
Detto questo possiamo concludere la nostra introduzione e passare alla lezione successiva. Nel
prossimo articolo daremo uno sguardo alle varie soluzioni contemplate: cosa possiamo ottenere
gratuitamente, cosa, eventualmente, si deve pagare e quali sono effettivamente i costi.
Unity 3D – 02 – Costi e Soluzioni

Come già detto nell’articolo precedente, Unity3D è gratuito in quasi tutte le sue features. Tuttavia,
per particolari scopi o esigenze di pubblicazione, ci sono alcuni strumenti o parti del sistema che
sono a pagamento. Lo scopo di questo articolo sarà quello di farvi capire precisamente cosa ottenete
gratuitamente e cosa dovete pagare. Soprattutto, quanto dovrete pagarlo.
Partiamo innanzitutto dalle nostre necessità: escluderemo per ora le versioni iPhone e quelle
dedicate alle altre piattaforme, concentrandoci solo sul PC. Le possibilità quindi scendono a due:
nella sezione Store del sito potremo infatti scegliere tra “Unity” e “Unity Pro”. Ovviamente già
avete capito cosa sto per dire.

Unity è la versione “base” che viene rilasciata gratuitamente senza nessun tipo di problema per
quanto riguarda i costi. Quasi tutte le funzionalità più importanti sono messe a disposizione dal tool,
mentre la cosa cambia per l’altra versione. Unity Pro consente allo sviluppatore (o al suo team) di
ottenere tutti i vantaggi delle varie features.
Ecco un elenco contenente tutte le features presenti in Unity Pro che invece NON sono presenti in
Unity “base”:
• Filtri Audio – utilizzati per effettuare delle operazioni sui file audio, per dare loro degli
effetti ben precisi e creare un’atmosfera più immersiva;
• Riproduzione di Video – la descrizione parla da se: i video possono essere messi su un
piano 3D o riprodotti come avviene normalmente;
• Asset Bundle – un modo veloce di “espandere” il nostro gioco, nel caso volessimo creare
nuovi contenuti ed implementarli al volo;
• Assenza dello Splash Screen di Unity – una schermata iniziale che mostra il logo di Unity;
• Size Stripping – alcune parti del motore, nel caso non vengano utilizzate, vengono
eliminate dal “bundle” finale, per risparmiare spazio;
Questo per quanto riguarda le features più “generali”. Per la grafica invece gli aspetti tagliati fuori
dalla versione base sono i seguenti:
• Lightmap ad Illuminazione Globale – aggiunge un maggiore realismo al nostro gioco
tramite alcuni effetti di luce;
• Static Batching – procedura utilizzata per risparmiare CPU durante l’esecuzione del gioco;
• Effetti Render to Texture – utilizzati nella creazione di ambienti con acqua realistica e
superfici di questo genere;
• Effetti di Post Processing – effetti spesso utilizzati nei giochi come il Motion Blur, Glow e
così via;
• Accesso di basso livello al Render – utilizzato dai più esperti per gestire le routine di
rendering modificando direttamente il codice;
• Occlusion Culling – tecnica adatta all’ottimizzazione del nostro gioco, per fornire un
rendering molto più veloce;
• Ombre in Tempo Reale – ombre create in tempo reale in base alla situazione di gioco: è
possibile comunque realizzarle anche nella versione base con qualche trucco;
• Deferred Rendering – modalità di rendering che permette scene più realistiche con molto
meno utilizzo delle risorse;
Infine, ecco quali sono le caratteristiche assenti per quanto riguarda l’utilizzo del codice e la sua
modifica, oltre ai tool non presenti nell’ambiente in se.
• Supporto del Codice Nativo – utilizzabile dagli sviluppatori più esperti per entrare nel vivo
delle routine del motore, ottimizzandole in base alle esigenze;
• Profiler – tool molto efficiente in grado di ottimizzare il gioco fornendo una grande quantità
di statistiche di vario genere (rendering, utilizzo delle risorse e.c.c);
• Supporto Esterno a controllo di versione – un supporto per il salvataggio dei metadati
relativi alla versione attuale del gioco in fase di sviluppo in sistemi esterni (Subversion,
Perforce e.c.c);
• Accesso all’Asset Pipeline – accesso diretto alla pipeline delle risorse di gioco tramite il
sistema di scripting;
• “Dark” Skin – skin da utilizzare per il proprio ambiente di sviluppo, rendendola più scura e
simile all’interfaccia di programmi come 3D Studio Max o Maya.
Subito ci sono due cose che appaiono chiare: alcune features sarebbero state interessanti, ma
purtroppo non vogliamo pagare. Altre features invece, tutto sommato, possiamo risparmiarcele (un
esempio su tutti la “Dark Skin”).
Tuttavia non temete: nonostante la lista da me appena sciorinata sappiate che il 90% delle features
del nostro ambiente di sviluppo sono tranquillamente utilizzabili. Per le nostre prime prove poi, non
credo avremo bisogno di effetti come il Motion Blur o l’accesso diretto al codice dell’engine.
Quindi non allarmatevi per nessun motivo.
Anche perché l’alternativa non sarebbe stata molto economica: al momento in cui scrivo la
versione Pro di Unity ha un costo di 1500$ per licenza. Le altre aggiunte disponibili all’acquisto
sono tre: supporto per iOS, supporto per iOS in versione “Pro”, quindi con maggiori features, ed
infine il supporto per tutti i dispositivi mobile che hanno Android come sistema operativo. I costi?
400$ per la versione iOS base, 1500$ invece se vogliamo la versione iOS Pro oppure la versione
Android. (Ricordate che questi costi vanno comunque ad aggiungersi ai 1500$ di partenza).
Esempio veloce:
• Volendo sviluppare titoli per Android pagheremo 1500$ di Unity Pro più 1500$ per l’addon
relativo ad Android.
• Volendo sviluppare titoli per iPhone spenderemo 1900$ (Unity Pro + iOS Base) oppure
3000$ (Unity Pro + iOS Pro)
Più chiaro di così non si poteva
Ovviamente non mancano le soluzioni dedicate allo sviluppo per Wii, PS3 e Xbox360. Tuttavia, per
avere un preventivo del prodotto in questo caso dovrete contattare direttamente la Unity
Technologies.
Bene! Ora abbiamo le idee più chiare per quanto riguarda i costi e le features proposte. Adesso
qualche momento di relax prima di iniziare: nel prossimo articolo vedremo un po’ di video ed
immagini di titoli realizzati con Unity.
Unity 3D – 03 – Casi ed Esempi

Unity si è rivelato più di una volta capace di aiutare gli sviluppatori di giochi a realizzare dei
prodotti validi. In questa pagina raccoglierò un po’ di esempi, casi di studio e video di giochi
realizzati con l’ambiente di sviluppo in questione.

Il primo caso, il più eloquente sulle potenzialità di Unity, è senza dubbio il titolo della EA “Tiger
Woods PGA Tour Online”, che nonostante venga eseguito da un browser presenta una grafica niente
male. Di seguito le immagini.
Qui di seguito invece ripropongo un video di un progetto, addirittura, di un MMOG realizzato da un
team composto da due artisti e un programmatore. A me è piaciuto davvero tanto vedere il tutto in
azione!

http://youtu.be/56kSBMiCK3Q

Altri video che ho visto, invece, trattavano di aspetti essenzialmente legati alla tecnica: effetti
particellari, demo reel, oppure dei menù realizzati diversamente dal solito. Ripropongo qui di
seguito altri due di questi video!

http://youtu.be/_6wKG_vITGw

http://youtu.be/kxdQQ0MS8WQ

Dopo questo popò di roba, per finire, vi rimando alla Game List sul sito stesso di Unity, dove
potrete osservare un po’ tutti i progetti per i quali è stato utilizzato questo IDE. Bene, adesso direi
che possiamo inizare a tradurre questa signora guida
Unity 3D – 04 – Cosa Realizzeremo

Benvenuti a tutti in questa nuova parte interamente dedicata alla guida su Unity, che ci porterà alla
realizzazione di un gioco vero e proprio! Lo so che non vedete l’ora di iniziare, che siete impazienti,
ma cercate di dare il giusto tempo a tutto quanto. In questo articolo cercheremo di vedere nel
dettaglio cosa andremo a realizzare, all’atto pratico. Per prima cosa, infatti, è sempre opportuno
avere bene a mente quale sarà il risultato che vogliamo ottenere prima di mettere le mani sul codice.
Questo tutorial che state seguendo vi porterà alla creazione di un piccolo platform 3D. Per
intenderci, lo stesso genere che conta nelle proprie file dei capolavori come Super Mario 64, Super
Mario Sunshine, Rachet & Clank, Beyond Good and Evil. Come avete letto questi titoli già avete
l’acquolina in bocca, vero?
Per rendere meglio l’idea, ecco un video trovato su Youtube, che mostra il lavoro di un utente alle
prese con questo tutorial!

http://youtu.be/hVwjlqPqyF4

Beh, sappiate che Unity vi da tranquillamente la possibilità di realizzare giochi simili, con i dovuti
sforzi, volontà, materiali e team. Ogni cosa è possibile, se davvero lo volete e vi ci mettete
d’impegno. Dopo questa frase piena di nobili intenti, perché non andare a vedere quali ambiti
della creazione di giochi andremo a toccare?
Questo tutorial, proprio come fa Unity, coprirà vari argomenti e settori:
• Controller dei Personaggi (Character Controllers)
• Projectors
• Audio (Listener, Sources e Files)
• Telecamere Multiple (e come passare da una all’altra)
• Il sistema di Scripting dedicato all’interfaccia UnityGUI
• Collisioni
• Messaggi ed Eventi
• Gestione e Creazione di Luci
• Sistemi di Particelle
• Ombre
• Scripting (gestione di ogni aspetto: IA, stati del gioco, controlli e.c.c.
Quindi, come potete vedere, questo tutorial offrirà davvero un bel po’ di spunti e di argomenti: la
versione originale (in inglese) la potete trovare sul sito ufficiale di Unity. Potete trovare anche tutti i
file da utilizzare per il corretto svolgimento delle operazioni: modelli, audio e tutto ciò che serve. In
questo caso anche questo pacchetto si trova sul sito ufficiale di Unity (link).
Una nota importante: questa guida presuppone una certa “abilità” nell’uso di Unity. Non vi
spaventate, richiede delle conoscenze piuttosto basilari, ma le richiede. Essenzialmente, si
richiede di poter capire il codice e di eseguire operazioni base con l’IDE, come per esempio
posizionare una risorsa nella scena oppure aggiungere un componente a un GameObject.
Se conoscete già le basi non ci saranno problemi, altrimenti, man mano che andrò avanti,
provvederò io a creare degli articoli di “approfondimento” di queste operazioni basilari, in modo
tale da venirvi incontro il più possibile. Per quanto riguarda il codice, invece, partendo da quelli
offerti nella guida aggiungerò, dove necessario, altri commenti per rendere le cose ancora più
comprensibili.
Detto questo, quindi, possiamo iniziare a dare uno sguardo veloce a quella che è l’organizzazione
del progetto, sotto il punto di vista relativo ai file utilizzati e al loro posizionamento.
Unity 3D – 05 – Organizzazione dei Progetti

Come in ogni progetto che si rispetti, una buona organizzazione è essenziale alla buona riuscita.
Una buona gestione dei file, script e risorse in generale è essenziale per permettere agli sviluppatori,
artisti e designer, di potersi mettere d’accordo e lavorare in armonia. Anche se si lavora da soli
questo è un aspetto da non sottovalutare: adottare una buona politica nell’organizzazione del
proprio progetto aiuta anche a darsi, in prima persona, un’organizzazione mentale adeguata,
particolarmente utile nel caso si voglia aggiornare il proprio gioco in futuro.

In Unity viene lasciata la massima libertà all’utente per quanto riguarda la gestione degli asset e
file del progetto. Ovviamente ci sono i cosiddetti “standard” particolarmente consigliati. Per i
piccoli progetti, in genere, si usa raggruppare tutti i vari contenuti in cartelle separate, in questo
caso in base alla tipologia.
Avremo cartelle, quindi, come “texture”, “modelli”, “suoni”, “script” e così via. Ripeto, tutto questo
è particolarmente adatto in situazioni di sviluppo piuttosto piccole, individuali o comunque piccoli
team. Secondo alcune ricerche effettuate dai ragazzi di Unity Technologies (quindi non sono cose
che ho potuto verificare personalmente) nell’ambito di un progetto più grande le cose variano: al
posto di suddividere le cartelle del progetto in base alla tipologia della risorsa, si utilizza un
approccio più orientato verso le “entità” in gioco. Avremo quindi delle cartelle come “personaggi”,
“nemici”, “scenari” e così via.
Per quanto riguarda il nostro progetto di prova, del quale parleremo nella nostra guida, l’approccio
utilizzato è stato incentrato su un team di sviluppo piccolo. Di conseguenza l’organizzazione dei file
è stata mantenuta di conseguenza, anche per rimanere sulla stessa linea dell’originale.
Inoltre, è opportuno parlare anche dei cosiddetti “oggetti astratti”, che in inglese sono stati
menzionati come Abstract GameObjects. Dovete sapere, infatti, che Unity ha un approccio molto
orientato al posizionamento degli oggetti, delle scene, in modo piuttosto veloce, e così via.
L’avrete notato anche voi, e avrete visto anche quali possono essere le differenze, nel caso siate
(invece) abituati a lavorare con il codice per il 90% del tempo del percorso di sviluppo.
Le cose qui cambiano: alcuni oggetti sono visibili tranquillamente, altri invece sono astratti. Gli
oggetti astratti sono tutti quelli che esistono, ci sono, fanno effettivamente qualcosa. Ma non
vengono visualizzati. Un esempio può essere una sorgente audio, che riproduce un suono ma non
produce nessun effetto “visivo”. O ancora meglio, uno script.
Per Script intendiamo una risorsa che ha come obiettivo quello di “descrivere” l’interazione di un
GameObject all’interno della sua scena d’appartenenza. Grazie ad essi riusciamo a definire un sacco
di cose: come muovere il personaggio nella scena in cui ci troviamo, come programmare
l’intelligenza dei nemici che combatteremo o magari gestire un menù.
Ok, penso che iniziate ad avere le idee chiare… oppure no? GameObject, Scene, Script,
interazioni… ho usato tanti di quei paroloni che magari vi ho anche incasinato la testa. Bene, prima
di continuare allora poniamo un rimedio a questa situazione!
Nel prossimo articolo, infatti, faremo una piccola carrellata di termini e terminologie legate ad
Unity ed al suo uso. In questo modo avrete tutto molto più chiaro
Unity 3D – 06 – Un Po’ Di Terminologia

Nei prossimi capitoli della guida dedicata a Unity useremo termini che, probabilmente, non avete
mai sentito prima. Progetti, Scene, Oggetti, Gerarchie… ci sono un bel po’ di cose da capire e da
tenere sempre a mente, in modo tale da avere presente la visione nel suo insieme, senza dover tutte
le volte stare li a cercare di capire “cosa vuol dire”. Questo articolo, che precede l’inizio della
pratica vera e propria, ha come obiettivo quello di spiattellare un po’ di termini “tecnici”
utilizzati dai ragazzi di Unity Technologies.
Non vi spaventate se vedrete che il grosso dei termini (se non tutti) non riguardano il codice. Unity
è uno di quegli IDE che mette al centro delle priorità le risorse, il loro posizionamento dello spazio.
Il codice, per quanto importante, è nell’intorno.
Iniziamo!
Nota: metterò sia i termini in inglese che una “traduzione” maccheronica in Italiano. Non ho la
presunzione di voler usare i miei termini come standard, sia chiaro…
Projects (Progetti)
Ogni gioco realizzato in Unity è identificabile, nel contesto dell’ambiente di sviluppo, come un
Progetto. Un progetto contiene tutti gli elementi che il vostro gioco include. Parlo di modelli, script,
livelli, menù: tutto. In genere, quindi, un singolo file di progetto contemplerà tutti i file utilizzati
dalla vostra creazione. Di default, l’IDE di Unity al primo avvio presenta il progetto Island Demo.

Una Visuale del Progetto “Island Demo”


Scenes (Scene)
Ogni Project a sua volta contiene degli elementi chiamati Scenes. Una singola scena può avere
svariati compiti: dal contenere un singolo livello (l’uso più intuitivo) oppure degli elementi di
interfaccia, come per esempio un menù. Nei progetti più grandi e complessi, addirittura, una scena
può servire anche solo come “contenitore” per tutte quelle funzioni logiche di caricamento dei
contenuti e risorse.
Pensate infatti a progetti davvero grandi, con gigabyte di risorse da caricare. Non è un qualcosa che
avviene nell’immediato, per cui si potrebbe usare una scena per gestire il tutto al meglio. Non vi
scervellate però, in caso lo vedremo più avanti.
Da qui, quindi, possiamo trarre una conclusione importante: ogni livello di gioco è una scena, ma
non tutte le scene sono un livello di gioco.
Dopo aver parlato di scene e progetti possiamo entrare ancora di più nel dettaglio. Aprite bene le
orecchie, perché sto per parlare di uno dei legami più importanti di Unity.
GameObjects, Components, Assets e Prefab
(stavolta non traduco)
Iniziamo dalla prima voce della nostra lista: un GameObject è qualcosa che può essere considerato,
a tutti gli effetti, come la base di tutto ciò che viene creato con Unity. Come la guida originale
spiega: un mattone, a tutti gli effetti. L’elemento essenziale. Un mattone però piuttosto particolare:
si può identificare infatti come un “contenitore” di pezzi differenti e funzionalità. Questi “pezzi”
vengono chiamati Components. In genere, un GameObject contiene più di un singolo Component.
In molti casi uno di questi, per esempio, è il cosiddetto Transform Component, che si occupa di dare
una posizione nello spazio e un orientamento all’entità presa in considerazione.
Partendo da questa nozione, aggiungeteci un’altra osservazione: un GameObject può contenere un
altro GameObject. Per farvi capire al meglio il concetto, immaginate una cartella che contiene
svariati file. Oltre a contenere questi file, contiene altre cartelle con altri file al loro interno. Così è
più chiaro, vero?

Ora che tutto è più chiaro possiamo parlare dei Components. Siamo nel cuore vero e proprio dello
sviluppo con Unity. Senza i Components non ci sarebbe niente, dato che possono rappresentare
svariate tipologie di entità: un entità visibile, come un modello, materiale, sistema di particelle o
dati relativi a un terrain.
Altri Components, invece, sono astratti ma sempre essenziali al progetto: telecamere, oppure luci.
Un Componente è SEMPRE collegato ad un GameObject. Senza di esso non esiste e non può
essere utilizzato. Ad un GameObject si possono collegare più Components di un certo tipo:
per esempio possiamo collegare tutti gli script che vogliamo ad un GameObject a nostra
scelta.
Altri Components, invece, sono esclusivi. Per esempio un sistema di particelle (Particle
System). Nel caso volessimo definirne di più nello stesso oggetto, allora utilizzeremo più
GameObjects da mettere poi in uno “padre” che faccia da contenitore.
Spiegato per bene il ruolo dei Components, scendiamo ad un gradino più in basso. Arriviamo agli
Assets, che in poche parole sono quelle “risorse” allo stato naturale, “grezzo”, per così dire. Stiamo
parlando di texture, file audio, oppure un oggetto leggermente più complesso come il Prefab,
ovvero un GameObject “prefabbricato”, appunto.
Eccoci arrivati ai Prefab. Volendo dare una spiegazione corretta, possiamo dire che sono degli
Asset definiti seguendo le linee guida di un preciso template (seguendo quindi delle regole ben
precise e predeterminate). Quando posizioniamo in una scena un Prefab, creiamo un’istanza di
questo. In questo modo, qualsiasi modifica noi effettueremo sull’originale, verrà automaticamente
riflessa su ogni istanza presente nel livello.
Il vantaggio di una tale politica è ovvio: pensate ad una scena dove dovete, per esempio, far sbucare
fuori una quarantina di nemici dello stesso tipo. Non dovrete di certo realizzare quaranta nemici
diversi, ma basterà crearne uno (e buono) e realizzare tutto più semplicemente!
Prima di concludere, una nota piuttosto importante: una volta creata un istanza di un Prefab, non
è possibile collegarci altri components. Nel caso l’utente cerchi di fare una cosa del genere,
automaticamente verrà notificato e quindi ogni legame con il Prefab originale verrà spezzato.
Detto questo, direi che come introduzione è sufficiente… nel prossimo capitolo della nostra guida
inizieremo a vedere qualcosa che di sicuro vi piacerà: inizieremo a smanettare con il nostro tool,
creare e controllare il personaggio, gestire entità logiche come vita, morte, rinascita del
personaggio, aggiungere ombre e così via.
Unity 3D – 07 – Creiamo il nostro Personaggio

Finalmente, è giunto il momento di iniziare a lavorare nel vero e proprio senso della parola. Negli
articoli precedenti ho cercato di spiegare per sommi capi quello che avremmo fatto, cosa ci sarebbe
servito. Adesso possiamo passare alla fase successiva. Nei prossimi articoli, seguendo il filo della
guida originale, ci occuperemo di creare il nostro personaggio in tutti i suoi aspetti.

Precisamente, ecco cosa faremo:


• Vedremo come implementare la telecamera in terza persona ed i controlli del nostro
personaggio;
• Gestiremo le varie animazioni da utilizzare e capiremo come passare da una all’altra;
• Utilizzeremo un sistema di particelle per simulare il JetPack del personaggio;
• Aggiungeremo un’ombra al nostro personaggio;
• Capiremo come gestire lo “stato” del nostro personaggio, ovvero tutte le variabili legate alla
salute e.c.c;
• Di conseguenza vedremo come gestire morte e rinascita del nostro personaggio;
Vi piace come programma eh?
Come ogni gioco che si rispetti, anche questo demo ha un suo plot.
La Storia
Il protagonista di questo gioco si chiama Lerpz: è un alieno che sta visitando il Robot World
Version 2. Al nostro eroe non mancano gli imprevisti: la sua navicella, infatti, è stata sequestrata
dalla polizia locale, palesemente corrotta. Il cattivo di turno sarà un certo Mr. Even Bigger. Lo
scopo del demo? Muovere il caro Lerpz nell’area di gioco, collezionare più barili di carburante
possibili, in modo tale da usarli per mandare in sovraccarico i sistemi di sicurezza di Robot World
Version 2 e poter usare liberamente la sua nave per fuggire. Mr. Even Bigger tuttavia ha pensato un
po’ a tutto: ha infatti assunto delle guardie per complicare le cose al nostro eroe. Tuttavia,
fortunatamente per noi, queste guardie non saranno poi così intelligenti per costituire un vero
problema.
Direttamente nell’Azione
Ora che abbiamo una vaga idea di quale sia la storia, buttiamoci a capofitto nell’azione. Mi
raccomando, sappiate che do per scontato che avete preso tutti i file necessari (ho spiegato dove
prenderli qualche articolo fa).
Si comincia!!!
• Apriamo Unity 3D;
• Dalla cartella delle Scene, apriamo la scena TheGame;
a questo punto, ci ritroveremo davanti quella che sarà il nostro luogo principale di ambientazione
del demo. Direi quindi di fare un altro passo avanti, cercando tra gli asset il nostro Lerpz per
aggiungerlo.
• Nel pannello di progetto, apriamo la cartella Objects: troveremo il prefab di Lerpz;
• Facendo del semplice Drag’n’Drop (click e poi trascina) prendiamo il prefab e
mettiamolo nella vista della scena, oppure nella vista gerarchica (Hierarchy);
• Diamo un nome da usare come riferimento: cliccando sul prefab di Lerpz nel pannello
Hierarchy, assegniamo ad esso il nome di “Player”;
• Lasciando selezionato il Prefab di Lerpz, premiamo il tasto F sulla tastiera: questo servirà
a centrare la visuale su di esso (un piccolo trucchetto da tenere a mente per il futuro);
• Adesso possiamo prendere il personaggio dalla scena e spostarlo in quello che sarà il suo
punto di partenza: il Jump Pad metallico, vicino la prigione;
• Proviamo la demo: clicchiamo sul pulsante Play, e vediamo che succede!
Non vi aspettavate un granché, vero? E facevate bene: d’altronde non abbiamo fatto altro che
mettere nella scena gli oggetti che ci servono! Quello che ci apparirà ora è piuttosto prevedibile: un
mondo non ancora interattivo, dove vengono caricati i modelli ma non succede niente, non c’è
nessuna interazione.
Fermiamo l’esecuzione del demo, tornando alla modalità di modifica. Prima di iniziare a pensare al
“come muovere Lerpz” facciamo un passo indietro: spendiamo due parole riguardo ad un
argomento molto, molto importante.
Stiamo parlando della telecamera in terza persona.
La Telecamera in Terza Persona (Third Person Camera)
Se qualcuno di voi ha provato la famosa IslandDemo, avrà notato senza dubbio il tipo di
telecamera: in prima persona, proprio come in un qualsiasi FPS. Per il nostro platform, tuttavia,
complicheremo un po’ le cose: la telecamera da usare, infatti, sarà in terza persona.
Come i più perspicaci di voi avranno già immaginato, la telecamera in terza persona può dare
qualche grana in più rispetto ad una prima persona. Le domande che subito vengono spontanee,
infatti, possono essere:
• Che succede se ci ritroviamo a dare le spalle al muro, con il nostro personaggio? La
telecamera deve andare in alto e guardare da li il giocatore, oppure spostarsi sui lati del
muro?
• Che succede se un nemico si ritrova tra la telecamera e il nostro personaggio?
• Come devono funzionare i controlli del giocatore? Potrebbero esserci degli imprevisti nel
caso questi siano regolati “relativamente” alla telecamera e la telecamera dovesse
spostarsi in maniera imprevista.
Come vedete, non manca più di un interrogativo a riguardo.
Beh, sappiate che nel corso degli anni i tentativi nel cercare un sistema perfetto sono stati molti. Ne
sono stati trovati altrettanti, probabilmente, ma se c’è qualcosa di sicuro è che nessuno di questi è
effettivamente perfetto in tutti i possibili casi contemplati.
Alcune soluzioni hanno visto ridurre l’opacità di tutti gli oggetti tra il giocatore e la telecamera,
altre soluzioni invece hanno permesso di muovere la telecamera oltre i confini di muri e ostacoli, in
modo tale da seguire comunque il giocatore. Come potete immaginare, sono soluzioni che bene o
male hanno funzionato, ma da qui a raggiungere la perfezione ce ne sta di strada.
La Telecamera con Unity 3D
Fortunatamente, Unity come al solito ci evita il grosso del lavoro, e ci da la possibilità di utilizzare
uno dei suoi script già fatti per gestire questo aspetto. In questo demo, infatti, utilizzeremo lo script
“SpringFollowCamera”. Come fare a renderlo operativo? Semplice.
• Dal pannello di progetto, prendere lo script SpringFollowCamera, e trascinarlo
sull’oggetto NearCamera nel pannello Hierarchy;
• Cliccate su Play e…
ERRORE! Non avverrà nessuna riproduzione: avete incontrato il vostro primo errore su Unity. Se
siete “novizi” questo sarà uno degli errori più frequenti. Nel caso non sia già visibile, aprite la
finestra di debug tramite la combinazione di tasti Shift + Ctrl + C.
Verranno mostrati un bel po’ di errori, anche se la maggior parte sono simili se non uguali. Per
essere precisi, l’errore che viene fuori è di tipo UnassignedReferenceException. Non vi
preoccupate, non è niente di grave: semplicemente, il problema riguarda una qualche variabile dello
script che non è stata assegnata.
• Clicchiamo sulla NearCamera nel pannello Hierarchy, e successivamente clicchiamo
sullo script SpringFollowCamera per vederne le proprietà.
• Osserviamo la proprietà Target: è impostata su None (Trasform)! Questo vuol dire che
attualmente la nostra telecamera non ha nessun obiettivo da riprendere. Sappiamo però
che le cose dovrebbero andare diversamente: la nostra telecamera deve seguire Lerpz. Per
cui ecco cosa dobbiamo fare: tramite il solito drag’n’drop prendiamo Lerpz e
trasciniamolo sulla proprietà Target della SpringFollowCamera, per fare in modo di
mettere le cose a posto.
Maledizione! Cliccando su Play pare che le cose non siano cambiate per niente, ottengo ancora
degli errori!
Tranquilli, il nostro lavoro non è ancora finito.
Dovete sapere, infatti, che utilizzando questo script sarete strettamente vincolati alla necessità di
gestire correttamente i comandi del personaggio, dato che la telecamera segue effettivamente il
personaggio. Questo vuol dire che il target della telecamera deve avere associato uno script di tipo
ThirdPersonController.
So che potrebbe non essere molto chiaro come concetto. Starete infatti pensando: la telecamera è la
telecamera, e non deve fare altro che seguire il giocatore. Perché devo determinare i comandi del
giocatore per far funzionare la telecamera?
La risposta è semplice: la telecamera segue il giocatore, e si sposterà come conseguenza dei suoi
movimenti. Non scordatelo
Bene, direi che per ora è tutto. Nel prossimo articolo vedremo come utilizzare al meglio il
ThirdPersonController e capire quindi come far muovere per bene il nostro personaggio!
Unity 3D – 08 – Definiamo i Controlli

Durante il nostro ultimo incontro abbiamo visto come fare per creare una telecamera in terza
persona, che seguisse il nostro personaggio. Abbiamo visto, però, che sono rimasti ancora dei
problemi da risolvere. Questo perché dobbiamo ancora collegare un altro script al GameObject di
Lerpz.
Stiamo parlando del ThirdPersonController. Iniziamo subito!

Proprio com’è accaduto per l’altro component, le cose sono piuttosto semplici:
• Nel pannello di progetto, selezioniamo lo script ThirdPersonController dalla cartella
Scripts –> Player.
• Una volta trovato, trascinarlo (drag’n’drop come sempre) sul nostro Player. Fatto questo,
ricordate che la connessione con il Prefab originale verrà spezzata
Proprio come avvenuto per SpringFollowCamera, anche ThirdPersonController ha i suoi
prerequisiti. Questi “legami” in Unity sono decisamente importanti, considerando che lo scripting
è la base della logica del nostro gioco. Unity, comunque, cerca sempre di gestire queste operazioni
nella maniera più intelligente possibile: gli stessi script, infatti, “diranno” a Unity quali sono le loro
dipendenze, che verranno aggiunte di conseguenza.
Adesso un altro passo piuttosto importante: aggiungere un Tag al nostro GameObject.
Assegnandone facciamo in modo che gli script riconoscano dove agire, e di conseguenza la logica
di gioco viene applicata sull’oggetto desiderato. Inoltre, assegnare un tag ad un oggetto equivale a
dotarlo di una caratteristica molto utile in fase di ricerca (considerate situazioni di sviluppo con
centinaia di GameObject sparsi in giro!).
• Dopo aver selezionato il nostro Player, cerchiamo tra le proprietà mostrate a lato il menù
“Tag” e selezioniamo la voce Player.
Niente di complesso quindi, solo una semplice selezione.
Il prossimo passo in questo lavoro di configurazione è sistemare Lerpz in modo tale che tocchi terra
con i piedi, quindi vedere come fare per modificare i controlli. Cliccando su Lerpz ed esaminandone
a lato le proprietà, noterete che è possibile decidere un sacco di cose: la possibilità di saltare, altezza
del salto, velocità di movimento, di camminata e la gravità.
Guardando Lerpz nell’IDE, è possibile notare una capsula blu in wireframe: rappresenta la
“presenza” del personaggio in termini di collisioni. I calcoli legati alle collisioni con l’ambiente
circostante, quindi, verranno effettuati partendo da questa forma.
Sperimentando potrete modificare la posizione di questa capsula, in modo tale da avere un risultato
migliore (e quindi più gradevole alla vista). Il risultato ideale è vedere, una volta avviata la demo, il
nostro personaggio camminare con i piedi ben saldi a terra.

Schermata di Esempio – Varie Capsule di Collisione – @unity/support


Il Sistema di Comandi e il Character Controller
Il Character Controller è sicuramente uno strumento utilissimo. Come molte delle feature di Unity,
semplifica il nostro lavoro e ci permette di gestire al meglio le modalità di input. Tramite esso
possiamo facilmente leggere tastiera, mouse e joypad, senza buttarci a capofitto nel codice.
Ora, alcuni di voi si chiederanno: va bene, ma se volessi personalizzare i comandi del mio
personaggio?
La soluzione è semplice:
• Navigando tra i menù di Unity, selezionate “Edit > Project Settings > Input Manager”.
Da questo strumento potrete decidere senza problemi come e quali tipi di input usare.
Nota: Unity, oltre a consentire allo sviluppatore di scegliere i tasti e le periferiche da usare,
consente anche all’utente finale questa possibilità. Automaticamente, infatti, Unity genera un mini-
tool di configurazione dei comandi molto simile a questo di seguito.
Che ne dite se facciamo un test? Stavolta non dovremmo avere nessun problema: il nostro avatar si
muoverà tranquillamente nell’area di gioco senza problemi. Però… non credete sia un po’ troppo
“statico”?
Dopo questo breve intermezzo dedicato ai controlli di Lerpz, facciamo un altro passo avanti.
Il prossimo articolo parlerà infatti di come animare il nostro personaggio, utilizzando le risorse
precedentemente importate.

Unity 3D – 09 – Usiamo le Animazioni di Lerpz – Parte 1

Per i controlli è andata, idem per il sistema della telecamera da utilizzare. Adesso dobbiamo fare
ancora un passo avanti. Se avete provato la demo, avrete notato che si, il nostro caro Lerpz si sposta
tranquillamente in giro per l’area di gioco, ma il suo modello è immobile, statico. Dobbiamo quindi
usare le animazioni che sono state create per lui.

Fortunatamente, non dovremo crearle noi: sono state già realizzate da coloro che hanno creato tutto
il materiale per i test che state attualmente usando. Nel nostro caso, per questa volta, le operazioni
da svolgere saranno piuttosto semplici:
• utilizzando il menù Component, aggiungete lo script ThirdPersonPlayerAnimation,
ovviamente, al GameObject del nostro caro Player
Mandando in esecuzione la demo, adesso il giocatore si muoverà correttamente.
Magia nera?
Pozioni?
Wanna Marchi?
Niente di tutto ciò. Per cui, riavvolgiamo il nastro e vediamo cosa troviamo dietro le quinte.
Animazione dei Personaggi
Per prima cosa dobbiamo un po’ analizzare l’animazione del personaggio, e di come Unity la
gestisce. Come alcuni di voi già sapranno, o perlomeno immagineranno, le varie animazioni dei
personaggi vengono realizzate con programmi ben precisi: parlo di 3D Studio Max, Maya,
Blender e chi più ne ha, più ne metta.
Queste animazioni, sia chiaro, non sono create così da zero: hanno una struttura ben precisa, che
fonda le proprie basi sul concetto di “scheletro” (Skelton). Questi scheletri virtuali definiscono la
struttura dei movimenti e danno delle importanti informazioni su come la superfice del modello
cambia in base alle necessità.
A questo importante concetto, inoltre, è il caso di aggiungere quello di Animation Blending. In
poche parole, pensate all’esempio stesso che la guida originale propone. Per il nostro personaggio
abbiamo realizzato due animazioni. Nella prima cammina, mentre nella seconda parla.
Grazie alla flessibilità che l’Animation Blending dovrebbe poter offrire, quindi, sarà possibile
“miscelare” (un significato del termine blend è appunto questo) le due animazioni, in modo tale da
vedere il nostro protagonista parlare e camminare allo stesso tempo.
Tutto questo non avviene in automatico: abbiamo bisogno di uno script che regoli quindi come
utilizzare determinate animazioni, quando utilizzarle e così via, gestendo ogni caso contemplato dal
game designer.
Torniamo ad Unity
Bene, ora che abbiamo brevemente visto questi concetti essenziali, sappiamo che per il nostro Lerpz
sono state create ben 15 animazioni differenti. Eccole:
• Camminata
• Corsa
• Pugno
• Salto (ascesa)
• Salto (discesa)
• Fermo
• Salto all’Indietro (backflip)
• Salto con il JetPack
• Caduta (da usare quando il protagonista cade da una piattaforma)
• Caduta (da usare quando il protagonista viene colpito da un nemico)
• Atterraggio (il momento in cui il protagonista atterra, prima di tornare allo stato normale)
Per vedere le varie animazioni basta cercarle nell’Inspector del GameObject di Lerpz.
Nota: le animazioni, come già detto, sono state create tramite dei programmi appositi insieme
ovviamente al modello. Successivamente, seguendo determinate istruzioni, sono state importate
in Unity. Tuttavia, nel corso di queste lezioni, non parleremo di queste operazioni dato che non
sono strettamente collegate.
Tornando a noi, come avrete capito quindi il funzionamento dello script
ThirdPersonPlayerAnimation inizia ad essere più chiaro: in base ai controlli attualmente utilizzati,
lo script si occupa di cambiare l’animazione attuale del personaggio. Lo fa in vari modi:
sovrapponendone due o più insieme (il blending di cui parlavo prima) oppure mettendone una dopo
l’altra per creare un qualcosa di coerente con la logica di gioco.
C’è inoltre da dire che alcune animazioni vengono gestite da altri script, a parte, in modo tale che il
lavoro necessario venga “ottimizzato” in base alle operazioni. I tipi di attacchi effettuabili, infatti,
possono variare di gioco in gioco. Per quanto riguarda Lerpz un esempio può essere l’animazione
del pugno: essa infatti viene gestita dallo script ThirdPersonCharacterAttack (script che
aggiungeremo più in la).
Per ora fermiamoci qui. So che può sembrare strano come approccio, ma è meglio fare un poco alla
volta. Nel prossimo articolo faremo qualcosa di più per l’animazione del nostro personaggio:
gestiremo al meglio il suo JetPack, utilizzando un sistema particellare (Particle System) e una luce
posizionata e scriptata nella maniera più corretta.

Unity 3D – 10 – Usiamo le Animazioni di Lerpz – Parte 2

Dopo aver dato uno sguardo alle animazioni del nostro personaggio, continuiamo cercando di
“complicare” leggermente le cose: in questo articolo infatti continueremo a gestire le animazioni
del nostro personaggio, introducendo anche quella relativa al JetPack.
Cosa faremo, di preciso?
L’animazione, in realtà, esiste già. Tuttavia, per rendere la cosa più “realistica” utilizzeremo due
strumenti molto importanti: un sistema di particelle (Particle System), per simulare le fiamme che
riescono dal JetPack, e una luce (Point Light) per simulare l’illuminazione delle fiamme nell’area
circostante.
Il funzionamento non è difficile da capire: appena tramite i comandi il giocatore attiva i razzi, il
sistema di particelle viene attivato ed altrettanto succede per la luce.
Volendo fare le cose in maniera più precisa, avremmo potuto sistemare due luci, una per ogni uscita
della cintura a razzi. In realtà queste uscite sono molto vicine, quindi sarà possibile tranquillamente
metterne una sola (come nella figura in alto, per capirci).
Ora che abbiamo spiegato il lavoro da fare, entriamo nel dettaglio. Prima domanda: cos’è un
sistema di particelle?

Sistemi di Particelle (Particle Systems)


I sistemi di particelle sono dei componenti ormai ampiamente utilizzati nel mondo dei videogiochi.
Il loro obiettivo è quello di simulare fenomeni come il fuoco, il fumo, l’acqua e via discorrendo. Lo
scopo viene raggiunto utilizzando decine di “particelle” che di solito sono semplici disegni in 2D
appositamente creati. Ogni particella ovviamente è dotata di una sua velocità e direzione. Questi
fattori, opportunamente calcolati, permettono al sistema di dare un’idea ben precisa e volendo
realistica di quello che si vuole realizzare. I parametri non si limitano alla semplice velocità: molti
moderni sistemi consentono di gestire la gravità, numero di particelle al secondo e tanti altri
fattori.
Ma torniamo a noi: come fare ad utilizzare in Unity un sistema di particelle?
Seguiamo alcune semplici operazioni.
• Utilizzando il menù GameObject, creiamo un GameObject vuoto nel pannello Hierarchy;
• Rinominiamo l’oggetto appena creato, in “jet”;
Selezionate il nuovo GameObject appena creato ed eseguite le successive operazioni.
• Aggiungete un Ellipsoid Particle Emitter;
• Aggiungete un Particle Animator;
• Aggiungete un World Particle Collider;
• Aggiungete un Particle Renderer;
• Cliccate sul segno di spunta “Enable” nell’Inspector del nostro sistema di particelle (nel
Particle Renderer). In questo modo verrà disabilitato temporaneamente;
• Posizionate l’oggetto poco più al di sotto del Jet destro di Lerpz. Abilitate nuovamente il
sistema cliccando sul segno di spunta “Enable” precedentemente disabilitato;
• Seguendo le indicazioni di seguito, date i valori corretti all’Ellipsoid Particle Emitter

Come vedete, ci sono molti parametri da decidere. Il consiglio che vi do come al solito è quello di
sperimentare a più non posso, in modo tale da capire al meglio ogni singola voce a cosa serve.
Prima di concludere le operazioni, passiamo un attimo per il Particle Animator, in modo tale da
scegliere i colori più appropriati. Sarà ovviamente possibile scegliere più di un colore: per il fuoco,
in questo caso, è stato usato il bianco come colore di partenza, per poi passare verso l’arancione,
finendo verso il marrone, prima della cancellazione della particella.
Ora manca solo un’ultima parte prima di passare alla luce: dobbiamo aggiungere la texture da
disegnare. Il componente che si occupa di disegnare il tutto è, come già detto prima, il Renderer.
Sarà quindi tra le sue impostazioni che dovremo cercare la voce “Particle Texture”, selezionando la
texture “fire add”
(fire add è rintracciabile sotto la voce Particles –> Sources –> Materials –> fire add)
Seguiamo la traccia seguente per modificare le impostazioni del componente in maniera adatta:

Ultima Piccola Nota: ignoriamo le due voci “Cast Shadows” e “Receive Shadows”, dato che sono
“competenza” di argomenti che vanno oltre quelli del nostro tutorial
Ci siamo: è tempo di illuminare un po’ le cose.

Impostare la Luce Corretta (Point Light)


Testando la nostra demo potreste accorgervi di una cosa che di certo salta subito all’occhio: il nostro
JetPack ha il suo bel sistema di particelle, ma è del tutto irrealistico. Il fuoco, infatti, dovrebbe
illuminare l’area circostante, e invece non succede niente.
Come fare per risolvere il problema? Semplice: aggiungendo una luce.
• Creiamo un nuovo GameObject, di tipo Point Light e diamogli il nome di “Jet Light”;
• Posizioniamo l’oggetto appena creato a metà tra i due scarichi del JetPack (ne useremo
solo uno dato che non sacrificheremo niente in termini di “realismo” e nel frattempo
risparmieremo sulla performance);
• Nell’inspector della luce appena creata, dovremo impostare un’intensità della luce
piuttosto alta affinché funzioni;
Fatto questo, la nostra luce è stata creata. Adesso quello che dobbiamo fare è collegare tutto ciò che
abbiamo creato al nostro oggetto Player.
• Nel pannello di Progetto, selezioniamo la cartella (vuota) Player e clicchiamo su
“Create”;
• Dal menù in drop-down, selezioniamo “Prefab”;
• Rinominiamo l’oggetto appena creato in “Jet”;
• Trasciniamo tramite drag and drop il nostro oggetto appena creato, dal pannello
Hierarchy sul Prefab;
• Cancellate dal pannello Hierarchy l’oggetto da poco creato, dato che ora è linkato al
prefab;
Fate attenzione a questi passi, dato che possono essere piuttosto laboriosi e complessi se non ci si
presta la dovuta attenzione. Ora avverrà l’effettivo collegamento tra personaggio e i vari
GameObject legati al JetPack.
• Dal pannello Hierarchy, selezioniamo l’oggetto Player;
• Esploriamolo fino a selezionare l’oggetto “torso”;
• Spostiamo per due volte l’oggetto Jet (prefab) in “torso”. Rinominiamone uno Jet L ed
uno Jet R (il destro e il sinistro per intenderci);
• Spostiamo anche il GameObject della luce in “torso”.
Utilizzando quindi i tool di manipolazione di Unity, facciamo in modo di posizionare tutti i vari
componenti nel modo corretto. Una volta sistemati poi non ci sarà più bisogno di spostarli, in
quanto si muoveranno tutti relativamente al Player.
Ed ora l’ultimo passo prima di concludere!
• Cercate lo script JetPackParticleController in Scripts –> Player e trascinatelo,
ovviamente, sul giocatore, nel pannello Hierarchy.
Provate tutto e direi che ce l’abbiamo fatta!
La prossima volta parleremo un po’ di ombre
Unity 3D – 11 – Usiamo le Blob Shadow

Quando si parla di ombre, si parla sempre di un argomento molto importante. Apparentemente,


l’impatto che abbiamo è essenzialmente legato all’estetica: un’ombra ben definita e ben realizzata è
realistica, bella da vedere. Tuttavia, l’utilità di un’ombra, soprattutto in alcuni tipi di giochi, non si
ferma assolutamente al fattore “bellezza”. Mi ritorna così in mente il buon vecchio caro Super
Mario 64, per l’ormai defunta Nintendo 64. (qualcuno se lo ricorda?)
Beh, in alcune cadute epiche necessarie a finire un livello, GUAI se non avessi avuto sotto di me
l’ombra di Mario per vedere dove stavo andando a finire. Se non fosse stato così sarei finito male,
in qualche strapiombo. In questo caso, quindi, l’ombra viene utilizzata come “aiuto” per il
gameplay vero e proprio!

Che Nostalgia.
Tornando a noi, le Ombre si possono creare in vari modi: ovviamente, come alcuni di voi già sanno,
hanno un impatto notevole sulle performance del gioco in se.

Creando le Ombre
Volendo semplificare le cose, diciamo che in genere vi sono due metodi per creare le ombre. Il
primo è un metodo che permette di diminuire il peso dei calcoli: il metodo del “Baking”. In questo
caso, le varie ombre sono state già create a priori, e non vengono calcolate dal motore di gioco.
Ovviamente il loro uso non può essere destinato ad oggetti ed entità dinamiche, quali il personaggio
(che infatti si muove): viene quindi utilizzato dagli oggetti statici, ad esempio gli elementi della
scenografia del livello in cui ci troviamo (alberi, muri, e.c.c).
Il secondo metodo, invece, è quello più efficiente e sicuramente più bello da vedere: parlo infatti
delle Ombre Dinamiche, ovvero quelle ombre che vengono calcolate in base a vari fattori
(posizione del giocatore, posizione delle luci, orientamento delle luci e così via). L’unico
inconveniente, però, è che in questo caso abbiamo una mole di calcolo piuttosto pesante da
sostenere, per alcune macchine. Certo, ormai i PC di oggi hanno degli Hardware potenti, ma in
questo tutorial noi faremo delle cose più semplici, venendo anche incontro a tutti coloro che non
hanno un PC potente. In poche parole, utilizzeremo un trucco. Introduciamo in questo modo una
terza strada per ottenere un risultato simile a quello che ci siamo preposti: le Blob Shadows.

Blob Shadows, Queste Sconosciute (o forse no?)


E sottolineo il “o forse no?”. Sicuramente infatti le avremo viste da qualche parte. Se non vado
errato, anche nel sopracitato Super Mario 64 ne ho viste, di Blob Shadows. Ok, non usciamo fuori
dall’argomento, torniamo a noi. Cosa sono di preciso queste benedette Blob Shadows?

Di sicuro una delle parole che meglio spiegano il concetto l’abbiamo letta poco più sopra: un
trucco. Esatto, perché questo tipo di ombra in realtà non è vera e propria ombra, ma solamente una
texture scura, tendenzialmente dalla forma semplice (in questo ed anche in altri casi, circolare).
Utilizzando questa tecnica aiuteremo non poco il nostro sistema ad alleggerire la mole di calcoli da
effettuare, che altrimenti sarebbe sicuramente più dispendiosa in termini di risorse.

Le Blob Shadows In Unity


Come se non fosse già sufficiente sapere che questa tecnica semplifica di molto il lavoro del PC, vi
do una buona notizia: Unity ovviamente supporta le Blob Shadows, ed in più offre dei Prefab già
pronti nella sua Asset Collection. In questo modo avremo già pronto quello che ci serve. Bene,
sappiate che questo Asset è stato già importato nel pannello di progetto, e tutto quello che dovrete
fare sarà semplice:
• Trascinare tramite drag’n’drop il prefab “Blob Shadow Projector” sull’oggetto Player,
ovviamente al livello superiore di questo.
Un’immagine per chiarirvi le idee:
Un particolare del Pannello Hierarchy, con il Blob Shadow Projector appena posizionato.
Ora, c’è ancora qualche operazione da effettuare prima che la nostra ombra sia utilizzabile:
• Selezioniamo il Layout 4-Split;
• Tra le impostazioni di rotazione del Blob Shadow Projector, settiamo rispettivamente
come valori 90, 180 e 0;
• Utilizzando le varie views (nello specifico quella dall’alto e dal lato) sistemiamo il
proiettore sulla testa di Lerpz. (volendo, giocate con la posizione fino ad avere un risultato
per voi soddisfacente);
Se testassimo ora il gioco, il risultato sarebbe decisamente poco gradevole: vedremmo infatti il
blob proiettato anche su Lerpz! Questo non deve succedere, anche perché l’ombra è la sua.
Per sistemare questo inconveniente, i metodi sono due: possiamo muovere il Near Clip Plane in
modo tale da evitare questa situazione, oppure andare a lavorare sui livelli, “spiegando” ad Unity
che le ombre devono essere disegnate, in questo caso, solo su alcuni livelli e su altri no. Traducendo
il tutto in termini più semplici: dire ad Unity di disegnare le ombre solo su alcuni oggetti e non su
tutti.
Useremo ovviamente la seconda tecnica, ed il motivo è semplice. Utilizzando la prima sicuramente
avremmo meno problemi e, avviato il gioco, non noteremmo nessun inconveniente. Ma al primo
movimento ed al cambiamento di posizione del personaggio, le ombre verrebbero disegnate nel
caso, per esempio, il piede di Lerpz andasse di poco al di fuori di quella che era la posizione
iniziale.
Lavorare sui livelli è quindi una tecnica più raffinata e a lungo andare più facile da gestire.

Creiamo un Livello!
Creare un livello non è poi così complesso, basta seguire poche istruzioni.
• Aprire il GameObject “Player” nell’Inspector;
• Aprire quindi il menù in drop down “Layer”;
• Selezionare la voce “Add New Layer…” (Crea Nuovo Layer);
• Selezionare la prima voce vuota (empty) degli User Layer e rinominarla “noShadow”;
La visuale potrebbe essere simile a questa.
• Torniamo adesso al nostro Player nella visuale del pannello Hierarchy, in modo tale da
visualizzare le impostazioni classiche dell’Inspector;
• Clicchiamo nuovamente sul menù in drop down “Layer”, ma stavolta selezioniamo il
nuovo Layer appena creato, “noShadow” (Unity probabilmente chiederà se deve
applicare le modifiche anche ai GameObject “figli”. Confermate cliccando su “Change
Children Layers”);
Bene: adesso non dobbiamo fare altro che dire al nostro proiettore di ombra che deve ignorare
determinati livelli. Indovinate quale diremo di ignorare?
• Andiamo ad agire sul pannello dell’Inspector del Blob Shadow Projector: alla voce
“Ignore Layers” selezioniamo ovviamente il layer “noShadow”
Direi che ce l’abbiamo fatta: da adesso in poi il nostro personaggio non avrà più problemi di ombre.
Testando il gioco vedremo che tutto funzionerà correttamente. Prima di lasciarvi, però, è necessario
fare un altro, ultimo, piccolo passo per perfezionare un po’ il tutto.
Ora come ora, infatti, non abbiamo ancora parlato dei cosiddetti “Collectables”, ovvero tutti quegli
oggetti che il giocatore può prendere per avere qualche vantaggio (punteggio o altro). Un esempio
per rendere l’idea sono le famose monete di Super Mario, per intenderci. Bene, quello che vogliamo
fare sarà gestire le ombre per loro, proprio come abbiamo fatto per il giocatore.
Fate attenzione infatti ad una cosa importante: per il nostro giocatore abbiamo un proiettore per
l’ombra. Ora, se volete guardatelo come una luce sempre posizionata sulla testa del giocatore, che
in questo modo lo colpisce e proietta a terra questa falsa ombra.
Se vi avvicinate ad uno degli oggetti collezionabili, noterete che le ombre verranno calcolate anche
per gli oggetti! Di sicuro non è quello che vogliamo. Ecco cosa dobbiamo fare per sistemare questo
ultimo problema.
• Nel pannello di progetto, selezioniamo gli oggetti FuelCellPrefab e
HealthLifePickUpPrefab, nella cartella Props;
• Per ognuno di essi, impostare il livello dell’elemento “radice” (ovvero come avevamo fatto
prima selezionando il livello più “in alto” del Player) su “noShadow”.
Ed in questo modo avremo risolto anche questo problema.
Anche per questa volta abbiamo finito. Iniziamo ad avere un risultato tangibile, gradevole alla vista!
Ovviamente le cose non finiscono qui: la strada è ancora lunga. Nel prossimo articolo, infatti,
daremo un’occhiata ad uno degli aspetti forse più interessanti in assoluto: è tempo di usare lo
Scripting.
Unity 3D – 12 – Tempo di Scripting – Parte 1

Nonostante gli anni passano e le tecnologie trovano la loro naturale (e veloce, nel caso
dell’informatica) evoluzione, certi concetti legati all’intrattenimento e ai giochi rimangono gli
stessi. Prendiamo, per esempio, in esame quelli che erano i primi giochi. Forse molti di voi non se li
ricorderanno, io stesso non ero ancora nato all’epoca. Tralasciando la lunghissima discussione che
riguarda il dibattito relativo a quale sia stato il primo gioco (andrei troppo fuori tema anche se
l’argomento mi piace) siamo tutti d’accordo che una quarantina d’anni fa al posto di tastiera e
mouse avevamo valvole, manopole e il livello dell’output su schermo era questo:

Tennis For Two – 1958


Da quando esiste questo tipo di divertimento, come dicevo, questi concetti rimangono gli stessi: i
designer, gli artisti creano i contenuti, poi tramite istruzioni (o circuiti elettrici a seconda dei tempi)
vengono realizzate delle macchine che usano questi contenuti, regolandoli tramite delle istruzioni.
Cosa cambia, di preciso, rispetto al passato? Semplice: ciò che cambia è la natura delle macchine
stesse. Al tempo, alcuni giochi avevano vere e proprie macchine dedicate alla loro esecuzione,
mentre oggi le cose vanno diversamente. Abbiamo i giochi che prendiamo, installiamo e via.
Forse non è proprio esatto come paragone, ma in un certo senso Unity è una macchina. Una
macchina virtuale, certo, ma una macchina alla quale diamo in pasto dei contenuti: l’abbiamo visto
nei capitoli precedenti. Ora è il tempo di dedicarci alle cosiddette “istruzioni” da dare alla
macchina. È tempo di iniziare ad osservare lo Scripting.
Con esso gestiamo vari aspetti del gioco, a livello logico:
• La vita del giocatore;
• Il numero di collectables attualmente presi;
• Capire quando il giocatore colleziona abbastanza oggetti per sbloccare i campi di forza;
• Capire quando il giocatore usa il JetPack;
• Capire quando il giocatore muore e quindi va in Game Over;
• Capire quando il giocatore tocca un Respawn Point
e così via.
NOTA: Per comprendere pienamente questi concetti è necessario avere bene a mente, come
prerequisito, quello di Automa a Stati Finiti. Ora, eviterò di scrivere un papiro a riguardo, ma vi
rimando alla pagina su Wikipedia dedicata all’argomento, sperando che possa essere abbastanza
chiara.
Tornando a noi, vediamo un po’ di esaminare questa relazione tra script e contenuti da noi aggiunti.

Struttura ed Organizzazione
Alcuni di voi, per sommi capi, avranno già capito più o meno come vanno le cose. Abbiamo
aggiunto i nostri contenuti, e dopo averli collegati ad un tot di script li abbiamo visti prendere
“vita”, seguendo delle istruzioni a condizioni ben precise.
Ora, sappiate che ci sono svariati metodi per effettuare questi collegamenti. Vediamone un po’:
• Usando l’inspector, aggiungendo gli oggetti e gli script tramite drag’n’drop coinvolgendo gli
oggetti desiderati. Sicuramente una delle tecniche più utilizzate, oltre che più efficaci. Vi
chiederete perché ed è presto spiegato: assegnando un certo script ad un certo GameObject,
non bisognerà effettuare ricerche interne, ma semplicemente abbiamo già detto a cosa
assegnare quello script. Punto e basta.
Un esempio di questo utilizzo riguarda il sistema di telecamere legate al livello in cui si sta
giocando. Lo script LevelStatus, che di default è già linkato al GameObject del nostro livello,
permettere di scegliere e di impostare più di una telecamera.
Unity ci semplifica molto la vita, e cerca di prevedere quelle che sono le nostre necessità: di default,
infatti, è impostata la telecamera “base” che inquadra la situazione di gioco in cui ci troviamo, una
dedicata alle cut-scenes ed un’altra per la fase in cui il giocatore completa il livello correttamente.
• Un altro modo di creare questi collegamenti è andare a modificare il contenuto stesso dello
script, nel metodo “Awake()”. Questo metodo viene richiamato prima dell’altro metodo
Update(). Intuitivamente potete capire qual è lo scopo dei due metodi: il primo viene
richiamato una volta, all’inizio della “vita” del nostro GameObject collegato, mentre Update
serve ad aggiornare l’oggetto nella situazione in cui si trova momento per momento.
Dato che qui bisogna fare una ricerca, a volte, il metodo è sicuramente più lento del precedente.
• La terza alternativa è creare questo collegamento, allo stesso modo in cui si modifica Awake,
utilizzando però il metodo Update. Ovviamente in questo caso stiamo contemplando dei
GameObject che possono richiedere delle modifiche ben determinate in Runtime.
Un esempio pratico potrebbe essere la scelta del respawn point dal quale far rinascere il nostro
giocatore, man mano che va avanti nel livello in cui si trova. In questo caso l’esecuzione è ancora
più lenta dei due metodi precedenti, quindi bisogna usare questa opzione in casi eccezionali,
cercando di concepire il gioco e il suo design di conseguenza.

NOTA: So che può sembrare piuttosto confusionale questo approccio. Sto sparando tante nozioni
ed è difficile seguirle. Leggete sempre bene e magari anche due volte, per fissare i concetti. In
più, c’è da dire che man mano che prenderete confidenza con Unity le cose cambieranno e
capirete che per ogni gioco c’è un approccio ben preciso che dovrete elaborare.
Dobbiamo considerare, inoltre, la struttura di Unity stesso. Come ho già spiegato in precedenza,
Unity è un ambiente di sviluppo che al contrario di molti altri focalizza la sua attenzione
prettamente sulle risorse da utilizzare. Questo non vuol dire che lo Scripting passa in secondo piano,
assolutamente. Tuttavia, bisogna capire come funzionano le cose per fare in modo di adattarle alle
proprie necessità e soluzioni.
Anche Unity fa la sua parte, anche per quanto riguarda lo Scripting: i ragazzi di Unity Technologies
infatti hanno cercato di rendere il tutto molto orientato agli oggetti, in modo tale da permettere uno
scambio di informazioni più agevole e veloce. Pensante infatti ad uno scambio di valori tra due
script, dovuto ad una necessità di qualsiasi tipo: Unity mette a disposizione la possibilità di
memorizzare localmente il valore che ci interessa, in modo tale da rendere meno traumatico il
passaggio e, soprattutto, più veloce.
Nel prossimo articolo vedremo tutte queste cose più da vicino, senza i troppi fronzoli della teoria:
analizzeremo infatti le condizioni per le quali il giocatore muore, resuscita, usa i punti di respawn e
anche come viene gestita la vita del giocatore stesso.
Unity 3D – 13 – Tempo di Scripting – Parte 2

Oggi, in questa seconda parte della sezione dedicata allo scripting, vedremo come “dire” ad Unity
come fare a riconoscere le condizioni di Game Over. Analizzeremo, infatti, i passi necessari a
definire la morte del personaggio e il successivo Respawn.

Il Problema
Nello specifico, il nostro percorso coprirà un argomentazione ben precisa: vedremo di riconoscere
quando il giocatore cadrà dal livello. In tal caso, verranno attivate delle routine che lo porteranno a
riapparire in posti ben precisi, chiamati i Respawn Point. In più, c’è anche un’altra cosa da
considerare: i nemici che si trovano nel livello tenderanno a seguirci! Considereremo, quindi, anche
questa problematica.

La Soluzione
Fortunatamente, ad ogni problema c’è una soluzione. In questo caso utilizzeremo un Box Collider,
strumento che ci permetterà di rilevare qualsiasi oggetto nel caso cada al di sotto di una certa
altezza. Oltre al Collider, quindi, definiremo un punto ben preciso dove riapparire dopo la “morte”.
Stiamo parlando del famigerato Respawn Point.
Iniziamo quindi sistemando in maniera appropriata il box collider:
• Create un oggetto GameObject vuoto;
• Rinominatelo “FalloutChecker”;
• Aggiungeteci un Box Collider;
• Aggiungeteci anche uno script FalloutDeath, reperibile in Component –> Third Person
Props;
Ecco come apparirà il nostro GameObject nell’inspector.

Bene. Stiamo parlando di Scripting, a questo punto direi di vederlo un po’ più da vicino, questo
benedetto FalloutDeath…
Lo Script FalloutDeath
Questo script, decisamente corto, delega il grosso del suo lavoro ad un altro script che andremo a
collegare tra poco: il ThirdPersonStatus.
Il cuore, il perno di tutta l’operazione si trova in un metodo ben preciso: OnTriggerEnter. Questo
evento viene lanciato quando un altro GameObject con un collider collegato viene a contatto con il
nostro oggetto al quale abbiamo applicato lo script. Questo “altro GameObject” può essere di tutto:
soprattutto può essere il nostro Lerpz.
Vengono eseguiti tre test: il primo, per il giocatore, il secondo, per un oggetto di tipo Rigid Body,
il terzo per controllare la presenza di un componente CharacterController. Il secondo test è ideale
per tutti quei corpi “rigidi”, appunto, come oggetti inanimati e simili. Ovviamente i risultati saranno
diversi in base al corpo: per Lerpz sarà necessario riportarlo al punto di respawn, mentre per altri
oggetti basterà distruggerli e basta, onde evitare la loro caduta verso l’infinito. Il terzo test invece è
particolarmente indicato per i nemici, che possono avere dei modelli di collisione diversi dal solito.
Ma vediamo cosa altro ci viene offerto:
• il metodo Reset() – controlla che ogni altro prerequisito sia presente. Viene, tra l’altro,
richiamato immediatamente dopo la creazione dell’oggetto interessato.
• la direttiva @Script – permette di aggiungere lo script direttamente nel menù “Component”
di Unity. Può rivelarsi un ottimo aiuto durante lo sviluppo di progetti più grandi ed
impegnativi.
Volendo potremmo provare a fare qualche test. Tuttavia, Unity avrebbe qualcosa da ridire a
riguardo, considerando che non ancora diciamo dove il nostro Lerpz deve riapparire dopo aver
tirato le cuoia…

I (benedettissimi) Respawn Point


“benedettissimi” perché li ho menzionati così tanto che non mi pare vero, finalmente, di averci a
che fare. Per prima cosa, sappiate che questi punti, fortunatamente, sono già pronti e preparati sotto
il nome di un prefab ben preciso: RespawnPrefab. Lo troverete nella cartella Props del Project
Panel.

Yay.
Soffermiamoci per un po’ su questo prefab, analizzandone i componenti nel dettaglio:
• RSBase – il modello cilindrico in se per se, ovvero la base con il disco luminoso al centro;
• RSSpotlight – una spotlight che emana una luce blu dalla base del modello, in modo tale da
rendere più realistico l’effetto di illuminazione;
• RsParticlesInactive – un sistema particellare utilizzato quando la piattaforma è inattiva. Un
tenue effetto luminoso tendente al blu;
• RsParticlesActive – utilizzato nel caso la piattaforma sia attiva e in uso, evidenzia l’effetto
iniziale di RsParticlesInactive, dando l’idea dell’utilizzo;
Ci sono, in fine, altri tre sistemi particellari: RSParticlesRespawn1, RsParticleRespawn2 ed
RsParticleRespawn3. Questi non sono sempre attivi, ma vengono utilizzati ed attivati in base alle
necessità, grazie all’uso dello scripting. Una volta che la sequenza viene completata, si ritorna ad
usare RsParticlesActive. Ciò lascia capire che in questo caso l’effetto dei tre sistemi particellari
non è continuo, ma viene inteso come un qualcosa da vedere una volta sola e basta, senza
ripetizione.
I componenti del Prefab, tuttavia, non finiscono qui.
Troviamo lo script Respawn, che ha lo scopo di controllare il RespawnPoint a cui è collegato.
Prima di usarlo a tutti gli effetti, però, dobbiamo prima definire bene qualche regola legata alla
posizione del giocatore. Considerando che vogliamo mettere più di uno di questi punti, infatti, viene
spontaneo chiederci: come fare per definire le regole da seguire?
Vediamo come fare. Per prima cosa posizioniamo un po’ di punti qua e la per l’area di gioco:
• Trascinate nella scena un RespawnPoint;
• Posizionatelo come indicato nell’immagine qui di seguito;

• Rinominate questa istanza del Prefab in “Respawn1”;


• Ripetete questa sequenza un altro paio di volte, in modo tale da avere due o tre punti di
respawn a disposizione (ovviamente, non sistemateli troppo vicini tra loro);
Lo step successivo serve quindi a creare un GameObject contenitore.
• Create un GameObject vuoto;
• Rinominate questo GameObject contenitore “RespawnPoints”;
• Fate in modo che ogni istanza del prefab (i “Respawn1”, per intenderci) diventino
componenti figlio di “RespawnPoints”;
E Ora Che Succede?
Direi che è il caso di spiegare un po’ nel dettaglio quello che abbiamo fatto. Con Unity è così, ci
sono delle procedure da seguire (almeno in questi casi) sapendo i ragionamenti che ci sono dietro al
sistema stesso.
Quando Unity viene avviato, questo richiama il metodo Start() per ogni istanza dello script
Respawn (che ricordo, è collegato ad ogni singola istanza del prefab). Questo serve ad inizializzare
e rendere quindi pronte alcune variabili necessarie alla logica che useremo successivamente.
Al centro di tutto questo ragionamento legato ai punti di respawn c’è una variabile ben precisa da
calcolare:
static var currentRespawn : Respawn;
La parola chiave “static” indica che questa variabile è condivisa tra tutte le istanze in funzione dello
script stesso. Questa condivisione ci permette di “tenere traccia” del punto attualmente in uso.
Appena la scena viene caricata, tuttavia, non è selezionato alcuno di questi punti che noi
abbiamo creato.
Per questo motivo dovremo specificarne uno, in maniera del tutto comoda, tramite l’IDE stesso.
• Dopo aver selezionato l’Inspector, tramite drag’n’drop trasciniamo il nostro Respawn1
sulla voce “Initial Respawn”;
• Ripetiamo quindi questa operazione per ogni istanza del prefab Respawn, in modo tale da
coprirli tutti quanti;
So che il funzionamento, spiegato così, potrebbe non essere chiaro: parliamo quindi in termini
ancora più pratici. A livello di logica del gioco stesso, in poche parole, quando il giocatore verrà a
contatto con un punto di respawn questo diventerà il punto “attivo”. Nel caso il giocatore
morisse, quindi, il respawn avrebbe luogo in quel preciso punto. Nel caso il giocatore toccasse un
altro punto, quindi, il punto attivo attuale cambierebbe nuovamente.
Tutte queste problematiche sono affrontate dal metodo SetActive(), gestendone tutti gli aspetti,
effetti sonori inclusi.
Il Respawn del giocatore, invece, è gestito a tutti gli effetti dallo script ThirdPersonStatus, che
come potete immaginare dal nome si occupa di gestire tutti gli aspetti legati allo stato attuale del
giocatore.
• Aggiungere lo script ThirdPersonStatus al nostro Player. Lo si trova in Scripts –> Player
–> ThirdPersonStatus;
Con questo ultimo tocco, per quanto riguarda il nostro personaggio abbiamo finito. Nei prossimi
capitoli torneremo su questi argomenti, in alcuni casi. Ora però guardiamo altrove: vediamo di
analizzare l’ambiente circostante ed aggiungere qualcosa di nuovo
Unity 3D – 14 – Costruiamo il Mondo di Gioco

Nelle lezioni precedenti di questa sottospecie di “corso” abbiamo visto tutto quello che riguardava il
nostro personaggio, Lerpz. Tuttavia, nel gioco non c’è solo lui: c’è il mondo con cui deve interagire,
nel quale deve stare. Ecco, quindi, il prossimo passo nella creazione del nostro gioco: vediamo
come costruire il nostro “set”, come posizionare gli oggetti, come assegnare loro degli script
per interagire con Lerpz.
Nota: il livello di prova che potete usare è già fornito di luci adeguate, un dettaglio oltremodo
importante. Le luci sono state posizionate in maniera studiata dagli artisti che hanno creato il
livello stesso.
Ma torniamo a noi: precisamente, in questo articolo vedremo come posizionare e/o tre oggetti:
• Gli oggetti a forma di cuore, da usare come cura per la nostra vita;
• Il campo di forza che impedisce a Lerpz di tornare sulla sua nave;
• Le piattaforme di salto, le Jump Pads, che permettono a Lerpz di fare salti più alti rispetto
alle sue normali capacità.
Detto questo non perdiamo altro tempo: iniziamo subito.

Posizioniamo i Cuori
Sicuramente questa è una delle parti più semplici: come già detto, questi oggetti servono a ridare
energia al giocatore, per permettergli di continuare il livello senza troppe difficoltà nel caso se ne
presentino. Nel gioco appaiono come dei cuori rotanti, con una luce pulsante ad abbellirli.
• Nel Project Panel, cercate il Prefab “HealthLifePickUpPrefab”. Sarà questo che
useremo;
• Tramite drag’n’drop sistemateli nel livello, nelle posizioni che preferite. Mettetene a
vostro piacimento (nel tutorial si consigliano 6-7 circa);
Dopo averli posizionati tutti, non dobbiamo fare altro che “raggrupparli” in qualche modo. Creiamo
un nuovo GameObject vuoto, chiamandolo HealthPickups. Rendete ogni istanza del prefab
precedentemente messo figlio di questo nuovo oggetto, ottenendo quindi qualcosa del genere:

Ora dobbiamo provvedere a scriptarli, questi cuori, in modo tale da dargli un effettivo risultato.
Bisogna quindi effettuare due operazioni, per ogni istanza dell’oggetto:
• Aggiungere un Collider Component;
• Aggiungere uno Script che rilevi la collisione e agisca di conseguenza, aumentando, in
caso, la vita del giocatore;
Tuttavia, non sembra un po’ laboriosa come cosa? C’è davvero bisogno di effettuare tutte queste
manovre per OGNI collectable che abbiamo messo in mezzo?
In realtà no, ecco perché queste modifiche andranno fatte sul Prefab, e NON su ogni singola
istanza dell’oggetto. I collegamenti quindi saranno aggiornati in maniera automatica.
Lavorando quindi sul Prefab, ecco cosa dobbiamo fare:
• Selezioniamo il Root Element del Prefab;
• Aggiungiamo un Collider Component selezionando “Component –> Physics –> Add
Sphere Collider”. Apparirà nell’inspector;
• Selezionate l’opzione “Is Trigger”;

Nota: c’è già un oggetto di tipo ObjectRotator collegato al nostro oggetto. Renderà più semplice il
movimento di rotazione che vogliamo fargli effettuare. Per movimenti più complessi, in caso,
affronteremo l’argomento più in la.
I Colliders hanno essenzialmente due possibilità d’uso: o li facciamo entrare in contatto con
qualcosa, oppure li usiamo come “condizione” per far scattare qualcos’altro. In termini tecnici,
stiamo parlando di Triggers.
I Triggers sono un qualcosa di invisibile, ma che comunque riescono a percepire l’eventuale
contatto con il giocatore. In base ad alcune condizioni lanciano di conseguenza dei metodi: queste
tre condizioni sono indicate come OnTriggerEnter, OnTriggerStay, OnTriggerExit. I nomi
ovviamente la dicono lunga sul loro uso.

• Dal menù Components, selezioniamo il Pickup Script e aggiungiamolo al nostro prefab;


• Selezioniamo dall’inspector la voce “Health” ed impostiamo l’entità della “guarigione”
da dare al nostro caro Lerpz (un valore consigliato è 3);
Una domanda sorge dunque spontanea: cosa succede se ho già la vita al massimo e prendo altri
cuori? In questo caso i designer hanno deciso di implementare un sistema di vite. Se si prendono
più cuori del previsto, quindi, aumenta il numero di vite. La logica di questo comportamento la
potete trovare nello script ThirdPersonStatus.
Bene, un passo l’abbiamo fatto. Adesso è il turno del campo di forza.

Animiamo il Campo di Forza


A differenza degli altri oggetti, il campo di forza dovrebbe già essere posizionato: tuttavia, a
meno che non abbiate già fatto delle modifiche per conto vostro, è del tutto immobile ed
inanimato. Vediamo di porre rimedio immediatamente.
Come immaginate, anche in questo caso la chiave della soluzione è da cercare nello scripting: lo
script che useremo sarà FenceTextureOffset. Lo troverete in Scripts –> Misc. Il suo funzionamento
è semplice da comprendere: abbiamo una variabile scrollSpeed che gestisce la velocità del
movimento, che viene quindi moltiplicata al tempo attuale di gioco per dare l’idea di movimento ed
animare il tutto.
Ora non dobbiamo fare altro che assegnare lo script:
• Cerchiamo nel pannello il GameObject “LevelGeometry”. Esaminiamone tutti gli
elementi figli, e selezioniamo “impoundFence”. È il nostro campo di forza che non
ancora viene animato;
• Tramite drag’n’drop assegniamogli lo script precedentemente trattato;
Et voilà, il gioco è fatto!

Posizionare e Sistemare i Jump Pads


Ora non resta altro che sistemare questi ultimi oggetti, e il nostro livello potrà contare qualcosa di
più rispetto a prima. Il loro funzionamento è semplice: quando Lerpz ci sta sopra e salta, allora il
suo salto diventa più forte e viene sparato più in alto del previsto. Ovviamente, questi aspetti sono
gestiti come al solito da un buon uso dello scripting.

Mettiamoci subito all’opera:


• Creiamo un nuovo GameObject, chiamandolo “JumpPad Trigger 1”;
• Aggiungiamoci un Box Collider;
• Impostiamo la voce “Is Trigger” tra le proprietà del Collider;
• Aggiungiamoci lo script JumpPad;
Dopo questa modifica, dobbiamo creare un nuovo Prefab da usare come partenza per i prossimi usi.
• Selezioniamo “Prefab” dal menù Create, al di sopra nel Project Panel;
• Trasciniamo il nostro GameObject appena creato sul Prefab;
• Chiamiamo il Prefab “JumpPad Trigger”;
• Cancelliamo l’oggetto originale;
• Selezioniamo il Prefab e trasciniamolo nell’area di gioco per crearne delle istanze.
Occorre sistemarlo bene per evitare imperfezioni, per cui occhio alla visuale e alle misure.
Ce ne sono 6 in tutto da sistemare;
• Tornando a lavorare sul Prefab, occorre sistemare il valore che definisce la “potenza” del
salto di Lerpz: stiamo parlando di Jump Height. Attualmente il valore è 5 e non è
sufficiente. Portiamolo a 30 oppure giocateci come volete.
Testate il tutto e verificate che sia tutto posizionato bene: anche questo passo ulteriore è andato
Nel prossimo articolo parleremo di un altro argomento molto interessante: la GUI.
Unity 3D – 15 – Serve un’Interfaccia

Il nostro gioco, piano piano, inizia a prendere forma. Nella prima sezione di questa guida abbiamo
infatti cercato di caratterizzare e gestire nel miglior modo possibile il nostro personaggio, Lerpz.
Nella seconda breve sezione, invece, abbiamo visto come impostare alcuni elementi dello scenario,
per rendere più gradevole l’esperienza di gioco.
Ovviamente mancano ancora molti elementi per arrivare ad avere qualcosa di dignitoso. Uno tra
questi, oggetto delle nostre prossime lezioni, è un’interfaccia grafica (o GUI, Graphical User
Interface). La GUI ha un compito decisamente importante: in primis, è decisamente utile per creare
menù nei quali il giocatore si può muovere per effettuare svariate scelte. Un esempio, quello di
Mass Effect, qui di seguito.

Inoltre, l’altro importante scopo delle GUI è quello di informare l’utente. Soprattutto in giochi
dove l’utente deve sapersi gestire le vite, i punti ferita, i soldi posseduti e così via. Ecco quindi un
esempio di questo tipo di GUI, preso da quel piccolo capolavoro che è The Legend Of Zelda –
Ocarina of Time, per la Nintendo 64.
Dunque, c’è poco da fare. Abbiamo decisamente bisogno di un’interfaccia grafica per guidare
l’utente ed aiutarlo nella sua missione di recupero. Anche in questo caso, Unity ci viene incontro,
fornendoci dei tools niente male. Primo tra tutti, il sistema Immediate GUI.
Per chi avesse delle nozioni anche minime su quello che può essere un codice dedicato, sappiate che
bastano queste poche righe:
function OnGUI()
{
If (GUI.Button (Rect(50, 50, 100, 20), "Start Game") )
Application.LoadLevel("FirstLevel"); // load the level.
}
Da uno a dieci, quanto lo trovate intuitivo? In questo caso, come potete vedere, stiamo
parlando della GUI legata ai menù. Riguardo alla cosiddetta GUI “In Game”, come stanno le cose?
Dobbiamo utilizzare uno specifico script, che si chiama GameHUD. Questo script verrà collegato
all’oggetto Level, e da li poi vedremo come fare per utilizzarlo al meglio.
Ovviamente questa è solo un’introduzione, per farvi capire meglio a cosa andiamo incontro. Prima
di lasciarvi, ecco due esempi del risultato finale: il menù principale e la schermata in-game.
Alla prossima
Unity 3D – 16 – L’Interfaccia In-Game
ven, dic 17, 2010
Old Blog
Nell’articolo precedente abbiamo introdotto brevemente l’interfaccia di gioco. A questo punto
facciamo un passo avanti, ed iniziamo ad implementarla a tutti gli effetti. Avevo presentato per
prima l’interfaccia relativa ai menù, per poi parlare della cosiddetta “Interfaccia In-Game”, ovvero
quella che vedremo durante il gameplay del livello vero e proprio.
Un insieme di informazioni, essenzialmente. Ecco, precisamente, cosa vogliamo rappresentare:
• la salute del giocatore;
• il numero di vite rimanenti;
• il numero di celle di carburante possedute;
Come già accennato prima, a gestire questa GUI In-Game ci pensa uno script ben preciso: il
GameHUD. Questo script avrà bisogno di un GameObject al quale collegarsi: in questo caso
useremo come “genitore” il GameObject “Level”, ovvero quello del livello.
Nota: volendo si può agganciare questo script anche all’oggetto NearCamera, oppure ad un
oggetto GUI creato ad-hoc. Come anche il manuale suggerisce, è esclusivamente un discorso di
gusti personali.
In questa guida utilizzeremo il GameObject Level, per questo scopo.

Questione di “Pelle”
A dire il vero, probabilmente questa è una traduzione poco dignitosa. Comunque sia, è in questo
momento che voglio introdurre un oggetto molto importante, introdotto dalla versione 2 di Unity:
parlo del sistema di skinning della GUI. Il suo scopo è presto spiegato: ci permette di importare nel
gioco quelli che sono i nostri asset (immagini e.c.c.) da usare con il nostro gioco.
In questo modo potremo personalizzare molto velocemente tutti gli aspetti relativi alla GUI stessa:
aspetto dei pulsanti, font da utilizzare, e via discorrendo.
Ora, come facciamo ad usare tutto questo? Iniziamo.
• tramite il menù “Asset”, creiamo un nuovo GUISkin Object. Apparirà nel pannello del
progetto;
• rinominiamolo “LerpzTutorialSkin”;
Come potete immaginare, saranno caricati già molti valori di default, per permettere un “utilizzo
base” pressoché immediato. Andiamo a cambiare il font utilizzato: sceglieremo il Fluoride.
• trascinate il Font FLUORIDE tramite un semplice drag’n’drop;
Come vedete, anche nel caso del sistema di GUI Skinning i ragazzi di Unity Technology non hanno
voluto abbandonare la linea della semplicità e dell’intuitività. Sembra quasi di avere a che fare con
un foglio di stile CSS di una pagina Web.
Avrete notato, tra l’altro, che il nostro oggetto non è in alcun modo presente nel pannello Hierarchy.
D’altronde, abbiamo effettuato una reference a questo oggetto tramite lo script GameHUD.
Ora, dobbiamo provvedere a definire i vari asset da usare nel gioco vero e proprio: i vari elementi
dell’interfaccia. Abbiamo già definito il font, perché non provare con un immagine? Magari quella
che indica la salute del giocatore e il suo numero di vite.

In questo caso, nel cerchio a sinistra utilizzeremo una sorta di indicatore per la salute, mentre nello
spazio a destra inseriremo il numero attuale delle vite. Ecco, qui di seguito, l’indicatore che
utilizzeremo:
Insomma, niente di troppo complesso. Per finire la carrellata dei vari asset, ecco invece quello che
utilizzeremo per indicare il numero di celle di carburante in nostro possesso.

Adesso possiamo passare alla pratica.


• aggiungiamo il GameHUD Script al nostro oggetto Level;
• esaminiamolo tramite l’Inspector: troveremo anche il pannello relativo allo script
GameHUD;
• aggiungiamo allo script le immagini appena viste;
• apriamo la sezione “HealthPie Images”, che viene considerato come un array;
• clicchiamo sulla “o” a fianco della voce “Size”, impostando quindi il nuovo valore su 6;
• a questo punto avremo un array di sei elementi (partendo dallo 0 fino al 5). Sistemiamo di
conseguenza le varie immagini della HealthPie ai rispettivi posti, dal primo all’ultimo;
• aggiungiamo quindi la nostra LerpzTutorialSkin nello slot GUI Skin, finora rimasto
vuoto;
Le cose appariranno più o meno così:
Testando adesso il gioco, la nostra interfaccia funzionerà alla perfezione.

Note: in fase di importazione degli Asset, Unity potrebbe mostrare qualche “lamentela” relativa
alle immagini e alle potenze del due. Data l’architettura di un qualsiasi sistema, infatti, è più
semplice fare dei calcoli utilizzando numeri che sono potenze del due. Per questo motivo, Unity
consiglia di ridimensionare questi Asset per adattarli in maniera opportuna. In realtà, per la GUI
non c’è tutto questo bisogno di ottimizzazione, anche perché sono giusto due immagini, che pesano
pochissimo.
La prima parte relativa all’interfaccia utente possiamo definirla andata. Adesso, prima di concludere
questa sezione legata alla GUI, dobbiamo vedere come aggiungere al nostro progetto un menù
iniziale. Non vi preoccupate, è veramente semplice, come capiremo presto nel prossimo articolo.
Unity 3D – 17 – Creiamo il Menù Principale

Nel precedente articolo abbiamo visto come implementare una GUI In-Game. Adesso, per
dichiarare l’interfaccia dell’utente pronta al 100%, occorre creare anche un menù principale e una
schermata di Game Over. Iniziamo con il Menù Principale. Che in realtà non sarà niente di
complesso, e apparirà come nell’immagine qui di seguito:

Iniziamo subito, facendo una lista di tutti gli elementi di cui avremo bisogno:
• due pulsanti della gui: “Play” e “Quit”;
• il nome del gioco, che verrà renderizzato utilizzando un font;
• una musica di sottofondo;
• uno sfondo da utilizzare;
Il primo passo da fare è quello di creare una nuova scena.
• tramite la combinazione veloce CTRL+N, create una nuova scena. Tramite CTRL+S la
possiamo salvare immediatamente;
• al momento di scegliere il nome, la chiameremo “StartMenu”;
• nel pannello di progetto, creiamo un nuovo Javascript File;
• rinominiamolo StartMenuGUI;
Occhio, perché stiamo per scrivere per la prima volta uno script tutto da noi

Lo Script “StartMenuGUI”
Ecco cosa dovremo scrivere nel nostro script:
@script ExecuteInEditMode()
questa prima direttiva indica che il nostro script verrà eseguito anche nella modalità di modifica
dell’IDE, non solo quando il gioco sarà in esecuzione.
var gSkin : GUISkin;
con questa riga invece indicheremo il collegamento da effettuare con il sistema di Skinning
dell’interfaccia di Unity.
var backdrop : Texture2D;
questo oggetto di classe Texture2D si occuperà di mantenere i dati relativi all’immagine da
utilizzare come background del nostro menù.
private var isLoading = false;
la variabile isLoading è essenzialmente un flag, da utilizzare in fase di caricamento.
Considerando che vogliamo caricare il livello di gioco non subito, ma quando il giocatore
cliccherà su “Play”, impostiamo questo valore su false, per il momento.
Dopo queste dichiarazioni, andiamo avanti col codice.
function OnGUI()
{
if (gSkin)
GUI.skin = gSkin;
else
Debug.Log("StartMenuGUI: GUI Skin object missing!");

questo primo controllo serve a testare il link ad un eventuale oggetto GUISkin valido. Nel nostro
caso dovrebbe andare tutto bene, in quanto abbiamo precedentemente preparato la nostra skin
personalizzata (LerpzTutorialSkin, ricordate?)
var backgroundStyle : GUIStyle = new GUIStyle();
backgroundStyle.normal.background = backdrop;
GUI.Label ( Rect( (Screen.width – (Screen.height * 2)) * 0.75, 0, Screen.height * 2,
Screen.height), "", backgroundStyle);

quest’altra sezione di codice, come potete facilmente immaginare, si occupa di sistemare


l’immagine di background. Tramite i calcoli che vedete nel codice qui sopra, inoltre, si è fatto in
modo di evitare una distorsione dell’immagine, nonostante l’adattamento dell’immagine a
qualsiasi risoluzione dello schermo.
Ma continuiamo, spostando la nostra attenzione, adesso, sul testo da usare nel menù principale.
Sistemando la GUI nell’articolo precedente, avevamo utilizzato un font, Fluoride. Inutile dire che
va benissimo anche per la nostra scritta nel menù principale, ma c’è un problema: attualmente ha un
colore inadatto i nostri gusti! Serve qualcosa di meglio!
Ma, diciamocelo, potrebbe mai essere un problema questo, per Unity? Sistemiamo le cose al volo.
• dal pannello del progetto, clicchiamo su LerpzTutorialSkin, per scorrere le proprietà
della nostra skin;
• sotto la voce “Custom Styles” impostiamo il valore della variabile “Size” su 1.
Dovremmo ora vedere una voce “Element 0”;
• apriamo la sezione relativa all’ “Element 0” ed impostiamo il colore del testo di un
arancio/marrone, o quello che preferiamo;
Ora possiamo aggiungere le dovute istruzioni al nostro script:
GUI.Label ( Rect( (Screen.width/2)-197, 50, 400, 100), "Lerpz Escapes","mainMenuTitle");
Ed adesso tocca ai pulsanti da usare.

I Pulsanti del Menù


Come per ogni componente relativo alla GUI, Unity presenta i pulsanti con uno stile di default.
Tuttavia, lo stile utilizzato da Unity si adatta male alle nostre esigenze. Abbiamo modificato un po’
tutto per quanto riguarda le scritte ed il background, cosa aspettiamo a modificare anche i pulsanti
per ottenere qualcosa di meglio?
• clicchiamo, dal project panel, su LerpzTutorialSkin, cercando nell’Inspector la sezione
relativa al GUISkin Script
• modificate i valori che trovate, portandoli allo stato dell’immagine qua sopra. In questo
modo sistemeremo le cose anche per i pulsanti della GUI;
Ed ora, il codice vero e proprio. Partiamo dal pulsante “Play”:
if (GUI.Button( Rect( (Screen.width/2)-70, Screen.height – 160, 140, 70), "Play"))
{
isLoading = true;
Application.LoadLevel("TheGame"); // load the game level.
}

Le istruzioni non hanno quasi bisogno di commento: c’è un controllo sull’eventuale pressione
(nell’if sono stati impostati tutti i valori relativi alla posizione del pulsante e al testo da presentare) e
nel caso il controllo ritorni true allora viene mostrata la scritta “Loading…” per poi caricare il
livello “TheGame”, ovvero il livello di gioco vero e proprio.
Le cose funzionano in maniera praticamente identica, con l’unica “aggiunta” di un controllo relativo
all’eventuale presenza dell’Unity Web Player. Questo pulsante infatti dovrà funzionare solo su un
prodotto standalone, mandato in esecuzione a livello locale, e non su internet, altrimenti non
avrebbe molto senso.
var isWebPlayer = (Application.platform == RuntimePlatform.OSXWebPlayer ||
Application.platform == RuntimePlatform.WindowsWebPlayer);
if (!isWebPlayer)
{
if (GUI.Button( Rect( (Screen.width/2)-70, Screen.height – 80, 140, 70), "Quit"))
Application.Quit();
}

Le differenze sono poche. L’unica cosa che cambia sono la scritta (adesso ovviamente è “Quit”) e la
posizione, poco al di sotto del primo pulsante. Nel caso avviene il click, si esegue
“Application.Quit()”.

L’Ultimo Passo – La Musica di Sottofondo


Che menù sarebbe senza una musica di sottofondo a farci compagnia? Provvediamo subito:
• nel pannello di progetto, cerchiamo il suono “StartMenu” nella cartella dei suoni;
• tramite drag’n’drop, trasciniamolo sull’oggetto MainCamera, nel pannello Hierarchy;
• cercando nell’inspector le proprietà relative a MainCamera, andiamo a modificare quelle
del file audio. Precisamente, attiviamo le opzioni “Play On Awake” e “Loop”, in modo
tale da far riprodurre il file subito, all’avvio, e ripetendolo all’infinito;
• aggiungete a MainCamera anche lo script StartMenuGUI;
• come tocco finale, nello script StartMenuGUI, impostate LerpzTutorialSkin come valore
di GSKin, e come valore di backdrop invece utilizzate l’asset “StartSplashScreen”.
Testando il tutto non dovreste avere nessun tipo di problema. Detto questo direi che per quanto
riguarda il menù abbiamo terminato: nel prossimo articolo vedremo nel dettaglio la schermata di
Game Over. Vi lascio con il codice completo dello script
//@script ExecuteInEditMode()
var gSkin : GUISkin;
var backdrop : Texture2D;
private var isLoading = false;
function OnGUI()
{
if(gSkin)
GUI.skin = gSkin;
else
Debug.Log("StartMenuGUI : GUI Skin object missing!");
var backgroundStyle : GUIStyle = new GUIStyle();
backgroundStyle.normal.background = backdrop;
GUI.Label ( Rect( ( Screen.width – (Screen.height * 2)) * 0.75, 0, Screen.height * 2,
Screen.height), "", backgroundStyle);
GUI.Label ( Rect( (Screen.width/2)-197, 50, 400, 100), "Lerpz Escapes",
"mainMenuTitle");

if (GUI.Button( Rect( (Screen.width/2)-70, Screen.height -160, 140, 70), "Play"))


{
isLoading = true;
Application.LoadLevel("TheGame");
}
var isWebPlayer = (Application.platform == RuntimePlatform.OSXWebPlayer ||
Application.platform == RuntimePlatform.WindowsWebPlayer);
if (!isWebPlayer)
{
if (GUI.Button( Rect( (Screen.width/2)-70, Screen.height – 80, 140, 70),
"Quit")) Application.Quit();
}
if (isLoading)
{
GUI.Label ( Rect( (Screen.width/2)-110, (Screen.height / 2) – 60, 400, 70),
"Loading…", "mainMenuTitle");
}

}
Unity 3D – 18 – Game Over

Ogni gioco ha un inizio ed una fine. Per l’inizio le cose l’abbiamo sistemate, adesso tocca
solamente al cosiddetto “Game Over”. In realtà non faremo niente di troppo complesso: sia che il
nostro giocatore perda o vinca la sfida della raccolta dei bidoni di carburante, arriverà sempre alla
stessa schermata. D’altronde questo è un tutorial, serve giusto per capire il funzionamento.
• creiamo innanzitutto una nuova scena, che chiameremo “GameOver”;
• dai suoni prelevate “GameOverJingle” e trascinatelo sull’oggetto MainCamera della
scena appena creata;
• tramite l’inspector, impostate i valori dell’oggetto come segue

Abbiamo già visto i file audio, quindi c’è poco da spiegare: si tratta di spuntare il “Play On Awake”
per riprodurre il suono appena si entra in Game Over, appunto. Ovviamente il loop è disattivato,
stavolta. Non dobbiamo fare altro stavolta: sarà sufficiente questa scena così impostata.
Il lavoro vero stavolta è nello script che dobbiamo scrivere: mettiamoci subito all’opera!

Lo Script della Schermata di Game Over


@script ExecuteInEditMode()
var background : GUIStyle;
var gameOverText : GUIStyle;
var gameOverShadow : GUIStyle;
var gameOverScale = 1.5;
var gameOverShadowScale = 1.5;

function OnGUI()
{
GUI.Label ( Rect( (Screen.width – (Screen.height * 2)) * 0.75, 0, Screen.height * 2,
Screen.height), "", background);
GUI.matrix = Matrix4x4.TRS(Vector3(0, 0, 0), Quaternion.identity, Vector3.one
*gameOverShadowScale);
GUI.Label ( Rect( (Screen.width / (2 * gameOverShadowScale)) – 150, (Screen.height /
(2 * gameOverShadowScale)) – 40, 300, 100), "Game Over", gameOverShadow);
GUI.matrix = Matrix4x4.TRS(Vector3(0, 0, 0), Quaternion.identity, Vector3.one *
gameOverScale);
GUI.Label ( Rect( (Screen.width / (2 * gameOverScale)) – 150, (Screen.height / (2 *
gameOverScale)) – 40, 300, 100), "Game Over", gameOverText);
}

La prima istruzione già l’abbiamo vista: serve a dire ad Unity che questo script verrà eseguito anche
nella modalità di modifica, in fase di testing. A quel punto si tratta di dichiarare le variabili e gli
oggetti in gioco:
• background, lo sfondo da utilizzare per questa schermata;
• gameOverText, il testo da utilizzare sullo schermo;
• gameOverTextShadow, che come il nome suggerisce rappresenta l’ombra del testo da usare
su schermo
Per quanto riguarda questi tre oggetti, li imposteremo al più presto nell’Inspector.
Poi abbiamo:
• gameOverScale;
• gameOverShadowScale;
Che si occupano di fare da “moltiplicatori” per le varie operazioni in scala di ridimensionamento e
adattamento. Vengono entrambe impostate ad 1.5.
A questo punto viene scritto il metodo OnGui che si occupa di disegnare e gestire tutto.
function OnGUI()
{
GUI.Label ( Rect( (Screen.width – (Screen.height * 2)) * 0.75, 0, Screen.height * 2,
Screen.height), "", background);
GUI.matrix = Matrix4x4.TRS(Vector3(0, 0, 0), Quaternion.identity, Vector3.one
*gameOverShadowScale);
GUI.Label ( Rect( (Screen.width / (2 * gameOverShadowScale)) – 150, (Screen.height /
(2 * gameOverShadowScale)) – 40, 300, 100), "Game Over", gameOverShadow);
GUI.matrix = Matrix4x4.TRS(Vector3(0, 0, 0), Quaternion.identity, Vector3.one *
gameOverScale);
GUI.Label ( Rect( (Screen.width / (2 * gameOverScale)) – 150, (Screen.height / (2 *
gameOverScale)) – 40, 300, 100), "Game Over", gameOverText);
}

La prima istruzione si occupa di disegnare il background adattandolo alle dimensioni dello


schermo. Successivamente, quindi, tramite la matrice di trasformazione che Unity ci mette a
disposizione, andiamo a disegnare il testo, sia nella sua versione “normale” che nella sua versione
“ombreggiata” in modo tale da ottenere l’effetto desiderato.
• dopo aver salvato lo script, trasciniamolo tramite drag’n’drop sull’oggetto MainCamera;
Dopodiché possiamo procedere con la modifica dei valori direttamente nell’Inspector. Innanzitutto,
il Background GUI Style. Impostiamo come segue i valori delle variabili:
In questo caso prendiamo l’asset “GameOverSplashScreen” come immagine di background.
Facciamo un passo avanti, quindi, per andare a sistemare i font e le scritte:

• impostate il fattore di scala del game over ad 1.69;


E infine giù con gli ultimi settaggi per le ombre:
• impostate il fattore di scala dell’ombra del game over ad 1.61;
A questo punto dovremmo avere (quasi) tutto pronto e a disposizione, qualcosa di molto simile a
quello che vedete qui di seguito:
Esatto, “quasi” finito. Manca ancora l’ultimo tocco: non vi siete accorti che manca la logica
necessaria ad andare oltre la nostra bella schermata di Game Over?
• creiamo un nuovo asset Javascript, chiamandolo GameOverScript;
• aggiungeteci il codice qui di seguito;
function LateUpdate ()
{
if (!audio.isPlaying || Input.anyKeyDown)
Application.LoadLevel("StartMenu");
}

Questa semplice istruzione caricherà il nostro menù iniziale alla pressione di un qualsiasi pulsante,
facendo questo controllo dopo la fine della riproduzione del jingle.
Le nostre GUI sono sistemate! Adesso riposatevi un po’, magari rileggetevi un po’ di cose che non
vi sono chiare ed in caso chiedete pure! Forse non rispondo subito ma ci provo
Le prossime lezioni saranno dedicate ad un altro aspetto davvero interessante: avversari, trappole,
tattiche e tutto ciò che può davvero aumentare il fattore di sfida del nostro gioco.
Unity 3D – 19 – Tempo di Sfide

In questa nuova sezione della guida inizieremo a dare del filo da torcere al nostro caro Lerpz. Che
ne dite di aggiungere dei nemici e un po’ di ostacoli, nel nostro gioco? Non male come idea,
vero? Beh, vediamo un po’ cosa faremo nei prossimi articoli.
In un primo tempo parleremo di come implementare dei raggi laser da usare come ostacoli da
superare. Vedremo come realizzare gli script appositi e realizzeremo tutto il necessario.

In un secondo tempo invece complicheremo un po’ le cose mettendo qualche nemico nella zona e
studiando un po’ come fare per renderli abbastanza “divertenti”. Di certo non andiamo a creare
qualcosa che sta fermo, no? Qui di seguito un esempio di nemico che andremo ad usare nel
nostro gioco.
Potrebbe sembrare una cosa semplice, ma vi assicuro che non lo è. O meglio, lo è perché Unity
semplifica molto la normale prassi, ma comunque non è poi così semplice dato che dovremo pure
gestire il respawn dei nemici al momento giusto e nei posti giusti, senza considerare i vari effetti da
utilizzare, ad esempio, in caso di morte del nemico stesso.
Detto questo quindi vi lascio dopo questa brevissima introduzione In un certo senso, potremmo
dire che questa è l’ultima sezione della nostra guida. Le successive, infatti, saranno dedicate a
tutti quei cosiddetti “tocchi finali” prima di dichiarare a tutti gli effetti “finito” il nostro lavoro.
Buona lettura!
Unity 3D – 20 – Nuovi Elementi di Sfida

Finalmente, dopo giorni e giorni passati tra esami ed altri lavori, sono tornato a scrivere
Come il titolo lascia bene intendere, oggi introdurremo alcuni nuovi elementi di sfida nel nostro
gioco: parleremo infatti di avversari ma non solo. Dico “non solo” perché è necessario specificare
che gli avversari rientrano sicuramente nel campo delle sfide che poniamo di fronte al giocatore, ma
la relazione in questione non strettamente reciproca. Tra le sfide infatti troviamo anche i cosiddetti
“ostacoli”.

Eccovi servito un esempio di ostacolo. Dei laser daranno al giocatore del filo da torcere,
sicuramente più di un corridoio sgombro e, alla lunga, noioso. Oltre questa piccola nozione, bisogna
anche darne un’altra: ciò che distingue un bravo level designer da uno scarso level designer è
sicuramente l’abilità nel collocare questi elementi di sfida nel livello. Questo ovviamente senza
nessuna pretesa di “insegnare” a qualcuno come diventare un bravo level designer. Sta tutto nella
creatività della persona.

So, What are We Going to Do?


In questo ultimo capitolo di “costruzione” vera e propria (i restanti infatti saranno essenzialmente
dedicati ai ritocchi ed ottimizzazioni finali) aggiungeremo al nostro gioco, in primo luogo, dei
nemici che daranno del filo da torcere al giocatore.
Le Guardie Robot
Vedremo quindi come gestire il loro comportamento in generale, andando successivamente a
“scavare” in quelle che sono le situazioni specifiche di acting nel caso il giocatore ci entri in
conflitto.
Infine vedremo appunto come aggiungere i sopracitati laser, regolando i loro movimenti e le
loro posizioni nell’area di gioco.
Evitiamo di perderci ulteriormente in chiacchiere: iniziamo subito analizzando le guardie robot.
Unity 3D – 21 – Guardie Robot all’Attacco!

I nostri nemici principali saranno dei robot, che si muoveranno in giro per l’area di gioco, cercando
di ostacolarci in tutti i modi con l’obiettivo di non farci raggiungere il nostro obiettivo. Come
abbiamo visto precedentemente, Lerpz ha un indicatore che informa il giocatore sull’entità dei
danni attuali. Ogni volta che entreremo nel raggio d’azione di uno dei robot, questo cercherà di
venirci incontro e infliggerci dei danni.
Il tipo di modello l’abbiamo già visto nell’articolo precedente, ma lo ripropongo:

Il robot in questione è stato realizzato in modo tale da avere un punto debole: degli attacchi ben
assestati al torso lo metteranno fuori gioco. A questo punto, “sputerà” degli oggetti che il giocatore
potrà raccogliere (in pieno stile platform) e quando il giocatore si allontanerà, il suo BIOS verrà
resettato in modo tale da riavviarsi.
Da queste linee di game design carpiamo tre elementi senza dubbio importanti a livello di
gameplay:
• due colpi ben assestati lo mandano K.O;
• ogni volta che verrà “distrutto” lascerà al giocatore degli elementi collezionabili che potrà
raccogliere per aumentare il suo punteggio;
• quando il giocatore si allontanerà, invece, tornerà “in vita” per continuare ad essere un
elemento di sfida per il giocatore;
Possiamo quindi fare altre osservazioni come conseguenza di queste tre:
• il punto 2 è sicuramente il perno dell’elemento di sfida: dobbiamo uccidere un nemico per
aumentare il nostro punteggio;
• sarà necessaria una rudimentale implementazione di intelligenza artificiale per gestire il
comportamento del nostro robot;
Ora che abbiamo presenti questi elementi, possiamo passare alla pratica vera e propria.

La Guardia Robot nel Livello


Senza altre considerazioni meramente teoriche, torniamo nel nostro IDE. La prima cosa da fare è
trovare ed aggiungere al nostro livello di gioco, in punti determinati, alcune istanze del prefab
“Copper”, ovvero la nostra guardia. A questo punto non dovremo fare altro che aggiungere gli script
adeguati al contesto per vedere in azione i risultati.
Come ciliegina sulla torta, quindi, aggiungeremo al nostro personaggio la possibilità di attaccare, in
modo tale da potersi liberare dai nemici.
• apriamo il pannello di progetto e cerchiamo il prefab “Copper” nella cartella dei nemici,
“Enemies”;
• cerchiamo dei punti a piacimento nei quali vediamo bene la presenza del nemico e
provvediamo ad aggiungerli alla scena. Assicuratevi inoltre che la capsula del Character
Controller tocchi il pavimento, in modo tale da garantire una giusta collisione degli
elementi;
Se mandassimo in esecuzione adesso il nostro gioco, noteremmo che le guardie sono ferme, nella
loro animazione di default. Ora tocca dargli vita, aggiungendo i vari script:
• diamo al giocatore la possibilità di attaccare: cerchiamo lo script
“ThirdPersonCharacterAttack” e tramite drag’n’drop trasciniamolo sul nostro giocatore;
• apriamo l’inspector del prefab “Copper”;
• cerchiamo lo script “EnemyDamage” e trasciniamolo in maniera tale da assegnarlo al
prefab della nostra guardia robot;
• facciamo la stessa cosa per lo script “EnemyPoliceGuy”;
Giocando adesso il livello, se ci avviciniamo troppo ai nostri nemici questi dovrebbero reagire. Ora
la vostra domanda è più che lecita: in base a quale criterio reagiscono?
Lo so, lo abbiamo già accennato prima. Ma che ne dite di guardare nel dettaglio lo script
“EnemyPoliceGuy”?

Lo Script “EnemyPoliceGuy”
Lo script in questione rappresenta i comportamenti principali che il nostro robot può assumere nei
confronti dell’ambiente che lo circonda. Essenzialmente questi sono tre:
• idle – il comportamento di default, nel caso non ci siano minacce che implichino una
modifica nel comportamento del robot;
• threaten – qui il robot identifica la minaccia, quindi provvede a manifestare la sua
intenzione ad attaccare facendo volteggiare e ruotare il suo bastone;
• seek and destroy – da questo punto il robot inizia la vera fase di attacco, dopo quella di
minaccia. Se il giocatore si trova a distanza troppo ravvicinata, il robot attacca infliggendo
del danno;
• struck – nel caso il giocatore colpisce la guardia, questa mostra l’animazione
corrispondente;
Ovviamente, nel caso il giocatore riesca a muoversi velocemente uscendo dall’area di competenza
del robot, quest’ultimo interromperà la sequenza di “minaccia-attacco” in modo tale da tornare al
suo stato normale. Lo script EnemyPoliceGuy, quindi, non fa altro che far dialogare il robot con
l’ambiente esterno e determinare le situazioni per le quali questi stati si avvicendano.
Adesso la vostra domanda è un’altra: se il nemico è gestito essenzialmente da EnemyPoliceGuy, a
che diamine serve EnemyDamage? Diamoci un’occhiata.

Lo Script “EnemyDamage”
Seguendo, nel nostro sviluppo, una linea che segue la traccia dei punti che abbiamo definito
all’inizio dell’articolo, abbiamo notato che con EnemyPoliceGuy abbiamo già fatto il grosso del
lavoro. Tuttavia, manca ancora da gestire la parte in cui il robot si rialza e si resetta. Senza
considerare la parte relativa al KO del nemico. A questo punto entra in azione il primo script che
abbiamo aggiunto al nostro prefab: EnemyDamage.
Il suo funzionamento è semplice. Innanzitutto ricordate sempre che ogni oggetto comunica con gli
altri del mondo di gioco tramite messaggi. Quando il nostro personaggio infligge dei danni al robot,
quest’ultimo oggetto riceve un messaggio che viene chiamato “ApplyDamage”. A quel punto viene
richiamata la funzione “ApplyDamage” dell’oggetto robot e il danno viene inflitto correttamente.
Nel caso i punti danno siano tre, per esempio, e per tre volte il robot ha ricevuto il messaggio
ApplyDamage, viene richiamata la funzione “Die”, il cui nome è piuttosto eloquente. A questo
punto il nostro nemico va in KO. “Andare in KO” vuol dire che verranno sistemati tutti gli aspetti
relativi a questo stato del nemico: dal sistema particellare che gestisce l’alone blu (come quello
nella figura seguente) alla fisica che deve gestire il corpo esanime del robot.

Da qui, inoltre, vengono istanziati anche i pickup eventuali da prendere: lo script, in particolare,
prevede la possibilità di farci dare come ricompensa una cella per recuperare la vita o una di
carburante, per raggiungere il nostro obiettivo primario più velocemente.
A questo punto possiamo pensare al respawn dei nemici in giro per l’area, facendo anche un piccolo
lavoro di ottimizzazione.

Respawn!
Il respawn dei nemici in base ad un eventuale vicinanza al giocatore, se ben implementato, è
sicuramente molto utile. Ci evita svariati problemi: soprattutto il memorizzare i dati per ogni
nemico, che si traduce in un carico di lavoro significativamente minore per il sistema sul quale
facciamo girare il gioco. È una vecchia tecnica, sicuramente, ma trova respiro ancora oggi, per cui
vediamo come gestirla al meglio nel nostro gioco.
• Creiamo un nuovo oggetto vuoto (Empty) al livello più in alto del nostro Hierarchy Panel;
• Rinominiamo l’oggetto in questione “CopperSpawn”;
• Tramite drag’n’drop, assegnamo all’oggetto lo script “EnemyRespawn”;
• Sistemate le impostazioni, tramite l’inspector, come segue:
Come vedete, lo script prende in input pochi parametri. Come, ad esempio, “Spawn Range” che
determina la distanza alla quale un nemico deve attivarsi. Come al solito Unity fa le cose nel modo
più intuitivo possibile.
Tornando a noi, non ne basterà uno, ovviamente, di questi oggetti, nel nostro livello. Per questo
quindi dobbiamo provvedere a pensare leggermente più in grande creando un oggetto che ne
contenga di più:
• Come prima, creiamo un nuovo oggetto vuoto al livello più alto del nostro Hierarchy
Panel;
• Rinominiamo l’oggetto “Enemies”;
• Riprendiamo l’oggetto CopperSpawn, rendendolo un Child Object di Enemies;
• Utilizzando quindi l’oggetto CopperSpawn, creiamo un nuovo Prefab;
L’effetto di questa tecnica è semplice: una volta che avremo ucciso un nemico e ci allontaneremo,
tornerà in vita, successivamente, nel caso torneremo nella sua zona (decisa in base al valore Spawn
Range).
Il cuore del sistema appena descritto è ovviamente lo script EnemyRespawn. Vediamo nel dettaglio
da cosa è composto. Vi è innanzitutto la funzione Start, che si occupa di prendere un collegamento
all’istanza del robot nemico che ci interessa, in modo tale da lavorarci dopo in base alle necessità
che si possono presentare.
L’altra funzione è Update. Si occupa di controllare se il giocatore è dentro il range contemplato
dalla distanza massima e, in caso, istanzia l’oggetto relativo al nemico mettendolo in gioco.
Ci sono, inoltre, ancora due funzioni che vengono utilizzate in questo contesto. Riguardano i
“Gizmo”, ovvero dei corpi invisibili nel gioco vero e proprio che però danno una mano allo
sviluppatore. Ad esempio, un Gizmo a forma di sfera può dare un’idea allo sviluppatore della
distanza effettiva necessaria al respawn.
A questo punto possiamo procedere a creare i raggi laser di cui abbiamo parlato precedentemente.
Unity 3D – 22 – Creare i Raggi Laser

Come potete ben immaginare, i laser saranno decisamente più semplici da creare rispetto ai nemici
veri e propri. Infondo, il loro movimento non è poi così complicato: si limiteranno, infatti, a salire e
scendere secondo una traiettoria ben precisa. Nel caso il giocatore venga a contatto con essi, verrà
penalizzato con la perdita di punti vita. Il discorso però non vale solo per Lerpz. Anche i nemici che
verranno a contatto con i raggi, infatti, perderanno punti salute.
Iniziamo!

I raggi laser sono creati tramite un componente chiamato “Line Renderer”, contenuto nel
GameObject ad esso corrispondente. Per cui, la prima cosa da fare è creare un nuovo oggetto e
usarlo di conseguenza.
• Creiamo un nuovo GameObject vuoto, rinominandolo “Laser”;
• Partendo dal menù (Components –> Miscellaneous) aggiungiamo all’oggetto il
componente Line Renderer sopracitato;
• Aggiungiamo lo script “LaserTrap” all’oggetto, in modo tale da fornirgli anche la logica
del suo funzionamento basilare;
• Passiamo per l’Inspector, sistemando le varie impostazioni come segue:
• Posizioniamo il GameObject dove vogliamo, nel tunnel dei laser facilmente rintracciabile
nel livello;
• Creiamo un nuovo oggetto di tipo Point Light, applicandolo come child object del nostro
laser;
• Sistemiamo le impostazioni (tramite l’Inspector) in questo modo:

Vi chiederete a cosa serve la Point Light: semplicemente deve dare l’effetto di luce emanato dal
laser stesso… un po’ di realismo serve, no?
Rimanendo nell’inspector, a questo punto, possiamo sistemare le impostazioni dello script
“LaserTrap”:
A questo punto il nostro laser è pronto all’uso. Tuttavia, un minimo di approfondimento è sempre
gradito: entriamo un po’ nel dettaglio ed esaminiamo il LaserTrap Script.

Lo Script “LaserTrap”
Nello script in questione troviamo anzitutto alcune proprietà legate alle dimensioni e al movimento
nello spazio del laser stesso:
• height
• laserWidth
• damage
• speed
Tutte proprietà il cui nome spiega bene la funzione. Da menzionare, inoltre, hitEffect, collegabile
ad un altro GameObject in maniera del tutto arbitraria.
La funzione Start, come di consueto, si occupa di inizializzare il tutto in maniera corretta, mentre la
funzione Update si occupa di gestire la situazione in-game dell’oggetto stesso. Qualche piccola
curiosità su come viene calcolato e gestito il movimento: viene utilizzata la funzione Mathf.sin (la
funzione trigonometrica seno, per intenderci). Per variare la posizione nel tempo quindi diamo “in
pasto” alla funzione Sin il tempo di gioco attualmente passato (Time.time) moltiplicato per la
variabile speed, in modo tale da rendere il laser più o meno veloce.
Per quanto riguarda le collisioni, fondamentali per il funzionamento dello script stesso, sappiamo
che queste vengono calcolate tramite il cast di un raggio su tutta la lunghezza del laser. In questo
modo, ogni volta che il giocatore o il nemico vengono a contatto con il raggio, si attivano i
meccanismi logici di conseguenza.
Ed ecco il nostro laser in azione.
Unity 3D – 23 – Gli Ultimi Ritocchi – Audio

In genere, quando acquistiamo un dvd o un cd musicale, c’è quasi sempre un grande lavoro di
tuning audio nella fase di preparazione. La preparazione e il raffinamento dei suoni in output è
decisamente importante, per svariati motivi. Si può manifestare una certa necessità a livello di
dimensione dell’audio, o magari una necessità di un certo tipo di qualità. Le operazioni che
vengono svolte sono molteplici: vengono regolati i volumi, in modo tale da evitare che uno
strumento si senta troppo rispetto all’altro. Vengono eliminate le frequenze che, a seconda del
contesto, vengono reputate “inutili”. In questo modo, l’audio che ne viene fuori deve essere
accettabile su qualsiasi dispositivo, sia una TV economica o un sistema audio sofisticato.
Alla fine di tutti questi processi c’è quello finale, detto “Mastering”. Lo stesso procedimento, senza
nessuna eccezione, viene applicato anche al mondo dei videogiochi. In molte software house, oggi,
non è raro avere a disposizione vere e proprie orchestre sinfoniche di tutto rispetto. O magari, basti
pensare all’importanza generale dell’audio in un gioco: prodotti di catene come “Need For Speed”
vantano colonne sonore d’eccezione.
Uno dei tocchi finali che daremo al nostro gioco sarà proprio questo: l’aggiunta di audio ed effetti
sonori dove necessario, per creare una cosiddetta “esperienza di gioco più coinvolgente”. A volte,
inoltre, gli accorgimenti legati al mondo dell’audio nei videogiochi possono essere ancora più
importanti di una produzione cinematografica: non abbiamo più a che fare con semplici media dallo
svolgimento lineare, ma veri e propri prodotti interattivi.
È qui che iniziamo a chiederci: verrà utilizzato questo file audio? Se si, quanto? Per quante volte?
Devo ottimizzarlo?
E così via.
In un mondo ideale e perfetto non dovremmo fare altro che prendere e lasciar sistemare l’audio al
nostro caro ingegnere audio… ma la realtà è ben diversa: soprattutto per quanto riguarda i piccoli
progetti queste figure professionali non esistono, per cui è oltremodo necessario avere una
conoscenza di quelli che possono essere gli accorgimenti da prendere in considerazione.
Oltre agli accorgimenti puramente tecnici, inoltre, bisogna considerare anche che abbiamo a che
fare con una grande soggettività: alcuni possono preferire la potenza dei bassi, altri invece i suoni a
tutt’altre frequenze. Per cui, un buon primo consiglio può essere quello di sottoporre il vostro
prodotto a "giudizio” di più persone e non una sola, in modo tale da avere una base di pareri e idee
leggermente più oggettiva.

What About Unity?


Volendo parlare di Unity, possiamo subito entrare nel merito. Innanzitutto, c’è da dire che
nonostante presenti un’interfaccia con l’audio discretamente semplice, bisogna tenere in mente un
po’ di cose:
• Per prima cosa, bisogna assicurarsi che i vari sample audio che possediamo siano tutti ad un
livello coerente con quella che è la nostra aspettativa: vediamo di regolare per bene i volumi;
• Nel caso avessimo bisogno di sistemare in maniera realistica alcuni suoni in un mondo
tridimensionale, provvedere ad utilizzare dei sample in mono e non stereo;
• Comprimere i propri sample con il codec Ogg Vorbis (nel caso tu non sappia come fare,
Unity lo può fare comunque al posto tuo, per cui tranquillo);
• Il Codec Ogg Vorbis è particolarmente raccomandato soprattutto se vuoi pubblicare il tuo
lavoro su internet;
• Come ovvia conseguenza del secondo punto di questa lista, per i file audio da usare come
background (musiche, suoni dell’interfaccia) è consigliabile utilizzare file audio stereo;
Dopo questa breve introduzione all’argomento, possiamo passare al lato pratico della questione.
Aggiungiamo un po’ di audio al gioco del nostro Lerpz!
Unity 3D – 24 – Gli Ultimi Ritocchi – Audio / 2

Continuando il nostro lavoro sull’audio, vediamo innanzitutto di stilare una lista dei suoni che
avremo da sistemare:
• Suoni del Giocatore – tutti quei suoni che riguardano Lerpz in prima persona. Parliamo del
suono della camminata / corsa, dell’attacco, di quando viene attaccato da un nemico, di
quello riprodotto quando viene colpito a morte e quello del JetPack;
• Suoni dei Nemici Robot – qui abbiamo il rumore da fermo della guardia robot, il suono di
attacco e l’effetto sonoro del momento in cui viene colpito. Proprio come Lerpz, inoltre,
abbiamo il suono di quando viene colpito a morte dal nostro eroe;
• Suoni degli Oggetti da Raccogliere – in questo caso i suoni sono due: il suono della cella
di carburante, quando viene raccolta, e il suono del power-up che incrementa la salute;
• Suoni Ambientali – suoni di riempimento ma oltremodo necessari a dare la giusta
immersione al giocatore: in questo caso parliamo di un loop piuttosto lungo per l’atmosfera
e un effetto di “swhoosh” per i Pad di salto;
• Suoni della Nave Spaziale – un suono per il decollo della navetta di Lerpz. A cosa serve?
Lo vedremo tra un po’
Alcuni effetti sonori, nel nostro gioco, sono già stati aggiunti. Tuttavia, abbiamo ancora un lavoro
piuttosto incompleto: dobbiamo ancora aggiungere una decina e oltre di effetti sonori per
completare il lavoro e renderlo giocabile anche sotto il punto di vista dell’audio. Che gioco è un
gioco silenzioso?
Molto spesso alcuni suoni sono ottenuti con le tecniche più assurde: basti pensare al suono del
momento in cui prendiamo una cella di carburante, che è stato ottenuto colpendo con una mazza
una pallina da golf. A questo punto, iniziamo piano piano ad aggiungere questi effetti.

Suoni Ambientali
Per prima cosa, vediamo come aggiungere al nostro mondo di gioco gli effetti sonori ambientali.
Per questa tipologia di suoni il ragionamento è semplice: la sorgente audio è associata alla
telecamera che segue Lerpz, in modo tale da essere sempre presente. Tramite l’inspector della
nostra telecamera, ecco le semplici impostazioni per arrivare al nostro obiettivo:
• Tramite lo Hierarchy Panel, trascinare tramite drag’n’drop il sample audio
(sceneAtmosphere) in formato Ogg sull’oggetto della telecamera (NearCamera);
• Unity a questo punto gestirà da solo tutte le impostazioni, come nell’immagine qui di
seguito;
Come sempre, le impostazioni sono molto facili da leggere: il segno di spunta su “Play On Awake”
sta a significare che la riproduzione del file audio deve avvenire appena il livello viene caricato. Il
segno di spunta su Loop invece indica che il sample deve essere mandato in esecuzione
ciclicamente.
Le altre variabili che troviamo, invece, sono: Min Volume e Max Volume, che vanno a lavorare
anche sulla distanza massima alla quale il giocatore si deve porre per poter continuare ad ascoltare il
suono (parlando di suoni in ambienti 3D ovviamente).
Il Rolloff Factor invece si occupa di definire quanto velocemente un file audio non è più udibile
mano a mano che il giocatore si allontana dalla sua sorgente.
Piccolo Consiglio: è particolarmente consigliato utilizzare dei loop audio decenti e puliti che non
abbiano una fine inadatta. Altrimenti ci ritroveremmo a sentire il “click” ad ogni termine di
riproduzione. E noi non lo vogliamo, vero?
Adesso possiamo velocemente passare al Jump Pad. Fortunatamente per noi, lo script che ci viene
consegnato con il tutorial ha già una struttura per gestire l’audio solo quando il pad viene usato.
Quindi:
• Clicchiamo su una delle istanze del Jump Pad nello scenario, per selezionarla;
• Tramite drag’n’drop trasciniamo nell’inspector il file audio corrispondente (la procedura
si occuperà di creare una audio source in maniera automatizzata);
• Applichiamo le modifiche al prefab originale, per estendere i cambiamenti effettuati a
tutte le istanze;
• Sperimentare le impostazioni fin quando non si è soddisfatti del risultato.
Così, per quanto riguarda i suoni ambientali, abbiamo sistemato le cose.

Suoni dei Collectables


Per questa tipologia di oggetti le cose sono ancora più semplici. Sia il container di salute che la cella
di carburante hanno già una struttura dedicata che gestisce in maniera automatizzata la riproduzione
dei suoni, qualora ce ne siano di associati ad essi.
Quindi, non serve altro che prendere e trascinare con il drag’n’drop i file audio corrispondenti
proprio come abbiamo fatto con il Jump Pad. I suoni in questione sono pickupFuel e
pickupHealth.

Queste che vedete qui sopra sono le impostazioni consigliate: il volume del suono a 2, leggermente
più alto del normale, serve a far sentire bene l’effetto rispetto agli altri suoni del gioco quando viene
riprodotto.

La Barriera
A separare Lerpz dalla sua nave c’è una barriera di energia. Sarebbe ora di dare anche a lei un po’ di
vita con un suono decente, no? Provvediamo. Il sample in questione lo troviamo col nome di
“activeFence”.
• Nello Hierarchy Panel, sotto “levelGeometry”, cerchiamo l’oggetto impoundFence;
• Trasciniamo, sempre tramite drag’n’drop, il suono sull’oggetto. Verrà automaticamente
creata una sorgente audio in corrispondenza;
• Sistemare le varie impostazioni come segue:
Adesso il nostro livello ha un po’ di vita in più

Potrebbero piacerti anche