NIMBY-Städte simulieren: Adversarial vs. Sandbox-Sims

Jemand hat einen City-Builder gebaut, in dem man einen Wohnungsentwickler in San Francisco spielt und die Stadt selbst der Endgegner ist. Man will Wohnungen bauen, doch Bebauungsplan, Planungskommission, Nachbarn und das Einspruchsverfahren versuchen, es zu verhindern. Ein Spieler meldete 4.147 gebaute Wohnungen über sechzehn simulierte Jahre. Er überstand 16 Anhörungen, 3 Widersprüche und 4 Klagen und verdiente sich damit die Note „Builder of Some Things“, während die Stadt über 82.000 gebraucht hätte. Als politische Satire ist das sehr witzig. Als Simulationsdesign ist es wirklich interessant, denn es dreht die Annahme um, die jedem City-Builder seit SimCity zugrunde liegt: dass der Spieler ein allmächtiger Bürgermeister ist und die Simulation dazu da ist, optimiert zu werden. Hier ist die Simulation der Gegner.

Das Modell des allmächtigen Bürgermeisters: SimCity und seine Nachfolger

Klassische City-Builder sind Sandbox-Sims. Man zoniert, besteuert, legt Straßen an, und die kleinen simulierten Bürger reagieren auf die Entscheidungen. Das Interessante: Das Modell im Hintergrund ist über vierzig Jahre des Genres erstaunlich konstant. Grundstückswerte, Verschmutzung, Verkehrsfluss und Versorgungsabdeckung sind Felder über einem Raster, und Agenten (die Sims) treffen einfache Entscheidungen auf Basis dieser Felder. Cities: Skylines II, das aktuelle Schwergewicht, simuliert einzelne Haushalte mit Lebenszyklen, Arbeitsplätzen und Pendelwegen, aber sie reichen dir nie eine Klage ein. Das können sie nicht. Ihre Rolle im System ist es, betroffen zu sein, nicht zu handeln.

Diese Designentscheidung kodiert unauffällig eine politische Philosophie. In SimCity baust du eine Straße durch ein Viertel, wenn du willst, und dann ist sie da. Die Bewohner dieses Viertels sind höchstens als kleine Delle in einer Zufriedenheitsanzeige repräsentiert. Die Rückkopplungsschleifen belohnen Durchsatz: mehr Zonen, mehr Bevölkerung, mehr Steuereinnahmen. Wer diese Spiele hundert Stunden gespielt hat, hat ein Weltbild verinnerlicht, in dem das Hindernis für gute Stadtplanung die eigene fehlende Weitsicht des Spielers ist. Genau dieses Weltbild ist aber das, worum sich echte stadtpolitische Auseinandersetzungen drehen. Das Spiel bringt dir bei, wie Robert Moses zu denken, und dann erinnern dich echte Städte daran, dass gerade Robert Moses der Grund ist, warum wir die Regeln haben, die wir heute haben.

Ich will das Genre nicht schlechtmachen. Sandbox-Sims sind hervorragend in dem, wofür sie gemacht sind: Sie vermitteln ein Gefühl für Systeme, für Infrastruktur, Flächennutzung und die Nebenwirkungen von Zonierung. Industrie neben Wohnbebauung drückt die Grundstückswerte. Verkehrsstaus entstehen aus der Straßenhierarchie, nicht aus der Straßenbreite. Diese Lehren sind echt. Aber das Sandbox-Modell hat einen blinden Fleck von der Größe eines Planungsamts: Es behandelt Reibung durch Governance als Rauschen statt als Teil des Systems.

Das adversariale Modell: die Stadt als Gegenspieler

Das NIMBY-Städtebauspiel dreht das um. Du bist Entwickler mit Kapital, Zeit und der Geduld deiner Investoren als Ressourcen. Der Gegenspieler ist eine prozedurale Bürokratie: Ermessensprüfungen in Anhörungen, Umweltprüfungen, Nachbarschaftswidersprüche und die allgegenwärtige Drohung mit Klagen. Dein Job ist nicht, das Glück einer Stadt zu maximieren, sondern Wohneinheiten genehmigen und bauen zu lassen, bevor dir das Geld ausgeht oder die Investoren das Vertrauen verlieren. Jede Genehmigungshürde ist ein Würfelwurf, gewichtet nach dem politischen Charakter des Bezirks, in dem du baust.

Mechanisch ist das eher ein Roguelike als ein City-Builder. Du hast einen Durchlauf, und er endet, wenn Kapital oder Geduld aufgebraucht sind. Der prozedurale Inhalt ist kein Gelände, sondern Prozess. Und genau das ist die Erkenntnis, die man übernehmen sollte: Bürokratie ist ein lesbares, mechanisierbares System. Anhörungen haben Warteschlangen. Widersprüche haben Timer. Jede Hürde hat einen Durchsatz und eine Fehlerquote. Wenn man blinzelt, sieht ein Genehmigungsprozess genau so aus wie eine Anfrage, die durch eine Reihe überlasteter Dienste wandert, mit Retries, Backpressure und dem gelegentlich verlorenen Paket, das dich elf Monate kostet. Jeder Backend-Entwickler, der das liest, hat dieses System bei der Arbeit schon gebaut, nur mit besseren Absichten.

Es gibt einen Factorio-Mod, über den die Leute scherzen, der Papierkram-Verarbeitung als Rezeptbaum einbaut. Assembler stehen still, wenn du den bürokratischen Rückstau nicht abarbeitest, und die Biter stellen sich an, um dir Beschwerdeformulare zu überreichen. Der Witz trifft, weil er kaum einer ist. Der Grund, warum sich adversariale Prozess-Sims so anders spielen, ist, dass sie Warten zum zentralen Ressourcenproblem machen. In Sandbox-Sims ist Zeit meist kostenlos, du spulst vor. In einer adversarialen Simulation ist Zeit das, was der Gegenspieler dir abnehmen will, denn Verzögerung ist das verlässlichste Tötungswerkzeug eines Vetopunkts. Das ist keine Spielabstraktion. Das ist schlicht, wie Wohnungspolitik funktioniert: Man besiegt ein Projekt selten direkt, man lässt es nur so lange warten, bis es stirbt.

Was jedes Modell tatsächlich abbildet

Hier der ehrliche Vergleich. Keines der beiden Modelle ist „die Wahrheit“ über Städte. Jedes erfasst eine andere kausale Ebene, und sie scheitern in entgegengesetzte Richtungen.

• Sandbox-Sims bilden physische Systeme gut ab. Verkehr, Verschmutzung, Grundstückswerte, Versorgungsabdeckung, Netzwerkeffekte von Dichte. Dies sind kontinuierliche Felder und Flüsse, und agentenbasierte Modelle auf einem Raster reproduzieren tatsächlich emergente Phänomene wie Verkehrskollaps und Gentrifizierungsdruck.
• Sandbox-Sims bilden politische Systeme miserabel ab. Opposition auf eine Zufriedenheitszahl zu reduzieren ist kein Machtmodell. Es kann nicht ausdrücken, dass eine kleine, organisierte, langjährig ansässige Minderheit eine diffuse, beschäftigte Mehrheit dominieren kann, und genau das ist die wichtigste Tatsache in der lokalen Bodenpolitik.
• Adversariale Sims bilden Vetopunkte gut ab. Ermessensprüfungen, Widersprüche, Klagerisiko und Verzögerung als Waffe sind diskret, zustandsbehaftet und manipulierbar, also ideal für Mechaniken. Das Spiel gibt das empirische Ergebnis korrekt wieder: Wenn jedes Projekt eine Verhandlung ist, überleben nur große Entwickler mit Anwälten. Das Ergebnis sind weniger Wohnungen, dafür in größeren Projekten.
• Adversariale Sims bilden physische Systeme miserabel ab. Sobald du deine Einheiten gebaut hast, kümmert sich die Simulation nicht darum, ob das Viertel tatsächlich funktioniert. Verkehr, Schulen, Kanalisation werden abstrahiert oder ignoriert. Du kannst das Spiel gewinnen und trotzdem etwas Dysfunktionales gebaut haben.
• Beide scheitern am Kontrafaktischen. Keines kann dir die Stadt zeigen, die unter anderen Regeln existieren würde, und genau darüber streiten Politikerinnen und Politiker eigentlich.

Der letzte Punkt verdient Betonung, denn hier hört der Vergleich auf, nur von Spielen zu handeln. Wer über Aufzonungsregeln streitet, etwa über die jüngste Welle landesweiter Vorrangregelungen in Kalifornien, die lokale Ermessensspielräume rund um den Nahverkehr einschränken, streitet über eine kontrafaktische Simulation. Beide Seiten fahren ein mentales Modell. Die eine Seite stellt sich eine Stadt vor, in der das Entfernen der Vetopunkte das Angebot entfesselt; die andere eine Stadt, in der das Entfernen den Charakter der Nachbarschaft zerstört, ohne die Preise zu senken. Ein Spiel, das die Vetopunkt-Ebene spielbar macht, ist ein echter Beitrag zu dieser Debatte, weil es dich zwingt, sich mit dem Mechanismus statt mit dem Bauchgefühl auseinanderzusetzen. Wenn ein Spieler einen Durchlauf mit 4.000 von 82.000 benötigten Wohnungen beendet, lautet die Lehre nicht „Entwickler sind gierig“ oder „Nachbarn sind egoistisch“, sondern: Durchsatz ist eine Eigenschaft des Prozesses, nicht der Absichten irgendjemandes.

Die Technik hinter der Modellierung von Widerstand

Aus Sicht der Simulationstechnik ist das adversariale Modell interessant, weil Opposition heterogene Handlungsfähigkeit ist. Die Nachbarn sind kein Feld, sondern Akteure mit Gedächtnis, Relevanz und asymmetrischen Motiven. Sie gut zu modellieren heißt, sich bei einem anderen Teil des KI-Werkzeugkastens zu bedienen als üblicherweise bei City-Buildern. Ein paar Muster tauchen immer wieder auf:

• Aktivierungsschwellen mit Hysterese. Die meisten Anwohner beschäftigen sich nie mit einem Bauantrag. Opposition aktiviert sich, wenn die wahrgenommene Auswirkung eine Schwelle überschreitet. Und einmal aktiviert, deaktiviert sie sich nicht, wenn sich die Bedingungen verbessern. Diese Asymmetrie ist leicht zu modellieren und leistet den Großteil der Arbeit bei der Nachbildung realer Dynamiken.
• Warteschlangenbasierte Prozessschranken. Jede Prüfstufe ist eine Warteschlange mit einer Bearbeitungsrate. Verzögerung entsteht aus Last, nicht aus Bosheit, was sowohl lebensnah ist als auch die Quelle der zentralen Spannung des Spiels. Man kann eine ganze Planungsabteilung als eine Handvoll M/M/1-Warteschlangen modellieren und bekommt ein Verhalten, das unheimlich akkurat wirkt.
• Verzögerung als Schaden über Zeit. Haltekosten fallen monatlich an. Diese eine Mechanik macht prozedurale Verzögerung für den Spieler sichtbar und erzeugt die richtige strategische Anpassung: Entwickler zahlen zu viel für Grundstücke mit Baurecht und meiden Bezirke mit Ermessensprüfung ganz.
• Zufallsschocks mit Gedächtnis. Eine Klage kostet nicht nur Geld, sondern verändert den politischen Zustand des Bezirks. Ein dauerhafter Bezirkszustand macht aus einmaligen Ereignissen Pfadabhängigkeit.

Eine minimale Skizze der Kernschleife könnte so aussehen:

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

Das sind vierzig Zeilen, und sie reproduzieren bereits die typischen Ergebnisse des Genres: Bezirke mit hoher Opposition bekommen nichts gebaut, unabhängig von der Nachfrage. Entwickler sammeln sich in Bezirken mit geringer Reibung, und die Zeit bis zur Genehmigung dominiert die Projektwirtschaft. Die Lücke zwischen einer Spezifikation und ihrem emergenten Verhalten ist genau die Art von Problem, die wir in der Lücke zwischen Spezifikation und Implementierung untersucht haben. Niemand schreibt „erzeuge eine Wohnungsknappheit“ in die Bebauungsordnung, aber die Knappheit fällt trotzdem aus den Regeln heraus.

Emergentes Verhalten vs. programmierte Schwierigkeit

Eine Designentscheidung ist hier besonders wichtig: Programmierst du die Opposition fest, oder lässt du sie entstehen? Programmierte Schwierigkeit, bei der die Stadt mit jedem Level einfach willkürlich obstruktiver wird, ist leichter auszubalancieren, lehrt aber die falsche Lektion. Sie sagt den Spielern, das System sei absichtlich manipuliert. Emergente Opposition, aufgebaut aus Warteschlangen, Schwellen und Haltekosten, vermittelt etwas, das der Wahrheit näher kommt und viel unbequemer ist: Das System erzeugt diese Ergebnisse, obwohl sich jeder einzelne Akteur vernünftig verhält. Die Planerin mit einem neunmonatigen Rückstau ist nicht bösartig, sie ist unterbesetzt. Der Nachbar, der dein Projekt anficht, ist kein Karikatur-NIMBY. Er hat ein Haus, das sein ganzes Nettovermögen ist, und das Spiel gibt ihm einen Hebel, also zieht er daran. Wie wir in unserem Beitrag zum defensiven Engineering argumentiert haben, bekommen Systeme das Verhalten, das ihre Anreize zulassen, nicht das, das ihre Designer sich erhofft haben.

Emergenz macht das Spiel auch für die Gegenseite lesbar. Ein YIMBY, der dieses Spiel spielt, lernt am eigenen Leib, warum Prozessreform wichtiger ist als jedes einzelne Projekt. Ein Denkmalschützer, der es spielt, lernt, dass Vetopunkte nicht selektiv schlechte Projekte blockieren. Sie blockieren alles mit einem ausreichend langen Zeitplan, und das ist wahllos. Das lässt sich in einem Meinungsartikel viel schwerer vermitteln als in einem Spiel mit Durchläufen, in dem man zusieht, wie die Haltekosten in Runde vierzig ausbluten.

Verzögerung ist das verlässlichste Tötungswerkzeug eines Vetopunkts. Man besiegt ein Projekt selten direkt; man lässt es warten, bis es stirbt.

Ernsthafte Spiele vs. Satire: Wann welches gewinnt

Der Vergleich, den das Genre uns eigentlich aufzwingt, ist nicht Sandbox gegen adversarial, sondern Satire gegen ernsthafte Modellierung. Das NIMBY-Spiel ist Satire: Die Parameter sind auf Komik und Verzweiflung abgestimmt, nicht auf empirische Genehmigungszeiten kalibriert. Eine ernsthafte Version, eine die sich ein Stadtrat einmal als Übungswerkzeug gewünscht hat, würde Durchsatz der Schranken, Widerspruchswahrscheinlichkeiten und Haltekosten an echten Genehmigungsdaten kalibrieren. Einige Planungsämter und Forschende betreiben partizipative Simulationen und ernsthafte Spiele genau für diesen Zweck, meist allerdings mit PowerPoint-Produktionswerten.

Satire gewinnt, wenn es um Aufmerksamkeit und Intuition geht. Niemand teilt ein kalibriertes Planungsmodell in sozialen Netzwerken. Ein Browserspiel, in dem San Francisco dich mit Bürokratie erdrückt, wird dagegen gerade deshalb geteilt, weil die Übertreibung das Argument trägt. Satire hat zudem eine niedrige Hürde bei der Korrektheit, denn sie behauptet eine Richtung, keine Größenordnung. Doch Satire verliert, sobald die Frage lautet: „Was sollten wir ändern?“ Dafür braucht man die langweilige Version: parametrisierte Regeln, die man umschalten kann. Entferne im Modell die Ermessensprüfung und beobachte den Durchsatz. Verdopple die Planungsstellen und sieh zu, wie der Rückstau abfließt. Diese Schleife aus Umschalten und Beobachten ist der Punkt, an dem ein Spiel aufhört, Kommentar zu sein, und zu einem politischen Steuerungsinstrument wird. Die stärkste Version dieses Genres würde beide Modi ausliefern und den Spieler zwischen ihnen wechseln lassen: erst die Verzweiflung spüren, dann die Maschine reparieren.

Warum Spiele besser argumentieren als Meinungsartikel

Daraus folgt eine allgemeinere Lehre für alle, die erklärende Systeme bauen. Ein Meinungsartikel behauptet einen Mechanismus; ein spielbares Modell demonstriert ihn und lässt den Nutzer ihn widerlegen. Wenn dein mentales Modell von Wohnungspolitik „man sollte einfach mehr bauen“ lautet, verdrahtet eine halbe Stunde mit einer adversarialen Simulation es wirksamer um als jede Grafik über genehmigte Wohnungen pro Jahr. Das ist derselbe Grund, warum das Bauen einer Shell dir mehr über Unix beibringt als das Lesen der Man-Pages: Ein System zu betreiben, selbst ein Spielzeugsystem, zwingt die Abstraktionen dazu, konkret zu werden. Die Kommentare auf Hacker News zu diesem Spiel sind aufschlussreich. Die Leute schlugen sofort Versionen für ihre eigenen Städte vor, für Hochgeschwindigkeitsstrecken mit ihren verpflichtenden Wildtierausgleichsmaßnahmen, für Rechenzentren. Das Muster verallgemeinert sich, weil Vetopunkt-Architektur sich verallgemeinert. Überall dort, wo es sequenzielle Genehmigungsschranken, asymmetrische Motive und Verzögerung als Kosten gibt, hast du dieses Spiel.

Ich würde noch weiter gehen: Das adversariale Sim-Genre ist insgesamt ein unterschätztes Mittel für Engineering-Kommunikation. Stell dir vor, du bringst Engineers den Change-Management-Prozess deiner Organisation bei, indem sie ihn durchspielen. Ein Change wird ausgerollt, und du siehst zu, wie er hinter dem CAB-Review, der Security-Freigabe und einem eingefrorenen Release-Fenster in der Warteschlange hängt. Deine Begeisterung wandelt sich in das Verständnis, warum Leute zu Schatten-IT greifen. Wenn das vertraut klingt, steckt dahinter derselbe Impuls wie in unserem Argument, dass jede Review-Schicht ein Team langsamer macht. Die Reibung ist unsichtbar, bis jemand etwas durch sie hindurchdrücken muss.

Die Empfehlung

Also: Sandbox-Sim oder adversariale Sim? Spiel beide, aber bau, falls du überhaupt etwas baust, die adversariale. Das Sandbox-Genre ist ausgereift, gut von kommerziellen Titeln bedient, und seine Lehren (Dichte, Netzwerke, Externalitäten) stecken bereits in der Kultur. Das adversariale Genre ist dort, wo der unerforschte Designraum und der echte Erklärwert liegen. Wenn du als Entwickler ein Side-Projekt mit Biss suchst, modelliere die Prozessebene von etwas, das du in- und auswendig kennst: die Genehmigungspipeline deiner Stadt, das Beschaffungsspießrutenlaufen in deiner Firma, das Visasystem. Verwende Warteschlangen, Schwellen mit Hysterese und Haltekosten, mach Verzögerung zum Antagonisten und lass die Ergebnisse entstehen, statt sie zu skripten. Halte die Zahlen abstimmbar, damit Skeptiker ihre eigenen Annahmen testen können. Du lernst mehr über das System, wenn du seine Spielzeugversion baust, als in Jahren des Streitens darüber, und jeder, der deine Version spielt, auch. Das ist der eigentliche Trick dieses kleinen Spiels: Es nimmt eine Debatte, die meist nur Hitze erzeugt, und macht sie zu einer Maschine, an der man herumstochern kann. Mehr unserer Argumente verdienen es, Maschinen zu werden.