Lavorando con WiiU
Ora che il gioco era fatto e girava sulla console potevamo iniziare a sviluppare le feature che avrebbero usato il nuovo controller e messo il nostro gioco in condizione di spiccare sulla piattaforma. Ma poco dopo aver iniziato siamo incappati in una serie di problemi che la (minima) documentazione non copriva, quindi abbiamo chiesto al nostro team di supporto locale di Nintendo. Loro non sapevano la risposta così hanno detto che avrebbero dovuto controllare con gli sviluppatori in Giappone e così abbiamo aspettato una risposta. E abbiamo aspettato. E abbiamo aspettato.
Dopo circa una settimana passata a rincorrerli abbiamo sentito il team di supporto che aveva avuto una risposta dal Giappone, che ci hanno inoltrato. La risposta era sottoforma di poche frasi scritte in un Inglese sgrammaticato che non rispondeva realmente alla domanda che avevamo chiesto all’inizio. Quindi siamo andati a chiedergli nuovamente chiarificazioni, che ha comportato un’altra settimana più o meno. Dopo il secondo ritardo abbiamo chiesto perché ci mettessero così tanto per risponderci dal Giappone, erano veramente così impegnati? Il team di supporto locale disse di no, è solo che ogni domanda ha bisogno di essere mandata tradotta in Giapponese, poi inviata agli sviluppatori, che rispondono e le risposte tradotte in Inglese e inviate a noi. Con fusi orari differenti e il ritardo nel tradurre, tutto questo durò una settimana!
Far girare il gioco al frame-rate voluto è una parte del processo di sviluppo che è meno interessante in questo contesto poiché segue il pattern standard. Far girare il gioco, ottimizzare il codice (CPU e GPU) e se ancora non va, tagliare le feature finché va bene.
Finché l’ottimizzazione della CPU è andata bene, sì abbiamo dovuto tagliare qualche feature perché la CPU non era potente abbastanza. Come temevamo inizialmente, provare a supportare un gioco in HD dettagliato mette a dura prova la CPU e non potevamo fare come avremmo voluto. Tagliare delle feature era una cosa facile da fare, ma ha influenzato il gioco in tutti i suoi aspetti. Il codice ottimizzato per i processori PowerPC trovati in Xbox360 e Playstation 3 non calzavano molto bene per la CPU del WiiU, quindi mentre il chip ha alcune feature interessanti che spingono la CPU al di sopra del suo peso, ma non abbiamo potuto trarne pienamente vantaggio. Comunque, del codice poteva beneficiare di miglioramente sostanziali che mitigavano il clock basso – qualsiasi cosa fino a 4x per aumentare la dovuta rimozione dei Load-Hit-Stores, e maggiori IPC (istruzioni per ciclo) attraverso l’inclusione di esecuzioni out-of-order.
Sul lato GPU, la stroia era al contrario. La GPU provò di essere molto capace e alla fine abbiamo aggiunto feature di pulizia in più che la GPU aveva la capacità di fare. Ci son state anche delle discussioni sull’utilizzo della GPU attraverso shaders compilati (GPGPU) per sgravare del lavoro dalla CPU – esattamente l’approccio che mi aspetto di vedere sulle console next-gen – ma con molto poco tempo di sviluppo e nessun esempio o guida da Nintendo, non ce la siamo sentita di poter rischiare di provare questo lavoro. Se avessimo avuto un team di sviluppo più grande o dei tempi maggiori, magari ci avremmo provato, ma col senno di poi saremmo stati limitati poiché avremmo riempito la GPU. La GPU è migliore di quella di PS3 o Xbox360, ma ad anni luce di distanza dall’hardware grafico dentro PS4 o XboxOne.
Ho anche visto alcune perplessità riguardo l’uso di RAM DDR3 su WiiU, con un bandwith in deficit rispetto a PS3 e Xbox 360. Questo non era realmente un problema per noi. La GPU poteva attingere ai dati rapidamente con minimi ritardi (attraverso l’EDRAM) e potevamo efficientemente pre-fetch, permettendo alla GPU di girare a velocità massima.