Le prime differenze architetturali fra un PC ed una console saltano subito all’occhio analizzando i progetti dei due sistemi ad alto livello.
Una console è progettata per costare poco e per essere riprodotta nello stesso modo in grandi volumi (decine di milioni di unità): anche un piccolo cambiamento delle specifiche si traduce facilmente, nel ciclo di vita del prodotto, in centinaia di milioni di dollari. Aggiungere 512MB di ram, ad esempio, piuttosto che una porta USB in più come un hard disk, potrebbe sembrare un cambiamento di poco conto dall’esterno, ma nell’ottima della produzione di scala, pochi dollari possono segnare la viabilità economica o meno dell’intero progetto. Queste scelte “al risparmio” si scaricano immediatamente sullo sviluppo: minore potenza computazionale, minore memoria, architetture meno flessibili, ma maggiore “efficienza” complessiva di un sistema che è più facile da prevedere.
Su console il sistema operativo è minimale, perché ha meno compiti da svolgere. Il produttore dichiara esattamente quanta memoria riserva per la sua esecuzione e quanto tempo macchina è dedicato: su 360, ad esempio, lo sviluppatore sa che parte delle risorse del terzo core della CPU è riservato al sistema operativo e non può essere usato dall’applicazione, che ha tutto il resto della macchina a sua esclusiva disposizione. E’ un nodo importante che caratterizza tutte le metodologie di sviluppo e ottimizzazioni sulle architetture dedicate: la macchina è in uso esclusivo, si conoscono esattamente le risorse a disposizione, si ottimizza per il caso peggiore e non per il caso medio. Per entrare nello specifico, una volta fissato il framerate di riferimento e il budget di memoria, è necessario solo ottimizzare quelle scene che oltrepassano questi limiti nei casi peggiori, perché migliorare una scena che già soddisfa i limiti non porta alcun beneficio. Questo procedimento è in netto contrasto con ciò che avviene su PC dove i limiti non possono essere definiti in maniera univoca. Migliore prevedibilità, sistema costante, costi contenuti sono le chiavi dello sviluppo su console.
La scrittura del codice di un titolo su console avviene su un sistema host (praticamente sempre un PC con una qualche versione di Windows), dove è installato il kit di sviluppo e le librerie proprietarie della console per la quale si sta sviluppando. Il codice e gli asset sono compilati sul sistema host, sfruttandone la potenza di elaborazione e la flessibilità, e, infine, trasferiti in un qualche modo al devkit (una console opportunamente modificata) per l’esecuzione e il debugging. Gli strumenti di sviluppo comprendono Visual Studio oppure Codewarrior come ambiente, affiancati da compilatori e tool di profiling e debugging specifici per la piattaforma da supportare.
E per il PC che cosa cambia? La settimana prossima ne sapremo di più.
A fronte di quest’analisi, al di là del fatto che Microsoft non volesse esporsi nella scelta di un formato ottico, si può dire che riprogettare la console con un un lettore ad alta definizione al posto del tradizionale DVD sarebbe stato oneroso proprio in termini di costi?
Magari adesso che sono riusciti ad avere un utile dalla vendita delle console (non ricordo in che misura), inserendo un’unità bluray rischierebbero di andare di nuovo in passivo…
E’ solo una ipotesi ovviamente.
PS: Grazie per questa serie di articoli. Se ne sentiva veramente il bisogno! :)
Articolo molto interessante! solo un piccolo appunto: “viabilità” è un calco dall’inglese veramente osceno… non era meglio un’italianissima “fattibilità”?
Jacopo. Esatto. Considera che le specifiche tecniche di una console sono “chiuse” come minimo un anno prima dell’arrivo sul mercato. Nel caso del 360, dato che un vincitore nel formato era molto lontano, aveva poco senso economico sceglierne uno dei due e scaricare i costi sul consumatore oppure sul produttore per decine di milioni di pezzi. Il DVD al tempo era la scelta piu’ logica. Magari meno rumoso sarebbe stata anche una scelta piu’ gradita.
Grazie Andrea, “viabilita’” e’ terrificante, lo modifico subito con “fattibilita’”.
Molto interessante! Ma il devkit è disponibile anche per la vendta al pubblico? Se volessi sviluppare per conto mio un piccolo viodeogioco amatoriale per XBox, come tetris o pacman per esempio, potrei aquistare il necessario?
francesco. No, e’ disponibile solo agli sviluppatori registrati. Ma puoi sviluppare un giochino usando XNA, che copriro’ nelle prossime settimane.
Disponibilità a parte, credo che un DevKit abbia dei costi proibitivi per un privato.
Suppongo decine (centinaia?) di migliaia di euro.
E’ solo una MIA supposizione, non ho assolutamente preso da nessuna fonte.
max, un devkit per uno sviluppatore costa piu’ di diecimila dollari. Il costo non e’ tanto l’hardware, ma tutto il supporto tecnologico attorno, ovvero ingegneri che sono spediti in caso di problemi, o per aiutare nelle ottimizzazioni, lo sviluppo degl sdk, gli aggiornamenti.
Grazie Francesco.
Per cui così a maggior ragione si spiega la scelta di MS di tenersi fuori dalla battaglia dei formati…fatto patti saldi che supportare il rivale includendo un lettore Blu-Ray avrebbe probabilmente avuto ancora meno senso…
Anch’io volevo segnalare che “viabilità” mi sembrava strano (pensi in inglese?), poi ho visto che è già stato segnalato nei commenti ma anche che non è ancora stato corretto, ecco perché l’ho scritto :-) Poco prima c’è anche “ottima della produzione di scala” ma immagino dovesse essere “ottica”.
Dici che di solito la macchina host è Windows, so che per la PS2 la piattaforma di riferimento invece era Linux perché si usava gcc, non è così anche per la PS3?