Uno degli aspetti più complessi della progettazione di un videogioco è la formalizzazione del mondo. Con formalizzazione del mondo si intende il processo di sintetizzare in modo formale i vari aspetti di un ambiente o modello che si vuole rappresentare, elencando gli oggetti rilevanti e le relazioni fra gli stessi.

Videogiochi anche banali hanno un gran numero di oggetti. Prendiamo ad esempio un platform come Super Mario Bros. Il gioco è concettualmente semplice ma contiene un bel gruzzolo di oggetti: Mario, i mostri (ognuno con un suo comportamento), i proiettili (martelli e palline di fuoco), tubi, attivatori, power-up e molto altro. Tutti questi oggetti hanno i loro comportamenti caratteristici, i loro effetti e le loro proprietà. Per questo strutturare un “diagramma delle classi” che catturi il mondo da modellare in modo preciso può diventare un lavoro complesso e frustrante.

L’APPROCCIO GERARCHICO

Supponiamo che voi e il vostro team stiate progettando un piccolo gioco RPG-like. Se siete programmatori con un po’ di esperienza e avete dato esami di “Progettazione del Software” nella vostra vita, la prima cosa che vi verrà in mente di fare è di progettare la gerarchia delle classi con lo scopo di duplicare il meno possibile il codice necessario e relazionare gli oggetti fra loro in modo che siano coerenti con l’idea che abbiamo in mente.

Una volta individuati gli elementi principali del vostro gioco (ad esempio tavoli, mobilia, porte, NPC, oggetti e il giocatore) si comincia con il vedere quali proprietà/abilità/caratteristiche hanno in comune disponendoli all’interno di una gerarchia in cui il figlio eredita tutte le caratteristiche del padre (ed eventualmente ne aggiunge di nuove).

Con riferimento all’esempio del gioco RPG, gli oggetti si possono dividere fra oggetti “fissi” (come le porte, i tavoli e gli scaffali) e oggetti “dinamici” che possono muoversi e interagire (persone, animali e pozioni). A loro volta gli oggetti dinamici si dividono fra “item” (pozioni e armi) e personaggi in grado di parlare (come gli NPC, negozianti, mostri e il giocatore). Il risultato è molto probabilmente lo schema nella figura precedente. Lo schema funziona, è coerente con il mondo che progettavate e potete cominciare ad usarlo per programmare il vostro gioco. Tutti sono felici.

Poiché è innaturale e improbabile che tutto il gioco sia definito nei minimi dettagli prima di cominciare a programmare è possibile (diciamo certo) che ad un certo punto dello sviluppo i game designer vi chiamino dicendo: “Abbiamo pensato di inserire in questa mappa una porta parlante!” Voi nello schema precedente avete assunto che le porte non parlino, quest’idea dei game designer è interessante ma va in conflitto con il mondo che avete modellato! Sfortunatamente la porta parlante è una parte fondamentale della storia che i game designer si rifiutano di modificare. Cosa fate?

Per vostra sfortuna lo schema precedente è fisso! Le porte, per come le avete definite non si muovono e soprattutto non parlano. Lo schema gerarchico è rigido e pieno di assunzioni. Le soluzioni a questo punto sono poche:

• Aggirare il problema: la porta è in realtà un NPC con le sembianze di una porta, con vita infinita e inamovibile che “muore” quando viene aperta per poi “resuscitare” quando viene chiusa. Inquietante. No. Questa soluzione non è sufficientemente robusta ed elegante.
• Decidete che le porte possono parlare. Per fare ciò viene duplicato il codice di Talkable_Entity all’interno di Door_Entity. Questo però duplica il codice andando contro almeno sessantamila principi della programmazione (oltre che vanificare lo scopo dello schema precedente) il che non è desiderabile. In particolare stiamo sporcando il codice di tutte le porte per far parlare una porta che compare una ed una sola volta nel gioco!
• Si può spostare l’abilità di parlare da Talkable_Entity a Entity (o ad una super-classe qualsiasi in comune fra la porta e le Talkable_Entity). Ma questo non ha molto senso! In questo modo tutti gli oggetti possono potenzialmente parlare! Non solo la porta che voglio io ma anche scaffali, sedie e latrine.
• Oppure si può modificare l’intero schema in modo che tenga conto anche dell’evenienza di una porta parlante con conseguente riscrittura di gran parte del codice.

Poiché la porta parlante sarà solo la prima delle decine di eccezioni e entità fantasiose partorite dai vostri game designer, scoprirete presto che vi troverete a riscrivere il codice del vostro motore di gioco decine di volte solo per riadattarlo ad uno schema gerarchico in continua evoluzione!

In un gioco mediamente complesso vi ritroverete infine con centinaia e centinaia di classi, con fumose dipendenze e gerarchie. La complessità tecnica del gioco va alle stelle. Voi impazzite e il gioco finisce nel dimenticatoio.

L’APPROCCIO COMPONENT-BASED

La soluzione però esiste e per afferrarla è necessario dimenticarsi completamente di tutto ciò che sapete sulla progettazione del software. Per il solo fatto di parlarvene potrei essere bastonato dai vostri professori.

Ora seguitemi bene perché la questione è semplice ma sfuggente! Tornando al problema precedente una soluzione non ortodossa deriva dalla soluzione numero 3. Spostiamo la capacità di parlare da Talkable_Entity a Entity e aggiungiamo al costruttore un flag (ad esempio canTalk) in modo tale da poter scegliere durante la sua inizializzazione se l’oggetto può parlare oppure no. Una cosa di questo tipo:

A questo punto però ci rendiamo conto che possiamo usare la stessa tecnica per ogni componente dei nostri oggetti. Possiamo spostare in Entity la capacità di un oggetto di muoversi, la capacità di sparare, la capacità di essere raccolta, la capacità di ferire il giocatore, la capacità di essere distrutta e così via. Potete aggiungere ogni componente che vi pare basta aggiungere a Entity un flag e il rispettivo ComponentSystem.

Coa abbiamo ottenuto con questo? Ora abbiamo un unica classe per tutti gli oggetti del gioco (Entity) più una classe per ogni componente.

Notate che siamo passati da un approccio classico in cui gli oggetti sono caratterizzati dalla relazione is-a, oggetti diversi sono identificati dalla loro classe e dalle relazioni di ereditarietà che li lega, ad un’approccio basato sulla relazione “has-a“, in cui ogni oggetto è identificato dalle componenti che possiede.

Ovvero: ogni oggetto è definito unicamente dall’aggregato delle sue componenti!

Lo schema qui sopra rappresenta l’approccio a componenti di un piccolo gioco FPS e può aiutarvi a chiarificare il concetto. Primo: tutti gli oggetti nel gioco appartengono ad un unica classe (solitamente chiamata Entity. Secondo ogni entità può contenere una o più Componenti che definiscono le funzionalità del singolo oggetto. Ad esempio una granata ha una posizione, può muoversi, viene renderizzata, può essere un target e subisce l’influenza della fisica del gioco. Similmente il giocatore avrà molte capacità in comune con la granata ma non può essere un target (il giocatore non può spararsi da solo). E così via.

IN PRATICA

Una volta capito il concetto di approccio a componenti vediamo come può venir implementato. Cominciamo dalla classe Component. Ai fini di rendere l’architettura il più elastica, scalabile e coerente possibile, tutte le componenti devono mostrare la stessa interfaccia.

Questa è una classe astratta e quindi tutti i metodi vanno “riempiti” dalle singole componenti che ereditano dalla classe madre “Components”. Il tipo di un componente (come Talkable, Physics, Movements, e così via) serve ad identificare il componente e può essere identificato da un intero, come in questo esempio di classe Components, oppure in qualunque altro modo vogliate (stringhe, decimali, pittogrammi e chi più ne ha più ne metta).

Ora vediamo la classe Entity. Poiché la classe Entity altro non fa che fungere da “aggregatore” di componenti, l’implementazione risulta molto elementare:

Primo, la classe contiene un hash-table (o qualunque altra struttura efficiente) in grado di memorizzare la lista delle componenti dell’entità. Secondo implementa questi due metodi:

La classe Entity inoltre fa da tramite per la comunicazione fra componenti (anche se esistono approcci in cui due componenti possono comunicare direttamente).

VANTAGGI

Supposto per assurdo che quello che vi ho raccontato non bastasse, ecco una lista di vantaggi dell’architettura component-based.

• Scalabilità: non dovrete più conoscere a priori tutti gli elementi del vostro gioco, vi basta sapere quali componenti vi servono. Aggiungere oggetti o componenti si riduce ad aggiungere una classe e aggregare nel modo che più vi aggrada i componenti esistenti!
• Flessibilità: l’architettura è molto versatile. Talmente versatile che potete creare e modificare oggetti a runtime e farlo fare anche a chi non è pratico di programmazione (sfruttando ad esempio dei file XML in cui ogni oggetto viene definito semplicemente come una lista di componenti). Magari in qualche altro articolo vi farò vedere un esempio.
• Riusabilità: è molto comune che due giochi abbiano componenti in comune. Con il sistema component-based vi basta importare le classi componenti da un gioco all’altro e tutto funzionerà alla perfezione.

CONTRO

Ogni architettura ha i suoi vantaggi e svantaggi. Nel caso dell’architettura component-based il principale svantaggio consiste nel rispondere alla domanda “Questa particolare entità che oggetto è?”. Poiché gli oggetti sono tutti Entity e l’unica cosa che permette di discriminare fra loro sono le componenti che possiedono, se voglio identificare un oggetto devo mettermi la coscienza in pace e prepararmi ad una serie stremante di if-else per controllare la presenza di un particolare sotto-insieme di componenti. Nell’approccio tradizionale tutto questo si ridurrebbe nel farsi restituire il nome della classe dell’oggetto.

Nello sviluppo di videogiochi questo non è un grande problema ed è comunque controbilanciato dagli innumerevoli vantaggi che l’architettura component-based offre. Però se volete usare quest’approccio (o uno ibrido) per qualche altra tipologia di applicazioni vi conviene tenere a mente questo problema e valutare se sia conveniente o meno per il vostro scenario.

Fare un videogame è una delle cose più complicate del mondo. Il game development è una disciplina in cui non si incontra solo la bruta tecnica informatica bensì anche arti visive, musica, narrazione, design e un vero oceano di materie diverse. Anche restando solo nel livello informatico, la programmazione richiede un insieme eterogeneo di materie informatiche, dalla programmazione grafica, all’architettura di sistemi, all’IA, al data managment e così via. Per progettare un gioco gli sviluppatori indipendenti e gli aspiranti tali (come me) devono quindi aver ben chiaro come si struttura l’architettura di un programma complesso quanto un videogame. Cosa che in realtà non è così semplice e che cercherò di chiarire almeno nei suoi punti fondamentali.

Ok. Questa è a grandissime linee l’architettura di un gioco. Stampatevela in testa. Tenete presente però che nella pratica la divisione fra livelli non è sempre così netta ed è possibile trovare librerie che ne coprono due (o più) insieme .

Librerie Grafiche di Basso Livello

Tralasciando l’hardware (la cui spiegazione è più che ovvia), il primo strato che incontriamo riguarda le librerie di basso livello. Rientrano in questa categoria OpenGL e le Direct3D (badate bene, non le DirectX di cui le Direct3D sono la parte grafica).

Le librerie grafiche di basso livello sono la struttura più vicina all’hardware ed offrono una grande libertà al prezzo di un elevata complessità. Esse spesso fungono da interfaccia fra la CPU e la GPU tramite linguaggi di shading ad-hoc come HLSL o GLSL.

Raramente si sviluppa un gioco partendo da tali librerie. Guardando il diagramma precedente la motivazione è intuitiva: partendo dalle librerie di basso livello bisogna ricostruirsi tutti gli strati superiori. Cosa che per dei programmatori indipendenti è un compito lungo, noioso e quasi mai portato a termine.

Audio Engine e Librerie Audio di Basso Livello

Parlerò di questi due livelli assieme poiché nella pratica è difficile trovarli completamente separati. Queste librerie, come ad esempio le OpenAL, si occupano della gestione della parte audio del gioco. A seconda del livello di astrazione, tali librerie non si limitano solamente a leggere e riprodurre un file audio ma offrono funzionalità più avanzate quali ad esempio aggiungere effetti d’ambiente, riverbero, eco o la simulazione della spazialità del suono e dell’effetto doppler.

La programmazione dell’audio è solitamente considerata meno complessa della programmazione grafica e l’uso di librerie come OpenAL è decisamente comune. Tuttavia come vedremo i livelli superiori spesso e volentieri integrano tali librerie al loro interno.

Input

Il layer di input gestisce i comandi in arrivo dalle periferiche dell’utente come mouse, tastiera o gamepad. Librerie corrispondenti a questo livello sono ad esempio le OIS e parte di FreeGLUT. L’uso di queste librerie è solitamente piuttosto intuitivo e non necessita molte spiegazioni. I layer superiori di solito si limitano a wrappare semplicemente le librerie di input.

Rendering Engine

I motori di rendering sono molto simili alle librerie grafiche di basso livello ma aggiungono funzionalità importantissime quali: importazione di texture e modelli, gestione dello scenegraph e gestione delle animazioni (oltre a nascondere tutti i dettagli tecnici dei livelli inferiori). Oltre a questo spesso i motori di rendering sviluppano due backend separati e permettono quindi di scrivere codice che si poggia indistintamente su OpenGL o Direct3D in modo da facilitare la portabilità del codice su sistemi diversi.

Un motore di rendering molto noto è Ogre3D.

Multimedia/Game Library

Salendo di un livello troviamo le game library. I motori di rendering infatti si limitano a gestire la grafica ma non offrono ad esempio nessun supporto per l’audio e l’input.

A mettere tutto assieme sono proprio le game library, librerie che non solo uniscono e mescolano tutte le librerie degli strati inferiori (grafica, audio e input) ma aggiungono altre caratteristiche importantissime per i videogame come gestione dell’output su disco, l’integrazione di librerie fisiche (quali ad esempio Bullet o Box2d) e chi più ne ha più ne metta.

Rientrano nella categoria librerie come XNA, Panda3D, DeltaEngine, jMonkeyEngine (in gran parte) e per quanto riguarda il 2D SFML.

Le game library sono solitamente un buon punto di partenza per chi vuole sviluppare un videogame perché offrono un ottimo compromesso fra alto e basso livello.

Game Engine

La prima cosa da fare quando si sviluppa un videogame è scrivere il game engine. Oppure lo si può prendere già pronto. I game engine offrono un livello di astrazione ancora maggiore delle game library, implementano costruttori di mappe, gestione degli assets, generatori di terreni, acqua e condizioni climatiche e molto altro, lasciando allo sviluppatore solo la parte divertente: la logica di alto livello, la costruzione dei livelli e così via. I game engine commerciali sono vere e proprie applicazioni, una specie di IDE dei videogame e offrono quasi sempre tools di modellazione e design visuali all’avanguardia.

Game engine molto noti sono Unity3D, Unigine, CryEngine, Source Engine, Unreal SDK e molti altri ancora. I game engine sono molto potenti e permettono in breve tempo di tirare fuori qualcosa di interessante. Il rovescio della medaglia è che costano. Per usufruire di versioni complete o della possibilità di vendere il proprio gioco si può arrivare a sborsare centinaia o migliaia di euro.

Molti game engine inoltre offrono delle API di backend per poter scrivere i propri personali moduli di basso livello (ad esempio per gestire la rete, il multiplayer o un personale sitema di input).

Logica di Alto Livello

Siamo arrivati alla punta dell’iceberg e al livello più interessante. Arrivati a questo punto si programma il gioco vero e proprio, si decide la grafica, si impostano le strutture dati, si progetta l’IA e poi si lancia il tutto sul game engine. Spesso questo livello è implementato con linguaggi di alto o altissimo livello (proprietari come l’Unigine Script oppure generici come Lua, C# o Python).

Se arrivate a questo punto siete nella parte creativa del game developing.

Conclusione

Dopo questa panoramica veloce della struttura di un videogame siamo pronti a passare ad argomenti più pratici e meno teorici e forse anche più divertenti!

Giusto per fare un esempio in Java è abitudine leggere (o scrivere) codice raccapricciante quale

che in C# si risolve con un semplice

Qualcuno considererà questa caratteristica (tecnicamente si parla di Accessor e Mutators) un puro vezzo sintattico, ma quando si lavora con decine e decine di classi vi posso assicurare che questo facilita di un fattore dieci la produttività e la manutenibilità del codice. Problemi come questo ed altri più “concreti” sono ciò che mi hanno spinto a passare al lato oscuro della forza ogni qualvolta mi è possibile.

In attesa che Java venga riformato (sperando nella rivoluzionaria (?) versione 8 e 9 del linguaggio) la comunità si è messa in moto in modo autonomo. Uno dei progetti a mio avviso più interessanti è senza dubbio Ceylon, di Red-Hat.

Ceylon è un linguaggio JVM-based, ovvero che viene compilato generando byte-code compatibile con la Java Virtual Machine. Questo garantisce due vantaggi: il linguaggio sfrutta la portabilità e le ottime performance della JVM ed è potenzialmente compatibile con le librerie Java esistenti.

Ceylon è un linguaggio molto interessante perché non solo alleggerisce Java da tutti gli inutili orpelli sintattici di cui è infestato ma aggiunge anche una sorta di dinamismo opzionale nella gestione delle variabili (tramite il tipo jolly value). Ma facciamo qualche esempio.

Come non partire dal mitico “Hello, World!”? In realtà non è un “Hello, World!” semplice perché ci mostra due nuove caratteristiche del linguaggio. La prima è il modo con cui vengono documentati metodi e classi: niente commenti, ma una sintassi specifica che può essere letta dal generatore di documentazione integrato di Ceylon. La seconda è il tipo variabile value che può essere usato per simulare una certa dinamicità del linguaggio. Da notare però che nessuno ci obbliga ad usarlo: se siamo sicuri che la variabile message sia una stringa possiamo direttamente dichiararla come tale tramite String message.

Un’altra funzionalità molto utile è l’operatore di null check. Vediamolo in azione:

In questo esempio troviamo i due operatori in azione. Il primo è l’operatore “?”. Considerando il codice precedente, tale operatore restituisce name.uppercased se e solo se quest’ultimo è diverso da null, altrimenti restituisce il valore che lo segue (in questo caso la stringa “WORLD”). L’altro operatore nell’esempio è “?.”. Quest’ultimo fa in modo che si acceda alla funzione/attributo uppercased se e solo se name è diverso da null. Questi due operatori ci risparmiano quindi tutta una serie di noiosi “if” annidati!

Le caratteristiche di Ceylon sono numerosissime e per maggiori informazioni vi rimando alla loro pagina ufficiale. Ceylon è ancora in fase di sviluppo ma è già possibile scaricare delle versioni preliminari!

Come se non bastasse è in progetto lo sviluppo di un backend che compili Ceylon in JavaScript rendendone possibile l’uso anche per lo sviluppo di applicazioni web.

Insomma, Ceylon è un progetto che vi consiglio caldamente di tenere d’occhio!

Senza pretese di scientificità o di dogma o di starvi a rivelare chissà quale verità arcana nascosta, vi dirò la mia sull’argomento. Innanzitutto sappiate che sulla faida statico/dinamico ci sono tonnellate di discussioni filosofiche, euristiche, epistemologiche e tecniche capaci di far impallidire chiunque provi ad avvicinarsi alla questione.

Celeberrimo è il duck test di Whitcomb Riley: “Quando io vedo un uccello che cammina come un’anatra, nuota come un’anatra e starnazza come un’anatra, io chiamo quell’uccello “anatra”". Concetto che i sostenitori della tipizzazione dinamica sintetizzano in: guardate la vignetta precedente, se la scritta vi è stata di aiuto allora la tipizzazione statica fa per voi.

In pratica la questione è prettamente filosofica: l’identità di un oggetto-barra-valore deve derivare dalle sue caratteristiche o da una specifica esterna? Ovvero: un’anatra è un anatra perché vola, nuota, ha le piume, etc… oppure è un anatra perché dico che è un anatra?

Dal punto di vista della rappresentazione della conoscenza possiamo essere d’accordo che un oggetto sia identificato dalle sue proprietà, dal punto di vista informatico invece la questione è più spinosa. In informatica tutto è un numero e i numeri non hanno proprietà per natura bensì caratteristiche che nascono dall’interpretazione che io ne do (tramite l’assegnazione di un tipo).

Ma chiudendo la parentesi filosofica torniamo all’atto pratico: perché dovrei scegliere un linguaggio statico rispetto ad un linguaggio dinamico? Non c’è risposta, serve solo l’esperienza e il gusto personale. Tuttavia negli ultimi dieci anni ci hanno distrutto l’anima raccontandoci che i linguaggi statici (C, Java e compari) erano obsoleti e che il futuro era dinamico. Il risultato di questa campagna è che attualmente abbiamo decine di linguaggi dinamici liberi e di ottimo livello (Python, Ruby, PHP e molti altri) e solo un paio di linguaggi statici decenti. Io, da estimatore dei linguaggi statici, vengo qui per raccontarvi le mie personali considerazioni sull’argomento.

1. Ordine nel caos

Quando mi sono messo ad usare il Python per progetti di media complessità (vedi CobraDraughts) ho sempre avuto l’impressione che tutto era avvolto dal disordine. Il fatto che non bisognava dichiarare da nessuna parte gli attributi di una classe mi inquietava.

Oltre ai miei problemi psicologici però c’era un comportamento oggettivamente fastidioso: presa la classe A non c’era verso dalla classe B di sapere durante la digitazione del codice quali attributi avesse e, soprattutto, di che tipo fossero. Questo perché non esiste nessun tipo associato alle variabili di un linguaggio dinamico!

Questo comporta due grossi problemi:

• Il compilatore è quasi inutile come strumento di correzione degli errori. Se passo una stringa ad una variabile che nell’intero arco della sua vita deve contenere solamente interi non lo vengo a scoprire fino a quando non eseguo quella porzione di codice e il programma muore. Insomma, l’analisi statica del codice è praticamente nulla. Bisogna armarsi di pazienza e code-coverage ed eseguire il codice.
• L’overloading di funzioni con lo stesso numero di parametri è un parto greco. Probabilmente non si usano ma il mio cuore ne ha sofferto.

A me personalmente tutta questa cosa fa sembrare che il programma si regga su un sottobosco di magia che non apprezzo. Inoltre la stretta maglia dei tipi mi costringe anche a strutturare meglio il codice e ad essere più rigoroso nello sviluppo.

2. Prestazioni

Qui c’è poco da fare. I linguaggi statici stracciano spesso e volentieri un linguaggio dinamico sul campo prestazionale, sia per il tempo che per la memoria. Ciò è causato semplicemente da tutto l’overhead necessario a gestire la “naturalissima” dinamicità delle variabili. Per alcune applicazioni ciò non è un problema (anche grazie all’uso di librerie che wrappano codice C) ma per molte altre invece si!

Molti dicono che questo non è un gran problema perché abbiamo macchine sempre più efficienti. Io credo che questo sia come dire che posso ingrassare venti chili perché tanto ho i pantaloni con l’elastico.

3. Didattica

Un aspetto da non trascurare. Quando mi trovo davanti la solita domanda su quale linguaggio sia meglio per cominciare a programmare, sento che molti consigliano linguaggi come il Python perché sono più semplici. Questo è sicuramente vero, la tipizzazione dinamica permette di trascurare una gran parte di aspetti della programmazione, ma mentre ciò può essere buono per chi già programma, a mio avviso, è un problema per chi comincia. Sarebbe come se un maestro di scacchi mi insegnasse a giocare senza cavalli, alfieri e 4 pedoni perché così è “più facile”.

Il risultato di certe politiche è l’inondazione di brutto codice e la prolificazione di programmi orrendamente progettati. Senza contare i bimbominkia del development che vanno in giro a raccontare che “il C è inutilmente complesso e fa schifo” mentre “il PHP ruleggia”.

È quindi importante per chi tiene corsi o si vuole avvicinare alla programmazione senza tutta la vicinanza alla macchina del C, di mantenersi almeno all’inizio sui linguaggi statici (come il Java o il C#) che aiutano a creare quella forma mentis necessaria anche per i linguaggi dinamici.

Inoltre, se ciò non bastasse, è più facile passare dallo statico al dinamico che viceversa. Quindi sul lungo periodo si risparmia anche fatica.

In conclusione: questi sono i motivi per cui trovo molto molto più divertente lavorare con linguaggi staticamente tipizzati rispetto ai linguaggi dinamicamente tipizzati. Non sono leggi assolute e potete benissimo rispondermi che “io col Python ho programmato un AI senziente ed è stato facilissimo”. Ci credo, anche io uso il Python spesso.

Chiudo con una speranza. La speranza che i linguaggi statici vengano riscoperti e portati avanti in modo da avere la stessa scelta che abbiamo oggi con quelli dinamici. Lasciare questo mondo solo al C/C++, allo sgangherato Java e al controverso C# secondo me è una grandissima occasione sprecata.

Nell’analizzare variazioni complicate si deve esaminare ogni ramo dell’albero una ed una sola volta.

A scriverla non un informatico ne un matematico bensì il maestro di scacchi sovietico Alexander Kotov nel suo famoso Pensa come un Grande Maestro.

La cosa che più sorprende della frase, nonché di tutta l’opera di Kotov, è che in un epoca in cui l’informatica muoveva i suoi primi passi, un maestro sovietico di scacchi usasse con tanta naturalezza termini come ramo ed albero per descrivere il processo umano di analisi di una posizione scacchistica e della ricerca della migliore soluzione.

Ed è proprio la parola “ricerca”, secondo Kotov, il centro nevralgico di tutto il gioco: il grande maestro si differenzia dal principiante per la sua capacità di organizzare la mente, di strutturare il pensiero e di cercare in modo efficiente la migliore mossa possibile.

Oggi, a 40 anni di distanza da quelle parole, sappiamo che quelle parole erano vere e sono ancora oggi la base di tutta l’AI moderna. Il concetto di ricerca infatti rappresenta le fondamenta di tutte le tecniche di AI. Sia che si tratti di cercare un percorso, pianificare una serie di azioni, trovare una mossa in un gioco o il minimo di una funzione non-lineare, tutta l’intelligenza sintetica ha in comune lo stesso principio: navigare l’incerto alla ricerca della soluzione migliore.

La differenza vera riguarda il come questa ricerca viene effettuata. Gli algoritmi di ricerca solitamente si possono descrivere in 20 righe di pseudocodice, eppure nessuno di questi algoritmi, preso così com’è, potrebbe essere applicato con successo ad un problema reale. Prendiamo ad esempio l’alpha-beta pruning, algoritmo alla base di un infinità di intelligenze artificiali di giochi.

L’algoritmo è tutto qui, poco meno di 20 righe, eppure preso così è inutile. Prima bisogna rispondere a domande del tipo “Come costruisco l’albero?” o “Come posso valutare in modo preciso un nodo?” e “Come minimizzare il numero di nodi esplorati?”. Risposte che richiedono centinaia e centinaia di righe di codice e dalla cui risposta dipendono drammaticamente le prestazioni di ricerca.

Ad esempio sia Deep Blue che Junior utilizzano come base l’alpha-beta pruning per la ricerca e l’analisi di una posizione scacchistica, eppure Deep Blue, che altro non è che un gigantesco mainframe divora mosse, viene tranquillamente stracciato da Junior (che tra l’altro gira su un normalissimo PC) grazie ad una serie di ottimizzazioni che rendono il suo gioco molto più intelligente.

A questo punto la domanda sorge spontanea: quanto è simile tutto questo all’intelligenza umana? Onestamente credo che la risposta non abbia molta importanza. Per dirla come Drew McDermott

Dire che Deep Blue non pensa davvero quando gioca a scacchi equivale dire che un aereo non vola davvero perchè non sbatte le ali.

Ok. Una presentazione di de Icaza sui vantaggi di Mono suona molto come chiedere all’oste se il vino è buono. Tuttavia l’argomento è interessante e lancia subito una domanda: “Mono e C# sono veramente linguaggi utili e con un futuro nello sviluppo di videogame?”

C#

Innanzitutto va precisata una cosa: C# è un ottimo linguaggio. Che che ne dicano i detrattori di qualunque cosa sia Microsoft, C# è uno dei migliori linguaggi staticamente tipizzati in circolazione ed il tentativo di Mono di portare su altre piattaforme quella che sarebbe stata una tecnologia limitata a Windows è da ringraziare.

Il C# è un linguaggio che a prima vista ricorda molto il Java ma si differenzia da esso per essere molto più snello, avere una sintassi più pulita ed intuitiva e, al contempo, la possibilità di spingersi più a basso livello. Per esempio in C# possiamo implementare l’incapsulamento degli attributi di una classe in questo modo:

Questo creerà un’attributo pubblico “fittizio” chiamato Nome accessibile normalmente ma vincolato dalle funzioni “get” e “set” in esso contenute (in questo caso, non essendoci “set”, Nome è un’attributo in sola lettura).

Allo stesso tempo però C# mantiene un gran numero di elementi di basso livello (come le “struct”) che permettono un’integrazione diretta, quasi nativa, con il codice C e C++. Insomma, per i miei canoni è un ottimo strumento di lavoro.

Detto questo rimane la domanda iniziale: C# ha ed avrà un ruolo chiave nel settore ludico?

XNA e Unity3D

Per quanto mi riguarda la risposta è positiva e i motivi sono principalmente due:

• C# è un linguaggio che offre un ottimo compromesso fra l’immediatezza poco performante di un linguaggio di scripting e la complessità efficiente di un linguaggio di basso livello. Questo gli permette di soppiantare (totalmente?) l’uso dello scripting nei giochi (come per l’AI) migliorando le prestazioni.
• XNA e Unity3D (non c’entra Ubuntu stavolta). Due game engine che utilizzano C# come linguaggio predefinito che hanno riscosso enorme successo.

Mentre il primo è un motivo, se mi permettete il termine, oggettivo, il secondo sembra una marchetta. In realtà XNA ha avuto e probabilmente avrà un ruolo chiave nello sviluppo videoludico, specialmente per il settore indie.

XNA, per chi non lo conoscesse, è un ottimo game engine e ha permesso in questi anni la realizzazione di numerosi giochi indipendenti di successo (per esempio Magicka di Arrowhead Game Studio o Bastion). Uno dei grandi punti a favore di XNA è la possibilità di operare sia ad alto livello (entità, scene, collisioni e input), sia a basso livello (ad esempio con la possibilità di scrivere uno shader o di personalizzare la rappresentazione di un vertice variando il numero di bit da allocare e il modo di utilizzarli nella memoria video).

Lo svantaggio principale di XNA è il solito di ogni tecnologia Microsoft: gira solo su prodotti Microsoft (Windows, XBox e Windows Phone). Il corrispettivo di XNA per Mono, chiamato MonoGame, che dovrebbe colmare questa lacuna, è ancora incompleto (attualmente è implementata solo la parte 2D di XNA), speriamo ancora per poco.

Un’altro famoso game engine utilizzato massivamente dalla comunità indie (e anche da alcune realtà commerciali) è Unity3D. Questo è un motore gratuito (tuttavia con una licenza gratuita più restrittiva di XNA) dotato di un editor grafico e integrato con MonoDevelop. Il punto di forza di Unity è il numero di piattaforme su cui gira: è possibile infatti rilasciare giochi scritti in Unity su PC, Mac, Android, iPhone, PS3, XBox, Wii e un’altro paio di piattaforme. Sfortunatamente fra queste, al momento, non c’è Linux.

Le Alternative Open

Ovviamente non di solo codice proprietario è fatto il mondo e ciò vale anche per i game engine Mono-based. Nel mondo open source ci sono fondamentalmente due motori C# per giochi:

• Axiom 3D: giunto alla versione 0.8 rappresenta un wrapping di OGRE in C#.
• Delta Engine: giunto alla versione 0.9.4, Delta Engine è un motore di gioco scritto interamente in C#.

Personalmente non ho provato nessuno dei due ma ne ho sentito parlare in modo positivo.

Il Futuro

In definitiva, se avete sogni di game development è bene quindi fare un pensierino ad imparare il C# poiché, come abbiamo visto, oltre ad essere divertente (almeno per me lo è) è utilizzato da due dei più promettenti motori di sviluppo attualmente disponibili.

C# e Mono hanno dimostrato ampiamente di avere tutte le carte in regola per essere nel prossimo futuro uno strumento importante nello sviluppo di videogame e le future versioni del linguaggio promettono vantaggi ancora più importanti.

La terza reincarnazione di SlashCode porta con se un paio di novità. Per prima cosa SlashCode ha subito un grosso restyling grafico: nuovo template, nuovi colori e nuovo logo. Ho puntato ad eliminare tutti i dettagli inutili per cercare di mantenere l’attenzione sugli articoli piuttosto che sul contorno. Spero che sia una modifica gradita!

Secondo, come forse sapete è da febbraio che collaboro con OneOpensource ed Edit. Questo significa che su SlashCode eviterò (quasi del tutto) di parlare di argomenti sovrapponibili e cercherò quindi di concentrarmi sulla programmazione e l’AI.

Alla luce dei miei interessi attuali credo che gli argomenti principali saranno l’AI, il Game Development e qualcosa riguardante framework web quali Django. Questo sommario comunque non è un giuramento quindi mi riservo il diritto di cambiare idea.

Questo è tutto. Ci vediamo presto con qualche nuovo post.

Il primo problema che risolveremo è il seguente

A chi non è capitato almeno una volta nella vita?

PREMESSA:

Ogni applicazione sul vostro sistema usa delle librerie. Una libreria non è altro che un insieme di codice già pronto e compilato che esegue delle funzioni specifiche. Questo permette ad ogni sviluppatore di non reinventare la ruota ogni volta ma di utilizzare il codice già scritto da altri.

Una libreria può essere statica (.a) o dinamica (.so o .dll su Windows). Nel primo caso la libreria viene inglobata nell’eseguibile in fase di compilazione, nel secondo invece la libreria è un file separato che viene agganciato all’eseguibile durante il caricamento del programma da un componente del sistema operativo chiamato linker dinamico.

Ovviamente le librerie dinamiche ottimizzano meglio le risorse evitando che del codice uguale venga replicato inutilmente in ogni eseguibile.

CAUSA:

Il messaggio di errore non lascia alcun dubbio: la libreria dinamica non è presente nel sistema o il linker dinamico non riesce a trovarla.

SOLUZIONE:

Se la causa è semplice la soluzione è altrettanto semplice.

Per prima cosa accertiamoci che la libreria sia installata e presente nel nostro sistema. Possiamo verificarlo agilmente con

locate libXXX.so

Che restituirà il percorso della libreria.

Se la libreria è stata installata durante la sessione corrente allora dobbiamo forzare l’aggiornamento del database con

sudo updatedb

A questo punto probabilmente la libreria si troverà in un percorso non standard. Non ci resta che aggiungere questo percorso nella lista dei percorsi scandagliati dal linker.

Per fare questo apriamo il file /etc/ld.so.conf (o creiamo un file nella cartella /etc/ld.so.conf.d/) e inseriamoci dentro il percorso della libreria, ad esempio:

/usr/local/lib.

A questo punto chiamiamo

sudo ldconfig

per aggiornare la cache del linker.

E il gioco è fatto.

In questa nuova rivoluzione Web chiamata per brevità HTML5, uno dei protagonisti è senza alcun dubbio il riesumato JavaScript. Tornato dalla tomba in cui sembrava essere stato sepolto per riportare nuova luce e dinamicità ai contenuti Web.

JavaScript, in quanto computazione client-side ha anche lo spiacevole effetto di condizionare le prestazioni di un sito e di scaricare il gravoso costo della sua esecuzione sui browser. Questa è la casus belli della JavaScript War che imperversa nei centri di sviluppo dei vari browser da qualche anno.

Iniziamo quindi ad analizzare la battaglia dei contendenti più accreditati: Firefox e Chrome.

Firefox

• Versione: 5.0
• Rendering: Geko 5.0
• Motore JavaScipt: SpiderMonkey

Chrome

• Versione: 13
• Rendering: WebKit 535.1
• Motore JavaScipt: V8 3.3.10.22

BENCHMARK 1 : SUNSPIDER 0.9.1

Il primo benchmark è SUNSPIDER di casa WebKit. Il test mi ha sorpreso perché Firefox risulta più performante di Chrome. Come potete vedere dal risultato (FROM è Firefox e TO è Chrome) la differenza è minima ma a favore di Firefox.

Risultato:

BENCHMARK 2 : V8 BENCHMARK

Questo è un benchmark piuttosto minimale fatto da Google appositamente per V8 e usato per il tuning dello stesso. C’è poco da sorprendersi che il risultato sia a vantaggio di V8 per un buon 168% in più.

Risultati Firefox:

Risultati Chrome:

BENCHMARK 3 : Kraken 1.1

Per par condicio ho lanciato anche Kraken, benchmark minimale di casa Mozilla. Tuttavia anche Kraken va contro la sua stessa creatura. La differenza è meno marcata (106%) ma comunque sostanziosa. In pratica Firefox ci mette il doppio del tempo del concorrente a terminare il benchmark.

BENCHMARK 4 : Dromaeo

Per finire ecco il risultato del benchmark javascript più completo che conosco: Dromaeo. Sempre di casa Mozilla ma è chiaro, verificabile e il codice del benchmark è disponibile a chiunque voglia controllarlo.

Risultati Firefox = 132.72runs/s

Risultati Chrome = 238.36runs/s

Potete controllare i dettagli cliccando sui link.

Chrome è più performante del 79.6% rispetto a Firefox.

CONCLUSIONE

Questa sfida è terminata 3-1 per il browser di Google e quel punto di Firefox è strappato per un soffio. Insomma, Chrome si classifica, come da pronostico, estremamente più veloce di Firefox nell’esecuzione del JavaScript. Tenendo però conto della velocità con cui questi Browser si riproducono non ci resta che aspettare qualche mese per vedere come evolverà questa appassionante sfida.

Durante lo sviluppo di Cobra Draugths ho avuto la necessità di trovare un profiler per Python che facesse al caso mio. Dato che non c’è un unico strumento adatto ho deciso di spiegare passo passo come ottenere dei dati di profiling veloci, puliti e graficamente guardabili.

È una guida espressa: niente discussioni, niente commenti, solo fatti e procedure.

1. cProfile

Primo passo. Installare i tool di profiling per python.

Supponiamo che il vostro programma/libreria abbia un file che invoca i metodi che volete profilare. Possiamo lanciare il comando

Questo avvierà il file test.py e, una volta terminato, creerà un file output.prof contenente tutte le informazioni di profiling.

2. Esplorare il file

Il modo più semplice per esplorare il file creato è usare il modulo pstats.

Ci troveremo davanti una shell. Primo comando da dare è

Che carica il file. Dopo di che possiamo ordinarlo per ordine di tempo (prima le funzioni più costose)

E poi leggere i primi 10 elementi

3. Grafo dei tempi

Il modo più elegante, chiaro e stiloso per ottenere un report leggibile è trasformare tutto in un bel grafo colorato. Per fare questo usiamo il tool Gprof2dot.

Scaricate lo script Python e installatelo con un

A questo punto createvi uno script bash con questo contenuto:

Chiamatelo, ad esempio, gprof2png. Installatelo alla stessa maniera.

A questo punto potete lanciarlo semplicemente con

Questo creerà una gradevole immagine png con tutti i dati di vostro interesse. Come esempio posto l’immagine generata per Cobra Draughts in una partita AI vs. AI.

Buon profiling.