Galactic Network Engineer

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

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

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

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

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

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

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

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

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

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

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

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

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

🚀 У Galactic Network Engineer появился новый первый уровень

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

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

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

Первый такой уровень уже готов. 🎮
В нём игрок постепенно учится:
🔹 передвигаться и использовать лестницы;
🔹 прыгать между платформами;
🔹 работать с патч-кордами;
🔹 подключать сетевое оборудование;
🔹 взаимодействовать с сервером и транспортным кораблём;
🔹 прятаться внутри объектов от противников.

И всё это без необходимости сразу разбираться в Cisco CLI, VLAN, маршрутизации и остальных сетевых механиках. Мне хочется, чтобы сложность в игре появлялась из сетевых задач, а не из-за того, что игрок ещё не понял, какие кнопки нажимать.

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

Продолжаю переделывать обучение. Дальше появятся ещё несколько вводных уровней, прежде чем игрок попадёт в ту часть игры, которая раньше была самым первым уровнем. 🚀

🚀 Как изменилась архитектура Galactic Network Engineer
Когда я только начал создавать игру, мне было интересно понять: получится ли у меня вообще довести эту идею до рабочего результата?
Поэтому первые промты просто добавляли в игру новый функционал. Об архитектуре кода я тогда практически не думал.
В результате игра получилась почти монолитной: большая часть геймплея, интерфейса, терминала и сетевой логики находилась в одном огромном файле game.js и нескольких тесно связанных модулях.
Проект работал, но с появлением новых уровней и механик любое изменение становилось всё сложнее и рискованнее. ⚠️

🛠 Что было сделано
Архитектура проекта прошла две большие миграции.
🌐 Сетевой движок стал единым источником истины
Вся работа сети была централизована в GNENetworkEngine:
🔹 VLAN, OSPF, BGP и статическая маршрутизация
🔹 ping и расчёт связности
🔹 состояние сетевых устройств
🔹 Cisco-подобный CLI
🔹 таблицы маршрутизации и топология
Более того, сетевой движок теперь можно перенести из GNE в другую программу.
Я изначально предполагал, что хороший сетевой симулятор может пригодиться мне и в других проектах. Для его тестирования и развития я даже создал отдельную браузерную программу наподобие Cisco Packet Tracer.
В ней можно создавать сетевые устройства, соединять их между собой, настраивать через CLI и проверять связность.
После того как движок был протестирован и доработан отдельно, я внедрил его обновлённую версию обратно в игру.
Теперь миссии, терминал и интерфейс используют одно и то же состояние сети — без дублирования логики.

🧩 Монолитный game.js был разделён на подсистемы
Из него постепенно вынесли:
🔹 игровые состояния и миссии
🔹 взаимодействие игрока
🔹 терминал и его view-models
🔹 инвентарь, кирку и реактивный ранец
🔹 сохранение и восстановление состояния
🔹 каталоги уровней, предметов, способностей и устройств
Теперь контроллеры принимают решения и формируют планы действий, а game.js в основном координирует работу подсистем и применяет игровые эффекты: физику, анимации, сообщения и изменения игрового мира.

✅ Результат
Архитектура стала модульной и расширяемой:
🧠 правила находятся в контроллерах
📚 контент — в каталогах
🌐 сеть — в отдельном движке
💾 сохранение — в отдельном pipeline
🎮 game.js — orchestration layer

Текущий этап архитектурной миграции завершился в версии v581 со статусом:
🟢 MIGRATION_COMPLETE
Теперь новые уровни, предметы, способности и сетевые устройства можно добавлять безопаснее, не превращая основной файл игры в ещё больший монолит. 🌌🔧
Но на этом работа не заканчивается. В планах ещё третий этапа миграции, чтобы продолжить отделять игровые модули от game.js и сделать архитектуру проекта ещё более независимой и масштабируемой.

Приведу пример, как я разрабатывал сетевой движок для 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. Расскажу об этом позже. 🚀

Я давно занимаюсь созданием игр для сетевых инженеров.
Не учебных тренажёров в классическом виде, не наборов тестов и не симуляторов «нажми кнопку — получи результат», а именно игр, где сетевые технологии встроены в 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 — игра про сетевого инженера, который чинит инфраструктуру буквально на бегу.

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

🎮 Игровая механика и физика

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

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

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

🌐 Сетевой движок

Внутри игры работает собственный сетевой движок. Устройства можно открывать в консоли и настраивать командами, похожими на Cisco CLI.

Поддерживаются разные сетевые механики:

• IP-адресация и маски
• ping и проверка связности
• VLAN и access/trunk-порты
• sub-interface и dot1q
• static routing
• OSPF
• BGP
• ARP/MAC-логика
• show-команды
• command history
• контекстная помощь через ?
• сохранение и загрузка сетевых конфигураций

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

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

К посту прикладываю скриншоты из игры.

Вчера Galactic Network Engineer впервые полноценно показала себя в боевых условиях — на ИТ-конференции «Сетевое лето» 🚀
https://it-elements.ru/setevoe-leto

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

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

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

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

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

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

Спасибо «Сетевому лету» за возможность показать проект вживую.

Channel photo updated