Crackdown 3 vs EverQuest Next: quando la distruttibilità ha bisogno del cloud computing

Pochi giorni fa, nel maxi articolo dedicato alla situazione di Xbox One dopo l’E3 e la Gamescom 2015, ho già avuto modo di parlare di Crackdown 3 e del suo ricorso al cloud computing (tramite la tecnologia Cloudgine) che consentirà nel multiplayer una distruttibilità totale e fisica (quest’ultima parola è di cruciale importanza e vedremo più avanti il motivo), mai vista prima d’ora.

Nonostante ciò ho deciso di tornare già a trattare l’argomento. Perché così presto? Semplicemente poiché navigando in diversi siti e forum sia italiani che esteri ho visto che la macchina dei “detrattori di Xbox sempre, comunque e ad ogni costo”, dopo un attimo di inevitabile smarrimento conseguente allo schiaffone morale ricevuto con la demo mostrata a Colonia da Dave Jones, è ripartita.

Adesso non possono più affermare che il supporto via cloud per Xbox One di cui Microsoft parla dal lancio della console non esista o che sia solamente una mossa del marketing o ancora che necessiti di una larghezza di banda enorme (basteranno infatti 2-4Mbps), ma non si sono persi d’animo. Dopo il disorientamento di cui sopra, si sono riorganizzati e hanno dato il via al piano B: sminuire il più possibile quanto mostrato nella demo tecnica.

Tra tutti mi sono imbattuto in utenti che, nel tentativo di far passare come poco rilevante dal punto di vista tecnologico quanto possibile in Crackdonw 3 Multiplayer, ne hanno associato la distruttibilità totale a quella del MMORPG EverQuest Next in sviluppo presso Daybreak Game Company (ex Sony Online Entertainment).

Ma la distruttibilità di Crackdown 3 è veramente equiparabile a quella di EverQuest Next?

Assolutamente no. Senza nulla togliere al MMORPG della ormai ex SOE la cui totale plasmabilità del mondo di gioco è super promettente e interessante, non ha alcun senso associarne la distruttibilità con quella che avremo nel multiplayer di Crackdown 3, specialmente dal punto di vista tecnologico e del carico computazionale. La differenza sta nella fisica in ballo. Da un lato (quello di EQN, vedi video qui sotto) abbiamo il ricorso ai voxel (pensate a dei piccoli “mattoncini” 3d che costituiscono gli scenari) che, a seguito degli input inviati dal giocatore, vengono rimossi dal server (l’unico e solo ad ospitare quel dato mondo di gioco) per rendere a video gli esiti dell’azione distruttiva. Di simulazione fisica vi è poco e nulla e, quindi, non entra in gioco in tal senso una grande mole di calcoli.

Sull’altro fronte (quello di CD3), invece, la distruttibilità oltre ad essere totale è anche fisica. Ogni poligono che costituisce la città è distruttibile, nessun frammento sparisce dallo scenario, ogni elemento grande o piccolo che sia risponde in modo coerente con le leggi della fisica. Questo vuol dire che per ogni singola maceria che viene a crearsi è necessario calcolarne continuamente il corretto posizionamento spaziale e tutte le interazioni con ciò che la circonda. In questo caso sì che la mole di calcoli è veramente notevole e richiede per la fisica un carico computazionale via via crescente, man mano che aumentano le azioni distruttive che hanno luogo in contemporanea. Da qui non è difficile comprendere come tale elaborazione sia fuori dalla portata di una sola console o di un solo PC o di un solo server; per forza di cose occorre il cloud computing con la sua intrinseca scalabilità, cioè la capacità di variare automaticamente in base alle richieste le risorse computazionali necessarie a soddisfare il carico di lavoro.

Nella distruttibilità di Crackdown 3, dunque, un’infrastruttura cloud entra in gioco eccome e la prova (vedi video qui sotto dal minuto 4 in poi) sta nell’assegnazione di diverse aree della città non ad un’unica macchina ma a diversi server ovviamente virtuali (nel video colori diversi indicano server diversi) in grado di interagire tra di loro per ripartirsi il carico computazionale (guardate come i pezzi di un edificio che finiscono nell’area di competenza di un altro server diventino responsabilità di quest’ultimo). Le barre in alto a sinistra, invece, rendono perfettamente l’idea della scalabilità di cui sopra, usando come unità di misura la potenza di calcolo che una Xbox One riserva alla fisica. Vi ricordo che senza tutta questa flessibilità non è possibile in alcun modo parlare di cloud computing.

La prima barra verde in alto a sinistra preceduta dal simbolo di Xbox rappresenta proprio il contributo all’elaborazione della fisica fornito dalla console. Tale contributo non è ovviamente sufficiente man mano che la distruzione dell’ambiente aumenta e, di conseguenza, le necessarie risorse di calcolo vengono pescate dinamicamente e in tempo reale dalla “nuvola” (barre successive precedute proprio dal simbolo della nuvola).

  • Stefano Ecoretti

    Bella spiegazione, manca il piccolo punto che il cloud promesso da MS la lancio su cui si è discusso è cloud computing a supporto della console, mentre in questo caso è cloud computing a supporto del server. Infatti la x1 non ha nessun ruolo attivo nel calcolo della fisica del mondo di gioco dì crackdown, si occupa di tutto il/i server. Il client si limita a trasmettere i comandi di gioco del giocatore e ricevere i dati con fisica già calcolata e pronti per la renderizzazione. Se così non fosse alla disconnessione di un client si avrebbe il mondo di gioco distrutto male perché una parte dei calcoli non verrebbe completata
    Ciò che invece il marketing MS ha venduto è che la console sarebbe diventata 5 volte più potente con il cloud computing, ovvero cloud computing invocato direttamente dalla console

    • In realtà in base a quanto mostrato nella demo e raccontato da chi l’ha vista e provata, la XOne non ricopre un ruolo esclusivamente passivo. Parteciperebbe anch’essa ai calcoli della fisica. La prima delle barre nel video rappresenta proprio il contributo ai calcoli della fisica forniti dalla console.
      La One probabilmente (ma in assenza di altre info si entra nel campo delle ipotesi) presidierà solo ed esclusivamente alcune delle conseguenze fisiche legate direttamente all’azione del nostro pg. Ovviamente non quelle derivanti dall’azione degli altri giocatori o indirette (es frammenti che interagiscono tra di loro). Inoltre un sistema cloud deve essere per forza flessibile, quindi nel momento in cui viene meno una console (causa disconnessione) é probabile che il suo lavoro venga preso in carico da uno dei server virtuali.
      Come tutto ciò sia possibile senza far avvertire ritardi e incoerenze agli utenti non è qualcosa che potremo sapere a breve visto che è il core della tecnologia e sia MS che Cloudgine vorranno tenere lontani gli occhi della concorrenza.
      Cmq aspettiamo maggiori info per capire se e come la One partecipa ai processi elaborativi.

      • Stefano Ecoretti

        Vederlo e provarlo non può dirti nulla sul fatto che la fisica sia elaborata dal client o meno, a meno che non giochi con uno dei client con problemi di ping o connessione poco stabile e noti che la distruzione avviene in maniera errata a causa del lavoro non svolto per tempo o non sopraggiunto dal client. Perchè è questo che succederebbe.
        La One farà di sicuro del lavoro predittivo come succede per esempio in Half-Life ma questo come saprai non è rilevante ai fini dello stato del mondo presente sul server
        Quella barra indica quanto potrebbe contribuire la X1 per dare un ordine di grandezza del lavoro svolto

        Tu la fai facile sul deviare il lavoro quando una console viene meno, ma immagina il caso reale. Il palazzo sta crollando, se tu lasci una parte del calcolo al client come pensi di sapere se quel client è attivo o meno? Aspettando la risposta. Mandi la richiesta ma ti accorgi che ti serve deviare il lavoro quando il risultato ti manca e la scena è andata avanti. Non puoi permetterti la flessibilità di cui parli su calcoli la cui risposta ti serve immediatamente.
        PS: La flessibilità di cui parli si tratta di gestire il caso in cui la macchina a cui hai affidato il calcolo viene meno, probabilmente diverso è il caso in cui devi stimare in anticipo quanto sarà pesante un calcolo per gestire il load balancing fra i server disponibili