Preparare una demo – Sotto la Scocca Speciale E3!
L’E3 si avvicina e quindi ho pensato di scrivere qualcosina di più leggero e a tema. Uno degli aspetti più interessanti della fiera losangelina sono i giochi che vengono mostrati, non solo quelli annunciati. In fondo provare un gioco in funzione è sempre meglio di vederne il solo logo, e avere prova del gameplay in azione è sempre più convincente di un trailer studiato ad hoc.
Creare una demo però non è qualcosa di semplice. Considerate lo sviluppo di un videogioco come un caos costante dove ogni elemento non è definitivo finché non si entra nell’ultimo mese. Si continuano a imbastire placeholder, pezzi provvisori, ben oltre il punto il quale uno si aspetterebbe. Questo perché il processo di fare giochi è estremamente iterativo, dato che il nuovo sostituisce il vecchio, con funzioni implementate in modo diverso dal solito in corso d’opera. Quando c’è un evento durante il quale si vuole mostrare una demo giocabile, si dovrà spostare gente per curare questa versione del gioco, eliminando bug che normalmente aspetterebbero altri mesi, affrettandosi a completare quel singolo livello della campagna che vuoi far vedere, e poco importa che gli altri siano ancora rotti.
Quante funzioni sono state implementate? Che problemi tecnici ci sono? La gui in che stato è? Quanto tempo abbiamo per testare il gioco prima di andare in scena? Quello che stiamo facendo, finirà poi nel gioco finale? Perché sprecare tempo per correggere un bug della versione v1.0 del nostro sistema solo per la presentazione visto che poi il gioco finale avrà la versione v2.0 totalmente diversa? Quanta fiducia abbiamo del nostro prodotto?
Quando credi nel tuo prodotto, sei sempre combattuto nel mostrarlo così com’è, vorresti presentarlo al meglio, anche a costo di ingannare l’utenza. Alcune demo sui palchi arrivano pre-registrate e non live. In quel momento devi vendere l’idea, fallire anche in questo può portare a percezioni errate e calo di autostima, col rischio anche di mostrare un prodotto rotto. Ci sono poi le demo live, pronte a rompersi nei modi più inaspettati. Uncharted 4 a volte non dava i comandi al giocatore dopo una cutscene, lo abbiamo visto durante la presentazione all’E3 2015. Anche Assassin’s Creed IV ebbe un po’ di incertezze nella sua presentazione. Però almeno i giochi venivano mostrati per quello che erano in quel momento. Ricordiamo tutti l’imbarazzante presentazione di The Legend of Zelda: Skyward Sword, con i comandi che praticamente non funzionavano affatto. In quell’occasione Miyamoto dovette rassicurare pubblico e stampa garantendo che i controlli funzionavano e si era trattato soltanto di un disguido tecnico. Le interferenze sono una brutta bestia.
Ci sono invece altri sviluppatori oramai abituati a lavorare in questo modo. Prendiamo i DICE con Battlefield o in generale tutti quelli che pianificano una beta pubblica del loro gioco anche svariati mesi prima del lancio a volte. Avere una pipeline di produzione rodata permette di creare build demo senza eccessive perdite di tempo e risorse. Credo che uno dei migliori modi per capire come funzionino le dinamiche in queste occasioni sia seguire i vari video di Star Citizen. Indipendentemente da quanto possiate ritenere credibile il progetto, il sorprendente quantitativo di video rilasciati mostrano diversi aspetti di game design degni di nota.
Star Citizen ha una propria convention e ovviamente gli sviluppatori cercano di arrivare con delle nuove demo da mostrare al pubblico. All’inizio dovevano portare una demo della campagna in Single Player ed una della tecnologia dei pianeti, ma si sono ritrovati a dover eliminare la demo della campagna. Il problema è sempre lo stesso: risorse. Questo video ne illustra il processo. Non è dissimile da come viene eseguito nei grandi studio, specialmente quelli dislocati in più parti del mondo come Ubisoft. Anche io e il mio studio, per prepararci allo Svilupparty, abbiamo dovuto preparare feature di gioco che avremmo potuto mettere in piedi più in là, un carico di lavoro extra di cui avremmo fatto volentieri a meno. Il programmatore ha fatto un rush per montare la logica di gioco, il grafico ha realizzato qualche pezzo extra di interfaccia che si poteva benissimo fare più in là. Non era essenziale per costruire il gioco, lo era per farlo vedere agli altri. E non oso immaginare quanti mostravano una build compilata soltanto la sera prima, in albergo.
Questi aspetti del settore non cambiano mai, sia nel piccolo, che nel grande. Attendo ogni E3 con curiosità per vedere quello che gli sviluppatori sono riusciti a mettere in piedi da far vedere a noi giocatori. Frutto di ore ed ore di fatica alle volte anche inutile, perché hai risolto il problema solo nella demo ma non nel gioco completo, lavorando più “all’italiana” che “alla tedesca”. Ancora meglio se i giochi sono ad anni di distanza dall’uscita. Generalizzando, in quel caso stai mostrando cose messe su ad hoc per la presentazione, senza starci a pensare neanche troppo. Non stupitevi quindi se le demo iniziali di un gioco dall’ampio respiro e ancora lontano dalla fase Gold, contengono elementi dissimili dal prodotto che giocherete a casa, preparare una demo è anche questo.
