Follow

Volevo iniziare a parlarvi un po’ del Game Development, tuttavia mi sono reso conto che c’è molta confusione sull’argomento a livello tecnico. Domande del tipo “Voglio sviluppare videogiochi, meglio OpenGL o DirectX?” fanno accapponare la pelle e sono indice del livello di nebulosità che avvolge la materia. Per questo, per prima cosa faremo un bel punto della situazione sui vari elementi di un videogioco.

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! 🙂