Ascoltando le richieste del pubblico, l’argomento di questo nuovo Sotto la Scocca è: il Porting, ovvero il processo di prendere un gioco nato per una piattaforma e farlo funzionare su un’altra.Le informazioni in giro non sono tantissime. In generale gli sviluppatori non si addentrano in cose tecniche nelle loro interviste e ogni singolo port è una bestia a sé. Io personalmente distinguo due diversi processi. Il primo è quando si pensa alle piattaforme sulle quali rilasciare il proprio prodotto in anticipo, in fase di progetto, il secondo invece è quando il port è pensato solo in un secondo momento. Questi due processi hanno un punto di incontro nella fase di pianificazione del progetto. Ogni piattaforma ha la sua architettura e le sue interfacce di programmazione (API). Quindi quando scelgo le piattaforme target, sto scegliendo anche quali strumenti andare ad usare. In generale i programmatori scrivono il codice di un progetto multipiattaforma senza sapere la piattaforma di riferimento. Questo perché si scrive usando linguaggi di programmazione di alto livello come il C++ o Lua.
Una volta scritto il codice, sarà compito di uno strumento chiamato compilatore tradurre i comandi scritti dagli uomini in comandi capibili dall’architettura della macchina. Questi compilatori sono costruiti da chi fa il motore grafico o dalle case stesse di produzione in base alle proprie esigenze. Richiedono competenze specifiche che non tutti hanno. Per questo quando un motore grafico non supporta una piattaforma, difficilmente si vedono prodotti che usano tale motore, perché si devono creare da zero strumenti che su altre piattaforme ci sono già.
Quando si programma un gioco si cerca di costruire il codice nel modo più astratto e generico possibile, così da andare successivamente a riempire i dettagli. Non è inusuale che le versioni PS4, One e PC condividano il 90% del codice del gioco. Ovviamente ogni piattaforma richiede degli accorgimenti specifici, non sempre elementari. Questi sono dominio di pochi specialisti che conoscono alla perfezione come funziona l’architettura della macchina bersaglio. Spesso, invece di perdere tempo a fare i cambiamenti a mano, lavorano a strumenti che possono farlo automaticamente. Telltale ad esempio aveva dei programmi fatti in house che convertivano texture e codice dalle versioni PC dei loro giochi in versioni Wii, risparmiando molto tempo e riducendo gli interventi a mano. Questi processi automatizzati sono imperfetti e sono in generale la causa dell’ottimizzazione variabile tra piattaforme. Ma servono perché il tempo per lavorare ad un progetto è limitato. O lo è il budget, ma come si suol dire, il tempo è denaro.
Quando si progetta in questo modo bisogna sempre tenere conto della piattaforma più scarsa come base. Un possibile processo decisionale può essere il seguente: ci si appunta quali feature si vogliono nel gioco e si formulano ipotesi su quanta percentuale di processore, GPU e memoria queste utilizzano. Si dividono queste feature in diverse categorie di priorità. Una volta raggiunto il minimo e testato il funzionamento sulla piattaforma minore, si passa ad aggiungere. Questo approccio è stato usato da Visceral con Dead Space per esempio. Ed è un processo che si attua nella fase iniziale. Tra l’altro non è neanche così scontato, in quanto una piattaforma può essere più scarsa in un aspetto ma non in un altro. Bisogna quindi idealmente costruire per un’ipotetica piattaforma che è la somma delle le caratteristiche peggiori delle console reali. A volte però i port non vengono fatti dalla casa madre, ma da sussidiarie, che si ritrovano a dover lavorare con un codice che cambia di continuo e a riadattarlo costantemente alla piattaforma alla quale lavorano, spesso senza che la casa madre si renda conto delle necessità del port. Questo accade in genere quando ci sono i giochi transgenerazionali, dove il team principale lavora alla versione next gen ed un altro team fatica a comprimere e rimuovere pezzi per farlo stare sulla generazione precedente. Con risultati altalenanti.
In fondo però, in questi casi basta organizzare bene il flusso di lavoro e si possono ottenere buoni risultati. Il problema c’è quando il port non era minimamente pensato. La problematica non è limitata al mondo dei videogiochi, è proprio un problema di impostazione di lavoro. Quando devo lavorare per me stesso, per il mio team, per un’unica piattaforma, posso usare strumenti che conosco solo io, magari prendendomi la libertà di progettare in un ordine sconclusionato o a scrivere codice in linguaggi strani, o ancora ad avere un’organizzazione ottusa delle varie versioni del progetto. E questi fattori si sommano al fatto che un gioco per una singola piattaforma farà uso di ottimizzazioni di livello più basso, di meno automatismi. Roba che non funziona su altre piattaforme, che deve essere riscritta da capo.
Un retroscena carino è quello della Ico & Shadow of the Colossus Collection. I file originali richiedevano per essere aperti una specifica build di Linux in Giapponese. Oltre ad affrontare questo problema, gli statunitensi incaricati del porting hanno dovuto affrontare una pipeline di lavoro praticamente aliena. Un altro aneddoto simpatico riguarda Silent Hill HD, un remaster pessimo perché i dati originali archiviati erano di una beta del gioco e non della versione commercializzata. Con gli indie a volte è anche peggio, perché lavorando da soli o in gruppi ristretti, la possibilità di fare le cose di testa propria è ancora più alta. FEZ è un gioco scritto in origine in C#. Ma su Playstation non c’è il minimo supporto a questo linguaggio. È stato quindi convertito in C++, praticamente smontandolo e rimontandolo. Questa cosa a quanto pare accade sufficientemente spesso da spingere Bitworks a creare un sistema automatizzato chiamato “unsharper”, che è stato usato anche per i port di Bastion e di Axiom Verge.
Uno dei punti più famosi delle discussioni sul processo di porting è la differenza di potenza. In realtà la potenza non dice tutto. Bisogna capire come funziona tutta l’architettura ed individuare i colli di bottiglia. Wii U ha un processore a 1,2Ghz. Xbox 360 uno a 3Ghz. Ergo Wii U è meno potente. E poi si scopre che riscrivere il codice in un certo modo ne triplica la velocità di esecuzione su macchina Nintendo. Ma nel riscrivere il codice in quel modo, si potrebbe rompere qualcos’altro. Ed il tempo per lavorarci è sempre limitato. È vero che la potenza bruta conta spesso nei port. Resident Evil 4 su PS2 era nettamente inferiore alla versione per Gamecube. Modelli poligonali dimezzati, texture ridotte da 24bit a 8 o 4 bit e meno punti luce. Poco poteva la maggiore banda di memoria della PS2 in un’era dove erano i poligoni a farla da padrone. Le problematiche però ci sono anche quando si va verso l’alto. Perché non è la potenza che determina la difficoltà, ma la diversità comportamentale. The Last of us HD su PS4, ad esempio, girava a 10fps appena portato da PS3. Naughty Dog ha dovuto praticamente cambiare come funziona il loro motore grafico quando sono passati su PS4. Un processo così arduo che c’è una presentazione della GDC 2015 di un’oretta sull’argomento.
Le problematiche che nascono sono imprevedibili e di ogni tipo. E quando si ha un tempo ridotto per lavorare ad un progetto i risultati possono essere molto scarsi. Un port nasce se c’è convenienza economica. E questa decisione non è indipendente da quella tecnica. Più è difficile un port, più richiede uomini e tempo e più costa. Il problema può essere anche di tipo “artistico”. Se il differenziale di performance tra le piattaforme è troppo alto, può capitare che il gioco stesso perda di senso, arrivando in una forma troppo snaturata graficamente o meccanicamente. Nonostante i mille problemi che possano insorgere abbiamo assistito a porting improbabili. Call of Duty 4 esiste su Wii. Così come Shadow of Mordor su 360 e PS3, dove appare con il sistema nemesi estremamente ridotto ed il gioco risulta molto meno divertente. Che dire di Hyrule Warriors Legends sul primo modello di 3DS poi? La lezione è: se l’odore dei soldi è abbastanza stuzzicante, anche i miracoli sono possibili.
