Adversarial vs Sandbox Sims: Modeling NIMBY Cities

Someone built a city-builder where you play a housing developer in San Francisco, and the city itself is the boss fight. You try to build apartments; the zoning code, the planning commission, the neighbors, and the appeals process try to stop you. One player reported building 4,147 homes over sixteen simulated years — surviving 16 hearings, 3 appeals and 4 lawsuits to earn the grade of "Builder of Some Things" — while the city needed over 82,000. As a piece of political satire it's very funny. As a piece of simulation design, it's genuinely interesting, because it inverts the assumption baked into every city-builder since SimCity: that the player is an omnipotent mayor and the simulation is there to be optimized. Here the simulation is your opponent.

The omnipotent-mayor model: SimCity and its descendants

Classic city-builders are sandbox sims. You zone, you tax, you lay roads, and the little simulated citizens respond to your decisions. The interesting part is that the model under the hood is remarkably consistent across forty years of the genre: land value, pollution, traffic flow, and service coverage are fields over a grid, and agents (sims) make simple decisions based on those fields. Cities: Skylines II, the current heavyweight, simulates individual households with life cycles, workplaces, and commutes — but they never file a lawsuit against you. They can't. Their role in the system is to be affected, not to act.

This design choice quietly encodes a political philosophy. In SimCity, if you want to build a highway through a neighborhood, you build it. The residents of that neighborhood are represented, at most, as a dip in a happiness meter. The game's feedback loops reward throughput: more zones, more population, more tax base. Anyone who's played these games for a hundred hours has internalized a worldview where the obstacle to good urbanism is the player's own lack of foresight. That's precisely the worldview real urban policy disputes are about. The game teaches you to think like Robert Moses, and then real cities remind you that Robert Moses is why we have the rules we have.

I'm not dunking on the genre. Sandbox sims are excellent at what they're for: teaching systems intuition about infrastructure, land use, and second-order effects of zoning. Mixing industrial next to residential tanks land value. Congestion emerges from road hierarchy, not road width. Those lessons are real. But the sandbox model has a blind spot the size of a planning department: it treats governance friction as noise rather than as the system.

The adversarial model: the city as opponent

The NIMBY city-builder flips this. You're a developer with capital, time, and investor patience as your resources. The opponent is a procedural bureaucracy: discretionary review hearings, environmental review, neighborhood appeals, and the ever-present threat of litigation. Your job isn't to maximize a city's happiness — it's to get units entitled and built before your funding runs out or your investors lose faith. Each approval gate is a dice roll weighted by the political character of the district you're building in.

Mechanically, this is closer to a roguelike than a city-builder. You have a run. The run ends when capital or patience runs out. The procedural content isn't terrain; it's process. And that's the insight worth stealing: bureaucracy is a legible, mechanizable system. Hearings have queues. Appeals have timers. Each gate has throughput and a failure rate. If you squint, a permitting pipeline looks exactly like a request moving through a set of overloaded services with retries, backpressure, and the occasional dropped packet that costs you eleven months. Any backend engineer reading this has already built this system at work, just with better intentions.

There's a Factorio mod people joke about that adds paperwork-processing as a recipe tree — assemblers shut down if you don't clear the bureaucratic backlog, and the biters queue up to hand you complaint forms. It's a joke that lands because it's barely a joke. The reason adversarial process sims feel so different to play is that they make waiting the core resource problem. In sandbox sims time is mostly free — you fast-forward. In an adversarial sim, time is the thing the opponent is trying to take from you, because delay is the most reliable kill mechanism a veto point has. That's not a game abstraction. That's literally how housing politics works: you rarely defeat a project outright, you just make it wait until it dies.

What each model actually captures

Here's the honest comparison. Neither model is "the truth" about cities; each captures a different causal layer, and they fail in opposite directions.

• Sandbox sims capture physical systems well. Traffic, pollution, land value, service coverage, network effects of density. These are continuous fields and flows, and agent-based models on a grid genuinely do reproduce emergent phenomena like congestion collapse and gentrification pressure.
• Sandbox sims capture political systems terribly. Reducing opposition to a happiness number is not a model of power. It can't express that a small, organized, long-tenured minority can dominate a diffuse, busy majority — which is the single most important fact about local land-use politics.
• Adversarial sims capture veto points well. Discretionary review, appeals, litigation risk, and delay-as-weapon are discrete, stateful, and gameable — perfect for mechanics. The game correctly reproduces the empirical outcome: when every project is a negotiation, only big developers with lawyers survive, so you get less housing and bigger projects.
• Adversarial sims capture physical systems terribly. Once you've built your units, the sim doesn't care whether the neighborhood actually functions. Traffic, schools, sewers — abstracted away or ignored. You can win the game and build something dysfunctional.
• Both fail at the counterfactual. Neither can show you the city that would exist under different rules, which is the question policy people actually argue about.

The last point deserves emphasis because it's where the comparison stops being about games. The people who argue about upzoning laws — say, California's recent spate of state-level preemption bills that strip local discretion near transit — are arguing about a counterfactual simulation. Both sides are running a mental model: one side models a city where removing veto points unleashes supply; the other models a city where removing them destroys neighborhood character without denting prices. A game that makes the veto-point layer playable is a genuinely useful contribution to that argument, because it forces you to engage with the mechanism instead of the vibes. When a player finishes a run having built 4,000 of 82,000 needed homes, the lesson isn't "developers are greedy" or "neighbors are selfish" — it's that throughput is a property of the process, not of anyone's intentions.

The engineering of modeling opposition

From a simulation-engineering standpoint, the adversarial model is interesting because opposition is heterogeneous agency. The neighbors aren't a field; they're actors with memory, salience, and asymmetric motivation. Modeling them well means stealing from a different part of the AI toolbox than city-builders usually use. A few patterns that show up:

• Activation thresholds with hysteresis. Most residents never engage with a permit application. Opposition activates when perceived impact crosses a threshold — and once activated, it doesn't deactivate when conditions improve. That asymmetry is easy to model and does most of the work of reproducing real dynamics.
• Queue-based process gates. Each review stage is a queue with a service rate. Delay emerges from load, not malice — which is both true to life and the source of the game's central tension. You can model an entire planning department as a handful of M/M/1 queues and get behavior that feels eerily accurate.
• Delay as damage-over-time. Carry costs accrue monthly. This single mechanic converts procedural delay into player-visible pressure and produces the correct strategic adaptation: developers over-pay for as-of-right sites and avoid discretionary-review districts entirely.
• Random shocks with memory. A lawsuit doesn't just cost money; it changes the political state of the district. Persistent district state turns one-off events into path dependence.

A minimal sketch of the core loop might look like this:

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

That's forty lines, and it already reproduces the genre's signature outcomes: districts with high opposition get nothing built regardless of demand, developers cluster in low-friction districts, and time-to-entitlement dominates project economics. The gap between a specification and its emergent behavior is exactly the kind of thing we've explored in the specification-implementation gap — nobody writes "produce a housing shortage" in the zoning code, but the shortage falls out of the rules anyway.

Emergent behavior vs scripted difficulty

One design fork matters a lot here: do you script the opposition, or do you let it emerge? Scripted difficulty — the city just gets arbitrarily more obstructive each level — is easier to balance but teaches the wrong lesson. It tells players the system is rigged by intent. Emergent opposition, built from queues, thresholds, and carry costs, teaches something closer to the truth and much more uncomfortable: the system produces these outcomes even when every individual actor is behaving reasonably. The planner with a nine-month backlog isn't villainous; she's understaffed. The neighbor appealing your project isn't a cartoon NIMBY; he has one house, it's his entire net worth, and the game gives him a lever, so he pulls it. As we argued in our piece on defensive engineering, systems get the behavior their incentives permit, not the behavior their designers hoped for.

Emergence also makes the game legible to the other side of the argument. A YIMBY playing this game learns viscerally why process reform matters more than any single project. A preservationist playing it learns that veto points don't selectively block bad projects — they block everything with a long enough timeline, which is indiscriminate. That's a harder thing to get across in an op-ed than in a run-based game where you watch your carry costs bleed out on turn forty.

Delay is the most reliable kill mechanism a veto point has. You rarely defeat a project outright; you make it wait until it dies.

Serious games vs satire: when each one wins

The comparison the genre really forces on us isn't sandbox vs adversarial — it's satire vs serious modeling. The NIMBY game is satire: the parameters are tuned for comedy and despair, not calibrated to empirical entitlement timelines. A serious version — one a city council member once said they'd want as a practice tool — would calibrate gate throughput, appeal probabilities, and carry costs against real permit data. Some planning departments and researchers do run participatory simulations and serious games for exactly this purpose, though usually with PowerPoint-grade production values.

Satire wins when the goal is attention and intuition. Nobody shares a calibrated planning model on a social network; a browser game where San Francisco buries you in process gets shared precisely because the exaggeration carries the argument. Satire also has a low bar for correctness — it's making a claim about direction, not magnitude. But satire loses when the question becomes "what should we change?" For that you need the boring version: parameterized rules you can toggle. Remove discretionary review in the model and watch throughput. Double planning staff and watch the backlog drain. That toggle-and-observe loop is where a game stops being commentary and starts being a policy instrument. The strongest version of this genre would ship both modes and let the player flip between them — feel the despair, then fix the machine.

Why games argue better than op-eds

There's a broader lesson here for anyone who builds explanatory systems. An op-ed asserts a mechanism; a playable model demonstrates one, and lets the user falsify it. When your mental model of housing politics is "someone should just build more," thirty minutes with an adversarial sim rewires it more effectively than any number of charts about units-permitted-per-year. This is the same reason building a shell teaches you more about Unix than reading the man pages: operating a system, even a toy one, forces the abstractions to become concrete. The Hacker News comments on this game are telling — people immediately started proposing versions for their own cities, for high-speed rail with its mandatory wildlife mitigations, for data centers. The pattern generalizes because veto-point architecture generalizes. Anywhere you have sequential approval gates, asymmetric motivation, and delay-as-cost, you have this game.

I'd go further: the adversarial sim is an underused genre for engineering communication generally. Imagine onboarding engineers to your organization's change-management process by making them play it. Deploy a change; watch it queue behind CAB review, security sign-off, and a frozen-release window; feel your enthusiasm convert into an understanding of why people reach for shadow IT. If that sounds familiar, it's the same instinct behind our argument that every layer of review makes a team slower — the friction is invisible until someone has to push something through it.

The recommendation

So: sandbox sim or adversarial sim? Play both, but build — if you build anything — the adversarial one. The sandbox genre is mature, well-served by commercial titles, and its lessons (density, networks, externalities) are already in the culture. The adversarial genre is where the unexplored design space and the real explanatory value live. If you're a developer looking for a side project with teeth, model the process layer of something you know intimately: your city's permitting pipeline, your company's procurement gauntlet, the visa system. Use queues, thresholds with hysteresis, and carry costs; make delay the antagonist; let the outcomes emerge instead of scripting them. Keep the numbers tunable so skeptics can test their own assumptions. You'll learn more about the system from building its toy version than from years of arguing about it — and everyone who plays your version will too. That's the real trick this little game pulls off: it takes a debate that usually generates heat and turns it into a machine you can poke. More of our arguments deserve to be machines.