Sims adversariales vs sandbox: modelar el NIMBY urbano

Alguien construyó un city-builder en el que juegas como promotor inmobiliario en San Francisco, y la propia ciudad es el jefe final. Intentas construir pisos; el código de zonificación, la comisión de urbanismo, los vecinos y el proceso de recursos intentan detenerte. Un jugador reportó haber construido 4.147 viviendas durante dieciséis años simulados, superando 16 audiencias, 3 recursos y 4 demandas para obtener el rango de «Constructor de algunas cosas», mientras la ciudad necesitaba más de 82.000. Como sátira política es muy divertido. Como diseño de simulación, es genuinamente interesante, porque invierte la suposición que está en todo city-builder desde SimCity: que el jugador es un alcalde omnipotente y la simulación está ahí para ser optimizada. Aquí la simulación es tu oponente.

El modelo del alcalde omnipotente: SimCity y sus descendientes

Los city-builders clásicos son sims sandbox. Zonificas, cobras impuestos, trazas carreteras, y los pequeños ciudadanos simulados responden a tus decisiones. Lo interesante es que el modelo subyacente es notablemente consistente a lo largo de cuarenta años de género: el valor del suelo, la contaminación, el flujo de tráfico y la cobertura de servicios son campos sobre una cuadrícula, y los agentes (los sims) toman decisiones simples basándose en esos campos. Cities: Skylines II, el peso pesado actual, simula hogares individuales con ciclos de vida, lugares de trabajo y desplazamientos, pero nunca te demandan. No pueden. Su papel en el sistema es ser afectados, no actuar.

Esta decisión de diseño codifica en silencio una filosofía política. En SimCity, si quieres construir una autopista atravesando un barrio, la construyes. Los residentes de ese barrio están representados, como mucho, como una bajada en un medidor de felicidad. La retroalimentación del juego premia el rendimiento: más zonas, más población, más base fiscal. Quien ha jugado a estos juegos durante cien horas ha interiorizado una visión del mundo en la que el obstáculo para un buen urbanismo es la falta de previsión del propio jugador. Esa es precisamente la visión del mundo sobre la que tratan las disputas reales de política urbana. El juego te enseña a pensar como Robert Moses, y luego las ciudades reales te recuerdan que Robert Moses es la razón de que tengamos las normas que tenemos.

No estoy criticando el género. Los sandbox sims son excelentes en lo que buscan: enseñar intuición sobre sistemas en infraestructura, uso del suelo y efectos de segundo orden de la zonificación. Mezclar industria junto a residencia hunde el valor del suelo. La congestión surge de la jerarquía de carreteras, no de su anchura. Esas lecciones son reales. Pero el modelo sandbox tiene un punto ciego del tamaño de un departamento de urbanismo: trata la fricción de la gobernanza como ruido en lugar de como parte del sistema.

El modelo adversarial: la ciudad como oponente

El city-builder NIMBY le da la vuelta a esto. Eres un promotor con capital, tiempo y paciencia de inversores como recursos. El oponente es una burocracia procedimental: audiencias de revisión discrecional, evaluación ambiental, recursos vecinales y la amenaza siempre presente de litigio. Tu trabajo no es maximizar la felicidad de la ciudad, sino conseguir que tus unidades sean aprobadas y construidas antes de que se acabe la financiación o los inversores pierdan la fe. Cada puerta de aprobación es una tirada de dados ponderada por el carácter político del distrito donde construyes.

Mecánicamente, esto se parece más a un roguelike que a un city-builder. Tienes una partida. La partida termina cuando se acaban el capital o la paciencia. El contenido procedimental no es el terreno; es el proceso. Y ahí está la idea que vale la pena robar: la burocracia es un sistema legible y mecanizable. Las audiencias tienen colas. Los recursos tienen temporizadores. Cada puerta tiene un rendimiento y una tasa de fallo. Si entrecierras los ojos, un proceso de permisos parece exactamente una petición que pasa por un conjunto de servicios saturados con reintentos, contrapresión y el paquete perdido ocasional que te cuesta once meses. Cualquier ingeniero de backend que lea esto ya ha construido este sistema en el trabajo, solo que con mejores intenciones.

Hay un mod de Factorio del que la gente bromea que añade el procesamiento de papeleo como árbol de recetas: los ensambladores se paran si no despejas el atasco burocrático, y los biters hacen cola para entregarte formularios de quejas. Es un chiste que funciona porque apenas es un chiste. La razón por la que los sims de proceso adversarial se sienten tan distintos al jugarlos es que convierten la espera en el problema central de recursos. En los sandbox sims el tiempo es casi gratis: adelantas. En un sim adversarial, el tiempo es lo que el oponente intenta quitarte, porque el retraso es el mecanismo de eliminación más fiable que tiene un punto de veto. Eso no es una abstracción de juego. Es literalmente cómo funciona la política de vivienda: rara vez derrotas un proyecto de golpe; simplemente lo haces esperar hasta que muere.

Lo que captura realmente cada modelo

Aquí va la comparación honesta. Ningún modelo es «la verdad» sobre las ciudades; cada uno captura una capa causal distinta, y fallan en direcciones opuestas.

• Los sandbox sims capturan bien los sistemas físicos. Tráfico, contaminación, valor del suelo, cobertura de servicios, efectos de red de la densidad. Son campos y flujos continuos, y los modelos basados en agentes sobre una cuadrícula reproducen de verdad fenómenos emergentes como el colapso por congestión y la presión de gentrificación.
• Los sandbox sims capturan fatal los sistemas políticos. Reducir la oposición a un número de felicidad no es un modelo del poder. No puede expresar que una minoría pequeña, organizada y de larga residencia pueda dominar a una mayoría difusa y ocupada, que es el hecho más importante de la política local del suelo.
• Los sims adversariales capturan bien los puntos de veto. La revisión discrecional, los recursos, el riesgo de litigio y el retraso como arma son discretos, con estado y manipulables, perfectos para mecánicas. El juego reproduce correctamente el resultado empírico: cuando cada proyecto es una negociación, solo sobreviven los grandes promotores con abogados, así que hay menos vivienda y proyectos más grandes.
• Los sims adversariales capturan fatal los sistemas físicos. Una vez construidas tus unidades, la simulación no se preocupa de si el barrio funciona de verdad. Tráfico, colegios, alcantarillado: abstraídos o ignorados. Puedes ganar la partida y construir algo disfuncional.
• Ambos fallan en el contrafactual. Ninguno puede mostrarte la ciudad que existiría con otras reglas, que es la pregunta sobre la que realmente discuten quienes hacen política pública.

El último punto merece énfasis porque ahí la comparación deja de tratar sobre juegos. Quienes discuten sobre las leyes de recalificación, por ejemplo la reciente oleada de leyes estatales de California que anulan la discrecionalidad local cerca del transporte público, están discutiendo una simulación contrafactual. Ambos bandos ejecutan un modelo mental: uno modela una ciudad en la que eliminar los puntos de veto desata la oferta; el otro modela una ciudad en la que eliminarlos destruye el carácter del vecindario sin afectar a los precios. Un juego que hace jugable la capa de puntos de veto es una contribución genuinamente útil a ese debate, porque te obliga a enfrentarte al mecanismo en lugar de a las sensaciones. Cuando un jugador termina una partida habiendo construido 4.000 de las 82.000 viviendas necesarias, la lección no es «los promotores son codiciosos» ni «los vecinos son egoístas», sino que el rendimiento es una propiedad del proceso, no de las intenciones de nadie.

La ingeniería de modelar la oposición

Desde el punto de vista de la ingeniería de simulación, el modelo adversarial es interesante porque la oposición es agencia heterogénea. Los vecinos no son un campo; son actores con memoria, relevancia y motivaciones asimétricas. Modelarlos bien significa robar de una parte distinta de la caja de herramientas de IA que los city-builders suelen usar. Algunos patrones que aparecen:

• Umbrales de activación con histéresis. La mayoría de residentes nunca se involucra con una solicitud de permiso. La oposición se activa cuando el impacto percibido cruza un umbral, y una vez activada no se desactiva cuando las condiciones mejoran. Esa asimetría es fácil de modelar y hace la mayor parte del trabajo para reproducir la dinámica real.
• Puertas de proceso basadas en colas. Cada etapa de revisión es una cola con una tasa de servicio. El retraso surge de la carga, no de la malicia, lo que es fiel a la vida real y a la vez la fuente de la tensión central del juego. Puedes modelar un departamento de urbanismo entero como un puñado de colas M/M/1 y obtener un comportamiento inquietantemente realista.
• El retraso como daño en el tiempo. Los costes de mantenimiento se acumulan mensualmente. Esta única mecánica convierte el retraso procedimental en presión visible para el jugador y produce la adaptación estratégica correcta: los promotores pagan de más por solares con derecho directo y evitan por completo los distritos de revisión discrecional.
• Shocks aleatorios con memoria. Una demanda no solo cuesta dinero; cambia el estado político del distrito. Un estado persistente del distrito convierte los eventos puntuales en dependencia de la trayectoria.

Un esbozo mínimo del bucle principal podría verse así:

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

Son cuarenta líneas, y ya reproduce los resultados característicos del género: los distritos con mucha oposición no construyen nada sin importar la demanda, los promotores se agrupan en distritos de baja fricción y el tiempo hasta la aprobación domina la economía del proyecto. La brecha entre una especificación y su comportamiento emergente es exactamente el tipo de cosa que hemos explorado en la brecha entre especificación e implementación: nadie escribe «producir escasez de vivienda» en el código de zonificación, pero la escasez surge de todos modos de las reglas.

Emergencia frente a dificultad programada

Una bifurcación de diseño importa mucho aquí: ¿programas la oposición o dejas que emerja? La dificultad programada, en la que la ciudad simplemente se vuelve arbitrariamente más obstructiva en cada nivel, es más fácil de equilibrar, pero enseña la lección equivocada. Le dice al jugador que el sistema está amañado a propósito. La oposición emergente, construida a partir de colas, umbrales y costes de mantenimiento, enseña algo más cercano a la verdad y mucho más incómodo: el sistema produce estos resultados incluso cuando cada actor individual se comporta razonablemente. La planificadora con un atasco de nueve meses no es villana; está desbordada de personal. El vecino que recurre tu proyecto no es un NIMBY de caricatura; tiene una sola casa, que es todo su patrimonio, y el juego le da una palanca, así que la acciona. Como argumentamos en nuestro artículo sobre ingeniería defensiva, los sistemas obtienen el comportamiento que sus incentivos permiten, no el que sus diseñadores esperaban.

La emergencia también hace que el juego sea legible para el otro lado del debate. Un YIMBY que lo juegue aprende de forma visceral por qué importa más la reforma de procesos que cualquier proyecto concreto. Un conservacionista que lo juegue aprende que los puntos de veto no bloquean selectivamente los malos proyectos: bloquean todo lo que tenga un calendario lo bastante largo, lo que es indiscriminado. Esto es mucho más difícil de transmitir en un artículo de opinión que en un juego por partidas donde ves cómo tus costes de mantenimiento se desangran en el turno cuarenta.

El retraso es el mecanismo de eliminación más fiable que tiene un punto de veto. Rara vez derrotas un proyecto de golpe; lo haces esperar hasta que muere.

Juegos serios frente a sátira: cuándo gana cada uno

La comparación que el género realmente nos obliga a hacer no es sandbox frente a adversarial, sino sátira frente a modelado serio. El juego NIMBY es sátira: los parámetros están ajustados para la comedia y la desesperación, no calibrados con plazos de licencia empíricos. Una versión seria, la que una concejal de ayuntamiento dijo una vez que querría como herramienta de práctica, calibraría el rendimiento de las puertas, las probabilidades de recurso y los costes de mantenimiento con datos reales de permisos. Algunos departamentos de urbanismo e investigadores sí ejecutan simulaciones participativas y juegos serios con este fin, aunque normalmente con una calidad de producción de nivel PowerPoint.

La sátira gana cuando el objetivo es la atención y la intuición. Nadie comparte un modelo urbanístico calibrado en redes sociales; un juego de navegador en el que San Francisco te entierra en trámites se comparte precisamente porque la exageración transporta el argumento. La sátira además tiene un listón bajo de corrección: hace una afirmación sobre la dirección, no sobre la magnitud. Pero la sátira pierde cuando la pregunta pasa a ser «¿qué deberíamos cambiar?». Para eso necesitas la versión aburrida: reglas parametrizadas que puedas activar y desactivar. Elimina la revisión discrecional del modelo y observa el rendimiento. Duplica el personal de planificación y observa cómo se vacía el atasco. Ese bucle de alternar y observar es donde un juego deja de ser comentario y empieza a ser un instrumento de política pública. La versión más sólida de este género incluiría ambos modos y permitiría al jugador alternar entre ellos: sentir la desesperación y luego arreglar la máquina.

Por qué los juegos argumentan mejor que los artículos de opinión

Hay una lección más amplia para quien construye sistemas explicativos. Un artículo de opinión afirma un mecanismo; un modelo jugable lo demuestra, y deja que el usuario lo refute. Cuando tu modelo mental de la política de vivienda es «alguien debería construir más», treinta minutos con un sim adversarial lo reconfiguran más eficazmente que cualquier cantidad de gráficos sobre unidades permitidas al año. Esta es la misma razón por la que construir una shell te enseña más sobre Unix que leer las páginas del manual: operar un sistema, incluso uno de juguete, obliga a que las abstracciones se vuelvan concretas. Los comentarios de Hacker News sobre este juego son reveladores: la gente empezó enseguida a proponer versiones para sus propias ciudades, para el tren de alta velocidad con sus mitigaciones obligatorias de fauna, para centros de datos. El patrón se generaliza porque la arquitectura de los puntos de veto se generaliza. Donde haya puertas de aprobación secuenciales, motivaciones asimétricas y retraso como coste, tienes este juego.

Iría más lejos: el sim adversarial es un género poco explotado para la comunicación en ingeniería en general. Imagina incorporar ingenieros a tu proceso de gestión de cambios haciendo que lo jueguen. Despliegas un cambio; lo ves hacer cola tras la revisión del CAB, la firma de seguridad y una ventana de congelación de releases; ves cómo tu entusiasmo se convierte en comprensión de por qué la gente recurre a la TI en la sombra. Si esto te suena familiar, es el mismo instinto que hay detrás de nuestro argumento de que cada capa de revisión hace más lento a un equipo: la fricción es invisible hasta que alguien tiene que hacer pasar algo por ella.

La recomendación

Entonces, ¿sim sandbox o sim adversarial? Juega a ambos, pero si vas a construir algo, construye el adversarial. El género sandbox está maduro, bien servido por títulos comerciales, y sus lecciones (densidad, redes, externalidades) ya están en la cultura. El género adversarial es donde están el espacio de diseño sin explorar y el valor explicativo real. Si eres desarrollador y buscas un proyecto personal con miga, modela la capa de procesos de algo que conozcas a fondo: el circuito de permisos de tu ciudad, el laberinto de compras de tu empresa, el sistema de visados. Usa colas, umbrales con histéresis y costes de mantenimiento; haz del retraso el antagonista; deja que los resultados emerjan en lugar de programarlos. Mantén los números ajustables para que los escépticos puedan probar sus propias suposiciones. Aprenderás más sobre el sistema construyendo su versión de juguete que en años de discutir sobre él, y todos los que jueguen tu versión también. Ese es el verdadero truco de este pequeño juego: toma un debate que normalmente genera calor y lo convierte en una máquina que puedes manipular. Más de nuestros argumentos merecen ser máquinas.