Lo scorso martedì, sul sito CGWORLD.jP, è stata pubblicata un’intervista a Tetsuya Takahashi e Michihiko Inaba a riguardo del team di R&D (ricerca e sviluppo) di recente creazione all’interno di Monolithsoft, il cui scopo principale è lo sviluppo di nuove tecnologie per il futuro dei propri videogiochi.
Takahashi non ha certo bisogno di presentazioni (nella propria introduzione afferma che oltre ad essere un director e supervisionare lo sviluppo, da circa un anno si occupa anche di questo nuovo gruppo di R&D), mentre Inaba è stato un programmatore dedito al rendering engine degli Xenoblade sino al terzo, per poi diventare director e producer per l’R&D.
Il testo si concentra sulle motivazione storiche dello studio che hanno portato a questa decisione, per poi addentrarsi in dettagli sempre più tecnici, rivelandosi di fatto finalizzato principalmente all’assunzione di nuovo personale, da cui anche la scelta di un sito non generalista di notizie ma dedicato agli sviluppatori. Per queste ragioni, invece di una traduzione integrale che potrebbe risultare prolissa e non del tutto interessante, vi proponiamo di seguito gli estratti più significativi, seguendo l’originale ordine.
Takahashi: “Abbiamo lavorato sull’R&D anche prima di dare vita ad uno studio dedicato. Dato che Monolithsoft è solamente una software house, non ha le medesime risorse umane di un publisher. I publisher possono con facilità assumere nuovo staff come asset societario per l’R&D, ma nel nostro caso il focus principale è lo sviluppo di titoli, quindi non avevamo sufficienti risorse da dedicare ad investimenti futuri di nuove persone. Quando stavamo realizzando Xenoblade 2 (2017), avevamo soltanto poche dozzine di programmatori interni, ed eravamo completamente assorbiti col solo lavoro di sviluppo, per cui non sussisteva una situazione favorevole alla creazione di un team di R&D.
Quella situazione si è protratta per un po’, ma la scala dello sviluppo è divenuta maggiore quando abbiamo iniziato a realizzare con Nintendo titoli che potessero essere apprezzati da decine di milioni di persone nel mondo, ed il livello di competenze richieste per lo sviluppo è aumentato di conseguenza.
Poi è divenuto chiaro che era terminata l’era in cui fosse possibile gestire le cose con un ridotto numero di persone. Abbiamo capito che non potessimo per sempre basarci sulle strategie di gestione del personale, e realizzato di avere bisogno di creare un’organizzazione con un approccio tecnico, riducendo le ore di lavoro necessarie e aumentando l’efficienza. Ciò ha portato alla nascita del gruppo di R&D.”
Inaba: “In sostanza abbiamo radunato TA (technical artist) con un forte background tecnico, ad esempio persone che potesseri scrivere script, brave nel rigging, e che sapessero usare Houdini. Abbiamo anche reclutato programmatori con dimestichezza nella costruzione di ambienti di sviluppo e implementazione di sistemi di rendering.”
Inaba: “Il team R&D ha tre ruoli: migliorare la qualità generale dell’ambiente di sviluppo della compagnia; supportare la creazione dei tool per ogni sezione; ricercare e costruire nuove tecnologie. In passato i team di ogni titolo sviluppavano i propri tool, quindi avevamo dei duplicati in azienda, quali gli ambienti di Jenkins, tool DCC e i convertitori di dati. Il primo passo per migliorare l’efficienza di un ambiente di sviluppo è centralizzare e gestire tutto ciò nel team di R&D.
Il secondo ruolo è consolidare e accentrare i tool proprietari della software house, e svilupparli, e fornire supporto agli altri membri. Pur non essendo facile con l’attuale dimensione del team, crediamo che sia imporante realizzare i tool nel team.
Il terzo ruolo, ricerca e sviluppo di nuove tecnologie, include non solo quelle di ogni parte della compagnia, bensì anche l’effettiva implementazione di esse. In particolare, vorrei concentrarmi su quanto legato a rendering, scrittura e animazioni. Osserviamo ed impariamo anche pratiche eccellenti di sviluppo da altre aziende, documentandole e condividendole all’interno del team.”
Inaba: “Il motore in-house (proprietario) che stiamo al momento sviluppando è stato in origine realizzato per Xenoblade (2010), e viene tuttora espanso. Alla fine, vorremmo che il motore venisse completamente gestito dall’R&D, attualmente avviente congiuntamente col team di sviluppo.
In futuro, integreremo la tecnologia accumulata all’interno di un engine proprietario in modo da renderlo disponibile per altri giochi. Il team R&D è in attività da circa un anno, quindi pianifichiamo di portarne la struttura a pieno regime gradualmente nel corso di più o meno tre anni.”
Takahashi: “E’ vero che mantenere un engine in-house pone delle difficoltà, ma per i titoli di cui ci occupiamo, non ci sono al momento opzioni disponibili per i motore realizzati da terzi. La ragione risiede nel fatto che un motore proprietario è più facile da gestire e adattare ai nostri bisogni.
Inaba: “A riguardo del motore del rendering dei modelli, stiamo lavorando su cinque aspetti: un modulo per l’output dei modelli dal tool DCC, l’implementazione di materiali, illuminazione, effetti post processing e mappe seamless.
Per gli effetti, stiamo inserendo l’effect engine nel runtime e sviluppando tool per essi. Per esempio, qui c’è un’immagine di un motore per gli effetti che stiamo sviluppando internamente. Ho creato un sistema utilizzando l’editor a nodi, ma alcuni designer non sono bravissimi con i nodi e preferiscono creare gli effetti basati sulle proprietà, quindi abbiamo realizzato un sistema ibrido che permetta la creazione di effetti a partire da entrambi.”
Inaba: “Per esempio, in Houdini stiamo lavorando sulle simulazioni e tool di posizionamento procedurale. Durante lo sviluppo recente di un gioco, abbiamo creato un sistema che piazzasse proceduralmente gli elementi di sfondo usando Houdini. Questo ci ha permesso di maneggiare con efficienza un volume di sfondi impossibili da gestire a mano. Un compito che avrebbe richiesto circa 20 giorni può ora essere terminato in soli 30 minuti, il che è un gran risultato. Intendiamo continuare a migliorare quest’area.
Nell’immagine di esempio, tutti gli asset di sfondo, inclusa la strada, sono stati posizionati proceduralmente, così che le mappe col suolo e l’erba sfumino naturalmente avvicinandosi alla strada. Posso mostrarvi solo il wireframe, ma le transizioni sono molto realistiche. I designer hanno ora la possibilità di costruire sfondi complessi semplicemente impostando traiettorie curve.
Stiamo anche lavorando sull’utilizzo di modellazione procedurale per generare automaticamente oggetti distruttibili e impostare le variazioni basandosi sulle regole.”
Inaba: “Ci sono delle occasioni in cui il team R&D opera in risposta ai bisogni dello staff di sviluppo. Per esempio, il gruppo ha studiato una simulazione per rendere bellissimo l’aspetto dei capelli, e quella tecnologia è stata in effetti usata in un gioco. In futuro, vorremmo rafforzare la nostra struttura imbastendo un sistema in cui i ricercatori possano proporre i propri progetti.”
Takahashi: “La sfida più grande è ancora la mancanza di personale.”
Inaba: “Al momento, il team sta in qualche modo funzionando, ma per raggiungere una qualità ancora maggiore, abbiamo ancora bisogno di altro staff. Per il futuro, per prima cosa vorremmo ottenere nuove persone abili allo sviluppo di motori di rendering. Vorremmo espandere il numero dei membri per fronteggiare vari problemi, ad esempio le sfide nello sviluppo di titoli moderni.
Inaba: “Inoltre, vorremmo che entrassero a far parte di noi persone interessate ai motori proprietari. Se sei una persona con esperienza a cui piace esplorare le particolari tecnologie che non possono essere realizzate con engine generali, credo che questo team ti fornirà una pratica davvero notevole.
Questo potrebbe sembrare come una semplice opinione personale, ma credo che le grafiche renderizzate da un engine proprietario riflettano davvero le unicità di quel motore.
Quando gli utenti vedono un gioco sviluppato da Monolithsoft, a volte dicono: “Questo è lo stile grafico di Monolithsoft”, dunque saremmo felici se potessimo lavorare con qualcuno che condivida questo sentimento unico e dimostri la volontà di fare parte di noi. In pratica siamo alla ricerca di staff con esperienza, ma anche chi ha seguito all’università corsi di livello mondiale sull’espressione tecnica è il benvenuto.
Inoltre, al fine di raffinare l’espressione delle animazioni, oltre all’implementazione delle animazioni secondarie con rigging e simulazioni, vorremmo esplorare l’espressione nel runtime, quali IK (animazioni a cinematica inversa) e retargeting. Saremmo molto felici se qualcuno con esperienza come animatore e implementazione delle animazioni nei giochi, incluse le espressioni in runtime, potesse entrare nel nostro organico.”
Inaba: “In modo tale da rafforzare l’ambiente, stiamo operando su un gran numero di azioni, inclusi la conversione automatica dei dati, il potenziamento della build usando Jenkins, testing automatico, rilevamento automatico dei bug, e misurazione dei carichi. Siamo anche alla ricerca di personale appassionato a questi aspetti.
Ad esempio, in Xenoblade 3, abbiamo misurato il carica sulla CPU e GPU con le heatmap posizionando i personaggi su varie mappe, e conducendo dei test notturni in modalità di gioco automatico. Vorremmo espandere ulteriormente questi sistemi.”
Inaba: “Crediamo che inseguire la tecnologia sia interessante, ed il nostro team di R&D è composto da membri con la medesima mentalità. Costruendo un team con tale passione, speriamo di migliorare le abilità dell’intero gruppo e di conseguenza contribuire alla compagnia tutta, ed in ultima analisi all’industria dei videogiochi nel suo complesso.”
COMMENTO
La prima cosa che emerge dalle loro vive parole è, indubbiamente, la volontà di potenziare il proprio organico e competenze, per continuare a migliore la qualità dei futuri giochi. Miglioramento inteso non soltanto a livello del massimo prodotto ottenibile, ma ad ogni livello di sviluppo per rendere il tutto più efficiente, risparmiando tempo e risorse.
Ma subito dopo questa sensazione, si avverte in maniera sensibile le difficoltà con cui hanno finora realizzato i titoli, ovvero dei team sempre sottodimensionati rispetto alle ambizioni. E se ciò ha avuto dei risvolti certamente positivi che ha reso Monolithsoft uno degli studi portabandiera delle capacità Nintendo, come testimoniato dal coinvolgimento in The Legend of Zelda: Breath of the Wild e Tears of the Kingdom o anche dai pubblici “complimenti” di Sakurai in occasione dell’inserimento di Pyra e Mythra in Super Smash Bros. Ultimate, dall’altro ne ha forse impedito di spiccare il definitivo salto di qualità, in termini di ricezioni ma soprattutto di vendite.
Non possono non riecheggiare le affermazioni Takahashi di agosto in cui annunciava nuove assunzioni per il futuro RPG, in cui apertamente dichiarava che l’obiettivo principale fosse l’espansione del personale per fronteggiare le crescenti richieste del mondo dei videogiochi, in quanto il precedente approccio del (banalizzando) “pochi ma buoni” non fosse più sostenibile. L’esempio principle è rappresentato dal loro stesso citato Xenoblade 2, che nonostante i molti pregi è probabilmente il gioco meno rifinito della serie a livello tecnico, e rende notevolissimi i miglioramenti raggiunti poi col 3 un lustro più tardi. Dall’uscita di Xenoblade 2 ad oggi lo studio ha più che raddoppiato le proprie dimensioni, e dunque la moltiplicazione delle attività da svolgere non può che essere un ottimo segnale.
Pur non venendo di fatto mai menzionata, i ripetuti discorsi intorno ad un engine proprietario per i futuri giochi e la ricerca di persone che capiscano lo stile di Monolithsoft, non possono non far pensare alla prossima console Nintendo, Switch 2 (o qualunque sarà il suo nome) e tutto ciò che essa comporterà. La nuova potenza e possibilità da essa offerte verranno a fondo sfruttate da una software house che nel frattempo ha espanso in maniera distinta i le proprie tecnologie applicabili e non versa più in ristrettezze di personale, peraltro mal ottimizzato.
Che ne dite, stiamo per assistere ad un salto generazionale che ricorderemo a lungo?
