Le basi del Game Engine, il motore di gioco di Blender 3D 2.6 – Lezione 3; videotutorial con trascrizione

Video sottotitolato Per attivare i sottotitoli in questo video, aprire il menù in basso a destra nel Player YouTube e selezionare la casella "CC".

Salve a tutti, eccoci alla terza puntata del videocorso sulle basi del Blender GE, il Game Engine, motore di gioco di Blender 3D 2.6; in questa puntata, come anticipato nelle puntate precedenti, inizieremo a parlare dell'interazione (in particolare mediante tastiera), dello schema logico sensori-controller-attuatori, delle proprietà e della fisica nel GE.

Dico “inizieremo” perché questi argomenti sono piuttosto vasti e verranno approfonditi nelle prossime puntate, non possiamo parlare di tutto in questo video, qui vedremo un'introduzione e un esempio pratico. Per prima cosa, quindi, due parole sulla logica nel GE.

Il Blender Game Engine è stato progettato per consentire un approccio il più possibile visuale alla definizione dell'ambiente di gioco, definendo cioé i comportamenti e le interazioni degli oggetti con poche proprietà o condizioni collegate tra loro e rappresentate in maniera visiva mediante “blocchi”, detti Logic Bricks, letteralmente i mattoncini della logica del gioco.

E' quindi possibile realizzare applicazioni senza conoscere nemmeno le basi della programmazione o del linguaggio Python, ma la cosa positiva è che è possibile estendere le funzionalità di base del Game Engine mediante la programmazione, se si conoscono le API di programmazione, ossia le librerie di classi e metodi per interfacciarsi col GE, e ovviamente il linguaggio Python.

E' più facile comprendere il sistema “logico” di sensori, controller e attuatori mostrando direttamente un esempio pratico piuttosto che descrivendolo a parole, per cui con la scena di base passiamo subito al motore di gioco nel selettore Engine, nella finestra Info, al sistema di ombreggiatura GLSL e alla modalità Textured (questo non è fondamentale, ma così ci abituiamo a farlo), dopodiché selezioniamo ad esempio il cubo di default e soprattutto cambiamo una finestra del programma in Logic Editor, ossia l'ambiente di sviluppo visuale della logica del gioco.

Blender mette a disposizione proprio un Layout per lavorare meglio alla realizzazione di un'applicazione, per cui è possibile cambiare lo Screen in Game Logic per visualizzare immediatamente 3D View, editor di testo (per realizzare o visualizzare script in Python o altre risorse), Outliner, Properties Window e Logic Editor.

Come possiamo notare, la finestra è divisa in due parti: a sinistra una sezione chiamata “Properties” e inizialmente vuota (a parte il pulsante “Add Game Property”), a destra una sezione con tre colonne: sensori, controller e attuatori. Le due sezioni possono essere ridimensionate ed è possibile spostarsi nelle aree e zoomare, in particolare il panning si fa con click della rotellina o testo centrale del mouse e lo zoom con + e – del tastierino numerico oppure con la rotellina del mouse.

Nota importante: questi elementi (ossia proprietà, sensori, controller e attuatori) fanno riferimento all'oggetto attivo della scena, che nel nostro caso corrisponde con l'unico oggetto selezionato, il cubo, come possiamo notare comunque osservando i pulsanti “Object Name” sotto le etichette di sensori, controller e attuatori.

Ed eccoci al discorso della logica del GE: ad ogni elemento possiamo associare delle proprietà (che possono essere dei valori, ad esempio il livello di energia, il numero di vite, il nome, eccetera), dei sensori (che rilevano degli eventi o condizioni, ad esempio la pressione di un tasto della tastiera o una collisione con un oggetto) e degli attuatori, che effettuano delle azioni.

Se ad esempio vogliamo che alla pressione della freccia in su il cubo si sposti in avanti, ossia – ad esempio – lungo il suo asse Y (e per “suo” intendiamo l'asse LOCALE), allora dovremo inserire un sensore in grado di rilevare la pressione del tasto freccia in su per attivare un attuatore in grado di spostare l'oggetto.

I controller sono ponti di collegamento tra sensori e attuatori, per far passare il “segnale” in un certo senso; inizialmente useremo quello di default, AND, in seguito vedremo di approfondire anche questo aspetto.

Clicchiamo quindi su Add Sensor per il cubo: abbiamo a disposizione vari sensori e nelle prossime puntate li vedremo un po' tutti, trattando le loro caratteristiche. Per sviluppare il nostro esempio, ossia lo spostamento in avanti del cubo, aggiungiamo un sensore Keyboard, la tastiera.

Nella scheda del sensore possiamo impostare il tasto da rilevare, che attiverà il sensore, in Key, o scegliere “All Key” per attivare il sensore alla pressione di un tasto qualsiasi (ad esempio per realizzare un “premere un tasto per continuare”); nel nostro caso, quindi, facciamo click sul pulsante accanto a Key e premiamo la freccia in su nella tastiera: nel campo apparirà la scritta Up Arrow.

Lanciando il gioco ora con P e premendo la freccia in su non noteremo comunque nulla: il sensore infatti c'è, ma non abbiamo associato a tale elemento l'azione da intraprendere.

Torniamo quindi alla finestra Logic Editor e facciamo click, questa volta, su Add Actuator, per aggiungere un attuatore; anche qui abbiamo varie possibilità, che tratteremo in seguito, ma qui scegliamo subito “Motion”, letteralmente “Movimento”.

La scheda che ci verrà mostrata è nella versione ridotta, visto che di default gli oggetti non sono sottoposti a forze fisiche e non reagiscono a urti e collisioni; tra pochi minuti, vedremo la differenza tra oggetti Statici, Dinamici e Rigid Body e noteremo anche le nuove voci nella scheda Motion, che attualmente presenta solo Loc e Rot, ossia posizione e rotazione.

Notate le caselle L, di default attive, nelle righe Loc e Rot: indicano che gli spostamenti o le rotazioni fanno riferimento agli assi LOCALI dell'oggetto, non alle coordinate globali... siccome vogliamo spostare l'oggetto cubo lungo l'asse Y locale, lasciamo selezionate tali caselle.

Intuitivamente, possiamo scrivere in Loc Y locale l'entità dello spostamento da effettuare quando l'utente preme il tasto freccia in su, per cui scriviamo ad esempio 0.01: alla pressione di quel tasto, il cubo avanzerà di 0,01 unità di Blender lungo l'asse Y locale e continuerà ad avanzare finché terremo premuto il tasto.

Lanciamo di nuovo l'applicazione con P, premiamo il tasto freccia in su e... ancora una volta, non succede niente. Il motivo è chiaro: sensore e attuatore ci sono, ma non sono collegati!

Nel Logic Editor, quindi, facciamo click col tasto sinistro del mouse sul cerchietto a destra della scheda di Keyboard (cerchietto detto socket di output, porta di uscita) e, tenendo premuto il tasto sinistro del mouse, trasciniamo fino a rilasciare sulla porta di ingresso (socket di input) dell'attuatore Motion, realizzando appunto un collegamento.

Anche se non l'abbiamo inserito, è apparso un controller di default nel collegamento tra il sensore e l'attuatore, in particolare un controller AND (dal nome della porta logica rappresentata), che nel nostro caso lascia passare tranquillamente il segnale.

Ricapitolando: alla pressione del tasto freccia in su, il Game Engine attiverà il sensore Keyboard sensibile alla freccia in su per il cubo, che trasmetterà un segnale che passerà nel controller AND ed arriverà all'attuatore Motion, che in questo caso sposterà il cubo in avanti lungo l'asse Y locale.

Premiamo P per avviare il gioco e, dopo, la freccia in su: questa volta, il cubo si sposterà come previsto.

Da notare che, facendo uscire il cubo dal piano, l'oggetto non cadrà, in quanto di default statico, non soggetto a forze o urti, nemmeno alla forza di gravità. Usciamo dal gioco e torniamo al Logic Editor.

Va detto subito che da un sensore possono uscire più collegamenti, diretti a più controller, e da un controller possono uscire più collegamenti, diretti a più attuatori; inoltre, più collegamenti possono finire in un attuatore e più collegamenti possono finire in un controller, ma quest'ultimo caso è un po' particolare, per cui lo esamineremo per ultimo. Vediamo quindi degli esempi.

Aggiungiamo un nuovo attuatore, questa volta di tipo “Filter”. Questo attuatore implementa un filtro di post-produzione all'immagine visibile in tempo reale; in particolare, possiamo scegliere tra più filtri, come ad esempio Sharpen (per mettere in rilievo i bordi), Blur (la sfocatura, molto utile per gli oggetti in movimento) ed altri... per notare l'effetto in questo test, scegliamo “Sharpen” e colleghiamo il controller AND anche a tale attuatore, oltre che a Motion.

Esaminiamo il flusso logico: alla pressione della freccia in su, verrà generato un segnale che passerà attraverso il controller AND e arriverà sia all'attuatore Motion (spostando in avanti l'oggetto) che a Filter, attivando il filtro. Premiamo P e proviamo il tutto a runtime, premendo il tasto freccia in su.

Torniamo quindi nella finestra Logic Editor, in fase di modifica.

E' possibile associare un nome ai vari sensori, controller e attuatori in modo da riconoscerli velocemente quando diventano parecchi o vengono minimizzati, per risparmiare spazio e rendere lo schema logico di più facile lettura; le schede vengono minimizzate cliccando col tasto sinistro del mouse sulla freccia in alto a sinistra nelle schede, come sto mostrando a video, e vengono massimizzate cliccando nuovamente su tale freccia. Il nome della scheda va digitato nel campo testuale in alto al centro, per cui ad esempio possiamo scrivere FrecciaSu per il sensore Keyboard che si attiva con tale tasto, “Avanti” nell'attuatore Motion su Y locale, e così via.

Tagliamo il collegamento tra AND e Filter: questa operazione va fatta premendo CTRL e il tasto sinistro del mouse e, tenendoli entrambi premuti, trascinando in modo da “tagliare”, appunto, il collegamento, come visibile a video.

Togliamo l'attuatore Filter facendo click sul pulsante con la X in alto a destra nella scheda dell'attuatore; come è possibile notare, questo pulsante è presente in tutte le schede di sensori, controller e attuatori e consente la rimozione dell'elemento dal Logic Editor.

Come anticipato, è possibile collegare più sensori ad un controller, ma qui bisogna aprire una piccola parentesi.

Il controller di default, AND, implementa appunto la porta logica AND, che – detto brevemente – fa passare un segnale se e solo se sono presenti dei segnali positivi, o “True” (veri), in tutti i collegamenti in ingresso.

Quando c'è un solo collegamento in ingresso, come nel nostro caso, il segnale viene trasmesso nel momento in cui arriva, infatti non c'è bisogno di controllare con altri segnali: non ce ne sono!

Facciamo alcuni esempi utilizzando due sensori; il primo è Keyboard, già presente, mentre per il secondo scegliamo il tipo “Always”, letteralmente “sempre”, che difatti invia costantemente un segnale in uscita (ottimo, ad esempio, per realizzare contatori, timer, eccetera).

Se colleghiamo Always all'attuatore di movimento mediante un nuovo controller AND, creato per l'occasione, allora a runtime il cubo si sposterà da solo, perché Always manderà costantemente un segnale che, passando da un AND privo di altri sensori in ingresso, raggiungerà indisturbato l'attuatore Motion e sposterà il cubo.

Togliamo il secondo controller AND e colleghiamo Always alla socket di input del primo controller AND, quello che riceve anche il segnale di ingresso di “FrecciaSu”: adesso il cubo non si sposterà fino a quando non premeremo il tasto freccia in su, infatti adesso AND deve ricevere un segnale contemporaneamente da due ingressi per trasmettere il comando agli attuatori collegati (in questo caso, solo Motion).

AND è il controller di default ma non è l'unico: è possibile scegliere tra altre porte logiche, come OR (che trasmette un segnale se almeno uno dei sensori in ingresso lo sta trasmettendo), oppure Expression che verifica un'espressione (formulata in linguaggio Python) o, ancora, Python, che esegue uno script o un modulo Python.

Nota a margine: il segnale trasmesso è, di default, positivo, o “True” per gli informatici, ma un sensore può trasmettere anche un comando False, negativo, quando viene attivato, purché si selezioni la casella “Invert”, inverti segnale appunto, presente nella scheda di ogni sensore.

Le Properties o proprietà degli oggetti sono invece caratteristiche degli stessi, memorizzate come dati numerici, booleani (cioé vero o falso) o stringhe di caratteri; l'esempio tipico è il numero di vite del personaggio, memorizzato appunto mediante un numero da associare ad un elemento.

La scheda delle Proprietà si trova a sinistra nel Logic Editor e il funzionamento di tali elementi è abbastanza semplice: per associare una proprietà numerica al cubo, ad esempio, clicchiamo su Add Game Property e personalizziamo la scheda proprietà appena creata.

In questa puntata non lo vedremo ma è possibile, ovviamente, ricavare o modificare i valori delle Properties mediante gli attuatori, oltre che generare degli eventi se le proprietà assumono determinati valori (ad esempio, terminare il gioco se finisce il tempo o il giocatore perde tutte le vite).

Questa è la punta dell'iceberg riguardo a proprietà, sensori, controller e attuatori ma in questa puntata la panoramica introduttiva su questi argomenti si ferma qui per passare ad un'altra introduzione: quella relativa alla fisica nel GE; sempre in questa puntata, per finire, vedremo un esempio pratico che riguarderà interazione e fisica.

Questo è un buon momento per mettere in pausa, riposarsi un po' e riprendere tra poco con la seconda parte di questa puntata, relativa ad un argomento del tutto differente: la fisica nel GE.

* * *

Eccoci alla seconda parte di questo tutorial: gli elementi di base della fisica degli oggetti nel GE.

Come avrete notato, di base gli elementi sono statici, ossia non sono soggetti a forze, nemmeno alla forza di gravità (che pure è presente). Le informazioni che riguardano questi aspetti si trovano principalmente (ma non solo) nella scheda Physics, all'interno della Properties Window, che con l'Engine Blender Game mostra strumenti diversi da quelli presenti con Blender Render.

La prima voce da esaminare è quella che determina la natura fisica dell'oggetto: il menù Physics Type, il “tipo fisico” appunto, che ha voce di default Static.

Un oggetto Static può essere mosso mediante attuatori, infatti abbiamo spostato il cubo, ma non reagisce a forze e impatti. Static è il tipo di default e, per inciso, anche il Plane che fa da pavimento per il cubo è di tipo Static, infatti non cade nel vuoto. La funzione di Static non è solo quella di fare da pavimento o comunque da contorno immutabile, ma anche di risparmiare risorse a tempo di esecuzione: se un oggetto non può essere spostato, raggiunto o distrutto, ad esempio un vaso su un mobile, è inutile farlo partecipare alla simulazione dinamica, tanto vale lasciarlo Static.

Il tipo base per la simulazione dinamica è, appunto, Dynamic: un oggetto Dynamic è soggetto a forze, quindi precipita se lasciato nel vuoto, e reagisce agli urti, in particolare rimbalzando, traslando o scivolando, non rotolando; implementa, cioé, la “Linear Physics”.

Se ad esempio rendiamo il cubo Dynamic e lo posizioniamo inizialmente ad una certa quota rispetto al piano, lo vedremo cadere all'inizio dell'esecuzione del gioco (e, ovviamente, impostando come Dynamic anche il Plane, li vedremo precipitare entrambi nel vuoto, mentre impostando il Plane come “No Collision”, cioé esente da qualsiasi tipo di collisione, vedremo il cubo passare attraverso il Plane e precipitare nel vuoto; No Collision va bene per oggetti che non possono essere raggiunti, come oggetti di sfondo, per risparmiare ulteriormente risorse a runtime).

Il passaggio a Dynamic rende disponibili anche altre parametri sia nell'attuatore Motion che all'interno della stessa scheda Physics.

Per quanto riguarda Motion, abbiamo dei campi (Force e Torque) che ci permettono di impostare le trasformazioni come forze, non come semplici traslazioni o rotazioni immediate, per cui ad esempio cambiando l'attuatore di movimento su Y da Location a Force su Y, cambiando i parametri nei relativi campi, durante l'esecuzione dovremo tenere premuta la freccia in su per muovere il cubo gradualmente e l'entità dello spostamento aumenterà sempre più finché terremo premuto il tasto... in pratica, come premere sull'acceleratore di un'automobile.

Nella scheda Physics per il momento notiamo solo, tra i nuovi parametri presenti, Mass, che indica appunto la massa dell'oggetto (importante per valutare le forze da applicare) e Radius, che si riferisce al raggio della sfera (invisibile in tempo reale e visualizzata come un cerchio tratteggiato nella 3D View) che serve a rilevare le collisioni per l'oggetto, almeno fino a quando non si impostano forme ad hoc per rilevare le collisioni in Collision Bounds, in basso nella scheda.

Per implementare, oltre alla Linear Physics, anche la Angular Physics, ossia le rotazioni a seguito di forze, collisioni o altro, dobbiamo scegliere il tipo Rigid Body. E' un tipo distinto da Dynamic perché non tutti gli oggetti hanno bisogno di questo tipo di simulazione fisica, che richiede più risorse rispetto a Dynamic, quindi se possibile si sceglie Dynamic, altrimenti (ad esempio, per far rotolare una sfera) si fa ricorso a Rigid Body.

Soft Body è il tipo più complesso e che richiede più risorse: consente la deformazione a runtime degli elementi, ad esempio la deformazione di un oggetto in seguito ad un urto o altre simulazioni fisiche. Richiede molte risorse ed è in grado di rallentare sensibilmente l'esecuzione del programma, è ottimo per realizzare animazioni da renderizzare poi col rendering classico partendo da simulazioni fisiche interattive.

Facciamo un esempio pratico: rendiamo il Plane Static, suddividiamo il Cubo un bel po' di volte e rendiamolo un Soft Body, quindi posizioniamo sopra al cubo, sospesa nel vuoto, una sfera, da rendere di tipo Dynamic. Avviando l'esecuzione, molto probabilmente vedremo la sfera rimbalzare sul cubo ma far precipitare questo al di sotto del Plane utilizzato come pavimento... un comportamento anomalo dovuto ai pochi calcoli di simulazione fisica realizzati di default dal Game Engine a runtime, ancora una volta (tanto per cambiare) per rendere l'esecuzione del gioco più fluida a scapito dell'accuratezza... ebbene, per risolvere questo problema possiamo aumentare il valore del campo Physics Substeps nella scheda World, all'interno della Properties Window, ed osservare il comportamento a runtime con valori differenti.

Valori elevati produrranno una simulazione fisica più accurata ma anche rallentamenti sensibili, a volte non tollerabili, durante l'esecuzione dell'applicazione, per cui si tratta di trovare il giusto compromesso tra qualità e velocità.

Cancelliamo sia il cubo che la sfera e lasciamo, per il momento, solo il Plane, Static, da utilizzare come pavimento per l'esempio pratico finale.. magari associamogli un Material e una Texture, giusto per non lasciare il solito Material grigio, e cambiamo anche il colore di World, ad esempio in nero.

Fisseremo meglio le differenze tra Static, Dynamic e Rigid Body tra pochissimo, realizzando un esempio pratico passo per passo, dove inizialmente sbaglieremo di proposito, in modo da ricordare meglio in futuro quale tipo fisico scegliere a seconda dell'effetto che vogliamo ottenere.

NOTA importante: alcune proprietà fisiche degli oggetti vanno impostate nei loro Materials, ma in questa puntata non tratteremo questo argomento, che vedremo quindi un'altra volta.

E' giunto il momento di passare ad un esempio pratico per mettere insieme gli elementi discussi in questo tutorial; in particolare, realizzeremo un effetto domino mediante una sfera e alcuni parallelepipedi, rappresentanti appunto le tessere del domino.

Inseriamo nella scena un nuovo cubo, che di default sarà di tipo Static, posizionandolo sul Plane-pavimento e scalandolo lungo i vari assi in modo da fargli assumere la forma di una tessera del domino in verticale; per risparmiare tempo, non fornirò Textures UV Mapped ai pezzi, solo un Material di default, d'altronde non è una cosa importante per questo esempio.

Di fronte al pezzo appena creato, inseriamo – poggiandola sul pavimento – una sfera. Anche questo oggetto sarà, almeno all'inizio, di tipo Static.

Dotiamo la sfera di sensore Keyboard con tasto da rilevare la barra spazio, attuatore Motion con spostamento lungo l'asse locale diretto verso il pezzo del domino e colleghiamo i due elementi con un semplice controller AND.

Avviamo l'esecuzione: premendo la barra spazio, e tenendola premuta, sposteremo la sfera – che traslerà, non rotolerà – fino a farla sbattere con il pezzo del domino, ma a quel punto la sfera passerà attraverso il pezzo e continuerà a spostarsi fintantoché terremo premuta la barra spazio.

Ormai sappiamo che per spostare gli oggetti in seguito a urti o forze dobbiamo renderli almeno di tipo Dynamic, per cui cambiamo la natura del pezzo del domino in Dynamic, avviamo il gioco e... vediamo che succede.

Il pezzo, all'inizio dell'esecuzione, è caduto un po', rimanendo a metà all'interno del pavimento: perché? Perché il bound iniziale utilizzato per rilevare le collisioni è la sfera, indicata col cerchietto tratteggiato nella 3D View, che ha diametro inferiore alla dimensione massima del parallelepipedo e, comunque, forma diversa, per cui quello che dobbiamo fare è attivare la casella Collision Bounds nella scheda Physics del parallelepipedo, all'interno della Properties Window, impostando Box come forma per rilevare le collisioni. Eseguiamo nuovamente il gioco: adesso ci siamo.

C'è da dire però che facendo sbattere la biglia con il pezzo del domino, l'urto farà scivolare il pezzo sul piano, senza farlo cadere; per implementare quest'effetto, il pezzo del domino deve diventare un corpo rigido, non un semplice Dynamic, in modo da attuare la Linear Physics, per cui cambiamo la sua natura in Rigid Body e riproviamo... ah, se prima abbiamo lasciato un valore alto per Physics Substeps, possiamo mettere nuovamente 1, perché in questo caso va più che bene e non rallenta inutilmente l'esecuzione del gioco.

Prima di procedere, aggiungiamo un sensore Always e un attuatore Filter 2D, con filtro di Blurring, al parallelepipedo che rappresenta il pezzo del domino, in modo da implementare una sfocatura permanente sugli oggetti, che tornerà utile quando saranno in movimento.

Adesso con il movimento del pezzo ci siamo e possiamo iniziare a posizionare altri pezzi, realizzati con semplici copie in Object Mode mediante SHIFT D e posizionati con semplici spostamenti sul piano X e Y e rotazioni intorno all'asse Z... l'ultima cosa da sistemare è il movimento della biglia, che si sposta con intensità fissa e senza rotolare.

Per quanto riguarda la biglia, visto che ci serve la sua rotazione cambiamo subito la natura in Rigid Body, quindi portiamo a 0 il valore di Location per l'attuatore Motion ed impostiamo un buon valore (da determinare facendo delle prove) per Force.

Ora che la biglia è un Rigid Body, può reagire all'urto con il pezzo del domino tornando indietro, senza far cadere il pezzo, per cui magari aumentiamo il valore della forza da applicare in seguito alla pressione della barra spazio.

Faccio notare che probabilmente dopo la prima collisione la biglia non si muoverà più nella direzione precedente se premeremo ancora la barra spazio; ciò è dovuto al fatto che la forza viene applicata sull'asse Y locale della biglia, oggetto che ora può orientarsi diversamente nello spazio in seguito alle collisioni... vi invito quindi a fare delle prove con gli assi globali oppure con Torque anziché Force.

Concludo questa puntata con uno spunto: con le conoscenze acquisite finora, provate a realizzare un giochino dove l'utente può lanciare una sfera con una traiettoria parabolica, con forze diverse, con lo scopo di abbattere dei pilastri o delle strutture poste ad una certa distanza... nella prossima puntata riprenderò il corso proprio da questo esempio, mostrando tra l'altro come fare per attivare certi attuatori solo in condizioni particolari (nel nostro caso, per evitare di spostare ulteriormente la sfera mentre è in volo, applicando cioé la forza di propulsione solo quando questa è a terra).

A presto!