Дневник разработчиков: Система подбора игр и новый режим

Всем привет!

Откатимся до 2021 года - а именно, к нашему посту: https://vk.ru/wall-97266992_64393

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

Да, прошло 4 года, и в данный момент мы спешим сообщить о том что система внутриигрового матмейкинга завершена практически на 80%, и уже совсем скоро начнёт внедряться под все игровые сервера!

Что такое матчмейкинг?

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

Матчмейкинг (от англ. matchmaking - подбор пары) -это система в видеоиграх, которая автоматически ищет и объединяет игроков для совместного или противоположного матча.

Вы сталквиваетесь с ней почти в любой современной онлайн игре:
1) Counter-Strike, когда нажимаете кнопку «Найти матч»
2) PUBG, когда нажимаете «Играть»
3) Средневековые ММО, когда нажимаете «Войти в подземелье»

Все эти игры объединяет одна простая, но довольно глубокая цепочка:
Собрать игроков → Разделить игроков → Создать сервер для игроков

Что такое Public Host (Или «паблики»)

Public game host (публичный игровой хост) - это общедоступный сервер или компьютер игрока, который запускает сетевую игру и принимает подключения от любых пользователей из интернета

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

Что было на ранних этапах:
1)Игровой сервер
2)Информация о Лобби сервере, переданная в лаунчер (IP Адрес + пароль)
4)Лобби-сервер содержит информацию о иных серверах для переходов и подключений

Т.е фактически, лобби всё так же оставалось таким же мастер-листом, но оформленное в более удобную обёртку.

Лобби НЕ ЗНАЕТ:
1)Сколько игроков на сервере
2)Сколько CPU/ОЗУ свободно на машине
3)Какой сервер сейчас заблокирован/недоступен/выключен

И это… сильно сковывает движения так и для нас, разработчиков, так и для игроков. Это означает, что отряды не смогут одновременно подключиться на один и тот же сервер - а игроки при попытке подключиться на заполненный сервер, будут получать ошибку «Сервер заполнен» - вместо того, чтобы дожидаться свободного слота автоматически. А так же… Игра не может динамически формировать сервера для сессионых матчей, которые должны начаться, завершиться, и выключиться, чтобы не занимать CPU/ОЗУ основной хост машины.

Старая реализация

Пробежимся по простой схеме:
На картинке изображено 4 ноутбука - наши игроки, которые хотят поиграть на сервере. Ранее, подключение происходило именно так, как мы описали выше, и как изображено на этой схеме

На схеме не изображено то, что игровой сервер общается с базой данных - Да и это не особо важно.

Из-за отсутсвия распределения, мы можем отправить игрока на другой сервер только в том случае, если он сам выберет его. А мы намерены это победить, тем, что сервер теперь не является изначальной конечной точкой подключения: Всё происходит куда сложнее

Новая реализация

Теперь, текущая архитектура в максимально упрощённом ввиде выглядит примерно так:

1)Игровой клиент требует запрос на подключение к игровому серверу
2)Координатор получает этот запрос, и смотрит его по критериям (Один он, или играет отрядом - нужен ли ему одиночный матч/матч на большое количество игроков и т.д)
3)Координатор собирает информацию о других игроках и их запросах
4)Координатор отправляет запрос на агент, о возможности формирование сервера
5)Агент отправляет координатору информацию о том, получится ли создать сервер
6)Координатор возвращает эту информацию игроку ввиде сообщения, например: «Ожидание формирования матча»
7)Агент сообщает координатору о том, что сервер готов и передаёт его конечные данные
8)Координатор отправляет информацию о сервере клиенту
9)Текущий игровой сервер обрабатывает запрос координатора, и подключает его в сформированный матч
10)Агент отслеживает текущее состояние матча, и сообщает информацию координатору о его завершении при необходимости
11)Координатор передаёт эти данные в базу данных при необходимости (Например для сохранения истории матчей)

Если вам ничего не понятно, то мы вас понимаем :D
Объясним на примере нового технического игрового режима - DGM (Dungeon Game Mode) и об трёх внешних утилитах: Server Manager, Coordinator и Agent.

Система подземелий и сессионых игровых серверов

Демонстрация системы подбора игр, на примере одиночного PvE матча:
(YouTube: https://youtu.be/Wsz3YFly5P8)

На видео представлен пример подключения в отдельный генерируемый сессионый матч. Применять данную систему мы можем для ВСЕХ без исключений серверов, чтобы оптимизировать потребление игровых ресурсов и упростить игрокам поиск игр, или переходы по локациям (Например между кластерами)

Технический Dungeon Game Mode

DGM (Или же «Лаборатория») - новый PvPvE режим, разделённый на несколько подрежимов: PvP, PvE, и режим «Story».

DGM - PvP

Вариация PvP режима представляет с собой следующий формат:

1)Несколько отрядов появляются в случайных местах определенной лаборатории (Мап-пул лабораторий будет расширяться)
2)Ищут предметы, воюют против мутантов, друг с другом при столкновенние
3)Должны найти выход
4)В случае смерти, игроки теряют все предметы которые были с собой.

PvP режим не включает в себя дополнительных задач - имеет изначально повышенный шанс на редкие предметы для этой лаборатории, и предназначен строго для подготовленных игроков.

Играть можно в режим SQUAD VS SQUAD, а так же SQUAD VS SOLO, если не получилось подобрать одиночного игрока для равного матча. Размер отряда не имеет значения.

DGM - PvE

Вариация PvE режима представляет с собой следующий формат:

1)Один отряд или одиночный игрок появляются в случайных местах определенной лаборатории
2)Ищут предметы, воюют против мутантов, друг с другом при столкновенние
3)Должны выполнить отдельное, генерируемое задание (Например найти документы, или убить определенное количество мутантов)
4)В случае смерти, игроки теряют все предметы которые были с собой.

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

DGM - Story

Режим «Истории» - уже включает в себя не только лаборатории, а почти любые необходимые нам локации, и будет использоваться в NET Online для реализации отдельных сложных срежисированных сюжетных сцен.

Нам пришлось прибегнуть к такому решению из-за нашего виденья:
Мы не хотим создавать локальные сервер или использовать Single Player режим по одной простой причине - такие квесты невозможно будет проходить в кооперативе. Мы хотим включить возможность прохождения не только подобных сюжетных «сессий», но и даже пролога модификации, поэтому играть вместе с друзьями можно будет с первого запуска модификации.

Запускаться такой подбор будет в строго необходимые сюжетные моменты модификации. И будет иметь разные правила по отношению к загрузке/сохранению предметов.

Зачастую, именно Story режим будет открывать доступ к повторному перепрохождению в PvP или PvE вариациях определенных лабораторий или локаций.

Возвращаемся к технической составляющей: Coordinator

Выше вы увидели пример использования системы матмейкинга для режима DGM. Как вы видите, теперь игра умеет понимать, сколько игроков готово начать игру, сколько игроков требуется, являются ли участниками отряда, и соответствуют ли они нужным критериям.

Разберём инструмент, который используется в нашей цепочке: xrCoordinator.

Задача координатора - собрать, накопить, и разослать информацию агентам о том, что N-ое количество игроков хочет получить игровой сервер.

Каждый координатор имеет в своём распоряжение собственный объём агентов, к которым он обращается для завершения цепочки. Без координатора подбор игр будет невозможен. Координатор не знает, какие сервера есть, кто ими управляет, кто на них играет. Этим занимается агент.

Возвращаемся к технической составляющей: Agent

Агент в отличие от координатора, располагается на прямой хост-машине, и знает
1)Нагрузку CPU
2)Свободную ОЗУ
3)Количество разрешенных нод для формирования сервера
4)Количество игроков и состояние игровых серверов

Агент передаёт эту информацию координатору, и тем самым, по его сигналу может сформировать необходимый сервер, и выдать информацию о нём координатору.

Возвращаемся к технической составляющей: Server Manager

Для удобного управления серверами и быстрого развёртывания на новой хост-машине, мы реализовали простенький, но очень хороший внутренний сервер-менеджер.

Данная утилита не является частью Agent или Coordinator. Она умеет лишь отправлять запросы на выполнение определенных задач. Без знания адреса до координатора и личного профиля с соответсвующим доступом на форуме, данная утилита становится бесполезной. Проверкой доступа занимается конечный Agent. Она позволяет безопасно передать доступ к определенным профилям другим разработчикам или запуску на внешнем компьютере.

Дальнейшие планы

Мы планируем полностью задействовать данную систему для всех TDM режимов, и привязать управление кластерным доступом, если игроки разрешили подбор между ними, а так же в будущем, когда появится уровни и внутриигровые ранги - уровнивать матчи игроков по эти критериям.

К слову - мы постараемся показать игровой процесс режима на ближайшем AP-PRO Showcase в этом году!

В следующем дневнике мы расскажем о переработке и улучшению оружейной составляющей, и вероятнее всего, наконец-то сообщим ДАТУ РЕЛИЗА