После успешной оптимизации клиентской части и серверной архитектуры пришла пора писать механики самой игры для взаимодействия по API — я называю их событиями (они вешаются на какой либо игровой объект на сервере, помещаются в очередь и срабатывают когда придет их время).Суть работы взаимодействия авторитарного сервера и клиентской части следующая:Мы создаем группу в которой будут собраны некие игровые механики (например идти в указанную точку, идти в указанном направлении, идти за указанным объектом).Мы указываем таймаут вызова механик этой группы в секундах или в виде кода по результатам которого будет выдано число с плавающей точкой (например пауза между движениями 1 / скорость * магнитуду направлении, но она может быть и 0 — например на механику получения урона).Мы указываем может ли игрок вызвать механику напрямую (если нет — ее можно будет вызвать лишь из другой механик, например вызов механики получения урона при атаке).Мы можем указать какие дополнительные параметры могут быть при вызове механики (например объем регенерации жизней или объем урона).Мы указываем нужно ли рассылать пакет с данными когда механика будет применятся на каком либо существе (например можно высылать время таймаута, доп параметры механики такие как объем урона).И наконец мы указываем сам код механики который манипулирует параметрами объекта на котором механика сработала и теми объектами которые на карте.Дополнительно можно указать — нужно ли вешать событие на то же существо когда оно отработает (например регенерацию — нужно).Пример создания группы игровой механикипример нескольких игровых механик в одной группепример кода при создание игровой механики в группе механикПример кода добавления простой механик на LUAТаким образом можно создать множество механик которые могут быть вызваны через отправку пакета по Websocket соединению со стороны клиента, а так же вызваны по цепочки внутри друг друга. Плюс ко всему мы можем менять код их работы не меняя ничего в клиенте (если это не затрагивает какую то визуальную часть которая еще не реализована).При замерах скорости работы на VPS с 2мя ядрами процессора и 4GB оперативной памяти результаты стремятся к 1.000.000 RPS и это только на CPU (в будущем я планирую внедрить параллельные вычисления на GPU), хотя имеются и долгие механики такие как:сохранение в БД игрока (несмотря на то что оно уже асинхронно делается)расчет поиска пути при движении до точкискорость выполнение игровых механик на сервереВ предыдущей статья я рассказал о горизонтальном масштабировании игрового сервера, так что при достижении работы с сервера к 60FPS (на примере выше он 1000FPS) можно переложить вычисления части открытого мира на другое железо (об открытом бесшовном мире я расскажу в следующих статьях которые вы сможете найти в моем профиле).В заключение я подготовил пару коротких и не только видео с демонстрацией кода и работы игровых механик проекта (доступен демо доступ на сайте mmogick.ru). Впереди еще долгий путь в котором надо будет разрабатывать механики для MMO RPG связанные с физикой. История:ВведениеМасштабируемость и асинхронностьWebSocketRedisLUA и JavaScriptВыбор технологий, протокола и архитектурный шаблон Entity Component SystemИгровые локации (тайловые карты)Клиентская часть на UnityИгровые серверные механикиОткрытый бесшовный мир в 2D игреFPS, Ping, паузы между командами, интерполяция и экстраполяцияОчереди и параллельное программирование на CPUEvent-driven паттерн, JSON-RPC и почему не сервисная (SOA) архитектураСетевая карта и задержка кадра (Latency frame) по RFC 2544 (1242)Создание сервера для онлайн ММО игр на PHPГотовое MVP сервиса 2D MMO RPG игр (realtime)