Sim avversarie vs sandbox: modellare i NIMBY nelle città

Qualcuno ha costruito una city-builder in cui sei uno sviluppatore immobiliare a San Francisco, e la città stessa è il boss finale. Tu provi a costruire appartamenti; il codice urbanistico, la commissione di pianificazione, i vicini e il processo di ricorso cercano di fermarti. Un giocatore ha riportato di aver costruito 4.147 case in sedici anni simulati, superando 16 audizioni, 3 ricorsi e 4 cause legali per ottenere il grado di «Costruttore di qualche cosa», mentre la città ne avrebbe richieste oltre 82.000. Come satira politica è molto divertente. Come design di simulazione, è davvero interessante, perché ribalta l'assunto alla base di ogni city-builder da SimCity in poi: che il giocatore sia un sindaco onnipotente e che la simulazione esista per essere ottimizzata. Qui la simulazione è il tuo avversario.

Il modello del sindaco onnipotente: SimCity e i suoi discendenti

I city-builder classici sono sandbox sim. Zonizzi, tassi, tracci strade, e i piccoli sim che abitano la città reagiscono alle tue decisioni. La parte interessante è che il modello sotto il cofano è notevolmente coerente da quarant'anni a questa parte: valore dei terreni, inquinamento, flusso del traffico e copertura dei servizi sono campi su una griglia, e gli agenti (i sim) prendono decisioni semplici in base a questi campi. Cities: Skylines II, il peso massimo attuale, simula le singole famiglie con cicli di vita, luoghi di lavoro e pendolarismo, ma non ti fanno mai causa. Non possono. Il loro ruolo nel sistema è essere influenzati, non agire.

Questa scelta di design codifica silenziosamente una filosofia politica. In SimCity, se vuoi costruire un'autostrada attraverso un quartiere, la costruisci. I residenti di quel quartiere sono rappresentati, al massimo, come un calo in un indicatore di felicità. I meccanismi di feedback del gioco premiano il throughput: più zone, più popolazione, più base imponibile. Chiunque abbia giocato a questi giochi per cento ore ha interiorizzato una visione del mondo in cui l'ostacolo a un buon urbanesimo è la mancanza di lungimiranza del giocatore. È esattamente la visione del mondo di cui parlano le vere dispute di politica urbana. Il gioco ti insegna a pensare come Robert Moses, e poi le città reali ti ricordano che proprio Robert Moses è il motivo per cui abbiamo le regole che abbiamo.

Non sto attaccando il genere. Le sandbox sim sono eccellenti in ciò per cui sono nate: insegnano l'intuizione dei sistemi su infrastrutture, uso del suolo ed effetti di secondo ordine della zonizzazione. Mettere un'area industriale accanto a una residenziale fa crollare il valore dei terreni. La congestione emerge dalla gerarchia delle strade, non dalla loro larghezza. Queste lezioni sono reali. Ma il modello sandbox ha un punto cieco grande quanto un ufficio urbanistico: tratta l'attrito della governance come rumore di fondo anziché come parte del sistema.

Il modello avversario: la città come avversario

Il city-builder NIMBY ribalta tutto questo. Sei uno sviluppatore con capitale, tempo e pazienza degli investitori come risorse. L'avversario è una burocrazia procedurale: audizioni di revisione discrezionale, valutazione ambientale, ricorsi di quartiere e la minaccia sempre presente del contenzioso. Il tuo compito non è massimizzare la felicità della città, ma ottenere i permessi e costruire le unità prima che i fondi si esauriscano o che gli investitori perdano fiducia. Ogni cancello di approvazione è un tiro di dado pesato sul carattere politico del quartiere in cui stai costruendo.

Dal punto di vista meccanico, somiglia più a un roguelike che a un city-builder. Hai una partita. La partita finisce quando capitale o pazienza si esauriscono. Il contenuto procedurale non è il terreno; è il processo. Ed è questo lo spunto che vale la pena rubare: la burocrazia è un sistema leggibile e meccanizzabile. Le audizioni hanno code. I ricorsi hanno timer. Ogni cancello ha un throughput e un tasso di fallimento. Se ci strizzi gli occhi, una pipeline di permessi assomiglia esattamente a una richiesta che attraversa una serie di servizi sovraccarichi con retry, backpressure e il pacchetto perso ogni tanto che ti costa undici mesi. Ogni backend engineer che legge questo articolo ha già costruito un sistema così al lavoro, solo con intenzioni migliori.

C'è una mod di Factorio di cui la gente scherza, che aggiunge l'elaborazione delle pratiche come albero di ricette: gli assemblatori si fermano se non smaltisci l'arretrato burocratico, e i biter si mettono in coda per consegnarti moduli di reclamo. È una battuta che funziona perché è appena una battuta. Il motivo per cui le sim avversarie di processo sono così diverse da giocare è che fanno dell'attesa il problema centrale di risorse. Nelle sandbox sim il tempo è per lo più gratuito: fai avanzare la simulazione. In una sim avversaria, il tempo è ciò che l'avversario cerca di sottrarti, perché il ritardo è il meccanismo di uccisione più affidabile di un punto di veto. Non è un'astrazione di gioco. È letteralmente come funziona la politica abitativa: raramente sconfiggi un progetto apertamente, lo fai semplicemente aspettare finché muore.

Cosa cattura davvero ciascun modello

Ecco il confronto onesto. Nessuno dei due modelli è «la verità» sulle città; ciascuno cattura un diverso livello causale, e falliscono in direzioni opposte.

• Le sandbox sim catturano bene i sistemi fisici. Traffico, inquinamento, valore dei terreni, copertura dei servizi, effetti di rete della densità. Sono campi e flussi continui, e i modelli ad agenti su griglia riproducono davvero fenomeni emergenti come il collasso della congestione e la pressione della gentrificazione.
• Le sandbox sim catturano malissimo i sistemi politici. Ridurre l'opposizione a un numero di felicità non è un modello del potere. Non può esprimere che una minoranza piccola, organizzata e di lunga data può dominare una maggioranza diffusa e distratta, che è il fatto più importante della politica locale sull'uso del suolo.
• Le sim avversarie catturano bene i punti di veto. La revisione discrezionale, i ricorsi, il rischio di contenzioso e il ritardo come arma sono discreti, stateful e manipolabili, perfetti per le meccaniche. Il gioco riproduce correttamente il risultato empirico: quando ogni progetto è una trattativa, sopravvivono solo i grandi sviluppatori con avvocati, quindi si costruisce meno e si fanno progetti più grandi.
• Le sim avversarie catturano malissimo i sistemi fisici. Una volta costruite le unità, la simulazione non si preoccupa se il quartiere funzioni davvero. Traffico, scuole, fognature sono astratti o ignorati. Puoi vincere la partita e costruire qualcosa di disfunzionale.
• Entrambi falliscono sul controfattuale. Nessuno dei due può mostrarti la città che esisterebbe con regole diverse, ed è la domanda su cui discutono davvero le persone della politica pubblica.

L'ultimo punto merita enfasi perché è dove il confronto smette di riguardare i giochi. Le persone che discutono delle leggi sulla densificazione, per esempio la recente raffica di proposte di legge statali in California che tolgono discrezionalità ai comuni vicino ai trasporti, stanno discutendo di una simulazione controfattuale. Entrambe le parti usano un modello mentale: una vede una città in cui rimuovere i punti di veto sblocca l'offerta; l'altra vede una città in cui rimuoverli distrugge il carattere del quartiere senza scalfire i prezzi. Un gioco che rende il livello dei punti di veto giocabile è un contributo davvero utile a quel dibattito, perché ti costringe a confrontarti con il meccanismo invece che con le sensazioni. Quando un giocatore finisce una partita avendo costruito 4.000 delle 82.000 case necessarie, la lezione non è «i costruttori sono avidi» o «i vicini sono egoisti», ma che il throughput è una proprietà del processo, non delle intenzioni di qualcuno.

L'ingegneria della modellazione dell'opposizione

Dal punto di vista dell'ingegneria della simulazione, il modello avversario è interessante perché l'opposizione è agency eterogenea. I vicini non sono un campo; sono attori con memoria, rilevanza e motivazioni asimmetriche. Modellarli bene significa attingere a una parte diversa della cassetta degli attrezzi dell'IA rispetto a quella che di solito usano i city-builder. Alcuni pattern che emergono:

• Soglie di attivazione con isteresi. La maggior parte dei residenti non si occupa mai di una domanda di permesso. L'opposizione si attiva quando l'impatto percepito supera una soglia, e una volta attivata non si disattiva quando le condizioni migliorano. Questa asimmetria è facile da modellare e fa gran parte del lavoro per riprodurre le dinamiche reali.
• Cancelli di processo basati su code. Ogni fase di revisione è una coda con un tasso di servizio. Il ritardo emerge dal carico, non dalla malizia: è fedele alla realtà ed è la fonte della tensione centrale del gioco. Puoi modellare un intero ufficio urbanistico come una manciata di code M/M/1 e ottenere un comportamento inquietantemente accurato.
• Ritardo come danno nel tempo. I costi di mantenimento maturano mensilmente. Questo singolo meccanismo trasforma il ritardo procedurale in una pressione visibile al giocatore e produce l'adattamento strategico corretto: gli sviluppatori pagano di più per i siti edificabili di diritto ed evitano del tutto i distretti con revisione discrezionale.
• Shock casuali con memoria. Una causa legale non costa solo denaro; cambia lo stato politico del distretto. Lo stato persistente del distretto trasforma eventi isolati in dipendenza dal percorso.

Uno schizzo minimo del ciclo principale potrebbe essere così:

class Project:
def __init__(self, units, district):
self.units = units
self.district = district      # has: opposition_level, backlog, discretion
self.stage = "application"
self.months_in_process = 0
def tick(self, month):
self.months_in_process += 1
# carrying costs: land, loans, staff. delay is the killer.
burn = self.units * 900  # $/unit/month while entitled is pending
if self.stage == "application":
if self.district.backlog < self.district.staff_capacity:
self.stage = "hearing"
self.district.backlog += 1
elif self.stage == "hearing":
self.district.backlog -= 1
p_appeal = min(0.85, self.district.opposition_level
* (1 + self.district.past_appeals * 0.2))
self.stage = "appeal" if random.random() < p_appeal else "entitled"
elif self.stage == "appeal":
if self.months_in_process % 6 == 0:  # appeals resolve slowly
self.stage = "entitled" if random.random() < 0.5 else "lawsuit"
return burn

Sono quaranta righe, e riproduce già gli esiti tipici del genere: i distretti con forte opposizione non ricevono nulla da costruire a prescindere dalla domanda, gli sviluppatori si concentrano nei distretti a basso attrito, e il tempo per l'ottenimento dei permessi domina l'economia del progetto. Il divario tra una specifica e il suo comportamento emergente è esattamente il tipo di cosa che abbiamo esplorato in il divario tra specifica e implementazione: nessuno scrive «produrre una carenza di abitazioni» nel codice urbanistico, eppure la carenza emerge comunque dalle regole.

Comportamento emergente vs difficoltà scriptata

Una scelta di design conta molto qui: scriptare l'opposizione oppure lasciarla emergere? La difficoltà scriptata, con la città che diventa arbitrariamente più ostruzionistica a ogni livello, è più facile da bilanciare ma insegna la lezione sbagliata. Dice al giocatore che il sistema è truccato di proposito. L'opposizione emergente, costruita a partire da code, soglie e costi di mantenimento, insegna qualcosa di più vicino alla verità e molto più scomodo: il sistema produce questi esiti anche quando ogni singolo attore si comporta ragionevolmente. La pianificatrice con un arretrato di nove mesi non è una cattiva; è sotto organico. Il vicino che fa ricorso contro il tuo progetto non è un NIMBY da fumetto; ha una sola casa, che è tutto il suo patrimonio, e il gioco gli dà una leva, quindi la tira. Come abbiamo sostenuto nel nostro articolo sull'ingegneria difensiva, i sistemi ottengono il comportamento che i loro incentivi consentono, non quello che i progettisti speravano.

L'emergenza rende inoltre il gioco leggibile anche dall'altra parte del dibattito. Uno YIMBY che lo gioca impara sulla propria pelle perché la riforma dei processi conta più di ogni singolo progetto. Un conservazionista che lo gioca impara che i punti di veto non bloccano selettivamente i progetti cattivi: bloccano tutto ciò che ha una tempistica abbastanza lunga, il che è indiscriminato. È una cosa più difficile da far passare in un editoriale che in un gioco a partite in cui vedi i costi di mantenimento dissanguarti al turno quaranta.

Il ritardo è il meccanismo di uccisione più affidabile di un punto di veto. Raramente sconfiggi un progetto apertamente; lo fai aspettare finché muore.

Giochi seri vs satira: quando vince ciascuno

Il confronto che il genere ci impone davvero non è sandbox contro avversario, ma satira contro modellazione seria. Il gioco NIMBY è satira: i parametri sono tarati per la commedia e per la disperazione, non calibrati sulle tempistiche empiriche dei permessi. Una versione seria, quella che un membro del consiglio comunale ha detto una volta che vorrebbe come strumento di pratica, calibrerebbe il throughput dei cancelli, le probabilità di ricorso e i costi di mantenimento sui dati reali dei permessi. Alcuni uffici urbanistici e ricercatori fanno davvero simulazioni partecipative e giochi seri proprio per questo scopo, anche se di solito con una resa da presentazione PowerPoint.

La satira vince quando l'obiettivo è attirare attenzione e intuizione. Nessuno condivide un modello urbanistico calibrato sui social; un gioco nel browser in cui San Francisco ti seppellisce di burocrazia viene condiviso proprio perché l'esagerazione porta l'argomento. La satira ha anche una soglia di correttezza bassa: fa un'affermazione sulla direzione, non sulla grandezza. Ma la satira perde quando la domanda diventa «cosa dovremmo cambiare?». Per quello serve la versione noiosa: regole parametrizzate che puoi attivare e disattivare. Rimuovi la revisione discrezionale nel modello e osserva il throughput. Raddoppia il personale dell'ufficio e guarda l'arretrato svuotarsi. Quel ciclo di attiva-e-osserva è dove un gioco smette di essere commento e diventa uno strumento di policy. La versione più forte di questo genere spedirebbe entrambe le modalità e lascerebbe il giocatore passare dall'una all'altra: sentire la disperazione, poi aggiustare la macchina.

Perché i giochi argomentano meglio degli editoriali

C'è una lezione più ampia per chiunque costruisca sistemi esplicativi. Un editoriale afferma un meccanismo; un modello giocabile lo dimostra, e lascia all'utente la possibilità di falsificarlo. Quando il tuo modello mentale della politica abitativa è «qualcuno dovrebbe semplicemente costruire di più», trenta minuti con una sim avversaria lo riscrivono più efficacemente di qualsiasi grafico sulle unità autorizzate all'anno. È lo stesso motivo per cui costruire una shell ti insegna più su Unix che leggere le man page: far funzionare un sistema, anche un giocattolo, costringe le astrazioni a diventare concrete. I commenti su Hacker News a questo gioco sono rivelatori: la gente ha subito iniziato a proporre versioni per le proprie città, per l'alta velocità ferroviaria con le sue mitigazioni obbligatorie per la fauna selvatica, per i data center. Il pattern si generalizza perché l'architettura dei punti di veto si generalizza. Ovunque ci siano cancelli di approvazione sequenziali, motivazioni asimmetriche e ritardo come costo, c'è questo gioco.

Andrei oltre: la sim avversaria è un genere sottoutilizzato per la comunicazione ingegneristica in generale. Immagina di far entrare i nuovi ingegneri nel processo di change management della tua organizzazione facendoglielo giocare. Rilasci una modifica; la guardi finire in coda dietro la revisione del CAB, la firma della sicurezza e una finestra di release congelata; vedi il tuo entusiasmo trasformarsi nella comprensione del perché la gente ricorre allo shadow IT. Se suona familiare, è lo stesso istinto dietro il nostro argomento secondo cui ogni livello di revisione rallenta un team: l'attrito è invisibile finché qualcuno non deve farci passare qualcosa.

La raccomandazione

Quindi: sandbox sim o sim avversaria? Gioca entrambe, ma se costruisci qualcosa, costruisci quella avversaria. Il genere sandbox è maturo, ben servito da titoli commerciali, e le sue lezioni (densità, reti, esternalità) sono già nella cultura. Il genere avversario è dove vivono lo spazio di design inesplorato e il vero valore esplicativo. Se sei uno sviluppatore alla ricerca di un progetto laterale con un po' di sostanza, modella il livello di processo di qualcosa che conosci a fondo: la pipeline dei permessi della tua città, la trafila degli acquisti della tua azienda, il sistema dei visti. Usa code, soglie con isteresi e costi di mantenimento; fai del ritardo l'antagonista; lascia che gli esiti emergano invece di scriptarli. Mantieni i numeri regolabili, così gli scettici possono testare le proprie ipotesi. Imparerai più sul sistema costruendone la versione giocattolo che da anni a discutere di esso, e lo imparerà anche chiunque giochi la tua versione. Questo è il vero trucco di questo piccolo gioco: prende un dibattito che di solito genera calore e lo trasforma in una macchina che puoi stuzzicare. Più dei nostri argomenti meritano di diventare macchine.