🚀 Новый второй уровень в Galactic Network Engineer — собираем сеть ракеты с нуля

На конференции я давал посетителям поиграть в Galactic Network Engineer, и несколько игроков независимо друг от друга отметили одну и ту же проблему: когда впервые попадаешь в ракету, довольно сложно сразу понять, как устроена её сеть, за что отвечает каждое устройство и как всё связано между собой.
Поэтому я решил не просто добавить ещё одну подсказку, а полностью переработать обучение.

Теперь на новом втором уровне игрок поэтапно собирает бортовую сеть ракеты.
Устройство за устройством он находит сетевое оборудование, доставляет его к ракете и монтирует. После установки можно зайти внутрь ракеты, открыть терминал и посмотреть, какое место новое устройство заняло в общей схеме сети и какую функцию оно выполняет.

При этом никто не торопит игрока. Можно спокойно открыть консоль устройства и изучить его конфигурацию: посмотреть интерфейсы, IP-адресацию, таблицу маршрутизации и другие настройки.
Таким образом, вместо того чтобы показать игроку сразу готовую сложную сеть, игра постепенно отвечает на вопросы:
— зачем здесь этот коммутатор?
— с чем соединён маршрутизатор?
— для чего нужна антенна?
— как устройства связаны между собой?
— что уже работает, а что появится после установки следующего элемента?
В результате сеть ракеты перестаёт быть просто красивой схемой в терминале — игрок сам её собирает и постепенно понимает её устройство.

Мне нравится именно такое направление развития Galactic Network Engineer: не упрощать сетевые технологии до условных кнопок, а учить через взаимодействие с максимально понятной моделью настоящей сети. 🚀🔧🌐

Galactic Network Engineer постепенно движется к кооперативному сетевому симулятору

Последнее изменение в игре началось с довольно обычного бага.
На одном уровне игрок настраивал коммутатор внутри одной ракеты. На следующем уровне использовалась уже другая ракета и другой коммутатор, но из-за совпадающего внутреннего deviceId новая ракета внезапно получила конфигурацию старой.
То есть для игры это были разные физические устройства, а для архитектуры — фактически один и тот же объект.

Исправляя это, я решил не ограничиваться точечным фиксом.
Теперь идентичность сетевого устройства строится по принципу:
networkScopeId + rocketId + hostname

Это значит, что устройство определяется сразу тремя вещами:
в какой игровой сетевой среде оно существует;
к какой физической ракете относится;
какой hostname у него настроен.
В результате одна и та же ракета может сохранять свои конфигурации между уровнями, а устройства разных ракет больше никогда не пересекаются.
Но главное — эта же архитектура нужна для следующего большого шага проекта.

Я хочу постепенно развивать Galactic Network Engineer в сторону многопользовательского сетевого симулятора.

Представьте общую виртуальную инфраструктуру, в которой несколько инженеров одновременно работают с одной сетью:
настраивают коммутаторы и маршрутизаторы, диагностируют аварии, видят изменения друг друга, восстанавливают связность и совместно решают реальные сетевые сценарии.
При этом networkScopeId сможет определять уже не отдельного игрока, а конкретную корпоративную лабораторию, учебную группу или multiplayer-сессию.
То есть разные команды будут полностью изолированы друг от друга, а инженеры внутри одной сессии — работать с одним и тем же состоянием оборудования.

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

И именно в эту сторону я хочу дальше развивать проект.

Пока я работаю над структуризацией и улучшением кода Galactic Network Engineer — несколько фактов о проекте.

Начал я его 20 апреля 2026 года. На фото один из первых релизов игры. 🍿

С тех пор:
— прошло 128 дней с начала проекта;
— текущая сборка уже называется v676 то есть за это время я вводил промпт и нажимал Enter 676 раз;
— в production-коде около 72 500 строк;
— вместе с инструментами разработки и автоматическими проверками — около 116 000 строк;
— проект содержит 554 JS/MJS-файла;
— только автоматических audit-проверок сейчас 411;
— в игре уже 9 уровней.


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


Продолжаем.

Недавно несколько версий подряд искал причину одной странной задержки в игре.

Симптом был простой: игрок подключает кабель — и в этот момент игра на долю секунды подвисает.

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

Тогда я начал постепенно усиливать логирование. С каждой новой версией в лог писалось всё больше этапов: когда подключился кабель, когда обновилась сеть, когда проверились задания, когда началась и закончилась отрисовка кадра.

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

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

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

Последние несколько дней я почти не добавлял в игру ничего нового.
Наоборот — удалял.
За время разработки накопилось много старого: куски кода, которые уже не используются, старые тесты, лишние файлы, прошлые версии логики, картинки, стили и документация от того, чего в игре давно нет.
Я решил остановиться и перед дальнейшей разработкой нормально всё почистить.

Результат получился довольно заметный.
Было:
— 642 файла
— 217 JS-файлов
— архив игры 6,23 МБ
Стало:
— 168 файлов
— 141 JS-файл
— архив 2,95 МБ
То есть размер игры уменьшился примерно в два раза, а количество файлов — почти на 74%.

Но самое интересное началось потом, когда я снова стал проходить игру руками и тестить.
Например, на 3 уровне внезапно появился очень забавный баг.
В какой-то момент игра решила, что уровень уже можно заканчивать, хотя впереди ещё должна была быть битва с врагом.
В итоге можно было просто сесть в ракету и улететь.
Сражение? Можно не проходить 😄
Причём игра не падала, ошибок на экране не было — она просто считала, что всё выполнено.

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

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

9 и 10 сентября я буду показывать Galactic Network Engineer на конференции IT ELEMENTS «Инфосистемы Джет».

Регистрация на конференцию здесь 💻

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

Одна из самых интересных — связность между Loopback 8.8.8.8/32 на AUX-RTR-01 и Loopback 9.9.9.9/32 на SPACE-RTR-01.

Здесь одновременно работают 802.1Q, multi-area OSPF, eBGP и static routing.
Если идти слева направо:
На AUX-RTR-01 создаю Loopback0 8.8.8.8/32 и помещаю его в OSPF Area 1. Сам линк AUX↔CORE работает через Area 0, так что AUX становится ABR.

Физический Gi0/2 используется как router-on-a-stick:
Gi0/2.31 — 192.168.101.2/30, VLAN31, OSPF Area 0
Gi0/2.32 — 192.1.1.2/30, VLAN32, eBGP AS100
Параллельно на AUX есть static route:
9.9.9.9/32 via 192.1.1.1
На ROCKET-CORE-SW порт к AUX — trunk с VLAN31 и VLAN32. Подняты два SVI:
Vlan31 — 192.168.101.1/30 для OSPF
Vlan32 — 192.1.1.1/30 для eBGP AS200
То есть между AUX и CORE одновременно существуют три независимых L3 control-plane пути: OSPF через VLAN31, BGP и static через VLAN32.

Дальше CORE соединён со SPACE-RTR routed link:
172.16.1.1/30 ↔ 172.16.1.2/30, OSPF Area 0.
На SPACE-RTR находится Loopback0 9.9.9.9/32. Но в OSPF он не попадает напрямую.
Сначала 9.9.9.9/32 анонсируется в BGP AS65036, а уже затем через redistribute bgp попадает в OSPF как external route.

Получается цепочка:
9.9.9.9 → BGP на SPACE-RTR → redistribution → OSPF → CORE → eBGP → AUX
На AUX для 9.9.9.9 одновременно могут существовать три маршрута:
Static — AD 1
eBGP — AD 20
OSPF — AD 110
Пока есть static route — выигрывает он. Удаляем static — начинает работать eBGP. Убираем BGP — остаётся OSPF.
Причём меняется и физический путь: static/eBGP идут через VLAN32, а OSPF — через VLAN31.

Обратный путь тоже интересный: 8.8.8.8/32 находится на AUX в Area 1 и распространяется через OSPF, поэтому трафик 9.9.9.9 → 8.8.8.8 может возвращаться через CORE уже по BGP.

В итоге в одной небольшой схеме одновременно получились: router-on-a-stick, trunk, два VLAN, multi-area OSPF, eBGP, BGP→OSPF redistribution, static routing, Administrative Distance и asymmetric routing.

И всё это не «зашито» в сюжет. Движок сам строит control plane, RIB/FIB, выбирает маршрут, разрешает next-hop, делает ARP, изучает MAC, учитывает VLAN и реально проводит пакет по сети.

Вот такими конфигурациями я сейчас и пытаюсь его ломать перед конференцией. Иногда получается 😄

До встречи завтра на IT Elements!

Сразу после окончания конференции я буквально засел за большую миграцию архитектуры Galactic Network Engineer.

Причина простая: локальная версия игры уже выросла настолько, что дальше развивать её «как есть» было опасно. А впереди у меня две большие цели — выпустить игру на сервере, чтобы в неё можно было играть через интернет, и в будущем сделать полноценный мультиплеер и кооперативные кампании.

Поэтому последние дни я почти не добавлял новый контент. Вместо этого полез глубоко внутрь игры и начал приводить в порядок фундамент.

Раньше значительная часть логики исторически жила в одном огромном game.js — почти 30 тысяч строк кода. Пока игра была маленькой, это ещё работало. Но когда появились 9 уровней, полноценная эмуляция сети, BGP, CLI, терминалы, сохранения, Rocket Builder, планшет, NPC и куча другой логики — такой файл начал превращаться в проблему.
Сейчас game.js — это всего 14 строк bootstrap-кода.

Вся игра разделена на отдельные домены. Кампания занимается кампанией. Игрок — игроком. Терминал — терминалом. Сохранения — сохранениями. Отрисовка — отрисовкой. Сетевой движок вообще живёт отдельным слоем.
Сам сетевой runtime тоже разделён: отдельно ядро работы с сетью и CLI, отдельно кабели и топология, отдельно логика сетевых заданий, серверов и босса.

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

Отдельно чистил конфиги и границы между системами, чтобы один модуль не мог просто залезть внутрь другого и поменять его состояние напрямую.

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

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

Сейчас в runtime игры 28 отдельных source-файлов и 27 доменов. Самый большой модуль — около 4 тысяч строк вместо прежнего файла почти на 30 тысяч. Циклических зависимостей между доменами больше нет, широкие старые API убраны, прямые обходы хранилища тоже убраны.
На текущей версии проходит 97 автоматических проверок, включая запуск игры в Chromium, переключение русского и английского языка, Rocket Builder и уровни с 1 по 9.

То есть последние дни выглядели примерно так: не «добавил красивую новую кнопку», а «разобрал половину космического корабля, перебрал проводку, выбросил старые переходники и собрал обратно так, чтобы потом к нему можно было нормально пристыковать сервер и мультиплеер» :)

Теперь фундамент для следующего этапа у игры есть.
А значит дальше можно снова заниматься самой игрой.