Limoni, giochi e l'economia dei remake

C'è una teoria economica molto diffusa secondo cui il mercato sistemerà tutto, che la concorrenza scarta i difetti e che se una soluzione è diventata uno standard industriale allora è oggettivamente la migliore. Nello sviluppo di videogiochi questa logica è arrivata alla fine degli anni Duemila con la diffusione di Unity, e poco dopo di Unreal, e oggi ogni tentativo di proporre di scrivere il proprio renderer o il proprio gestore della memoria si scontra con un'ondata di oppositori e dei loro cori: «non reinventare la ruota», «concentrati sul gameplay», «fai un gioco, non un motore».

Negli anni Settanta George Akerlof, nel suo lavoro sul «mercato dei bidoni», spiegava che se il compratore non riesce a distinguere a occhio un'auto usata di qualità da un catorcio (un lemon), allora il prezzo di mercato si appiattisce sulla media, le auto buone se ne vanno e il mercato si riempie proprio di quei limoni.

L'arrivo sul mercato di buoni motori di gioco ha prodotto una grande quantità di lavoretti di seconda mano di qualità, cioè di remake. Verrebbe da festeggiare la vita prolungata dei bei giochi, ma invece ci siamo ritrovati un mercato inondato di spazzatura, e la cosa ha colpito non solo i remake ma il mercato dei giochi in generale. Com'è successo?

Al management C-level e ai producer non si vende la buona architettura di UE5, ma una bella scena demo costruita su asset comprati, feature altisonanti e slide con i loghi di altri studi che «ce l'hanno fatta» a pubblicare un remake. E quando una presentazione su un motore del genere dice «il nostro nuovo sistema di gestione della geometria virtualizzata o del LODing automatico risolve tutti i problemi di memoria e della pipeline artistica», io vedo già licenziare metà dei modellatori, perché il management l'ha letta come un'occasione per risparmiare budget su di loro.

Quello che nelle presentazioni di marketing non c'è è che il design architetturale di quel sistema prevede la riscrittura continua dei buffer GPU, causando cali di frame su qualsiasi configurazione tranne il rack di test ideale del vendor con cento gigabyte di RAM e quattro 5090 in SLI.

Che appena si esce dai nominali «100 oggetti per frame» l'algoritmo comincia a degradare in modo esponenziale, e che fare il debug di tutto questo dentro una «scatola nera» a codice chiuso o con un C++ semidocumentato costerà allo studio sei mesi di lavoro dei pomodori senior — ma il licenziamento dei modellatori è già stato pianificato. I modellatori sono stati licenziati, e con loro una parte dei programmatori, e senza di loro le performance se le sono mangiate i punteruoli, Milord.

Se qualcuno azzarda un accenno al taglio dei costi, il marketing ha già vinto... ma i soldi sono già stati spesi, i modellatori già licenziati, il gioco è già in produzione, e l'opinione ingegneristica... beh... sul mercato degli strumenti B2B non vale più del vostro caffè del mattino. Ci manca disperatamente un nostro Kyle Kingsbury, uno che dica che quella decantata nuova feature complica lo sviluppo del 10% facendolo costare il 2% in meno.

buy vs build

Nel paradigma «compra, non costruire», che si sviluppa anch'esso attivamente da quando i grandi motori tuttofare sono arrivati sul mercato, si dà per scontato che un modulo di servizio di terze parti — che sia un motore fisico, un sistema di UI o uno stack di rete — sia sempre più efficiente della propria soluzione, perché ci lavora un «team specializzato», anche quando dentro c'è un solitario studente che cerca di pagarsi da mangiare. Ecco come si presenta nella realtà di un progetto medio:

[ Il vostro gioco ]
        │
        ├─► [ Motore UI di terzi ] ──► (Alloca 1000 piccoli oggetti nell'heap globale)
        ├─► [ Physics SDK di terzi ] ──► (Ignora l'alignment per le istruzioni SIMD della vostra CPU)
        └─► [ Analytics SDK di terzi ] ──► (Blocca il thread principale per 15ms su una richiesta HTTP)

Ognuno di questi moduli, preso singolarmente, ha superato i test interni del vendor — leggasi: è partito e non ha fatto crashare il motore — ma insieme trasformano la vostra memoria in poltiglia. Quando avete un motore in-house, il vostro architetto può prendere una decisione netta e stabilire che «tutte le allocazioni della UI vengono da un allocatore preallocato», il che ovviamente richiede un certo numero di righe di codice e forse persino un ingegnere dedicato, ma funziona in fretta e dentro il paradigma del vostro motore. Ma se avete comprato una soluzione di UI, state sottoscrivendo mille piccoli problemi dentro il codice chiuso di qualcun altro, frammentazione e freeze regolari, perché un modulo di terze parti non sa nulla né dell'architettura di memoria del vostro gioco, né del vostro gioco e delle sue esigenze e regole.

Cecità culturale

L'argomento più pericoloso contro lo scrivere il proprio motore o sottosistema da tempo non sono più i soldi. È la pressione culturale di una generazione di ingegneri e manager che in questi quindici anni sono cresciuti, quasi senza accorgersene, dentro il concetto che «il proprio se lo scrivono solo i pazzi».

E se andate dalla dirigenza a dire «ci servono 4 mesi per scrivere il nostro renderer tile specializzato/ui/fisica/mettete voi il resto» per il nostro splendido progetto isometrico, vi guarderanno come un «insane employee» fuori di testa. Perché i grandi studi stanno su Unreal/Unity — sei davvero più sveglio di mille ingegneri di Epic? E se non siamo su U/U non riusciremo ad assumere dal mercato, perché nessuno sa lavorare con il nostro codice fatto in casa, e quelli che lo sanno fare vogliono il doppio dei soldi.

Ma sono le domande sbagliate, e i mille ingegneri di Epic stanno scrivendo uno strumento universale che fa girare in modo ugualmente «mediocre» un puzzle mobile, un mondo aperto da 100 chilometri quadrati, un simulatore VR e il vostro gioco specifico con i suoi vincoli fissi.

La mia azienda fa uno strategico con decine di migliaia di piccoli oggetti 3D per livello, e ogni tentativo di usare il render graph standard di UE5 e Unity si arena sull'elaborazione delle trasformazioni degli oggetti e si mangia tutto il budget CPU da 30ms. Il nostro motore su questo stesso compito spende meno di 5ms, disponendo tutto il possibile in array piatti di float ed elaborandoli con istruzioni AVX — ma quel motore è stato scritto (probabilmente dagli dèi) dieci anni fa, per hardware completamente diverso, e non se ne fanno più da un pezzo... né dèi, né motori.

La norma culturale oggi impone di prendere qualcosa di più universale e più grosso, e poi di assumere 20 persone per «ottimizzare» ciò che per design non è ottimizzabile; metà di loro se ne andrà entro sei mesi perché «non ce l'ha fatta», l'altra metà verrà spostata sul fix dei bug, perché bisogna arrivare in qualche modo alla release e pubblicare un gioco con i requisiti di sistema e i consumi di una piccola centrale nucleare.

Core competency

«Se è la vostra competenza chiave, fatelo voi. Se non lo è, allora compratelo» — Joel Spolsky

E qui la dirigenza della maggior parte degli studi decide che, visto che non siamo capaci in tecnologia, la nostra core competency sarà il game design, la sceneggiatura e l'arte... Be', facciamo giochi, per i giocatori... e tutto quello che sta sotto (rendering, codice di rete, pipeline di build delle risorse, gestione della memoria) è «solo ingegneria», che si può dare in outsourcing a chi sviluppa motori.

Ma in molti videogiochi la tecnologia è già il gameplay, e non potete fare Factorio senza un motore specializzato capace di aggiornare centinaia di migliaia di entità per frame. Non potete fare No Man's Sky o Minecraft sulla pipeline artistica standard dei motori commerciali tradizionali senza una rilavorazione profonda della generazione procedurale. Non potete fare un picchiaduro reattivo se tra la pressione del tasto sul gamepad e il frame disegnato ci sono venti strati di astrazione di un framework comprato.

Dando l'infrastruttura in outsourcing, uno studio rinuncia volontariamente al proprio vantaggio competitivo. Se usate gli stessi strumenti, la stessa pipeline e gli stessi algoritmi di base degli altri 5000 studi sul mercato, le vostre possibilità tecniche sono limitate dal minimo comune denominatore di quegli strumenti, cioè dal motore. Un motore generico e universale porta alla perdita della core competency tecnologica, e allo studio non resta altro che fare un remake.

L'economia dei remake

È il prodotto naturale della paura di uno studio che ha perso le competenze tecniche ed è passato a un motore universale — paura del rischio e del degrado della R&S interna. Quando produrre un blockbuster AAA moderno costa quanto lanciare un programma spaziale, al management e agli investitori l'innovazione non serve più.

Serve un rendimento prevedibile sul capitale, e dal punto di vista di questi corporativi con il sedere su due sedie un remake o un remaster sembra la soluzione perfetta. Il vostro brand di marketing è già costruito e collaudato dal tempo, le scelte di design sono state validate 20 anni fa, e l'«innovazione» si riduce a tirare un rendering fisicamente corretto moderno e asset high-poly sopra una vecchia civetta. È la manifestazione estrema del mercato B2B dei «limoni» e della perdita della cultura della core competency: invece di investire in nuove meccaniche o costruire motori rivoluzionari, gli studi si trasformano in catene di montaggio ad alta tecnologia per riconfezionare nostalgia, dove l'unico rischio reale nel vendere un «limone» si riduce al fatto che le texture da 16K ci metteranno tre secondi in più a caricare.

Perché continuerete a comprare «limoni»

La situazione cambierà? Difficilmente. Il mercato B2B oggi è splendidamente protetto dalla selezione naturale, e quando un gioco fallisce per performance orribili, stutter o bug del codice di rete, la responsabilità viene scaricata sui designer, che danno la colpa agli ingegneri, gli ingegneri danno la colpa al motore, il vendor del motore rilascia la patch v5.4.2.2.1.4.5.6.7.83.beta con «stabilità migliorata» e ve la vende. Profit... sono tutti contenti, e questo convince ancora una volta il management che farlo da zero sarebbe costato di più.

Viviamo in un'industria in cui il codice rotto per design è diventato la norma di base, e il tentativo di scrivere una soluzione semplice, efficiente e funzionante per un compito specifico viene percepito come una ribellione contro le leggi... le leggi dell'economia dei remake.

C'è un sottile strato di studi che conserva una cultura ingegneristica e non ha paura di scrivere il proprio codice schifoso ma in cemento armato, e si scopre che il loro gioco per qualche motivo gira a 60 FPS su hardware obsoleto, carica in pochi secondi, non richiede 150 GB di disco e uno SLI di quattro schede video. A quanto pare lì ci lavorano gli alieni...