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

Почему сервер авторитарный
Есть сервисы-аналоги, но для ММО они либо не подходили либо требовали существенных доработок и непонятно как их теперь из РФ оплачивать (они для сессионных игр, их исчерпывающий список ниже).

Сервер нужен был авторитарный (P2P соединения или с проверками на клиенте для жанра MMO был не вариант), для тех кто не знает что это такое пример сравнения серверов ниже.

Инструменты, без которых он бесполезен
Раз всю логику считает сервер, менять её должно быть можно без переписывания сервера. Так появился редактор кода игровых механик.
Конечно, нужны были инструменты для настройки характеристик, игрового баланса, предметов и прочего (гейм дизайнер не полезет учить PHP и JS — максимум цифры поправит), и так я сделал редактор существ.
Нужно было что бы сервер имел представление о мире, его препятствиях для расчета пути NPC (игровых существ под управлением ИИ) и проверки проходимости области, так родилось приложение для загрузки 2D игровых карт.
Масштабирование
И только в самом конце нужно было позаботиться что бы сервер мог обслуживать и рассылать данные сотням и тысячам игроков, придумать систему оркестрации, горизонтального масштабирования и бесконечного бесшовного 2D мира. Так спустя 3 года разработки вишенкой на торте стала сервисная архитектура, где одни из сервисов выступал работающий в параллели WebSocket сервер.
Замеры
Моя разработка в серии статей встретила критику со стороны читателей в вопросе производительности. Требовались инструменты замера скорости работы. Сложность была в том, что т.к. сервер авторитарный таких метрик как PING было не достаточно — сервер тратил время не только на отправку и получение пакетов игроков, но и на вычисления команд игроков, расчета, что делает NPC, периодического сохранение в БД (последнее было вынесено в отдельный сервис).
Я написал приложение, что замеряло все: время отправки / сжатия пакетов, отдельных механик, обмена данными между сервисами — все с точностью до тысячной миллисекунды, а так же использование CPU и RAM.
Если коротко: на недорогой машине с двумя ядрами и двумя гигабайтами памяти одновременно играют около трёхсот человек, а таких машин можно поставить сколько угодно — мир останется единым.
И таких серверов может бесконечно и это останется единый бесшовный мир, где игроки со всего мира будут играть вместе (я лично проехал от юго-восточной Африки до Индии при PING 150-250 добавляя интерполяцию и экстраполяцию).
Что уже работает в игре
Демонстрационная игра пока простенькая, не замысловатая, без сюжета и музыки, мало механик, но игровой сервер одинаково хорошо работает как для браузерных игр, так и для версии на ПК, мобильных устройствах (код я выложил на GitHub). С готовой архитектурой сервера я не вижу того, что потребовало бы выход за рамки Web IDE.
Конечно, есть и 3D игры и кому, то хочется нестандартных режимов, новых жанров (типа стратегий или баталий). Для этого я сделал возможность не только редактировать отдельные механик (выстрел, движение к цели, дебафы, крафт, прокачка и т.д), но и самим, из личного кабинет на WEB, не погружаясь в иерархию всего проекта, приложений, сетевого взаимодействия редактировать тот код, который отвечает только за игровое взаимодействие — я назвал это Игровые Фреймворки (пока доступен только для RPG игр, в планах матчмейкинг и стратегии).
Как видите игровой сервер не просто шлет пакеты и ошибочно полагать что любой с ходу может сделать онлайн игру более чем на 20 человек (такое ограничение у западных аналогов).
Что было дальше
За 3 года разработки был проделан колоссальный труд и получилось что-то типа Тильды / Битрикса, но для онлайн игры.
Я стою перед выбором: сконцентрироваться над B2B продуктом предоставляя новые инструменты разработчикам или делать свою игру, и я спрашиваю вас:
Нужен ли Вам — разработчикам игр подобный сервис?
Сейчас поверх этой основы работает перенос настоящей игры: карты, существа, анимация и экипировка The Mana World едут на платформу, а механики описываются текстом и собираются в код без правки клиента.
В моих планах сделать сервис для 3D игр, добавление без программирования в игру музыки, анимацию героев, список друзей, новые игры
Как это выглядит в игре, показываю на канале проекта: youtube.com/@mmogick_ru.
Если бы вы делали свою MMO — с чего начали бы: с игровых механик или с архитектуры под нагрузку?
История:
Выбор технологий, протокола и архитектурный шаблон Entity Component System
FPS, Ping, паузы между командами, интерполяция и экстраполяция
Event-driven паттерн, JSON-RPC и почему не сервисная (SOA) архитектура
Сетевая карта и задержка кадра (Latency frame) по RFC 2544 (1242)
Готовое MVP сервиса 2D MMO RPG игр (realtime)
Конвейер контента для MMO: импорт анимации, экипировка и обновление игры без патчей