Ottimizzazione, questa sconosciuta.

Per tutti quelli che "oh, gira uno schifo, speriamo che ottimizzino tutto nei tre giorni prima del lancio".

apr 17, 2026

Il titolo potrebbe sembrare un modo per puntare il dito verso le software house e gli sviluppatori, e in parte in effetti è così, non ve lo nego. Però è solo una parte della storia: qui la responsabilità è distribuita con una certa democrazia. C’è quella dei team di sviluppo, quella dei publisher, quella dirigenziale di chi firma scadenze folli senza sapere come si fa un videogioco, e indubbiamente anche quella di motori grafici come Unreal Engine, che spesso pompano ed incentivano un utilizzo poco consapevole di alcuni strumenti venduti al pubblico come “magici”. E poi sì, c’è anche la nostra: quella dei giocatori che si stanno sempre più arrendendo alla normalizzazione di standard qualitativi sempre più bassi.

Prendete ad esempio i piani alti. Spesso il problema è che chi decide come deve essere gestito il processo produttivo, se gli chiedi cosa significa sviluppare un videogioco non va oltre ad un superficialissimo “è quella cosa che faccio sviluppare a dei minion in una stanza buia e poi a una certa viene data in pasto ai nerd, così faccio i bei soldoni”. Ora moltiplicate questa leggerezza di fondo per ogni anello della catena di sviluppo, con publisher che mettono fretta, team che arrancano per stare al passo e discussioni social degli utenti da far accapponare la pelle. Insomma, non è difficile immaginare come questo effetto domino sia potenzialmente letale per qualunque progetto.

Il vero cuore di questo articolo, in ogni caso, è un altro: capire cosa significa davvero ottimizzare un gioco. Perché finché questa parola continua a essere una specie di parola-coperta sotto cui nascondere qualunque cosa, si arriva sempre lì, ai classici “eh, ok, ma tanto è una beta, avranno tempo per ottimizzare, gli mancano ancora 2 mesi di sviluppo”.

Solo che no, non funziona così. Nei videogiochi, ma anche nello sviluppo di software in generale. Quella non è ottimizzazione, ma mettere una toppa su problemi che si sono accumulati nel tempo, generati da metodologie “sbagliate” e tempi di sviluppo scanditi male.

Cosa NON È l’ottimizzazione

Partiamo dai fraintendimenti, perché sono la parte più diffusa del problema.

Ottimizzare non significa “tagliare effetti grafici a caso finché il gioco non regge meglio”. Quello è damage control. Ottimizzare non significa “mettere una toppa tre giorni prima del lancio”: le due settimane finali sono, nel migliore dei casi, da usare per stabilizzare leggermente il tutto, sistemare i pochi (perché sì, dovrebbero essere pochi a quel punto) bug noti e fare un ulteriore passaggio rapido di QA. Non per riscrivere sistemi che non funzionano.

Ottimizzare non significa “lasciare che ci pensi il DLSS”. Upscaling e frame generation sono strumenti preziosi se usati come bonus; diventano tossici se usati come stampella per coprire un motore che non regge. Quando per arrivare a 60fps ti serve il DLSS in modalità Performance, quello non è un gioco ottimizzato: è un gioco che nasconde i suoi difetti dietro una tecnologia NVIDIA; è manutenzione reattiva, e confondere le due cose è esattamente ciò che permette al pubblico di tollerare cose che non dovrebbero essere tollerate.

Cosa È l'ottimizzazione

Ottimizzare un gioco significa fare scelte architetturali consapevoli a monte, decidendo chiaramente cosa il gioco debba essere e cosa no.

Significa profilare il gioco in continuazione, dal primo mese al lancio. Non una volta sola a sei settimane dalla release, quando ormai non puoi più cambiare niente senza riscrivere metà del codice. Significa accorgersi presto quando una feature costa troppo rispetto a ciò che dà, e avere il coraggio (o la struttura organizzativa) per tagliarla.

E significa soprattutto una cosa che nel mondo del gaming diciamo poco: accettare i trade-off. Se vuoi un mondo aperto enorme, rinunci a qualcosa sulla densità dei dettagli. Se vuoi 120fps stabili, rinunci a qualcosa sul carico di rendering per frame. Se vuoi fotorealismo, rinunci sull’interattività dell’ambiente. Non si può avere tutto, e ogni volta che un trailer promette “tutto” è praticamente garantito che qualcosa, al lancio, non ci sarà. Oppure, ancora peggio, che ci sarà ma peserà come un macigno sull’esperienza globale.

Un team che sa ottimizzare non è un team con più ingegneri. È un team che sa dire di no. A se stesso, alle richieste del marketing, all’hype costruito due anni prima del lancio. Ed è la cosa più difficile che ci sia.

Le “tecnologie”

L’Unreal Engine 5 — motore più utilizzato degli ultimi anni, nonché il più criticato sul versante ottimizzazione — è in realtà una figata sotto tantissimi aspetti. Solo che c’è da fare molta attenzione nell’usarlo, perché da tecnologie molto avanzate derivano tante potenziali fregature. E invece, purtroppo, capita sempre più spesso che i team finiscano per schiantarsi di faccia su una miriade di limitazioni auto-imposte, nate dalla necessità di mantenere promesse troppo grandi o magari, ancor peggio, soddisfare le richieste di una dirigenza che ha bisogno di acronimi e nomignoli altisonanti da dare in pasto al reparto marketing ancor prima che di un gioco soddisfacente per l’utente finale.

Questo non significa che l’Unreal Engine 5 non abbia intrinsecamente dei problemi: li ha eccome, e contribuiscono attivamente a renderlo un motore estremamente complesso da maneggiare. Prima o poi ho intenzione di farci un deep-dive dedicato, quindi restate nei paraggi se siete interessati!

Due etti di Nanite e uno di Lumen, grazie!

Nanite e Lumen sono due tecnologie straordinarie. Nanite permette di renderizzare geometrie assurdamente dettagliate senza il tradizionale lavoro di ottimizzazione dei modelli. Lumen gestisce l’illuminazione globale dinamica in tempo reale, roba che fino a ieri era il sogno bagnato di qualsiasi tecnico. Entrambe sono, sulla carta, rivoluzionarie.

Il problema è che vengono spesso trattate come pulsanti magici. Il ragionamento è: “abbiamo UE5 con Nanite e Lumen attivi, quindi il gioco è automaticamente moderno e ottimizzato”. No, al contrario: sono tecnologie molto costose, che vanno integrate con criterio in base al tipo di gioco che stai progettando.

E qui arriva il cortocircuito più tossico del decennio: team che attivano tutto perché altrimenti “sembra vecchio”, senza chiedersi se quella roba serva davvero al loro gioco specifico. Il risultato sono titoli che chiedono hardware da top di gamma per restituire un’immagine che, in certi casi, avresti potuto ottenere in modo più leggero con tecniche tradizionali e ben rifinite.

Due casi contrapposti

Per rendere la faccenda meno astratta, due esempi recenti opposti.

Battlefield 6 — il caso positivo. DICE — questa volta affiancata da Criterion, Motive e Ripple Effect sotto il nuovo ombrello Battlefield Studios — dopo il disastro di Battlefield 2042 ha fatto una scelta che nel 2026 suona quasi eretica: niente ray tracing. Né al lancio, né in futuro. Christian Buhl, Studio Technical Director di Ripple Effect, lo ha detto chiaramente: la decisione è stata presa per “focalizzare tutto lo sforzo sul rendere il gioco performante per chiunque”. Tradotto: preferiamo che giri bene sulla GPU che avete in casa voi, non sulla 5090 del recensore. Una presa di posizione forte per l’IP che con il quinto capitolo aveva praticamente fatto da apripista (e testimonial principale) per la stessa tecnologia.

Il sesto capitolo si appoggia a “semplici” tecniche di rasterizzazione tradizionali e un bel ventaglio di upscaler (DLSS 4, FSR 4, XeSS 2) per alleggerire il carico dove serve. I requisiti minimi, per un AAA del 2025, sono quasi comici rispetto alla media.

È una scelta impopolare sui trailer: nessun riflesso fotorealistico da postare sui social, nessun acronimo nuovo da far piazzare nelle thumbnail. Però il gioco fa il suo mestiere: framerate alti, netcode solido, tempi di risposta bassi. E ai giocatori, quelli che lo useranno davvero e non quelli che lo guardano una volta su YouTube, interessa quello. Ottimizzare, qui, ha significato scegliere cosa non fare. Che è poi la forma più sofisticata di ottimizzazione esistente.

Borderlands 4 — il caso negativo. Gearbox ha spinto il suo nuovo Borderlands su Unreal Engine 5 con tutte le tech più pesanti attivate: Nanite, Lumen (in versione software), Virtual Shadow Maps. Che non sarebbe neanche un problema, se non fosse che... queste non si possono in alcun modo disattivare. Non sono opzioni modificabili dal consueto menu delle impostazioni grafiche, bensì decisioni architetturali fatte a monte su cui il giocatore non ha nessun potere.

Il risultato? Al lancio il gioco si è affacciato sul mercato come uno dei giochi UE5 più pesanti mai usciti. A 1080p con preset Badass, le uniche GPU che reggevano stabilmente i 60fps erano la RTX 4090 e la 5090. A 4K nativo, nessuna scheda al mondo riusciva a tenere un’esperienza fluida.

E c’era un memory leak — riconosciuto da Randy Pitchford in persona — che faceva degradare il framerate dopo un’ora di gioco, con un’unica “soluzione ufficiale” (giuro!) tutta da ridere: riavvia il gioco. Non penso serva aggiungere altro.

Che poi per carità, il vero problema non sono sicuramente le performance al preset più spinto: prendere troppo in considerazione dei benchmark “con tutto ad ultra” non è mai una soluzione sensata. Nel momento in cui le tecnologie più pesanti dell’UE5 sono sempre attive per scelta degli sviluppatori, però, il gioco diventa semplicemente impossibile da scalare verso il basso. E il sondaggio hardware di Steam lascia poco spazio all’immaginazione: la GPU più diffusa al mondo, a marzo 2026, era ancora la RTX 3060, una scheda di fascia media di circa cinque anni fa, seguita dalla RTX 4060, sua omologa della generazione successiva. Le top di gamma occupano percentuali marginali. Gearbox ha progettato un gioco che, di fatto, pretende hardware che la stragrande maggioranza dei suoi potenziali clienti non possiede.

A onor del vero, però, da allora Gearbox ha lavorato parecchio. La patch di dicembre 2025 ha ottimizzato Lumen, sistemato vegetazione e cutscene (che prima erano bloccate a 30fps). La patch v1.5 di marzo 2026 ha alzato la media di frame al secondo su tutte le configurazioni del 20% circa, con picchi fino al 42% su alcune configurazioni. Non solo: anche il crash rate è sceso sensibilmente.

Buone notizie? Ovviamente sì, ci mancherebbe. Ma leggete bene quei numeri: Gearbox ha impiegato oltre sei mesi di patching intensivo post-lancio per portare il gioco in uno stato che sarebbe dovuto essere il punto di partenza. Ed è esattamente il modello di “ottimizzazione come manutenzione reattiva” che abbiamo messo sotto accusa all’inizio dell’articolo.

Il paradosso architetturale, peraltro, resta intatto anche dopo tutte le patch. Borderlands, come serie, ha un look in cell-shading stilizzato, pensato esplicitamente per non sembrare fotografico. Nanite e Lumen servono principalmente a gestire geometrie mega-dettagliate e un’illuminazione globale fisicamente accurata: due cose di cui un cell-shading, per definizione, non ha particolare bisogno. Hai quindi la complessità computazionale di un motore fotorealistico al servizio di un risultato visivo che non la richiede. È come usare una Ferrari per andare a prendere il pane: funziona, ma è evidente a tutti che c’è qualcosa di sbagliato nella logica di base.

Il contrasto tra i due titoli mostra chiaramente come ottimizzare non sia assolutamente una semplice fase finale del ciclo di sviluppo. È figlia di una sequenza di scelte fatte all’inizio, su cosa il tuo gioco deve e non deve essere.

Il ruolo della dirigenza

Fin qui abbiamo parlato di scelte tecniche. Ma le scelte tecniche, nei team grandi, non le fanno davvero i tecnici. O meglio: le fanno anche loro, ma sempre dentro binari decisi da qualcun altro.

E quel “qualcun altro” spesso non ha idea di cosa significhi sviluppare un videogioco. Parliamo di dirigenti che misurano il successo di un reveal dal numero di acronimi nuovi che il trailer riesce a piazzare, di roadmap scritte in funzione delle call con gli investitori e non del ritmo del team; di deadline spostate avanti e indietro a seconda di cosa fa il titolo concorrente nello stesso trimestre.

Il risultato è un sistema in cui il team eredita, e nel tempo accumula, un debito tecnico che nessuno potrà mai “ottimizzare nelle ultime due settimane di sviluppo”. Scope — da leggere in inglese, non è che ai dev di Gearbox hanno chiesto di pulire il pavimento — troppo grande? Si tira dritto, ormai è tardi per tornare indietro. Feature annunciate che si scoprono impossibili sei mesi dopo? Si tengono lo stesso, perché toglierle dal trailer farebbe brutto.

Il ruolo di noi giocatori

E finalmente passiamo anche all’ultimo dei punti citati in apertura, perché a sostenere tutto questo contribuiamo sicuramente anche noi. Ogni volta che scriviamo “ottimizzeranno dopo” sotto il video di una beta che crasha, stiamo di fatto dicendo al publisher: va bene così, potete lanciarlo in questo stato.

Stiamo normalizzando standard qualitativi sempre più tarati verso il basso, e spesso lo facciamo in maniera quasi inconsapevole, convinti di essere pazienti o comprensivi quando in realtà stiamo solo aumentando la soglia di tolleranza verso comportamenti tossici nei confronti dei consumatori e della parte sana dell’industria videoludica.

TL;DR

Spesso si dice che “non si può nascere imparati”. I giochi, però, purtroppo devono “nascere ottimizzati”, altrimenti succedono cose brutte in stile Borderlands 4.

Un gioco non si ottimizza in un secondo momento. O lo si sviluppa ottimizzando i processi, le feature e il codice fino dall’inizio, oppure non lo sarà mai davvero. Se qualcosa gira da schifo al lancio raramente diventa, negli anni, un prodotto tecnicamente perfetto. Al massimo può diventare un gioco che gira meno peggio. E sono due cose molto, molto diverse.

Alla prossima,

カゲ

Fonti e approfondimenti

Battlefield 6

Borderlands 4 — stato al lancio

Borderlands 4 — patch e miglioramenti post-lancio

Dati hardware di riferimento

Discussione su questo Post

Assolutamente, procediamo.