Più che sotto la scocca, oggi andiamo sotto il cofano
Recenti discussioni online e pezzi di opinione hanno messo in mostra un punto di confusione. In senso generale, si tende a confondere motore grafico e grafica. Si considerarli quasi sinonimi. E non ci può essere cosa più sbagliata. Quindi colgo l’occasione per fare un po’ di chiarezza su l’elemento costitutivo più importante di un videogioco.
Cos’è un motore grafico? È un ambiente di sviluppo software pensato per dare vita a videogiochi. Il problema della confusione deriva secondo me dal termina che utilizziamo in italiano. “Grafico”. Va a sottolineare troppo l’aspetto visivo. Il termine inglese più comunemente usato è invece Game Engine, cioè motore di gioco. Questo perché un motore grafico è in realtà l’insieme di componenti multipli. La parte grafica è gestita dal cosiddetto renderer, perché si occupa della parte di disegno. A questa va aggiunta la fisica, la gestione degli script, l’individuazione delle collisioni, l’intelligenza artificiale, il sonoro, le animazioni, il sistema di network ed un sacco di altri aspetti tecnici. Praticamente ogni aspetto del gioco è gestito dal motore.
C’è chi lo crea e chi lo usa
Ogni motore grafico è composto da due strati. Quello di basso livello, messo in pedi da esperti programmatori, va a descrivere come funzionano tutte le funzionalità del motore. Il tutto viene impacchettato in una forma facile da usare per chi poi va a costruire il gioco. Chi invece lavora ad alto livello, può anche non curarsi di come funziona il motore nella sua intimità. Ma deve essere realizzato per essere il più semplice da usare per ogni tipo di persona, dal level designer all’artista, all’animatore. Potete provare voi stessi. L’Unreal Engine 4, Game Maker Studio 2, Unity ed il Cryengine possono essere scaricati gratis, in versioni di prova per alcuni, complete per altri. Confrontate quanto siano facili ed intuitivi.
Una volta, ogni gioco veniva realizzato da 0. Considerate che fino al NES, creare un gioco era tanto un lavoro di programmazione quanto di progettazione elettronica della cartuccia che doveva contenerlo. I vari sviluppatori pensavano alle caratteristiche necessarie per realizzare la loro visione e realizzavano codice adatto. L’avvento di giochi sempre più complessi, specialmente quelli 3D, iniziò a richiedere di avere delle basi dalle quali partire. Invece di fare un lavoro nuovo ogni volta, lavorare in modo incrementale poteva essere estremamente più efficiente. La popolarità di Doom e Quake, giochi sparatutto in prima persona degli anni ’90 (il sottoscritto ha iniziato la sua carriera su Doom), fu tale che altri sviluppatori iniziarono a chiedere in licenza i motori grafici usati per usarli come base di partenza.
Dove c’è esigenza, si crea un mercato
E da qui nacque un nuovo business. Invece di creare videogiochi, creare strumenti per realizzare videogiochi. Software cosiddetto “middleware”. Software che potesse anche essere modulare. Un esempio può essere il motore fisico. Havok è il nome di un motore fisico progettato dalla casa omonima, che può essere innestato ed usato in numerosi motori grafici. Se uno sviluppatore vuole implementare una determinata fisica nel suo gioco, può affidarsi a tutti gli strumenti creati da altri invece di dover fare il lavoro in casa. Col tempo le cose si sono fatte parecchio complesse. Pensate al gioco Star Wars: The Force Unleashed. Il motore è il proprietario Ronin, ma integra ben 3 software di terze parti. Havok per la fisica del corpo rigido, DDM per i materiali distruttibili in modo dinamico e Euphoria per animazioni procedurali da parte dell’IA.
E qui si sviluppa un po’ il discorso del farsi il motore in casa rispetto ad usarne uno di terze parti. Ogni generazione ha avuto i suoi mostri. La scorsa gen ha visto tantissima roba realizzata in Unreal Engine 3, spesso molto simile e con difetti comuni. Di contro, software house giapponesi con motori proprietari fecero molta fatica a produrre un qualcosa di veramente flessibile e moderno, incorrendo in ritardi mostruosi nelle produzioni di alcuni loro franchise, pensiamo a Final Fantasy XV con il suo Luminous Studio. Ora la situazione sembra quasi invertita, con molti studi giapponesi, inclusi Nintendo, che fanno uso di Unreal Engine, e gli studi occidentali grossi rimasti tutti con roba interna, come il Frostbyte di EA o i vari Anvil e Dunia di Ubisoft.
Chi fa da se fa per tre
Ci sono sempre i pro ed i contro. Fare un singolo strumento condiviso in tutta la propria grande azienda ha senso, specie se ho bravi programmatori. Se il mercato non offre nulla che fa al caso mio, realizzare uno strumento apposito è una buona strada da seguire. Se invece si fanno tanti prodotti diversi, che spaziano molto, puntare su strumenti più flessibili e generalisti può essere un vantaggio. Poi c’è sempre da considerare su quante piattaforme il gioco dovrà girare. Se voglio uscire ovunque, il mio motore di gioco dovrà poter sapere come interfacciarsi con ogni singola piattaforma. La verità, al solito, sta un po’ nel mezzo. Nintendo, volendo inserire in Zelda un sistema di interazioni complesso, ha combinato una logica di interazione chimica fatta in casa al motore fisico Havok di terze parti per esempio.
Arc System Works invece, ha deciso di sfruttare il motore Unreal per far fare un salto grafico al suoi giochi picchiaduro più moderni, come Guilty Gear Xrd e Dragonball Fithers Z, lasciando indietro il loro motore proprietario. A volte però si possono fare… errori tattici abbastanza grandi, dei quali ci si rende conto in corso d’opera. EA ha forzato l’uso del Frostbyte a Bioware. Il problema fu come il Frostbyte non avesse all’inizio tutti i tool necessari a supportare un gioco di ruolo. Pensate, non aveva neanche la logica per gestire un semplice inventario. Tantissimo tempo fu perso per aggiungere tutte le funzioni al motore e sia Dragon Age Inquisition che Mass Effect Andromeda soffrirono molto questo passaggio, soprattutto perché tutti gli strumenti usati per i loro lavori precedenti andavano rifatti da 0.
I bagagli di un motore
Prima ho detto come molti giochi sviluppati su Unreal Engine la scorsa generazione sembravano uguali. Cosa vuol dire avere lo stesso motore grafico? Vuol dire avere la stressa infrastruttura, le stesse fondamenta. Che spesso si traduce in bug o comportamenti anomali. L’Unreal Engine 3 aveva seri ritardi nel caricare le texture sugli oggetti di gioco e puntualmente la stragrande maggioranza dei giochi esibiva questo difetto. Per i bug veri, basta andare da Bethesda. Fallout 4 può essere visivamente diverso da Oblivion, ma, come ci mostrano i modder, poco è stato fatto per cambiare il codice sottostante, che presenta le stesse logiche. E gli stessi bug. O in Witcher 2 e 3, le ombre posso apparire come una nuvola di punti in certe situazioni, per via di come sono renderizzate.
Mi stai quindi dicendo che la grafica in giochi fatti con lo stesso motore grafico cambia? Certo. Superficialmente. Sotto, il renderer è generalmente quello. Ma noi vediamo il suo risultato, non il processo che genera l’immagine. Sono gli artisti che danno la direzione al gioco. Il motore è solo uno strumento. La tanta omogeneità della scorsa generazione era data da un’unificazione di stili ed intenti, più che dalla diffusione massiccia dell’Unreal Engine 3. E con questo spero di aver gettato giusto le basi su quello che è il pezzo più importante della realizzazione della produzione videoludica. Senza il quale, oggi, non si avrebbe nulla. L’argomento è molto vasto, ho toccato giusto i punti salienti, per dubbi, domande e curiosità, ci sono i commenti. Se volete vedere qualche aspetto approfondito, ditelo pure!
