L’arte del Porting – Sotto la Scocca

scocca-arte-del-porting

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.

nvididabatman_610

Quando si fa un port in via di sviluppo a volte si lascia fare alla forza bruta se non si ha tempo per sistemare. Se non si avevano 16GB di RAM, Arkham Knight su PC aveva seri problemi.

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.

PortGC-PS2

Stesso gameplay, ma graficamente la differenza era notevole al tempo.

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.

  • Zenox (Luigi)

    Grazie dell’articolo cap, adoro sempre questi retroscena

  • Thrash Devil

    Grazie per aver ascoltato la mia richiesta! Come sempre tutto spiegato in maniera tale da poter essere compreso da chiunque ed ora anch’io mi son fatto un’idea migliore sull’argomento trattato! Continua cosí 😉

  • Sumiwake

    È sempre bello documentarsi, continua così Cap

  • shady8044

    Sempre interessanti questi articoli Cap. Sul porting di Zelda Botw che mi dici? Si poteva fare meglio su Switch e secondo te c’è ancora spazio per migliorare le performance anche dopo la patch?

    • Enry

      Prima o poi ti dirà la sua Cap, ma penso di poter dire qualcosa anche io (di giusto spero).
      Considera che Zelda Botw è un port su switch, come tale significa che è stato progettato per WII U e in seguito se n’è fatto il porting (anche molto velocemente). Se fosse stato sviluppato ad hoc per switch, avrebbe avuto di certo performance migliori, perchè non si sarebbe trattato di adattare il gioco alla nuova console, bensì di crearlo apposta per esso. Oltretutto nota che imho a livello di performance possono migliorare ancora con eventuali patch…tutto dipende da quanti soldi investiranno ancora in questo gioco.

    • Quello che dice Enry è giusto.
      Zelda ha il problema di essere nato prima di tutto su Wii U e poi portato su Switch. Si tratta di console con punti di forza quasi opposti (Qui https://www.nintendon.it/risoluzione-dinamica-tile-rendering-124200 nell’ultima parte chiarisco un po’ questa differenza), quindi riuscire a fare un gioco in grado di valorizzare allo stesso tempo l’architettura Wii U e quella Switch era semplicemente impossibile.

      Nintendo ha scelto poi di dare parità visiva tra le due versioni, col risultato che Wii U è tirato tantissimo, troppo a mio avviso, con tante zona dove il gioco va a 20fps costanti. Su Switch invece ci si è ritrovati con del codice un po’ raffazzonato. Si è visto nella patch 1.11 di Zelda che un miglioramento è possibile. A naso direi che si potrebbe fare ancora di più, ma ad un certo punto ci si sbatterà contro dei muri invalicabili proprio perché il gioco è comunque nato su Wii U. Se ci buttano sopra soldi, tutto è possibile.

      Siccome devono comunque produrci dei DLC, sono interessati a migliorare anche il gioco sottostante andando avanti, quindi è probabile che arriveranno altri miglioramenti.

      • shady8044

        Giusto quello che pensavo io. Tanto per rispondere ai soliti che: ” Switch è scarsa e non ce la fa”.

      • Japo

        Un vero peccato con le nuove Api di switch avrebbero sicuramente aumentato la parte tecnica e l’illuminazione

  • Enry

    Ottimo articolo 🙂

logo-bianco

NINTENDON EVENTI

Per la tua pubblicità su NINTENDON.IT

Regolamento Forum - Contatti - Nicer Design

Privacy Policy

Informativa estesa sui Cookie

©2017 NintendOn Tutti i diritti riservati. Tutti i marchi appartengono ai rispettivi proprietari.

Log in with your credentials

or    

Forgot your details?

Create Account