Я давно занимаюсь созданием игр для сетевых инженеров.
Не учебных тренажёров в классическом виде, не наборов тестов и не симуляторов «нажми кнопку — получи результат», а именно игр, где сетевые технологии встроены в gameplay.

Многие думают, что я делаю это как обучающий материал. Но на самом деле причина немного другая.
Для меня настройка сети сама по себе уже давно похожа на игру.
Это как собирать сложный конструктор Lego: есть устройства, интерфейсы, VLAN, маршруты, протоколы, ограничения и зависимости. Всё нужно правильно соединить, настроить и заставить работать как единую систему. Ошибся в одном месте — связность не появилась, маршрут не пошёл, ping не проходит.
В какой-то момент я подумал: если настройка сети уже ощущается как игра, почему бы не объединить её с настоящей игрой?

Раньше мы уже делали такие проекты вместе с моей командой. Я тимлид в Jet Infosystems: придумывал идею, механику, сетевые задачи и сценарии прохождения, а ребята из команды занимались программированием и реализацией.
Эти игры хорошо показывали себя на IT-конференциях. Людям нравилось, что сложные технические темы можно не просто смотреть на слайдах, а проживать через интерактив: играть, ошибаться, пробовать снова, разбираться в логике и при этом чувствовать азарт.
Про некоторые из этих проектов мы писали на Хабре:
https://habr.com/ru/companies/jetinfosystems/articles/1031584/
https://habr.com/ru/companies/jetinfosystems/articles/861690/

С новой игрой я решил провести эксперимент: можно ли использовать ChatGPT как программиста.
Не как волшебную кнопку «сделай игру», а именно как разработчика, которому я ставлю задачи.
Я решаю, какой будет игра: какая нужна механика, какие уровни, какие сетевые сценарии, какие ограничения, как должен работать интерфейс, что должен проверять сетевой движок и какие баги нужно исправить.
AI в этом процессе пишет код по моим указаниям. А я остаюсь в роли тимлида, архитектора, геймдизайнера и тестировщика: формулирую задачи, проверяю результат, нахожу ошибки, уточняю требования, фиксирую архитектурные границы и добавляю regression-аудиты, чтобы новые правки не ломали уже работающие механики.

Так появился Galactic Network Engineer — 2D-платформер, где игрок бегает по уровням, подключает устройства кабелями, открывает планшет с топологией, заходит в консоль и настраивает сеть, чтобы игровые объекты начали работать.

Приведу пример, как я разрабатывал сетевой движок для Galactic Network Engineer на примере BGP.

Увидите, что по достаточно простым промтам и нескольким troubleshooting-сообщениям нейросеть внедрила логику работы протокола. 🧠

Изначальный запрос был простой:

Добавить поддержку протокола BGP.

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

После проверки того, что нейросеть внедрила, я сделал следующий промт:

Усиль BGP IPv4, чтобы протокол работал максимально близко к RFC 4271.

Это был важный поворот. Я не хотел, чтобы протоколы в игре были просто набором команд. Нужно было, чтобы они вели себя как сетевые протоколы: строили соседства, обменивались маршрутами, устанавливали маршруты в routing table и влияли на реальную связность.
После этого BGP начал превращаться из “команды для красоты” в полноценный механизм и оказывать влияние на таблицу маршрутизации. ⚙️

Потом появился отдельный большой запрос на расширение функциональности BGP:

Улучшаем BGP: пока нет iBGP; нет route-reflector; нет update-source; нет next-hop-self; нет route-map; нет prefix-list; нет local-pref, MED, communities; нет VRF-aware BGP; нет redistribution.

После этого BGP начал развиваться уже не как одна отдельная команда, а как набор связанных механизмов: iBGP, update-source, next-hop-self, route-map, prefix-list, атрибуты маршрутов и redistribution. То есть движок начал двигаться от базового neighbor remote-as к более реальной логике маршрутизации.

Дальше пошли уже реальные кейсы траблшутинга. 🔍
Один из запросов был таким:

В iBGP маршрут появляется в BGP-таблице, но не устанавливается в таблицу маршрутизации, даже при настройке next-hop self. Проверить на конфигурации BOSS-C1-SW1 ↔️ BOSS-C1-SW3.

После этого в движке пришлось разбирать не просто факт наличия маршрута в BGP table, а почему он не попадает в routing table. То есть появилась логика, где важно не только “маршрут получен”, но и достижим ли next-hop, можно ли установить маршрут, и какой путь считается рабочим.

Потом был следующий кейс:

BGP-маршрут появился в таблице маршрутизации, но ping до сети всё равно не проходит. Проверить связность BOSS-C1-SW1 ↔️ BOSS-C1-SW3.

И это уже другой уровень симуляции. Недостаточно положить маршрут в таблицу — пакет должен реально пройти через data plane. После этого BGP начал проверяться не только через show, а через итоговую связность: проходит ping или нет, и по какой сетевой причине.

Был ещё важный запрос:

Связность не должна работать без корректного next-hop self, если по логике iBGP next-hop недостижим.

Это означало, что движок не должен “прощать” ошибки конфигурации. В реальной сети next-hop self часто критичен, особенно в iBGP-сценариях. Поэтому пришлось усиливать логику next-hop, чтобы связность не появлялась магически там, где она не должна работать.

Отдельно был запрос по диагностике:

show ip bgp summary должен показывать реальные полученные маршруты, а не всегда 0

После этого show ip bgp summary стал не просто декоративной командой. В нём начали отображаться реальные состояния и количество полученных маршрутов, чтобы игрок мог корректно диагностировать BGP.

Как вы видите, запросы были достаточно простые + потребовалась небольшая проверка работы протокола, и Chat GPT создал весьма неплохую эмуляцию BGP. Да пока достаточно базовую его реализацию, но не удивляйтесь, если скоро там появится address-family l2vpn evpn!

А вот где я действительно долго обучал нейронку- это arp/mac learning. Расскажу об этом позже. 🚀

🚀 Новый второй уровень в 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!