Emergent Gameplay in Deus Ex: 5 Miti Testati

Un quarto di secolo dopo l'uscita, il gameplay emergente è ancora la cosa che la gente cita quando spiega perché Deus Ex conta. Impili casse per raggiungere una finestra. Attiri una guardia oltre una torretta che hai hackerato dieci minuti prima. Fai saltare una porta dai cardini con un razzo che avevi tenuto per lo scontro con il boss, che, grazie alla deviazione dalla porta, non avviene mai. Niente di tutto questo era scriptato. È emerso da un piccolo insieme di sistemi — fisica, percezione dell'IA, grimaldelli, esplosivi — lasciati interagire senza supervisione.

La mitologia attorno al gioco si è ispessita abbastanza da oscurare l'ingegneria reale. A seconda della retrospettiva che guardi, Deus Ex era un'opera d'arte profetica o un'ispirazione divina che nessuno è riuscito a replicare. Entrambe le cornici sono sbagliate, e sono inutili se stai cercando di costruire sistemi — videogiochi o altro — che producono comportamenti interessanti che nessuno ha programmato esplicitamente. Quindi facciamo la cosa poco di moda: prendiamo le cinque credenze più comuni sul design di Deus Ex e le testiamo contro ciò che il gioco ha fatto davvero su hardware del 2000.

Mito 1: l'emergenza richiede tecnologia all'avanguardia

La narrazione standard dice: l'emergenza è costosa, quindi doveva aspettare l'hardware moderno. Motori fisici, nav-mesh, behaviour tree, gigabyte di memoria: è ciò che permette ai sistemi di interagire in modo ricco. Deus Ex smentisce completamente questa storia. Uscì nel giugno 2000, costruito sull'Unreal Engine originale, pensato per macchine con 64 MB di RAM e CPU di cui oggi ci si vergognerebbe anche per un termostato. L'IA dei nemici era così primitiva che i recensori dell'epoca si lamentavano. Il budget di rendering del gioco era talmente stretto che lo skyline di New York dovette essere ridotto per stare nei limiti.

Eppure l'emergenza c'è stata. Succede perché l'emergenza non dipende dalla sofisticazione dei sistemi, ma dall'interazione tra di essi. Una guardia non ha bisogno di un behaviour tree per produrre un esito interessante. Le servono poche regole leggibili (sento dei rumori, indago, combatto o fuggo in base alla mia salute) che altri sistemi possono perturbare. Il sistema delle esplosioni parla con quello delle guardie. Il sistema dei grimaldelli parla con quello delle porte. La fisica delle casse parla con la geometria del livello. Ogni sistema è semplice. La composizione è ricca.

È una lezione che vale ben oltre i videogiochi. La vediamo da decenni nei sistemi distribuiti: componenti semplici con interfacce ben definite producono comportamenti globali sorprendenti, nel bene e nel male. Il team di Deus Ex non aveva potenza di calcolo da sprecare, quindi ha speso il budget sulla coerenza — assicurandosi che, quando due sistemi si incontravano, accadesse qualcosa di sensato e prevedibile. Se la tua porta può essere distrutta da una granata LAM, dovrebbe poter essere distrutta anche da un razzo, da un colpo al plasma e da un'arma da mischia con abbastanza forza alle spalle. Una regola, applicata ovunque, batte cinquanta casi speciali.

L'inversione moderna va detta chiaramente: i team oggi hanno normalmente mille volte la potenza di calcolo e producono meno emergenza, perché spendono il budget in fedeltà — set piece scriptati in alta risoluzione — invece che nell'interazione. L'emergenza non aspettava l'hardware. Aspettava una decisione di design.

Mito 2: Warren Spector lo ha progettato da solo

La teoria dell'autore muore dura nei videogiochi. Spector è il nome associato a Deus Ex, ed è un designer davvero interessante con una filosofia di design citabile — il suo brief in tre parole al team, «problems, not puzzles», è una delle dichiarazioni di intenti più compatte nella storia del medium. Ma lo stesso Spector ha contestato le narrazioni del singolo creatore, notando la tendenza della stampa ad attribuire un gioco a una sola persona. E la genealogia del gioco rende impossibile sostenere la storia del genio solitario.

Deus Ex è, per usare una frase efficace, il miglior gioco che i Looking Glass Studios non hanno mai fatto. La linea dell'immersive sim parte da Ultima Underworld (1992), passa per System Shock (1994) — il gioco che impressionò così tanto Spector, allora produttore alla Origin, da fargli lasciare il posto per entrare in Looking Glass — e arriva a Thief (1998). Il vocabolario di design di Deus Ex (interfacce diegetiche, spazi di problemi guidati dalla simulazione, mondi 3D in prima persona che si comportano in modo coerente) è stato sviluppato collettivamente alla Looking Glass nel corso di quasi un decennio, da un gruppo che includeva Doug Church, le cui idee sul design sistemico hanno circolato ampiamente. Spector portò quel vocabolario in Ion Storm quando John Romero gli offrì il budget per fare ciò che voleva.

Persino il «significato» più famoso del gioco si rivela un incidente collaborativo. Per anni i fan hanno teorizzato che le iniziali del protagonista J.C. Denton stessero per Jesus Christ, collegandole al finale in cui Denton si fonde con un'IA. Durante una postmortem alla GDC, Spector ha confermato le iniziali — e poi ha sgonfiato la sala: il nome veniva da un vero amico di nome Denton, così instancabilmente disponibile che Spector gli urlava «Jesus Christ, Denton!». La profondità è stata ricostruita dal pubblico a posteriori. Non è una critica al gioco; è un promemoria che il significato nelle opere sistemiche spesso emerge dallo stesso posto da cui emerge il gameplay — dall'interazione delle parti, non da un'unica mano autoriale.

Perché questo mito conta per chi costruisce sistemi? Perché se credi che l'emergenza richieda un visionario, aspetterai un visionario. La storia reale dice che l'emergenza richiede una tradizione: un team che ha interiorizzato un insieme di principi di design abbastanza bene da applicarli in modo coerente in centinaia di piccole decisioni. Cultura, non genio.

Mito 3: più libertà produce sempre più emergenza

Ecco il mito con le conseguenze pratiche più dirette, perché è quello che fa fallire i progetti. L'intuizione è seducente: i giochi scriptati sono vincolati, quelli emergenti sono liberi, quindi la strada verso una migliore emergenza è rimuovere vincoli. Dai al giocatore ogni verbo. Simula tutto. Massimo spazio di possibilità, massima magia.

La genealogia di Deus Ex dimostra il contrario. System Shock era l'immersive sim più senza compromessi della sua epoca, e i giocatori trovarono la sua ampiezza di possibilità più confusa che stimolante. Looking Glass rispose restringendo il campo: Thief ti diceva chiaramente che la furtività era la strada. Spector trovava le prime build di Thief frustranti nella direzione opposta — venivi scoperto una volta e morivi, perché il personaggio non sapeva combattere. Il vero risultato di Deus Ex è stato trovare il centro di quel quadrante. Puoi sparare, muoverti furtivamente, hackerare, scassinare o convincere la maggior parte dei problemi — ma il sistema di abilità fa sì che in un'unica partita non puoi farle tutte bene. I vincoli sul personaggio sono ciò che rende le tue soluzioni tue.

La stessa restrizione ponderata si ritrova nella struttura della campagna. System Shock era un unico spazio simulato continuo. Deus Ex è composto da dodici missioni discrete, ognuna un sandbox autonomo con un'uscita fissa che conduce a una missione successiva fissa. È un compromesso con la struttura tradizionale dello sparatutto, e costa al gioco il «mondo vivo» a livello macro — i momenti della trama arrivano sempre in orario. Ma è proprio ciò che rende ogni sandbox leggibile. Uno spazio problematico limitato è uno su cui il giocatore può ragionare. La possibilità illimitata è solo rumore.

C'è un'analogia a cui continuo a tornare, e ne abbiamo parlato nel nostro approfondimento su design di simulazioni avversarie contro sandbox: una simulazione è interessante quando le sue regole creano tensione, non quando semplicemente esistono. I sandbox senza pressione sono dimostrazioni tecniche. Deus Ex ti mette sotto pressione — risorse limitate, fazioni ostili, conseguenze reali per il rumore — e i vincoli sono ciò che trasforma sistemi interagenti in storie.

Mito 4: il gioco ha previsto il futuro, quindi il design era lungimiranza visionaria

Passa dieci minuti su YouTube e troverai qualcuno che spiega come Deus Ex abbia previsto stati di sorveglianza, attentati terroristici interni, singolarità dell'IA e il crollo della fiducia nelle istituzioni americane. Le Torri Gemelle mancanti dallo skyline — tagliate per ragioni di budget poligonale — vengono citate come profezia. È il mito che fa più danni alla comprensione reale, perché inverte la freccia della causalità.

Deus Ex non ha previsto il futuro. Ha letto con attenzione il suo presente. Uscì nel 2000, l'anno in cui scoppiò la bolla dot-com, immerso nella cultura cospirazionista dell'America degli anni Novanta — milizie, elicotteri neri, la paranoia di X-Files, le ansie sulla FEMA come deep state. I cattivi del gioco sono la FEMA e cabale oscure perché era il rumore di fondo culturale del momento. Che quel rumore si sia rivelato duraturo dice qualcosa sul rumore, non su un design profetico. E persino il lead writer del gioco lo ha inquadrato in modo condizionale: con un leggero spostamento di focus, il futuro potrebbe ancora assomigliare a Deus Ex.

Perché preoccuparsi di correggere questo punto? Perché il mito della lungimiranza insegna la lezione sbagliata a chi costruisce: che le grandi opere nascono dall'indovinare il futuro. La lezione reale è l'opposto. Il team di Deus Ex prestò grande attenzione ai sistemi del proprio tempo — tecnologie di sorveglianza, reti emergenti, incentivi istituzionali — e li modellò con tale fedeltà che il modello restò rilevante man mano che il mondo lo raggiungeva. Una lettura profonda del presente batte ogni volta la profezia superficiale.

C'è una versione di questo nell'ingegneria del software. I sistemi che invecchiano meglio non sono quelli che scommettono su requisiti futuri specifici; sono quelli che hanno modellato onestamente gli invarianti del loro dominio. La simulazione del mondo di Deus Ex regge per lo stesso motivo per cui regge la simulazione del gameplay: è costruita da forze reali che interagiscono, non da scenografia. È anche per questo che recensori contemporanei come Computer Gaming World potevano apprezzare il design in astratto e catalogarne i difetti — IA traballante, problemi di prestazioni, ambienti forzati. Gli artefatti invecchiano. Le architetture durano.

Mito 5: emergenza e storia scritta sono nemiche

L'ultimo mito è una falsa dicotomia che struttura ancora molte discussioni di design: o costruisci un sandbox sistemico e rinunci al controllo narrativo, oppure scrivi una storia e sacrifichi l'emergenza. Deus Ex viene spesso citato dalla parte del sandbox — «ogni azione ha conseguenze di vasta portata», come scriveva la recensione entusiasta dell'epoca. Ma guardando la struttura reale, l'affermazione crolla. Il gioco colpisce sempre gli stessi momenti di trama. Le missioni arrivano sempre nello stesso ordine. L'arco generale è fisso, persino tradizionalista.

Ciò che Deus Ex dimostra davvero è un'architettura a strati: struttura autoriale in alto, simulazione in basso, con la giunzione tra i due posizionata deliberatamente. La narrazione macro è un binario. All'interno di ogni missione, la simulazione è completamente aperta. Il giocatore possiede il come; i designer possiedono il cosa succede dopo. I giocatori che ricordano il gioco come libertà senza confini confondono lo strato locale — che era davvero emergente — con quello globale, che non lo era. L'illusione di un mondo vivo nasce dalla cornice granulare di ogni missione, non da un macrocosmo simulato.

Questo stratificarsi è l'idea più trasferibile di tutto il gioco. Considera cosa ottieni davvero. Lo strato autoriale garantisce ritmo, tema e un finale coerente — le cose in cui la simulazione è scarsa. Lo strato simulato garantisce agency del giocatore e ricchezza combinatoria — le cose in cui lo scripting è scarso. Nessuno dei due assorbe l'altro. I giochi moderni che cercano di simulare tutto (o di scriptare tutto) continuano a riscoprire perché questa divisione funziona.

La stessa architettura si vede fuori dai videogiochi. Un'API ben progettata è autoriale al confine e libera all'interno — noi controlliamo il contratto, tu controlli la composizione. Il software che richiede tempo per essere costruito di solito si rivela un software in cui qualcuno ha riflettuto a fondo su dove debba stare quella giunzione. Metterla troppo in alto e ottieni un prodotto rigido e scriptato. Metterla troppo in basso e ne ottieni uno incomprensibile. Deus Ex l'ha messa esattamente all'altezza di una singola missione, e da allora i giocatori raccontano storie sulle conseguenze.

Problemi, non enigmi: offri affordance e fidati della simulazione, invece di progettare un'unica soluzione giusta e giudicare il giocatore in base a quella.

Cosa resta dopo i miti

Togli la profezia, il culto dell'autore e la teoria massimalista della libertà, e ciò che resta è più utile della leggenda. L'emergenza di Deus Ex è nata da una manciata di sistemi semplici, coerenti e interagenti. I designer hanno scelto vincoli deliberatamente, sia a livello del personaggio (non puoi essere bravo in tutto) sia a livello strutturale (missioni delimitate dentro una campagna fissa). La sua longevità è venuta dal modellare onestamente il presente invece di indovinare il futuro. E la sua virtù più citata — la sensazione di un mondo che reagisce a te — era un'illusione ingegnerizzata, costruita stratificando la simulazione sotto l'autorialità, non simulando il mondo intero.

Se costruisci videogiochi, la checklist si scrive da sola: meno sistemi, più interazioni, coerenza spietata, vincoli che creano pressione, e una decisione deliberata su dove finisce lo strato autoriale. Se costruisci altro — e, onestamente, la maggior parte di noi costruisce simulazioni di un tipo o dell'altro, che si tratti di un framework per agenti, di un motore di regole o di un marketplace — la stessa checklist vale. Il comportamento interessante non è mai stato nelle parti. Stava nelle giunzioni tra di esse. Deus Ex l'ha capito su una CPU da 500 MHz. Non abbiamo scuse.