🌊 Deepwake Online — Дневник разработчика #2

Декомпозиция ShardRuntime и расчистка серверного ядра

После первого этапа стало очевидно: один из главных узких участков проекта — это серверный ShardRuntime.

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

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

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


🧠 Почему это вообще важноКог
да слишком много серверной логики живёт в одном runtime-файле, начинаются типичные проблемы:

— сложно дебажить
— сложно безопасно вносить изменения
— растёт шанс сломать соседние подсистемы
— любая новая механика начинает врастать в общий комбайн
— серверная архитектура теряет расширяемость

Для MMO это особенно опасно.

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

Именно поэтому сейчас задача не “косметически подчистить код”, а разнести ответственности так, чтобы shard перестал быть монолитной точкой сборки всей серверной логики.


⚙ Что делается на этом этапе

Текущая работа идёт по нескольким направлениям.

Во-первых, из ShardRuntime постепенно выносятся отдельные зоны ответственности в самостоятельные серверные модули.

Это касается прежде всего таких направлений, как:

— обработка movement-логики
— репликация состояний
— маршрутизация игровых сообщений
— работа с сессиями
— части рыболовной серверной логики
— локальные decision / handler / context слои

Во-вторых, уменьшается объём inline-логики внутри самого shard runtime.

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

Это один из ключевых архитектурных разворотов текущего этапа.

🧩 Что это даёт проекту

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

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

Для Deepwake Online это критично, потому что проект изначально строится как server-authoritative MMO, где сервер — это не “пересылка пакетов”, а реальный носитель игрового состояния.

А значит, чем чище shard-ядро, тем легче масштабировать и развивать всё остальное.


🎣 Отдельно про рыбалку и репликацию

На фоне общей декомпозиции продолжается вынос частей рыболовной логики из shard-слоя в более специализированные модули.

Это важно по двум причинам.

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

Вторая — рыболовные события, snapshot-пакеты, warning-state и связанная с ними репликация должны иметь понятную границу ответственности, а не размазываться по runtime.

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

📦 Переход от “большого файла” к набору серверных компонентов

Главный смысл текущего этапа можно описать просто:

раньше shard был местом, куда постепенно стекалось всё;

теперь shard становится точкой координации, а не свалкой обязанностей.

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

Но именно такая работа определяет, сможет ли проект дальше нормально расти без постоянных архитектурных откатов.

🧪 Текущее состояние

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

Иными словами:

сначала shard должен стать меньше, чище и предсказуемее;

потом уже на эту основу можно безопасно навешивать дальнейшее расширение.

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

🌊 Что дальше

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

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

Сейчас работа идёт не вширь, а вглубь.

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

Дневник разработчика #3

3 views