Удар, шаг, регенерация, подбор предмета — всё это на авторитарном сервере одна и та же конструкция: событие, повешенное на игровой объект. У него есть очередь, время срабатывания и код, который меняет состояние мира. Клиент про эту кухню не знает и пересобирать его не нужно.
Из чего состоит механика
Механика описывается в веб-панели, код к ней пишется на Lua, JavaScript или PHP. Собирается она так:
Мы создаем группу в которой будут собраны некие игровые механики (например идти в указанную точку, идти в указанном направлении, идти за указанным объектом).
Мы указываем таймаут вызова механик этой группы в секундах или в виде кода по результатам которого будет выдано число с плавающей точкой (например пауза между движениями
1 / скорость * магнитуду направлении, но она может быть и 0 — например на механику получения урона).Мы указываем может ли игрок вызвать механику напрямую (если нет — ее можно будет вызвать лишь из другой механик, например вызов механики получения урона при атаке).
Мы можем указать какие дополнительные параметры могут быть при вызове механики (например объем регенерации жизней или объем урона).
Мы указываем нужно ли рассылать пакет с данными когда механика будет применятся на каком либо существе (например можно высылать время таймаута, доп параметры механики такие как объем урона).
И наконец мы указываем сам код механики который манипулирует параметрами объекта на котором механика сработала и теми объектами которые на карте.
Дополнительно можно указать — нужно ли вешать событие на то же существо когда оно отработает (например регенерацию — нужно).
Дальше такие механики вызываются с клиента одним пакетом по постоянному соединению — либо цепочкой одна из другой. И, что важнее, их код можно менять, не трогая клиент: пока правка не требует новой картинки или анимации, игроку ничего обновлять не нужно.
Сколько это держит
На виртуальной машине с двумя ядрами и четырьмя гигабайтами памяти замеры подбираются к миллиону выполнений в секунду — и это только на процессоре. Отдельно стоят механики, которые заведомо долгие:
сохранение в БД игрока (несмотря на то что оно уже асинхронно делается)
расчет поиска пути при движении до точки
Когда сервер перестаёт укладываться в кадр, часть открытого мира переезжает на другое железо — горизонтальное масштабирование для того и нужно. В примере выше запас ещё огромный: тысяча кадров в секунду против нужных шестидесяти.
Как это выглядит
Ниже — короткие записи с демонстрацией кода механик и их работы в игре.
Что было дальше
Конструкция дожила до текущей версии почти без изменений — на ней сейчас держится вся игровая логика: бой, лут, движение существ, переходы между картами. Изменилась подача: механику стало возможно описать текстом, а код к ней собирается уже под задачу.
Как это выглядит в игре, показываю на канале проекта: youtube.com/@mmogick_ru.
Если у вас механики живут в коде клиента — расскажите, что мешает вынести их на сервер.
История:
Выбор технологий, протокола и архитектурный шаблон Entity Component System
Игровые серверные механики
FPS, Ping, паузы между командами, интерполяция и экстраполяция
Event-driven паттерн, JSON-RPC и почему не сервисная (SOA) архитектура
Сетевая карта и задержка кадра (Latency frame) по RFC 2544 (1242)
Конвейер контента для MMO: импорт анимации, экипировка и обновление игры без патчей
