Настоящая MMO — не пошаговая, не PvP-комната на пять минут и не «сервер как один из клиентов», а мир, где сотни игроков одновременно видят друг друга и взаимодействуют в реальном времени. Когда берёшься за такой мир, выбор ровно из трёх вариантов, и каждый чем-то плох.
Три пути, и все плохие
Игровой движок в роли сервера — Unity с Mirror и аналоги. Оправдано, когда рядом живёт офлайн-версия той же игры: логика уже написана, остаётся её раздать. Во всех прочих случаях вы платите ресурсами движка за работу, которой движок не занимается.
Своё решение с нуля. Получается сервер под одну конкретную игру. Следующий проект начнётся с чистого листа.
Готовый сервис вроде Photon. Чужая инфраструктура, своя модель мышления, серьёзные требования к клиентской части и глубокое погружение в C#.
Четвёртого варианта нет. Десятки движков отлично делают клиент — и почти ничего не делают для мира, который живёт на сервере. Сколько это стоит нервов, хорошо видно по видео разработчика, который несколько лет воевал с мультиплеером:
Чего я хотел
Сервис, к которому подключаешься по API и получаешь готовый игровой мир. Админ-панель, куда заливаются карты, анимации, предметы, квесты и баланс. Реалтайм под Android и iOS. Экономный расход ресурсов на игрока.
По сути — Roblox для 2D MMO RPG: движок отвечает за клиент, платформа — за сервер и контент.
Разработчику клиента незачем разбираться в устройстве серверной части. Ему достаточно библиотеки для соединения и списка методов API с параметрами. Всё остальное — не его задача. Карты при этом рисуются в обычном редакторе тайловых карт Tiled и попадают в мир без единой строки кода.
Почему PHP
Главное возражение слышно сразу: PHP не компилируется, значит медленно.
Скорость сервера MMO определяется не языком. Её съедают база данных, кеширование, асинхронность и канал связи — язык там капля в море. К тому же в PHP 7.4 и 8 появились opcache и JIT-компиляция, а поверх ложатся Redis и WebSocket на постоянном TCP-соединении.
Исторически такие серверы пишут на том же языке, что и клиент, и те же люди — обычно C# или C++. Это традиция, а не требование. Разбор того, от чего на самом деле зависит скорость отклика:
Материала по теме на русском почти нет: одна старая статья про архитектуру игрового сервера и пересказы этой же статьи на YouTube. Пришлось читать англоязычные источники и проверять всё на практике.
Что уже работает
На момент этой статьи сервер умеет: регистрацию и авторизацию, загрузку мира — карта с анимациями прямо из админ-панели, движение, здоровье и смерть игрока, враждебных NPC с поиском пути до цели в обход препятствий.
Что было дальше
Эта статья открывает серию. За ней последовали масштабируемость и асинхронность, WebSocket, Redis, пользовательские скрипты на Lua и JavaScript, архитектура Entity Component System, тайловые карты, клиент на Unity, серверные механики, открытый бесшовный мир, работа с задержками и интерполяцией, очереди, event-driven архитектура — и дальше до готового MVP.
Сегодня контент в платформу добавляет ИИ: игровая механика рождается из одного текстового описания и появляется в игре без обновления клиента. Об этом — последние части серии в списке ниже.
Что в вашем опыте оказывалось настоящим узким местом игрового сервера: язык, база, канал связи или архитектура? Соберу боли читателей в темы следующих частей.
История:
Введение
Выбор технологий, протокола и архитектурный шаблон Entity Component System
FPS, Ping, паузы между командами, интерполяция и экстраполяция
Event-driven паттерн, JSON-RPC и почему не сервисная (SOA) архитектура
Сетевая карта и задержка кадра (Latency frame) по RFC 2544 (1242)
Конвейер контента для MMO: импорт анимации, экипировка и обновление игры без патчей
