Sims adversariais vs sandbox: modelando cidades NIMBY

Alguém criou um city-builder em que você joga como incorporador imobiliário em São Francisco, e a própria cidade é o chefe da fase. Você tenta construir apartamentos; o código de zoneamento, a comissão de planejamento, os vizinhos e o processo de recursos tentam barrar você. Um jogador relatou ter construído 4.147 casas em dezesseis anos simulados, sobrevivendo a 16 audiências, 3 recursos e 4 processos judiciais para ganhar o título de “Construtor de Algumas Coisas”, enquanto a cidade precisava de mais de 82.000. Como sátira política, é muito engraçado. Como design de simulação, é genuinamente interessante, porque inverte a premissa embutida em todo city-builder desde o SimCity: a de que o jogador é um prefeito onipotente e a simulação existe para ser otimizada. Aqui, a simulação é o seu adversário.

O modelo do prefeito onipotente: SimCity e seus descendentes

Os city-builders clássicos são sandbox sims. Você zoneia, cobra impostos, traça estradas, e os pequenos cidadãos simulados reagem às suas decisões. A parte interessante é que o modelo por trás é notavelmente consistente ao longo de quarenta anos do gênero: valor da terra, poluição, fluxo de trânsito e cobertura de serviços são campos sobre uma grade, e os agentes (os sims) tomam decisões simples com base nesses campos. Cities: Skylines II, o peso-pesado atual, simula domicílios individuais com ciclos de vida, locais de trabalho e deslocamentos, mas eles nunca entram com um processo contra você. Não podem. O papel deles no sistema é ser afetados, não agir.

Essa escolha de design codifica, discretamente, uma filosofia política. No SimCity, se você quer construir uma rodovia atravessando um bairro, você a constrói. Os moradores desse bairro são representados, no máximo, como uma queda em um medidor de felicidade. Os laços de feedback do jogo recompensam a vazão: mais zonas, mais população, mais base tributária. Quem jogou essas coisas por cem horas internalizou uma visão de mundo em que o obstáculo para um bom urbanismo é a falta de previsão do próprio jogador. Essa é exatamente a visão de mundo sobre a qual as disputas reais de política urbana tratam. O jogo ensina você a pensar como Robert Moses, e então as cidades reais lembram que Robert Moses é o motivo das regras que temos hoje.

Não estou desmerecendo o gênero. Os sandbox sims são excelentes naquilo para o que servem: ensinar intuição de sistemas sobre infraestrutura, uso do solo e efeitos de segunda ordem do zoneamento. Colocar indústria ao lado de residências derruba o valor da terra. O congestionamento surge da hierarquia de vias, não da largura delas. Essas lições são reais. Mas o modelo sandbox tem um ponto cego do tamanho de um departamento de planejamento: trata o atrito de governança como ruído, e não como parte do sistema.

O modelo adversarial: a cidade como oponente

O city-builder NIMBY inverte isso. Você é um incorporador com capital, tempo e paciência dos investidores como recursos. O oponente é uma burocracia procedimental: audiências de revisão discricionária, avaliação ambiental, recursos de vizinhança e a ameaça sempre presente de litígio. Seu trabalho não é maximizar a felicidade da cidade; é conseguir aprovar e construir as unidades antes que o financiamento acabe ou os investidores percam a fé. Cada portão de aprovação é um dado viciado pelo caráter político do distrito onde você está construindo.

Mecanicamente, isso se parece mais com um roguelike do que com um city-builder. Você tem uma partida. A partida acaba quando o capital ou a paciência se esgotam. O conteúdo procedimental não é terreno; é processo. E aí está a ideia que vale roubar: a burocracia é um sistema legível e mecanizável. Audiências têm filas. Recursos têm temporizadores. Cada portão tem vazão e taxa de falha. Se você olhar de lado, um pipeline de licenciamento se parece exatamente com uma requisição passando por um conjunto de serviços sobrecarregados, com retentativas, backpressure e o pacote perdido ocasional que custa onze meses. Qualquer engenheiro de backend que leia isso já construiu esse sistema no trabalho, só que com intenções melhores.

Há um mod de Factorio sobre o qual as pessoas fazem piada, que adiciona o processamento de papelada como uma árvore de receitas: montadores param se você não limpar o acúmulo burocrático, e os biters fazem fila para lhe entregar formulários de reclamação. É uma piada que funciona porque mal é uma piada. O motivo de sims de processos adversariais parecerem tão diferentes de jogar é que eles tornam a espera o problema central de recursos. Em sandbox sims, o tempo é praticamente de graça: você acelera. Em um sim adversarial, o tempo é o que o oponente tenta tirar de você, porque o atraso é o mecanismo de eliminação mais confiável de um ponto de veto. Isso não é uma abstração de jogo. É literalmente como a política habitacional funciona: você raramente derrota um projeto de vez; você apenas o faz esperar até morrer.

O que cada modelo realmente captura

Aqui vai a comparação honesta. Nenhum dos modelos é “a verdade” sobre as cidades; cada um captura uma camada causal diferente, e eles falham em direções opostas.

• Sandbox sims captam bem os sistemas físicos. Trânsito, poluição, valor da terra, cobertura de serviços, efeitos de rede da densidade. São campos e fluxos contínuos, e modelos baseados em agentes sobre uma grade reproduzem de fato fenômenos emergentes como colapso de congestionamento e pressão de gentrificação.
• Sandbox sims captam muito mal os sistemas políticos. Reduzir a oposição a um número de felicidade não é um modelo de poder. Ele não consegue expressar que uma minoria pequena, organizada e de longa data pode dominar uma maioria difusa e ocupada, e isso é o fato mais importante da política local de uso do solo.
• Sims adversariais captam bem os pontos de veto. Revisão discricionária, recursos, risco de litígio e atraso como arma são discretos, têm estado e são manipuláveis, o que é perfeito para mecânicas. O jogo reproduz corretamente o resultado empírico: quando cada projeto vira uma negociação, só sobrevivem grandes incorporadoras com advogados, então surgem menos moradias e projetos maiores.
• Sims adversariais captam muito mal os sistemas físicos. Depois que você construiu as unidades, a simulação não se importa se o bairro realmente funciona. Trânsito, escolas, esgoto: abstraídos ou ignorados. Você pode vencer o jogo e construir algo disfuncional.
• Ambos falham no contrafactual. Nenhum consegue mostrar a cidade que existiria sob regras diferentes, que é justamente a questão sobre a qual as pessoas que formulam políticas realmente discutem.

O último ponto merece ênfase porque é onde a comparação deixa de ser sobre jogos. As pessoas que discutem leis de adensamento, como a recente onda de projetos estaduais na Califórnia que retiram a discricionariedade local perto do transporte público, estão discutindo uma simulação contrafactual. Os dois lados rodam um modelo mental: um modela uma cidade em que remover pontos de veto libera oferta; o outro modela uma cidade em que removê-los destrói o caráter do bairro sem reduzir preços. Um jogo que torna a camada de pontos de veto jogável é uma contribuição genuinamente útil para esse debate, porque obriga você a encarar o mecanismo em vez de se guiar pelo clima. Quando um jogador termina uma partida tendo construído 4.000 das 82.000 casas necessárias, a lição não é “incorporadores são gananciosos” nem “vizinhos são egoístas”. É que a vazão é uma propriedade do processo, não das intenções de ninguém.

A engenharia de modelar a oposição

Do ponto de vista da engenharia de simulação, o modelo adversarial é interessante porque a oposição é agência heterogênea. Os vizinhos não são um campo; são atores com memória, saliência e motivações assimétricas. Modelá-los bem significa pegar emprestado uma parte diferente da caixa de ferramentas de IA, que os city-builders normalmente não usam. Alguns padrões que aparecem:

• Limiares de ativação com histerese. A maioria dos moradores nunca se envolve com um pedido de licença. A oposição é ativada quando o impacto percebido cruza um limiar, e, uma vez ativada, não se desativa quando as condições melhoram. Essa assimetria é fácil de modelar e faz a maior parte do trabalho de reproduzir a dinâmica real.
• Portões de processo baseados em filas. Cada etapa de revisão é uma fila com uma taxa de atendimento. O atraso surge da carga, não da má-fé, o que é fiel à vida real e é a fonte da tensão central do jogo. Você pode modelar um departamento de planejamento inteiro como um punhado de filas M/M/1 e obter um comportamento estranhamente preciso.
• Atraso como dano ao longo do tempo. Os custos de manutenção do capital se acumulam mensalmente. Essa única mecânica transforma o atraso procedimental em pressão visível para o jogador e produz a adaptação estratégica correta: incorporadores pagam caro por terrenos com aprovação automática e evitam completamente os distritos de revisão discricionária.
• Choques aleatórios com memória. Um processo não custa apenas dinheiro; ele muda o estado político do distrito. Um estado persistente do distrito transforma eventos pontuais em dependência de caminho.

Um esboço mínimo do loop central pode ser assim:

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

São quarenta linhas, e elas já reproduzem os resultados característicos do gênero: distritos com alta oposição não recebem nada construído independentemente da demanda, incorporadores se concentram em distritos de baixo atrito, e o tempo até a aprovação domina a economia do projeto. A distância entre uma especificação e seu comportamento emergente é exatamente o tipo de coisa que exploramos em a lacuna entre especificação e implementação. Ninguém escreve “produzir escassez de moradia” no código de zoneamento, mas a escassez surge das regras de qualquer forma.

Comportamento emergente vs dificuldade roteirizada

Uma bifurcação de design importa muito aqui: você roteiriza a oposição, ou deixa que ela emerja? A dificuldade roteirizada, em que a cidade simplesmente fica arbitrariamente mais obstrutiva a cada fase, é mais fácil de balancear, mas ensina a lição errada. Ela diz aos jogadores que o sistema é manipulado de propósito. A oposição emergente, construída a partir de filas, limiares e custos de manutenção, ensina algo mais próximo da verdade e bem mais desconfortável: o sistema produz esses resultados mesmo quando cada ator individual se comporta de forma razoável. O planejador com um acúmulo de nove meses não é vilão; ele está com falta de pessoal. O vizinho que recorre do seu projeto não é um NIMBY de desenho animado; ele tem uma casa, que é todo o seu patrimônio, e o jogo lhe dá uma alavanca, então ele a puxa. Como argumentamos em nosso texto sobre engenharia defensiva, os sistemas recebem o comportamento que seus incentivos permitem, não o comportamento que seus projetistas esperavam.

A emergência também torna o jogo legível para o outro lado do debate. Um YIMBY que joga aprende, de forma visceral, por que a reforma de processos importa mais do que qualquer projeto individual. Um preservacionista que joga aprende que os pontos de veto não bloqueiam seletivamente projetos ruins; eles bloqueiam tudo que tenha um cronograma longo o bastante, o que é indiscriminado. Isso é muito mais difícil de transmitir em um artigo de opinião do que em um jogo baseado em partidas, em que você vê seus custos de manutenção drenarem no turno quarenta.

O atraso é o mecanismo de eliminação mais confiável de um ponto de veto. Você raramente derrota um projeto de vez; você o faz esperar até morrer.

Jogos sérios vs sátira: quando cada um vence

A comparação que o gênero realmente nos força a fazer não é sandbox vs adversarial, e sim sátira vs modelagem séria. O jogo NIMBY é uma sátira: os parâmetros são ajustados para a comédia e para o desespero, não calibrados com prazos empíricos de aprovação. Uma versão séria, que um vereador disse certa vez que gostaria de usar como ferramenta de treino, calibraria a vazão dos portões, as probabilidades de recurso e os custos de manutenção com dados reais de licenciamento. Alguns departamentos de planejamento e pesquisadores de fato executam simulações participativas e jogos sérios exatamente para isso, embora geralmente com uma qualidade de produção de slides de PowerPoint.

A sátira vence quando o objetivo é atenção e intuição. Ninguém compartilha um modelo de planejamento calibrado em redes sociais; um jogo de navegador em que São Francisco soterra você em burocracia é compartilhado justamente porque o exagero carrega o argumento. A sátira também tem um padrão de correção baixo: ela faz uma afirmação sobre direção, não sobre magnitude. Mas a sátira perde quando a pergunta passa a ser “o que devemos mudar?”. Para isso você precisa da versão chata: regras parametrizadas que você possa ligar e desligar. Remova a revisão discricionária do modelo e observe a vazão. Dobre o quadro de planejamento e veja o acúmulo se esvaziar. Esse ciclo de alternar e observar é onde um jogo deixa de ser comentário e passa a ser um instrumento de política pública. A versão mais forte desse gênero entregaria os dois modos e deixaria o jogador alternar entre eles: sentir o desespero e depois consertar a máquina.

Por que jogos argumentam melhor do que artigos de opinião

Há uma lição mais ampla aqui para quem constrói sistemas explicativos. Um artigo de opinião afirma um mecanismo; um modelo jogável demonstra um, e deixa o usuário refutá-lo. Quando seu modelo mental de política habitacional é “alguém deveria simplesmente construir mais”, trinta minutos com um sim adversarial o reescrevem de forma mais eficaz do que qualquer número de gráficos sobre unidades licenciadas por ano. É o mesmo motivo pelo qual construir um shell ensina mais sobre Unix do que ler as páginas de manual: operar um sistema, mesmo um brinquedo, força as abstrações a se tornarem concretas. Os comentários do Hacker News sobre este jogo são reveladores: as pessoas imediatamente começaram a propor versões para suas próprias cidades, para trens de alta velocidade com suas mitigações obrigatórias para a fauna, para data centers. O padrão se generaliza porque a arquitetura de pontos de veto se generaliza. Onde houver portões de aprovação sequenciais, motivações assimétricas e atraso como custo, existe este jogo.

Eu iria além: o sim adversarial é um gênero pouco explorado para a comunicação de engenharia em geral. Imagine integrar engenheiros à processo de gestão de mudanças da sua organização fazendo-os jogar. Faça um deploy; observe a mudança entrar na fila do CAB, da aprovação de segurança e de uma janela de release congelada; sinta seu entusiasmo se converter em compreensão de por que as pessoas recorrem a shadow IT. Se isso soa familiar, é o mesmo impulso por trás de nosso argumento de que cada camada de revisão deixa um time mais lento: o atrito é invisível até que alguém precise passar algo por ele.

A recomendação

Então: sandbox sim ou sim adversarial? Jogue os dois, mas construa, se for construir algo, o adversarial. O gênero sandbox é maduro, bem atendido por títulos comerciais, e suas lições (densidade, redes, externalidades) já fazem parte da cultura. O gênero adversarial é onde estão o espaço de design inexplorado e o valor explicativo real. Se você é desenvolvedor e procura um projeto paralelo com dentes, modele a camada de processo de algo que você conhece intimamente: o pipeline de licenciamento da sua cidade, o calvário de compras da sua empresa, o sistema de vistos. Use filas, limiares com histerese e custos de manutenção; faça do atraso o antagonista; deixe os resultados emergirem em vez de roteirizá-los. Mantenha os números ajustáveis para que os céticos possam testar as próprias premissas. Você vai aprender mais sobre o sistema construindo sua versão de brinquedo do que em anos discutindo sobre ele, e todos que jogarem a sua versão também aprenderão. Esse é o truque real que este pequeno jogo consegue: pega um debate que normalmente gera calor e o transforma em uma máquina que você pode cutucar. Mais dos nossos argumentos merecem virar máquinas.