PC e Console sono due bestie estremamente differenti sia a livello di architettura sia per le problematiche che pongono di fronte allo sviluppatore, che vanno affrontate con strumenti e approcci differenti.
Da una parte una macchina molto flessibile, le cui performance sono generalmente ottime prendendo come riferimento configurazioni anche medie, ma che non è stata pensata esclusivamente per l’esecuzione di software videoludico, con tutte le conseguenze del caso.
Dall’altra parte di questa metaforica barricata ci sono le console, architetture chiuse, relativamente fisse nell’arco del loro ciclo di vita, dimensionate e ottimizzate per un solo scopo: i videogiochi e la multimedialità.
Qual è più semplice da affrontare?
Nessuna delle due: sono architetture differenti che pongono problemi diversi.
La flessibilità e la potenza di un PC permettono potenzialmente l’implementazione di tecniche di rendering più raffinate e precise, che possono coadiuvare un’esperienza di gameplay più profonda e complessa.
Il termine “potenzialmente” e’ la chiave del discorso: alla flessibilità è sempre associato un costo più o meno alto. Nel caso dello sviluppo su PC il costo della flessibilità si traduce nel dover supportare letteralmente milioni di configurazioni diverse (CPU, GPU, memoria, hard disk), magari non al passo con i tempi, che pongono limiti allo scopo dell’esperienza ludica che si cerca di costruire.
Un esempio relativamente banale è l’implementazione di un sistema di streaming in un mondo vasto: su PC non è garantito in nessun modo né il tempo di accesso all’hard disk, né la banda di trasferimento a disposizione.
E’ necessario quindi capire quanto dettagliato deve essere il mondo, di modo che possa essere di volta in volta trasferito dalla memoria di massa alla memoria centrale senza interrompere il flusso del gioco, oppure costruire un sistema scalabile che diminuisca la quantità di dati necessaria alla visualizzazione per andare in contro a sistemi con hard disk meno performanti: un’ulteriore complessità da gestire.
Su PC aumenta inoltre il tempo speso nella fase di testing (milioni di possibili configurazioni hardware e software) e nella fase di ottimizzazione. Su PC si spende molto più tempo ad ottimizzare semplicemente perché è molto più complesso per via del numero di variabili in gioco, al contrario delle credenze popolari.
Una console è, al contrario, un sistema fisso e chiuso: CPU, GPU, memoria centrale e di massa, le loro caratteristiche, sono conosciute in partenza e non variano (sensibilmente) per tutta la durata del ciclo di vita della piattaforma.
Molti dei problemi visti in precedenza spariscono: un sistema di streaming, nell’esempio appena portato, conosce in anticipo quanta memoria centrale ha a disposizione, il tempo di accesso della memoria di massa e la sua velocita’ di trasferimento; può essere quindi dimensionato esattamente per portare correttamente il mondo da visualizzare dal DVD (aiutato eventualmente dall’HD) alla memoria centrale in ogni condizione di gioco.
Il compito del testing è facilitato: una sola configurazione hardware e software (magari con l’aggiunta di un HD) da provare e riprovare. Sembra un paradiso e in parte lo è. I problemi, e sono grossi, nascono nel momento in cui si deve racchiudere nell’esigua quantità di memoria fornita, ad esempio, un mondo che su un PC di fascia media potrebbe godere di uno spazio anche quattro volte superiore.
Le console più performanti, infatti, sono dotate di 512mb di memoria centrale, che richiedono proverbiali salti mortali e lunghe settimane di performance tuning. Ma il discorso non si ferma alla memoria: CPU e GPU per quanto dedicate al compito, col passare degli anni segnano il passo, dove le aspettative del videogiocatore, al contrario, sono sempre superiori.
Questi i problemi, le soluzioni? Nelle settimane prossime vedremo piu’ da vicino alcuni degli strumenti di sviluppo usati su PC e Console, la differenza fra un devkit e la console venduta al pubblico, la differenza fra le architetture PC e le varie Console, come si affronta l’ottimizzazione su PC piuttosto che su Console.
Molto interessante… Aspetto gli articoli successivi con impazienza e curiosità!
Riguardo le aspettative dei giocatori e le console, spero venga preso in considerazione il discorso del “conoscere meglio l’architettura nel tempo”…
Molto molto interessante…però dal tuo articolo sembra quasi che lo sviluppatore lavori con il preciso obbiettivo di rendere il suo gioco compatibile con possibili configurazioni hardware vecchie di anni e anni. In realtà sappiamo bene tutti che non è così (il discorso poi cambia da gioco a gioco) e si nota come a volte sembri che gli sviluppatori tentino di tagliare fuori deliberatamente configurazioni non recentissime…da cui le ipotesi più o meno fondate di accordi tra i produttori hardware e gli sviluppatori di videogiochi.
Ultimamente invece vedo che molti giochi sono molto più scalabili di un tempo, a patto di scendere a compromessi con qualità ecc.
Io gioco a Crysis con un Athlon x2 4400 e una Ati 3650, dettagli medi a 1280*1024 e ho solo qualche piccolo rallentamento nelle scene più complesse. Per qualcuno è IMPOSSIBILE che giri sulla mia macchina … :)
Poi bisogna vedere di quanto indietro vogliamo andare come compatibilità. C’è un mio conoscente incavolatissimo perchè ha comprato un gioco che non parte sul suo pc perchè ha una X800 che all’epoca ha pagato un casino, ma come voi sapete non ha le DirectX9.0c, quindi il gioco girerebbe su una Geforce 6150 per assurdo, ma non sulla sua macchina.
Tornando in topic, devo dire che sono molto belli questi articoli, mi sono gustato quelli che parlavano della realizzazione dei giochi e anch’io attendo i prossimi.
Ottimo. Non vedo l’ora di leggere tutto.
SPero in questi punti:
Link (per approfondire il discorso) e per tool dimostrativi (quelli free: giusto per capire di cosa si sta parlando!)
na “raccolta” di questi punti finale così da poterla raccogliere e stampare/archiviare.
Magari illustrare l’uso di un dsp … Sarebbe il massimo!
Io sono un programmatore di sistemi embedded realtime, ma mi sono avvicinato ai computer ormai 25 anni fa grazie ai videogiochi. Adesso non carico neppure il campo minato!
Massimo. Buon idea, si puo’ pensare ad un ciclo di post su tool di sviluppo accessibili come XNA se la cosa interessa.
interessa eccome. Lo stanno utilizzando anche alcune Università nei corsi di progettazione/grafica 3D
Assolutamente interessante e affascinante questa serie di articoli sul mondo dello sviluppo dei videogiochi raccontata da un “insider” (almeno per me, che devo l’attuale passione per informatica e programmaizone proprio ai videogiochi di quando ero un ragazzino).
Da parte mia pollice in su e bava alla bocca per i futuri tuoi post circa tool di sviluppo tipo XNA!
C’è qualche modo per usufruire dei tool di XNA con python?? IronPython?
Di XNA non so dirti, ma il mitico Ogre ha il suo binding per python: http://www.ogre3d.org/wiki/index.php/PyOgre
e per .NET: http://www.ogre3d.org/index.php?option=com_content&task=view&id=411&Itemid=131
Lo sto usando da un po’ e funziona bene. E il bello è che è pure cross-platform (utenti linux e mac ringraziano!)
Ecco, se solo i sviluppatori per pc si sforzassero di ottimizzare al massimo le performance come si deve fare obbligatoriamente per le console, ora non avremo bisogno di super schede grafiche e 2gb di ram :|
Se avessi letto meglio l’articolo avresti visto che lo fanno, e anche più delle console: per PC si ottimizza di più.
Il problema, come diceva giustamente Francesco, è che le variabili in gioco da considerare sono troppe.
[…] e la pirateria. Francesco Carucci, dalla sua esperienza diretta nell’industry ci ha ben spiegato quali siano le differenze in termini di filosofia e di approccio allo sviluppo di un titolo per […]