Riccardo "The Gametist" Galdieri
Recensire un videogioco è una impresa complicata.
Ci sono migliaia di fattori da considerare, partendo dalla narrativa e arrivando al comparto tecnico, passando per grafica, sonoro, durata, e tempo di gioco. Insomma, recensire richiede una competenza teorica e tecnica del medium non banale, soprattutto se si ha la pretesa, come nel mio caso, di voler essere oggettivi.
La parte più difficile, viene di conseguenza, sta nel rimuovere dal proprio giudizio ogni bias: ci sono elementi non tecnici che finiscono spesso per influenzare una recensione, tra cui l’hype per il gioco stesso, il paragone con eventuali prequel/uscite annuali/competitor frequenti, la presenza di bug, l’essere o non essere parte del target del gioco, o anche solo l’attitudine verso il genere in questione.
Ora, i più acuti di voi si staranno chiedendo perché la presenza di bug sia annoverata tra i bias e le esperienze soggettive, e non tra ciò che è oggettivo: un bug è un bug, giusto? Non proprio.
I bug sono spesso legati a condizioni particolari legate allo stato del gioco o alla macchina in questione, una serie di co-fattori che fanno si che i bug appaiano solo ad alcuni giocatori e non ad altri.
In questo articolo proverò ad analizzare il problema del recensire prodotti non finiti, analizzando come elementi quali bug e aspettative possano influenzare la percezione di un videogioco soprattutto in fase di scrittura pre-release.
Cosa è un bug
Partiamo dalle basi, ovvero cosa sia un bug.
Seguendo la definizione vocabolariesca Wikipedia, un bug “è un’anomalia che porta al malfunzionamento di un software, per esempio producendo un risultato inatteso o errato”.
Una definizione semplice, ma che copre tutta una serie di errori che si possono incontrare in qualsiasi software. Tralasciando le varie classificazioni più o meno arbitrarie, ciò che ci interessa è che i bug possono avere vari livelli di severità: alcuni sono impercettibili, come magari il foro di un proiettile in un FPS che non sparisce quando dovrebbe mentre altri possono essere estremamente fastidiosi, come problemi coi driver che impediscono l’esecuzione del gioco se non direttamente una schermata blu del sistema operativo.
In linguaggio tecnico, i bug vengono categorizzati per severità, ovvero per l’impatto che hanno sull’esperienza.
Un altro fattore estremamente importante nella descrizione di un bug è la riproducibilità, ovvero la serie di azioni che sono richieste per riprodurre un bug. Per quanto tutto ciò sembri semplice, un grosso problema nello sviluppo è che alcuni bug NON sono riproducibili, ovvero la sequenza di azioni che li causa non sempre restituisce lo stesso risultato. Alle volte premere una leva fa crashare il gioco, alle volte no. Questi bug sono i più difficili da tracciare e da fixare, in quanto sono spesso sintomo di un problema che origina in un punto diverso del codice rispetto a quello in cui si manifesta. Per fare un esempio, se ogni volta che premete l’acceleratore in un gioco di corsa la macchina non accelera il problema è verosimilmente l’input, se succede quando aprite la mappa e solo una volta su dieci, in bocca al lupo capire dove il bug sia.
La combinazione tra severità e riproducibilità determina quanto un bug sia importante da risolvere e quanto tempo potrebbe essere allocato per la risoluzione da parte dello sviluppatore.
Inutile fare altri esempi, penso che abbiate capito.
Il problema con le recensioni
Il mondo della stampa vive di prime pagine, e una notizia di ieri non è già più notizia.
Per questo i giochi vengono spesso ricevuti una quantità di tempo ragionevole prima della loro uscita ufficiale, così da dare tempo ai recensori di giocarli, finirli, ed esplorarli nuovamente. Questo serve al giocatore per approfondire il gioco, metabolizzarlo e arrivare poi a poterne scrivere i propri pensieri in maniera distaccata e professionale (oltre a poter raccogliere tutti i dati necessari per poter realizzare una guida).
In un mondo ideale, tutto ciò dovrebbe garantire al recensore la possibilità di provare il prodotto finale che il giocatore poi vedrà comparirsi “sul tavolo”.
Purtroppo però, con l’affermarsi delle “D1P o Day One Patch” come pratica comune è molto difficile che tutto ciò avvenga. Il gioco che viene recensito può essere limitato o non corrispondere alla versione pubblica (Alcuni MMO forniscono server ai giornalisti, che tendono ad essere meno aggressivi tra di loro in game), o ancora peggio, essere pieno di bug che potrebbero esser poi fixati dalla patch di cui sopra.
La prassi in questo caso, quando si vogliono far le cose bene, è comunicare con gli uffici stampa e chiedere cosa sarà fixato e cosa no. Io stesso sono stato vittima di questo problema quando ho recensito Blacksad, un gioco che avevo trovato piacevole ma con moltissimi bug. L’ufficio stampa mi aveva garantito la risoluzione dei problemi, anche se, purtroppo, così non è stato.
In questi casi il dilemma etico è: do un voto basso a causa dei bug che ho trovato ma che potrebbero non essere nel gioco finale, o do un voto alto sperando che vengano effettivamente risolti rischiando che non sia così?
Non esiste una risposta unica, dipende purtroppo dalla soggettività del recensore, e nella sua onestà intellettuale nel riportarlo nell’articolo.
Purtroppo, vedo sempre troppi pochi articoli con tali informazioni.
Se tutto ciò vi fa venire il mal di testa, sappiate che quello non è neanche il caso peggiore. No, il fondo del barile lo si raschia quando durante le recensioni i bug NON vengono fuori, ma esplodono quando il gioco viene rilasciato. Spesso questi errori sono frutto di diverse configurazioni software/hardware, di driver obsoleti o alle volte persino periferiche non riconosciute. Gli sviluppatori non sono in grado di testare ogni configurazione possibile, e ciò che magari non viene fuori in sviluppo e neanche a molti giornalisti diventa un caso quando il gioco viene rilasciato.
Questo è stato in parte il problema di Cyberpunk, un gioco tecnicamente mastodontico ma fragile. Alcune configurazioni riuscivano a giocarlo con un numero moderato (o meno impattante di un gioco Bethesda, diciamo) di bug che magari neanche incidevano sul gameplay, altri invece hanno riscontrato quelli che sarebbero stati poi le vere spine nel fianco del titolo. Ciò crea una forbice enorme tra chi si riesce a godere il gioco a pieno, e chi neanche può finirlo a causa dei problemi tecnici.
Non esistono forum privati per giornalisti che recensiscono, l’unica vera speranza è che il prodotto finale rispecchi quella che è stata l’esperienza che ci è stata fornita.
Nuova versione, vecchi bug, nuovo voto
Sviluppare videogiochi costa un sacco di soldi, e visti i margini di rischio le software house provano a risparmiare dove possono.
Una delle tecniche più in voga è quella di riciclare gli asset, non solo intesi come modelli 3D ma anche come funzionalità, idee, design (emblematico il caso di Far Cry Primal, titolo ambientato nella preistoria con la stessa mappa di uno dei suoi predecessori).
Può capitare che dunque alcuni bug vengano trasportati da una versione del gioco a quella successiva. Ciò è particolarmente vero quando le software house sviluppano i giochi utilizzando il proprio engine, magari proprio per realizzare un titolo che annualmente esce in una nuova versione. Immaginate un Football Manager del caso: sarebbe impensabile ricreare il gioco da zero ogni anno, oltre che economicamente poco sostenibile; in questi casi l’unica L’unica soluzione logica per offrire un gioco sempre intrigante è aggiungere features sopra la versione dell’ano precedente.
Personalmente, trovo i giochi a cadenza periodica annuale tra i più difficili in assoluto da recensire. Essendo io sviluppatore so quanto sia difficile dover implementare nuove features sopra un prodotto già esistente, e quanto serva delicatezza per non rompere tutto.
Dall’altro lato, so quanto sia importante, soprattutto per il pubblico, non ritrovare sempre e comunque i soliti bug versione dopo versione.
Un problema di aspettative
Proprio di recente ho pubblicato la non-recensione di F1 2022, un gioco a cui ho dovuto togliere tanti, troppi punti per i bug che da anni e anni continuano a tempestare il gioco e che non sembrano essere una priorità per il team di sviluppo, nonostante il pubblico inferocito.
Insomma, ho fatto la scelta di punire un videogioco per un bug non tanto per il bug in se, ma per la sua storia In un certo senso, ho fatto pagare al gioco un problema già esistente.
La domanda è la stessa di prima: ciò che ho fatto è giusto o sbagliato?
Devo valutare l’opera per la sua storia, o ogni capitolo dovrebbe esistere in maniera a se stante? Ho fatto la mia scelta, liberi di non essere d’accordo.
Similmente, quando ho recensito F1 Manager 2022 sono stato altrettanto “cattivo” con gli sviluppatori perché il gioco non rispecchiava quelle che erano le mie aspettative.
Dal mio punto di vista, e quindi soggettivo, il gioco era stato presentato come il più avanzato simulatore di guida manageriale mai visto: una promessa che non ha in nessun modo soddisfatto le aspettative.
Da amante della F1 come sport ho percepito subito una grandissima superficialità nella gestione di dinamiche di gara: questo non vuol dire che il gioco sia pieno di bug, ingiocabile o sbagliato ma semplicemente l’ho trovato pesantemente diverso dalla visione che ho avuto del gioco in seguito agli annunci e alle dichiarazioni fatte dagli sviluppatori. Semplicemente non rispettava la visione che io avevo percepito volesse dare, ed essendone deluso ho dato un voto non altissimo. Sono sicuro che i voti più alti che alcuni miei colleghi hanno dato derivino da una passione superficiale per i motorsport, non per incompetenza, e sono altrettanto convinto che altri redattori di player sarebbero stati più coinvoltiin questo tipo di esperienza arcade-gestionale.
Il marketing e le aspettative sono un problema in fase di recensione, in quanto spesso ci si trova a dover recensire titoli che sono stati già categorizzati a prescindere dall’utenza, seguendo quelli che sono i contenuti rilasciati dal team di marketing. Ricordate il caso in cui una giornalista ricevette minacce di morte perché aveva osato dare 7 a Cyberpunk 2077 prima che il gioco fosse uscito e i bug fossero troppo palesi per essere ignorati? Ecco, questo tipo di pressione i recensori la sentono, e difficilmente possono ignorarla. Non dimentichiamoci che noi per primi siamo amanti dei videogiochi, e le emozioni che proviamo sono le stesse del pubblico, in positivo e in negativo. Alle volte si può avere un aspetto purista, che ci porta a demonizzare tutto ciò che è innovazione (ricordo ancora l’odio che Football Manager ricevette quando introdusse il motore 3D), mentre altre volte si ha un amore così profondo per una saga o un titolo da ignorarne le lacune. Si vorrebbe sempre essere oggettivi, ma siamo esseri umani anche noi.
Personalmente ho adottato di recente una politica “no spoiler” per i videogiochi che più mi sembrano interessanti, soprattutto se devo recensirli. Evito principalmente i trailer, ma anche le notizie sullo sviluppo. Voglio poter arrivare all’esperienza con una mente il meno condizionata possibile. Non sempre ci riesco, ma un tentativo vale sempre la pena farlo.
Conclusioni
Insomma, per tirare le fila, un problema di oggettività nelle recensioni esiste, e come abbiamo visto sopra non è facilmente aggirabile. I tempi ristretti, uniti a molti altri fattori, rendono la forbice di esperienze estremamente varia. Il gioco che io recensisco potrebbe non essere lo stesso che un altro recensore gioca tra una settimana dall’altra parte del mondo. Alcuni giornali hanno deciso di aggirare il problema eliminando il voto numerico, una lodevole iniziativa che però non risolve il problema delle esperienze soggettive. Il problema resta, e una soluzione al momento proprio non c’è. Se si vuole leggere un articolo su un videogioco bisogna accettare che l’opinione del recensore sia, nonostante l’impegno profuso, soggettiva, e in quanto tale è possibile, se non probabile, che differisca da quella che avremmo noi provando lo stesso videogioco.