«Продай мне этот космолёт» или история любви к симуляторам. От космосима X-Tension до ActorModel/DoD/ECS архитектуры. Ч3

«Лучший способ предсказать будущее - изобрести его.» - Алан Кэй

Это третья и финальная часть истории. По исходному плану их должно было быть две, потом я честно обещал уложиться в три после второй, и вот мы здесь. Будем считать это уроком: при оценке объёма любого личного проекта смело умножайте свою оценку на полтора, как учит классика. Спасибо тем, кто дочитал до этого момента, и отдельное уважение тем, кто пришёл сюда с первой части без перерывов.

Если совсем коротко напомнить, где мы остановились во второй части, то картинка такая. Гибридная архитектура из трёх слоёв: ECS-миры снизу как операционный движок для большого количества однотипных сущностей, акторы-менеджеры посередине как тактический уровень, и более тяжёлые акторы или сервисы наверху как стратегический мозг. Сбоку реактивная среда, которая подбрасывает события. Под всем этим слой данных на DuckDB. Технологически: Bevy ECS на Rust для движка, лёгкая акторная абстракция поверх, egui для дев-интерфейса, WASM для демонстраций в браузере, Godot 4 опционально как 3D-витрина. Этот расклад мне показался наиболее интересным, и в этой части я попытаюсь показать, к чему он прикладывается на практике. Однако остаётся вопрос, как соблюсти баланс между Rust и C#. Один даёт отсутствие garbage collector, лёгкий WASM и игровой движок Bevy, другой более развитый фреймворк actor model - Akka.NET ну и ряд других не указанных за и против.

В самом конце второй части я нарисовал шкалу от аркадных стратегий слева до инженерных тренажёров справа. От Civilization, Anno и Tropico слева, через RollerCoaster Tycoon, Kerbal Space Program, Factorio посередине, к AnyLogic-модели цехов и тренажёра пилотов справа. Гибридная архитектура любопытна именно тем, что теоретически применима ко всей шкале. Меняется глубина проработки, точность данных, степень валидации экспертами. Ядро же остаётся тем же ну или как минимум появляется возможность конфигурировать его без глобального переписывания.

Структура третьей части такова: сначала прикладные кейсы разного уровня амбициозности, от MVP за несколько недель (для эксперта разработчика) до видения автономного производства будущего, потом игровые примеры, в которых архитектура должна хорошо ложиться. Затем отдельная глава про то, что делает любой симулятор живым, а именно про реактивную среду и идею AI Director из мира игр. И в финале попытка собрать итоговую схему и рассказать с чего планирую начинать сам.

Глава 1. Прикладные кейсы

Кейс 1. MVP сортировочного центра с робо-стеллажами

Самая простая точка входа (относительно других), с которой стоит начинать. Представим современный сортировочный склад, где не люди ходят между стеллажами с тележками, а наоборот, стеллажи подъезжают к рабочим местам комплектации. Так устроены склады Amazon Kiva, частично у Wildberries и Ozon, частично у крупных постаматных операторов. Десятки или сотни роботов под стеллажами, диспетчер сверху, операторы на пикинг-станциях, поток заказов на входе.

С точки зрения архитектуры это чистый ECS, без всякого верхнего слоя. Один домен, ограниченное пространство, однотипные сущности. На Bevy получится так: робот это entity с компонентами Transform, Battery, Task, Status. Стеллаж это entity с компонентами Slot, Inventory, Position. Заказ это entity с компонентами Items, Deadline, AssignedStation. Системы прогоняют движение, разрешают конфликты на перекрёстках, считают батарею, формируют статистику. Стратегический мозг здесь не нужен, потому что вся «политика» помещается в простые правила и эвристики. Метрики тоже простые: throughput, утилизация роботов, средний time-to-pick, процент опозданий.

Визуализация Bevy + egui, компилируется в WASM, открывается по ссылке в браузере. Это важная фишка для MVP: никакого «подключитесь по zoom». Кликнул, и запустилась симуляция, с панелькой управления параметрами справа.

Что интересно, даже на этом простом кейсе быстро вылезают вопросы посерьёзнее, чем казалось на старте. Как моделировать заторы между роботами на узких проездах. Как учитывать износ батарей и время на зарядку. Как организовать смену уровней детализации, чтобы при зуме общая карта склада превращалась в подробную сцену на конкретном перекрёстке. И главное, как из всего этого сделать симулятор, а не просто красивую визуализацию, то есть как обеспечить детерминизм при перезапуске и валидировать поведение хотя бы по простым тестам. Как в конце концов убедить зрителей поверить, что на ECS это делать круто, а на всем остальном не очень.

Кейс 2. MVP городской логистики

Шаг посложнее. Тысячи курьеров на карте города, заказы появляются стохастически, пробки меняются в течение дня, кухни и магазины имеют разное время приготовления, клиенты обижаются на опоздания. Бизнес устроен как Яндекс.Еда, Delivery Club, Uber Eats. Внутри это задача распределения и маршрутизации в реальном времени.

ECS-доминирование тут сохраняется: курьеры, заказы, рестораны, клиенты, дорожный граф - всё это удобно ложится в таблицы компонентов. Но появляется потребность в чём-то умнее простых правил. Назначить заказ ближайшему курьеру это уже не FIFO. Это задача VRP (vehicle routing problem) с временными окнами, ограничениями по вместимости термосумки, прогнозами времени готовности у ресторанов. Тут на сцену выходит OR-Tools от Google, в котором есть готовый VRP-солвер и CP-SAT для constraint programming, ну либо придумывать более простые решения, которые бы при этом не выглядели бы слишком по-аркадному.

Архитектурно солвер ставится сбоку от ECS-цикла. Тактический актор-диспетчер раз в N секунд собирает текущее состояние, формирует задачу для солвера, получает план, передаёт его обратно в ECS-системы как новые компоненты Task. Геоданные обрабатываются через H3 (гексагональная сетка от Uber для зонирования) и визуализируются через deck.gl, если делать веб-версию.

И вот тут всплывает та самая боль из первой части про динамические перепланирования. Если перепланировать всё после каждого нового заказа, симуляция не выдержит и начнёт лагать. Если перепланировать редко, план устаревает и курьеры стоят. Появляется промежуточное решение: горячие изменения локально, полное перепланирование раз в несколько минут. И это уже архитектурная развилка, которая будет преследовать практически любой симулятор с оптимизацией внутри.

Кейс 3. Автономная фабрика будущего. Например мебельная

Это кейс из жанра «легенда о светлом завтра», но именно он показывает, где именно эта архитектура легла бы идеально. Представим: в чистом поле строится мебельная фабрика, на которой постоянно работают только десять айтишников (поддержка железа и софта) и десять экспертов-валидаторов в роли контроллеров адекватности работы всех систем (human-in-the-loop). Никаких операционных рабочих, никаких начальников цехов, никаких диспетчеров. Все производственные решения принимает программный комплекс.

Тут гибридная архитектура нужна целиком. Операционный слой это ECS-миры по цехам: раскрой ДСП, кромкооблицовка, сверловка, сборка, окраска, упаковка, отгрузка. Каждый цех это отдельный мир со своими сущностями (заготовки, инструменты, тележки, посты) и системами (движение по конвейерам, обработка, контроль качества). Между цехами потоки полуфабрикатов, в каждом много тиков симуляции, частота высокая.

Можно дополнительно выделить актора операционного уровня, но не как хранителя ECS-мира, а как индивидуальный мозг для сложного объекта из операционного уровня. Который запускается/подключается по требованию в особых случаях или переходе от централизованного управления к автономному.

Тактический слой это акторы-бригадиры. Каждый присматривает за своим цехом, держит метрики, реагирует на инциденты: оборудование встало, партия пошла с дефектом, нужно переналадить станок. Простые случаи бригадир обрабатывает по правилам, сложные эскалирует выше. Может вызывать и запускать инструменты вроде той же DuckDB или ONNX моделек in-process.

Стратегический слой это акторы-директора. Их немного, работают редко, но имеют доступ к большой картине: DuckDB с историей всех прогонов, ML-модели прогноза спроса, библиотека солверов, LLM-агенты для разбора аномалий и tool calling по внешним системам. Они меняют правила игры: переключают режимы цехов, перераспределяют ресурсы, принимают решение о расширении узких мест. Главное отличие от тактического, это возможность вызывать долгие по времени работы инструменты и не мешать своими действиями операционным и тактическим акторам.

Эксперты-валидаторы получают на проверку только аномалии и стратегические решения. Не операционную рутину. Их работа похожа на то, как сегодня устроены диспетчеры в авиации или операторы в больших дата-центрах: вмешиваются только тогда, когда система сама признаёт, что не уверена.

Тут же соединяются ERP/MES/WMS/TMS из первой части. Они никуда не исчезают. Просто из «главных героев» превращаются в источники или потребители данных и tool-calling инструменты для стратегических агентов или в экраны, на которых валидатор подтверждает финальное решение. Признаюсь честно, сходу сложно сказать кто именно должен работать под обёрткой акторов тактического или стратегического уровня и на каком этапе жизненного цикла существования: MARL агенты которые учатся управлять системой, простые или сложные локальные LLM или что-то из игр по типу: FSM, Behavior Trees, GOAP. Но направление видно достаточно ясно, чтобы под него уже сейчас закладывать архитектуру.

Кейс 4. Платформа-агрегатор для разных симуляций

В какой-то момент после третьего-четвёртого собранного симулятора может возникнуть вопрос: а почему мы каждый раз пишем всё с нуля? Если ядро одно и то же (ECS-движок, акторная абстракция, DuckDB как слой данных, реактивная среда, набор инструментов визуализации), то логичнее иметь платформу, а не отдельные продукты. Инженер описывает свой домен в каком-то DSL или конфиге, выбирает строительные блоки, и платформа собирает симулятор.

Похожая идея уже давно реализована в AnyLogic, Simio, FlexSim. Эти платформы зрелые и признанные, но у них есть ряд минусов: они дорогие (лицензии в десятки тысяч долларов), закрытые (модели не выйдут за пределы инструмента) и архитектурно остановились в начале 2010-х. Современные ML-фреймворки, LLM-агенты, RL-обучение прикручиваются к ним с трудом или никак. Открытая платформа на современном стеке кажется пустой нишей, в которую периодически кто-то заходит (тот же Mesa в Python-сообществе), но без серьёзного коммерческого продукта.

Технически тут начинаются интересные вопросы. Как должен выглядеть DSL, в котором инженер описывает свой склад или цепочку поставок? Сколько в нём готовых паттернов (конвейер, очередь, рабочее место, транспорт)? Как стыковать его с пользовательским кодом, когда стандартных кирпичей не хватает? Это уже не задача «собрать прототип за месяц», а задача из категории «годы исследовательской и инженерной работы». Но если получится, ценность для индустрии выходит на другой уровень. И ещё более сложными выглядят вопросы про то на какой все же домен ориентироваться: чисто игры - но тогда может получиться что то типа игровой платформы, для среднего уровня правдоподобных игр по идее также платформа, а вот реальный домен это уже сложности совсем иного уровня с совсем другими предъявляемыми требованиями. Также в теории возможна совсем универсальная платформа, которая бы позволяла выпускать как инженерные решения так и образовательно-игровые версии для студентов и школьников.

Кейс 5. Сложные реалистичные игры

И последний кейс, который замыкает шкалу аркада↔симулятор. На том же ядре можно собирать игры. Не отдельно, а буквально одно и то же ядро для тренажёра, цифрового двойника и сложной стратегии. Меняется насыщенность графики, темп, степень упрощения физики и экономики.

Тут есть любопытный парадокс. Самые сложные коммерческие игры жанра «менеджмент сложной системы» (Anno 1800, Factorio, RimWorld, Dwarf Fortress) архитектурно сегодня проще, чем то, что мы обсуждаем. Они построены на классическом ООП с тем или иным компонентом-движком, и из-за этого упираются в потолок по масштабу. Factorio героическими усилиями оптимизации тянет десятки тысяч активных конвейеров, но это именно героические усилия, а не комфортная архитектура.

Гибридная архитектура с ECS снизу теоретически даёт игры на порядок более сложные на том же железе. Сотни тысяч активных сущностей, тысячи автономных агентов, полноценная экономика на пару регионов карты. Не уверен, что это окупается коммерчески: ниша любителей таких игр узкая. Но как технологический эксперимент это интересно, и как доказательство архитектуры это сильный аргумент. Если симулятор справляется с игровым темпом и игрок не замечает лагов, значит, на этом же ядре будет быстро работать и инженерный симулятор склада.

От игр к цифровым двойникам. Современный мир подсказывает нам, что сейчас возможно лучшее время, чтобы попробовать это все. Подходы и инструменты из геймдева в чем-то более сложном и наоборот.

Глава 2. Десять игровых доменов под гибридную архитектуру

Если отойти от прикладных кейсов и посмотреть шире, какие игровые домены сами по себе хорошо ложатся на иерархию «ECS-миры плюс акторы-менеджеры плюс стратегический мозг»? Я перебрал в голове разные варианты и остановился на десяти, которые показались наиболее интересными. Подборка субъективная, можно было бы насчитать пятнадцать или семь, но мне показалось, что десять это хороший компромисс между шириной и тем, чтобы не превратить раздел в каталог.

Производственные комплексы. Заводы, верфи, химические производства, металлургические заводы, фармацевтические линии. Это самый чистый пример, и именно сюда упираются Production Line, Captain of Industry, Big Pharma. Игры эти любимы определённой аудиторией, но архитектурно они проседают как раз там, где гибридная схема дала бы простор: на тысячах сущностей с настоящими операционными ограничениями. Пересечение с кейсом 3 про мебельную фабрику здесь почти полное, только подача другая. В кейсе 3 мы делаем серьёзный симулятор, в игре мы заворачиваем то же ядро в развлекательную форму с упрощёнными правилами и красивыми анимациями. Многоуровневость в производстве видна невооружённым глазом: рабочие места это ECS-сущности, цех это ECS-мир, завод это тактический актор-директор по производству, корпорация это стратегический слой с финансовой моделью и инвестрешениями. Эмерджентность сама приходит, как только ты пытаешься перепланировать партию посреди смены и понимаешь, что косвенные последствия расползаются на весь оставшийся месяц.

Космические и морские торговые сети. Та самая X-серия, с которой началась вся история в первой части. Распределённая экономика, агенты-капитаны со своими маршрутами, фракции со своими стратегиями, эмерджентные торговые пути и пиратство как побочный эффект уязвимостей. Тут гибридная архитектура раскладывается красиво: ECS внутри отдельных секторов (корабли, станции, астероиды), акторы-капитаны и владельцы фракций посередине, стратегический ИИ для каждой фракции наверху. Egosoft в новых X4 пытается двигаться в эту сторону, но упирается в архитектурные ограничения, и каждый патч они латают перформанс на больших картах. Открытая ниша до сих пор не закрыта, несмотря на то что аудитория есть и она лояльная. Самое любопытное в этом домене это выбор роли игрока: можно быть честным торговцем, разбойником, исследователем, командиром флотилии или хозяином корпорации. Архитектура должна вытягивать любую из ролей, потому что мир не подстраивается под игрока, а живёт сам.

Энергетические сети. Электросеть города или региона: генерация (тепловая, атомная, гидро, ВИЭ), передача, распределение, конечное потребление. Каскадные эффекты впечатляют: одна авария на подстанции может за секунды положить район, а решения о перераспределении нагрузки принимаются в реальном времени. Открытых игр в этом домене я не нашёл почти ни одной. Есть закрытые тренажёры для операторов диспетчерских центров, стоят дорого, лицензии у энергосистем. Ниша для образовательного симулятора или серьёзной стратегии тут практически пустая, и при этом тема актуальная: каждый человек хотя бы раз сидел без света и хотел разобраться, как же это всё работает. Особенно интересно то, что зелёный переход добавляет в систему новые слои нестабильности: пиковая зарядка электромобилей, выработка солнечных панелей зависит от погоды, спрос меняется быстрее, чем модернизируется сеть. Это домен, где сценарии будущего особенно ценны.

Аэропорты и хабы. Балансировка эффективности и устойчивости. Минимизировать transit time пассажира хочется, но иметь резерв слотов на случай сбоев приходится. Багажная система отдельный сложный мир. Стоянки, рулёжки, очереди на досмотр, погранконтроль, гейты, отправка. Есть Airport CEO, есть SimAirport, но они опять же на ООП и быстро упираются в реализм. Архитектурно интересный момент: в аэропорту хорошо видны разные частоты решений. Самолёт стоит и ждёт минуты или часы, пассажир движется секундами, багажная лента крутится непрерывно. Иерархия частот ложится естественно. Отдельная драма это каскадные опоздания, когда один самолёт пришёл поздно, и через два часа уже половина расписания едет с задержкой, потому что экипажи не успели на свои рейсы, а гейты заняты не теми бортами. Гибридная архитектура такой каскад моделирует естественно, потому что у каждого слоя свои реакции на стрессы.

Сельское хозяйство и пищевая цепочка. От поля до тарелки. Сильная сезонность, которая даёт ритм всей системе. Длинные циклы (плодовый сад окупается лет за пять) сталкиваются с короткими (что продавать на этой неделе). Stardew Valley и Farming Simulator занимают развлекательный край шкалы, но настоящего стратегического симулятора всей цепочки я не встречал. От посева через хранение, переработку, дистрибуцию и до магазина. Каждый слой это свой мир. И эмерджентность тут сразу видна: погодная аномалия в одном регионе перекраивает торговые потоки на полгода вперёд. Добавьте к этому кооперативы, контракты на поставку с переработчиками, скоропортящиеся товары с разной полкой годности, климатические сдвиги, биржевые цены на зерно, и получится один из самых многослойных доменов вообще. Симулятор такой цепочки полезен и для отраслевого образования, и для бизнеса, и для понимания, почему хлеб подорожал.

Логистические компании. Грузоперевозки, экспресс-доставка, FTL и LTL. Близко к кейсу 2 про городскую логистику, но другой масштаб и другие ограничения. Тут уже фуры на междугородних маршрутах, мультимодальность (поезд, корабль, фура), таможня, тарифы. На малых масштабах есть симуляторы дальнобойщика, но это про вождение, а не про управление компанией. Стратегический симулятор логистической компании, где ты собственник или директор по операциям, с подбором парка, маршрутной сетью, конкуренцией с другими игроками, я бы с удовольствием посмотрел. Игровая ценность тут в том, что решения долгоиграющие: купил тягачи на пять лет вперёд, построил склад на десять, а рынок меняется быстрее. И при этом каждый день надо принимать сотни мелких операционных решений: какой груз кому отдать, где забрать обратный, как закрыть простой. Архитектура с разделением по частотам тут работает почти идеально.

Госпитали и медицинские системы. Чувствительный домен с моральными дилеммами. Триаж при перегрузке отделения, распределение реанимационных коек, очерёдность плановых операций. Граница между «игра» и «training tool для медобразования» тут особенно тонкая. Project Hospital игра, Surgery Simulator больше похож на тренажёр, и есть несколько закрытых educational simulators для медицинских вузов. Гибридная архитектура в больнице раскладывается так: ECS-миры это отделения (приёмное, реанимация, хирургия, терапия), акторы-врачи принимают решения по своим пациентам, стратегический слой это главврач и финансовая модель. Реактивная среда подбрасывает поток новых пациентов и нестандартные случаи. Отдельно стоит вопрос смен и расписаний персонала, который сам по себе тянет на полноценный солвер. И отдельный пласт это коммуникация с пациентами и родственниками, которую механически смоделировать сложно, но без которой картина неполная.

Экосистемы и заповедники. Природа отлично ложится на ECS плюс actor. Эмерджентность видна сразу: вырезал хищников, травоядные сожрали подлесок, эрозия почвы, через десять лет экосистема рухнула. Это уже не игра в её привычном смысле, а образовательная штука с потенциалом для школ и природных резерватов. Eco на Unity подходила близко к этому, но упёрлась в свои технические ограничения. Тут архитектурно интересен момент по частотам: животные передвигаются часами, экосистема меняется годами, климат десятилетиями. Симулятор должен уметь крутить разные слои с разной скоростью одновременно. Реальные истории вроде возвращения волков в Йеллоустоун или провала с инвазивными видами в Австралии дают готовые сценарии. И есть отдельный жанр: симулятор управления заповедником, где игрок принимает решения о подкормке, реинтродукции, борьбе с браконьерством, и видит последствия через десятки симуляционных лет.

Городская инфраструктура. Не строительство города (это SimCity и Cities Skylines), а управление существующим городом. Ты мэр, у тебя есть бюджет, есть жалобы граждан, есть кризисы (наводнение, эпидемия, забастовка), есть выборы через четыре года. Невозможно оптимизировать всё одновременно: вложил в школы, проседает дорожная сеть. Долгие циклы обратной связи: эффект от инвестиций в образование видно через десять лет, а отчитываться надо завтра. Tropico разве что приближается к этому, но в довольно карикатурном виде. Глубокого стратегического симулятора городского управления я не встречал. Отдельный пласт это публичная коммуникация: даже хорошее решение может провалиться, если его плохо объяснили, и эту динамику тоже хочется моделировать. И есть постоянный соблазн популистских решений с краткосрочным эффектом, который игра должна честно показывать как ловушку.

Виртуальные рынки и биржи. Особый домен, в котором почти нет физического движения сущностей в пространстве, но есть тысячи автономных агентов разных типов: retail-трейдеры, институционалы, маркет-мейкеры, арбитражники, hft-боты. Каждый со своей стратегией, со своим горизонтом, со своей толерантностью к риску. Тут архитектура раскладывается необычно: ECS-сетка это книги ордеров и тиковые потоки, акторы это сами агенты, стратегический слой это центральный регулятор или метаагент-аналитик. Тестировать торговые стратегии против экосистемы AI-противников намного честнее, чем на исторических данных, где твоя стратегия не влияет на рынок. Реальная пустая ниша для финтех-образования и для исследовательских лабораторий.

Что общего у всех десяти доменов? Многоуровневость по частотам решений, потоки однородных сущностей, и разделение на «что делать прямо сейчас» и «по каким правилам мы вообще играем». Если домен укладывается в эти три свойства, гибридная архитектура для него подходит почти гарантированно. Если не укладывается (например, симулятор отдельной молекулы или одиночная шахматная партия), то скорее всего, нужен другой подход.

Глава 3. Что делает симулятор живым

Без сбоев в симуляторе нет смысла в управлении. Идеальный план в идеальном мире, где ничего не ломается, это калькулятор, а не симулятор. Если у тебя курьеры никогда не опаздывают, оборудование не ломается, поставщики не подводят, спрос предсказуем, то управлять нечем. Достаточно один раз посчитать оптимальный план и поставить его на повтор.

Поэтому отдельным важным модулем гибридной архитектуры выступает реактивная среда. Та самая, что во второй части я обозначил сбоку, не сверху и не снизу. Её задача делать жизнь обитателей симулятора интересной и поучительной.

Самый простой способ это ChaosMonkey-подобный модуль. Идея пришла из практики Netflix, где они специально ломают свои сервисы в production, чтобы система научилась выживать. В симуляторе это превращается в скрипт, который случайно роняет оборудование, опаздывает поставщиков, повышает спрос на 30 процентов. Базовый уровень, который реализуется за вечер и сразу даёт жизнь любому прогону. Без него симулятор выглядит как сборка швейцарских часов в стерильной комнате, и решения, принятые в таких условиях, мало что говорят о реальном мире.

Шаг сложнее это AI Director. Термин пришёл из Left 4 Dead, где Valve в 2008 году придумал систему, которая следит за состоянием игроков и подкручивает сложность: слишком расслабились, добавим зомби, слишком устали, дадим аптечку. Похожая идея у RimWorld в виде «storytellers», у Alien: Isolation в виде персонажа-режиссёра, который никогда не появляется, но управляет поведением ксеноморфа. Принцип один: среда наблюдает за тем, что происходит, и подкручивает параметры, чтобы поддерживать интересный темп.

В инженерном симуляторе AI Director превращается в сценарный генератор. Среда подбирает не случайные катастрофы, а такие комбинации событий, которые сильнее всего стрессуют твою стратегию. Видит, что ты надеешься на один склад и три фуры, и устраивает кризис именно в этом узком месте. Симулятор тут начинает работать в режиме экзаменатора, который ищет твою слабую точку.

Можно идти ещё дальше. Сама среда может быть на ML-модели, обученной на предыдущих прогонах. Она знает, какие сценарии давали наиболее показательное поведение системы, какие приводили к скучной идеальной работе, какие, наоборот, ломали всё за пять тактов. С каждым новым прогоном она становится изобретательнее. Реактивная среда превращается в адаптивную, и это сильно ускоряет обучение людей, работающих с симулятором.

Архитектурно реактивная среда живёт сбоку от основной иерархии акторов. Она подписана на event bus (выходящий поток событий из ECS-миров и акторов), анализирует то, что там происходит, и через тот же bus инжектирует свои события: «оборудование номер 17 встало», «спрос вырос», «поставщик опоздал». Никакого прямого вмешательства в состояние мира, всё через те же интерфейсы, через которые работают остальные подсистемы. Это делает её выключаемой: для отладки можно её отключить и проверить, что симулятор детерминирован.

Отдельная заметка про обучение. Если когда-нибудь захочется поверх симулятора обучать LLM-агентов или RL-политики, то реактивная среда становится одним из самых ценных модулей всей конструкции. Агент, обученный в стерильном симуляторе без сбоев, переобучается на одном узком сценарии и в реальной жизни ломается на первом же неожиданном событии. Среда генерирует разнообразие, и именно разнообразие делает обучение полезным. Это перекликается с тем, что в RL-сообществе называют domain randomization: специально варьируешь параметры тренировочного окружения, чтобы политика училась обобщению, а не запоминанию.

Глава 4. Финальная архитектура и стек

Теперь попытаюсь собрать всё в одну картинку. Это кульминационный момент всей истории из трёх частей, и я постараюсь не уйти при этом в каталог технологий.

Слой 1. Операционный, на ECS. Bevy ECS на Rust или Arch на C#, в зависимости от того, какой стек удобнее команде. Каждый домен или подсистема это отдельный ECS-мир. Внутри простые tight-loop системы (discrete time simulation), высокая частота тиков. Все «исполнители» живут здесь: роботы, курьеры, заготовки, грузовики, заказы. Этот слой сам по себе не думает, он только применяет решения, поступающие сверху, и считает физику с простыми метриками + генерация каких то простых триггеров на основе данных, изменений статусов.

Слой 1.5. Индивидуальный актор для сущности из ECS мира (не стал отдельно выносить на слайд). Подключаемая по требованию сущность с правилами, поведением, FSM и еще чем-то относительно несложным, для случаев когда сущности все-таки сложные или когда сущности нужно позволить переключиться с централизованного управления на автономное (если это в принципе возможно).

Слой 2. Тактический, акторы-менеджеры. Лёгкая акторная абстракция: ractor для Rust-стека или Akka.NET для C#-стека, в обоих случаях через каналы для барьерной синхронизации, чтобы не упереться в проблему миллионов сообщений. Каждый менеджер «владеет» одним ECS-миром или его частью, наблюдает за метриками, принимает решения уровня «переключить режим конвейера», «пересчитать маршрут курьера 47», «вызвать локальный солвер», спросить простую аналитику в DuckDB. Менеджер может дёргать OR-Tools для своих задач или прогонять ONNX-инференс ML-модели.

Слой 3. Стратегический, акторы-стратеги (руководители). Внутри что угодно: rule engine, тяжёлая ML-модель, LLM-агент с tool calling по внешним системам. Работает редко, раз в минуты или часы симуляционного времени, но «думает» глубоко. Может задавать вопросы DuckDB про исторические тренды, прогонять what-if сценарии, эскалировать решения человеку.

Слой данных. DuckDB как in-process аналитическая база, доступная всем уровням, собирает инкрементально batch-ами изменения мира. Знает всю историю прогона, отвечает на произвольные SQL-запросы, работает в том же процессе без сервера. Для долгосрочного хранения и сравнения прогонов между собой больше подходит ClickHouse, в который трейсы скидываются по расписанию.

Реактивная актор-среда. Отдельный модуль. Может быть простым ChaosMonkey или более умным AI Director. Вставляет события в event bus, не трогая внутреннее состояние подсистем напрямую.

Визуализация. Для дев-режима и быстрых демо: Bevy плюс egui, компилируется в WASM, открывается в браузере. Для презентаций и 3D: Godot 4 как фронтенд поверх того же ECS-ядра через GDExtension. Для отладки и пошагового анализа: rerun, который пришёл из мира робототехники и отлично подходит для записи временной оси симуляции. Также при взрослении и росте числа объектов уходить в JS-стек: Babylon.JS, Three.JS, pixiJS, regl.

Внешние интерфейсы. Существующие ERP, MES, WMS, TMS не исключаются, а превращаются в источники или потребители данных и tool-calling инструменты для стратегического слоя. Существующие солверы (OR-Tools, HiGHS, Gurobi) подключаются как библиотеки или внешние сервисы.

Главное в этой схеме не конкретные названия библиотек. Bevy можно поменять на Flecs, ractor на Akka.NET, OR-Tools на HiGHS. Архитектурная суть от этого не меняется. Что действительно важно, так это разделение по слоям и частотам. Нижний слой работает на тиках. Средний работает на минутах. Верхний работает на часах. Реактивная среда работает по своему графику. Каждый слой имеет свою цену решения и свою скорость, и они подобраны так, чтобы более дорогие слои не блокировали более дешёвые. Это совпадает с тем, как реально устроено управление в больших организациях, и это же напрямую перекликается с DDAE-иерархией из первой части. Совпадение случайное только на первый взгляд.

Закрытие. Куда дальше

Чего эта архитектура не делает

Эта схема не для всего. Если задача маленькая и одноразовая, SimPy на Python соберёт нужную модель за час, и тащить сюда Rust с акторами было бы избыточно. Если задача сверхреалистичный промышленный тренажёр, в котором каждая трубочка и каждый клапан валидированы экспертами, AnyLogic с готовыми библиотеками сэкономит годы, и переписывать их с нуля смысла нет. Если задача real-time hardware-in-the-loop, где симулятор синхронизирован с реальным контроллером на микросекундах, нужен совсем другой стек, ближе к Simulink и RT-системам, и Rust-движок туда никто не пустит.

Жанр игр на такой архитектуре тоже нишевый. Не Fortnite, не Call of Duty. Это для людей, которые любят системное мышление и наблюдение за эмерджентностью. Те, кто залипает в Factorio на сотни часов, кто строит сложные машины в Dwarf Fortress, кто пишет таблицы в Excel по экономике RimWorld. Аудитория узкая, но лояльная и сильно недополучает хороших продуктов.

Что осталось открытым

Мультиплеер и сетевая синхронизация большая отдельная тема, которую я в этих трёх частях даже не пытался разбирать. Распределённый ECS с несколькими клиентами это серьёзная задача со своими подводными камнями (rollback, lockstep, authoritative server), и решение для симулятора одного человека и для онлайн-игры на сотни игроков будет разным.

Игровой UX многослойной архитектуры. Если у тебя три уровня управления, игрок должен это чувствовать, видеть разные представления для разных слоёв, переключаться между ними понятно. Это design challenge, не technical. И, честно говоря, в большинстве существующих игр он решён плохо.

Зрелость LLM-агентов для стратегического слоя сейчас на уровне «хайп опережает реальность». Через два-три года картина может выглядеть иначе.

С чего я попробую начать сам?

Начну с MVP сортировочного центра. Это относительно простая точка входа, она может дать конкретный осязаемый результат, и её можно показывать в браузере по ссылке. Bevy ECS на Rust, egui для интерфейса, компиляция в WASM, простые правила внутри ECS. Цель не идеальный продукт, а проверка, что архитектурное мышление совпадает с реальностью. Если на этом этапе не сломается всё: концепция или желание, можно идти дальше, в сторону городской логистики с подключением OR-Tools, а потом, при удаче и упорстве, в сторону амбициозной фабрики (возможно мебельной). Путь явно не из легких. По дороге архитектура наверняка может многократно меняться встречаясь с реальностью.

Литература

Книги и материалы по теме, которые читал в процессе:

1. Parallel and Distributed Simulation Systems - Richard M. Fujimoto.

2. Theory of Modeling and Simulation: Discrete Event & Iterative System Computational Foundations - Bernard P. Zeigler, Alexandre Muzy, Ernesto Kofman.

3. Simulation Modeling and Analysis - Averill M. Law.

4. Simulation and Computational Red Teaming for Problem Solving - Jiangjun Tang, George Leu, Hussein A. Abbass.

5. Как создавать сложные системы - П.О. Скобелев.

6. Making reliable distributed systems in the presence of software errors - диссертация Джо Армстронга создателя языка Erlang.

7. Доклад Майка Эктона «Data-Oriented Design and C++» на CppCon 2014. На YouTube есть запись, рекомендую посмотреть хотя бы для драйва первых минут.

И в самом конце

Если в финале пути окажется, что я просто пытаюсь собрать X-Tension в виде производственного симулятора, и кто-то скажет мне об этом со снисходительной улыбкой, то я с этим скорее соглашусь, чем буду спорить. Игры, которые в детстве показались чудом, часто оказываются той самой формой, в которой проще всего думать о сложных вещах. И если эта форма помогает разобраться, как могут быть устроены автономные производства будущего или какие архитектуры годятся для современных симуляторов, то это, наверное, не худший способ применить детское увлечение.

Спасибо, что дочитали все три части. Это было длинное путешествие и я искренне благодарен всем вам за компанию!