Adversarial vs Sandbox: моделируем NIMBY в городах
Градостроительный симулятор, где город сопротивляется, превращает NIMBY в игровую механику. Сравниваем adversarial и sandbox симуляторы: что каждый моделирует лучше и когда какой выбирать.
Elena Vasquez
Кто-то сделал градостроительную игру, где вы играете застройщиком жилья в Сан-Франциско, а сам город становится финальным боссом. Вы пытаетесь построить квартиры, а зонирование, городская комиссия по планированию, соседи и процедура апелляций пытаются вам помешать. Один игрок рассказывал, что за шестнадцать симулированных лет построил 4 147 домов, пережил 16 слушаний, 3 апелляции и 4 судебных иска и получил звание «Строитель кое-чего», при этом городу нужно было более 82 000. Как политическая сатира это очень смешно. Как дизайн симуляции это по-настоящему интересно, потому что игра переворачивает допущение, заложенное в каждом градостроительном симуляторе со времён SimCity: игрок — всемогущий мэр, а симуляция существует для того, чтобы её оптимизировать. Здесь симуляция — ваш противник.
Модель всемогущего мэра: SimCity и его наследники
Классические градостроительные игры — это sandbox-симуляторы. Вы зонируете, вводите налоги, прокладываете дороги, а маленькие симулированные жители реагируют на ваши решения. Интересно то, что модель под капотом удивительно стабильна на протяжении сорока лет жанра: стоимость земли, загрязнение, потоки транспорта и покрытие сервисами — это поля над сеткой, а агенты (симы) принимают простые решения на основе этих полей. Cities: Skylines II, нынешний тяжеловес, моделирует отдельные домохозяйства с жизненными циклами, рабочими местами и поездками на работу, но они никогда не подадут на вас в суд. Не могут. Их роль в системе — быть затронутыми, а не действовать.
Этот дизайнерский выбор незаметно кодирует политическую философию. В SimCity, если вы хотите провести шоссе через жилой квартал, вы его просто строите. Жители этого квартала представлены в лучшем случае провалом на шкале счастья. Обратная связь в игре вознаграждает пропускную способность: больше зон, больше населения, больше налоговая база. Тот, кто провёл за этими играми сотню часов, усвоил картину мира, в которой препятствие для хорошего урбанизма — это собственная недальновидность игрока. Именно эту картину мира и оспаривают реальные споры о городской политике. Игра учит думать как Роберт Мозес, а реальные города напоминают, что из-за Роберта Мозеса у нас есть те правила, которые у нас есть.
Я не критикую жанр. Sandbox-симуляторы отлично справляются с тем, для чего созданы: они развивают у игроков системное чутьё в отношении инфраструктуры, землепользования и эффектов второго порядка от зонирования. Промышленная зона рядом с жилой снижает стоимость земли. Пробки возникают из иерархии дорог, а не из ширины дороги. Эти уроки реальны. Но у sandbox-модели есть слепое пятно размером с целый отдел планирования: она считает трение в управлении шумом, а не частью системы.
Adversarial-модель: город как противник
NIMBY-градостроительная игра переворачивает эту логику. Вы застройщик, ваши ресурсы — капитал, время и терпение инвесторов. Противник — процедурная бюрократия: слушания по дискреционному обзору, экологическая экспертиза, соседские апелляции и постоянная угроза судебных исков. Ваша задача — не максимизировать счастье горожан, а получить разрешения и построить жильё, пока не закончатся деньги или инвесторы не потеряют веру. Каждый этап согласования — это бросок кубика, взвешенный по политическому характеру района, в котором вы строите.
Механически это ближе к роглайку, чем к градостроительному симулятору. У вас есть забег. Он заканчивается, когда иссякают капитал или терпение. Процедурный контент здесь не рельеф, а процесс. И это инсайт, который стоит позаимствовать: бюрократия — это читаемая, поддающаяся моделированию система. У слушаний есть очереди. У апелляций есть таймеры. У каждого шлюза есть пропускная способность и доля отказов. Если прищуриться, конвейер согласований выглядит в точности как запрос, проходящий через набор перегруженных сервисов с повторными попытками, обратным давлением и время от времени потерянным пакетом, который стоит вам одиннадцати месяцев. Любой бэкенд-инженер, читающий это, уже построил такую систему на работе, только с лучшими намерениями.
Для Factorio есть мод, над которым люди шутят: он добавляет обработку бумаг как дерево рецептов. Сборщики останавливаются, если не разобрать бюрократический backlog, а биters выстраиваются в очередь, чтобы вручить вам жалобы. Шутка работает потому, что она почти не шутка. Причина, по которой adversarial симуляторы ощущаются так иначе, в том, что они делают ожидание главной ресурсной проблемой. В sandbox-симуляторах время в основном бесплатное: вы перематываете. В adversarial-симуляторе время — это то, что противник пытается у вас отнять, потому что задержка — самый надёжный механизм уничтожения, которым располагает точка вето. Это не игровая абстракция. Так буквально и работает жилищная политика: проект редко проваливают напрямую, его просто заставляют ждать, пока он не умрёт.
Что на самом деле отражает каждая модель
Вот честное сравнение. Ни одна модель не является «истиной» о городах: каждая отражает свой causal-слой, и обе ошибаются в противоположных направлениях.
- Sandbox-симуляторы хорошо отражают физические системы. Транспорт, загрязнение, стоимость земли, покрытие сервисами, сетевые эффекты плотности. Это непрерывные поля и потоки, и агентные модели на сетке действительно воспроизводят эмерджентные явления, такие как коллапс транспортной сети и давление джентрификации.
- Sandbox-симуляторы ужасно отражают политические системы. Сведение оппозиции к числу на шкале счастья — это не модель власти. Оно не может выразить, что небольшое, организованное, давно живущее на месте меньшинство способно доминировать над рассредоточенным, занятым большинством, а это важнейший факт местной политики землепользования.
- Adversarial-симуляторы хорошо отражают точки вето. Дискреционный обзор, апелляции, риск судебных исков и задержка как оружие дискретны, имеют состояние и поддаются игровой механике. Игра корректно воспроизводит эмпирический результат: когда каждый проект превращается в переговоры, выживают только крупные застройщики с юристами, поэтому жилья строится меньше, а проекты становятся крупнее.
- Adversarial-симуляторы ужасно отражают физические системы. Построив свои квартиры, вы больше не интересуетесь тем, работает ли район на самом деле. Транспорт, школы, канализация — всё абстрагировано или проигнорировано. Можно выиграть игру и построить нечто дисфункциональное.
- Обе модели не справляются с контрфактуальными сценариями. Ни одна не покажет, каким мог бы быть город при других правилах, а именно этот вопрос и обсуждают люди, занимающиеся политикой.
Последний пункт заслуживает особого внимания, потому что здесь сравнение перестаёт быть про игры. Люди, которые спорят о законах об upzoning, например о волне законопроектов штатов Калифорнии, отменяющих местные полномочия вблизи транспортных узлов, по сути спорят о контрфактуальной симуляции. Обе стороны держат в голове свою модель: одна представляет город, где снятие точек вето высвобождает предложение; другая — город, где их снятие разрушает характер района и при этом не снижает цены. Игра, которая делает слой точек вето играбельным, — по-настоящему полезный вклад в этот спор, потому что заставляет разбираться в механизме, а не в ощущениях. Когда игрок завершает забег, построив 4 000 из 82 000 нужных домов, вывод не в том, что «застройщики жадные» или «соседи эгоистичные», а в том, что пропускная способность — это свойство процесса, а не чьих-либо намерений.
Инженерия моделирования оппозиции
С точки зрения инженерии симуляций adversarial-модель интересна тем, что оппозиция — это гетерогенная агентность. Соседи — не поле, а акторы с памятью, заметностью и асимметричной мотивацией. Чтобы моделировать их хорошо, нужно заимствовать паттерны из другой части инструментария ИИ, чем обычно используют градостроители. Вот несколько паттернов, которые здесь работают:
- Пороги активации с гистерезисом. Большинство жителей никогда не вникает в заявку на разрешение. Оппозиция активируется, когда воспринимаемое воздействие пересекает порог, и, однажды активировавшись, не деактивируется, даже когда условия улучшаются. Эту асимметрию легко смоделировать, и она делает большую часть работы по воспроизведению реальной динамики.
- Шлюзы процесса на основе очередей. Каждый этап проверки — это очередь с заданной скоростью обработки. Задержка возникает из нагрузки, а не из злого умысла, что одновременно правдоподобно и является источником центрального напряжения игры. Весь отдел планирования можно смоделировать несколькими очередями
M/M/1, и поведение получится пугающе точным. - Задержка как урон со временем. Затраты на содержание начисляются ежемесячно. Этот единственный механизм превращает процедурную задержку в видимое для игрока давление и порождает правильную стратегическую адаптацию: застройщики переплачивают за участки с правом на строительство и вовсе избегают районов с дискреционным обзором.
- Случайные шоки с памятью. Судебный иск не просто стоит денег; он меняет политическое состояние района. Устойчивое состояние района превращает разовые события в зависимость от пути.
Вот минимальный набросок основного цикла:
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Это сорок строк, и они уже воспроизводят характерные результаты жанра: районы с сильной оппозицией не застраиваются независимо от спроса, застройщики скапливаются в районах с низким трением, а время до получения разрешения определяет экономику проекта. Разрыв между спецификацией и эмерджентным поведением — ровно тот тип вещей, который мы разбирали в статье про разрыв между спецификацией и реализацией: никто не пишет «создать жилищный дефицит» в правилах зонирования, но дефицит всё равно возникает из этих правил.
Эмерджентное поведение против скриптованной сложности
Здесь важна одна развилка в дизайне: сценировать ли оппозицию или дать ей возникать самой. Скриптованная сложность, когда город с каждым уровнем становится произвольно более обструктивным, легче балансируется, но учит неправильному. Она говорит игроку, что система подстроена намеренно. Эмерджентная оппозиция, построенная на очередях, порогах и затратах на содержание, учит чему-то ближе к правде и гораздо более неприятному: система порождает эти результаты, даже когда каждый отдельный актор ведёт себя разумно. Планировщица с девятимесячным backlog не злодейка, а просто недоукомплектована штатом. Сосед, который подаёт апелляцию на ваш проект, не карикатурный NIMBY: у него один дом, это всё его состояние, и игра даёт ему рычаг, поэтому он за него и дёргает. Как мы писали в статье про оборонное проектирование, системы получают то поведение, которое допускают их стимулы, а не то, на которое надеялись их проектировщики.
Эмерджентность также делает игру понятной и для другой стороны спора. YIMBY, играющий в неё, на собственном опыте понимает, почему реформа процесса важнее любого отдельного проекта. Защитник исторического облика, играя, понимает, что точки вето не выборочно блокируют плохие проекты, а блокируют всё, у чего достаточно долгий срок, то есть действуют без разбора. Это гораздо сложнее донести в колонке, чем в забеге, где вы смотрите, как затраты на содержание вытекают на сороковом ходу.
Задержка — самый надёжный механизм уничтожения, которым располагает точка вето. Проект редко проваливают напрямую: его заставляют ждать, пока он не умрёт.
Серьёзные игры против сатиры: когда что побеждает
Сравнение, к которому жанр на самом деле нас подводит, — не sandbox против adversarial, а сатира против серьёзного моделирования. NIMBY-игра — это сатира: параметры настроены под комедию и отчаяние, а не откалиброваны по эмпирическим срокам получения разрешений. Серьёзная версия, о которой один член городского совета однажды сказал, что хотел бы иметь её как инструмент для практики, калибровала бы пропускную способность шлюзов, вероятности апелляций и затраты на содержание по реальным данным о разрешениях. Некоторые отделы планирования и исследователи действительно запускают партисипативные симуляции и серьёзные игры именно для этого, хотя обычно с качеством продакшена уровня презентации в PowerPoint.
Сатира побеждает, когда цель — внимание и интуиция. Никто не делится откалиброванной моделью планирования в соцсетях, а браузерная игра, в которой Сан-Франциско закапывает вас в бюрократии, расходится именно потому, что преувеличение несёт аргумент. У сатиры также низкая планка корректности: она утверждает направление, а не величину. Но сатира проигрывает, когда вопрос звучит как «что нам стоит поменять?». Для этого нужна скучная версия: параметризованные правила, которые можно переключать. Уберите дискреционный обзор в модели и посмотрите на пропускную способность. Удвойте штат планировщиков и посмотрите, как backlog рассасывается. Этот цикл «переключил и наблюдай» и есть то место, где игра перестаёт быть комментарием и становится инструментом политики. Самая сильная версия этого жанра выпустила бы оба режима и позволила игроку переключаться между ними: сначала прочувствовать отчаяние, а потом починить машину.
Почему игры аргументируют лучше колонок
Здесь есть более широкий урок для всех, кто строит объясняющие системы. Колонка утверждает механизм, а играбельная модель демонстрирует его и позволяет пользователю его опровергнуть. Если ваша ментальная модель жилищной политики — это «кто-то просто должен построить побольше», полчаса с adversarial-симулятором перестроят её эффективнее, чем любое количество графиков о числе выданных разрешений в год. Это та же причина, по которой написание своей оболочки учит вас Unix больше, чем чтение man-страниц: работа с системой, даже игрушечной, заставляет абстракции стать конкретными. Комментарии на Hacker News к этой игре показательны: люди сразу начали предлагать версии для своих городов, для высокоскоростной железной дороги с обязательными мерами по защите дикой природы, для дата-центров. Паттерн обобщается, потому что архитектура точек вето обобщается. Везде, где есть последовательные шлюзы согласования, асимметричная мотивация и задержка как издержка, есть эта игра.
Я бы пошёл дальше: adversarial-симулятор — недооценённый жанр для инженерных коммуникаций вообще. Представьте, что вы вводите инженеров в процесс управления изменениями вашей организации, заставляя их в него поиграть. Выкатите изменение и посмотрите, как оно стоит в очереди за ревью CAB, согласованием безопасности и окном заморозки релизов; почувствуйте, как ваш энтузиазм превращается в понимание, почему люди тянутся к shadow IT. Если это звучит знакомо, это тот же инстинкт, что стоит за нашим аргументом о том, что каждый уровень ревью замедляет команду: трение незаметно, пока кому-то не придётся протолкнуть через него что-то.
Рекомендация
Итак: sandbox-симулятор или adversarial? Играйте в оба, но если что-то создавать, то adversarial. Sandbox-жанр зрелый, хорошо обслуживается коммерческими проектами, а его уроки (плотность, сети, экстерналии) уже есть в культуре. Adversarial-жанр — там, где лежит неисследованное пространство дизайна и реальная объясняющая ценность. Если вы разработчик, ищущий побочный проект с характером, смоделируйте процессный слой того, что знаете досконально: конвейер выдачи разрешений в вашем городе, закупочную процедуру в вашей компании, визовую систему. Используйте очереди, пороги с гистерезисом и затраты на содержание; сделайте задержку антагонистом; дайте исходам возникать, а не скриптуйте их. Держите числа настраиваемыми, чтобы скептики могли проверить собственные допущения. Вы узнаете о системе больше, построив её игрушечную версию, чем за годы споров о ней, и каждый, кто поиграет в вашу версию, тоже. В этом и состоит настоящий трюк этой небольшой игры: она берёт дебаты, которые обычно порождают жар, и превращает их в машину, в которую можно тыкать палкой. Наши аргументы тоже заслуживают того, чтобы стать машинами.
