Мультиплеер своими руками. Часть 2.⁠⁠

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

Будучи еще подростком, сильно впечатлился игрой Cortex Command. Чисто случайно нашел ее на компьютере родственников, и часами сталкивал корабли словно консервные банки. Но у игры был один фатальный недостаток – принципиально нет мультиплеера. Игра представляла из себя шутер-песочницу, в которой каждый пиксель жил своей жизнью. Синхронизировать такое – невыполнимая задача для мультиплеера.

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

Игра мечты.

Конечно, хотелось сделать Игру Мечты. Чтоб с Душой. Но увы большинство задумок постигала одна и та же участь: делаешь ее по вечерам, пока интересно, потом наскучивает, и потихоньку забрасываешь, растягивая проект на многие месяцы. Или работа навалится, и просто нет времени. И в один прекрасный момент ты делаешь перерыв в недельку, а потом все. Думаю все знакомы с людьми, которые делают свои поделки долгое время. Один мой знакомый делает игру уже 5 (пять!) лет, и этому не видно конца.

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

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

Если не успеваю – в единоразовом порядке высылаю ему 50 долларов, и проект считаю проваленным. Конечно, в определенный момент меня не хватило, и я сдался. Отправил деньги как обещал, конечно. Но меня хватило на целых 6 месяцев!

Спустя время я уже был готов хоронить проект, но в одной конференции игра пришлась по нраву другому человеку (художнику), с которым мы начали думать, что делать дальше.

Что мы сделали, вы можете почитать в первом посте, а сейчас я расскажу, как сделан мультиплеер.

Онлайн.

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

Мультиплеер же состоит из трех компонентов: клиентская часть игры (графика), серверная часть игры (консоль), и онлайн (комплекс сервисов). Онлайн решает следующие задачи:

1. Авторизация (в т.ч. через соцсети)

2. Профили игроков

3. Доставка DLC

4. Внутриигровые сообщения

5. Рейтинги (лидерборды)

6. События (ежедневные задания)

7. Мачмейкинг

8. ???????

9. PROFIT!

Система была разработана с возможностью масштабирования, а также размещения игровых серверов в разных регионах мира.

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

Матчмейкинг.

Увы, об этом нигде не пишут, и то, к чему пришли получилось путем проб и ошибок. Сначала я просто запускал N игровых серверов, и они рапортовали в примитивный список о своем присутствии. Но потом стало понятно, что нужно делать систему "по требованию", в которой новый игровой сервер запускается, когда нехватает текущих.

Сам же матчмейкинг состоит из двух частей:

1. Мастер, который принимает запросы на поиск игр, отдает список комнат, а также создает новые игры, если кто хочет.

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

Так как Мастер и Контроллеры находятся на разных физических машинах, а могут и в разных регионах, то меж ними должен быть настроен VPN (OpenVPN хорошо решает эту задачу)

Пока у игрока мигает квадратик, под капотом происходят следующие вещи.

1. Клиент авторизуется в системе.

2. Клиент запрашивает у Мастер сервиса свободную комнату. Также клиент может перечислить требования к комнате. Например, определенная карта или режим игры. С точки зрения онлайна это всего лишь ключи/значения, по которым комнаты фильтруются.

3. Если свободной комнаты нет – Мастер регистрирует новую, а также выбирает самый подходящий контроллер, на котором можно разместить новый игровой сервер, который будет обслуживать саму игру. В процессе подбора участвуют следующие параметры: расстояние от игрока до контроллера (геопозиция), а также загруженность самого контроллера (% загруженности ЦП и свободная оперативная память). Таким образом, нагрузка распределяется меж нескольких машин.

4. Затем Мастер обращается к выбранному контроллеру, с просьбой запустить новый игровой сервер.

5. Контроллер, в свою очередь, запускает новый процесс игрового сервера (предоставленный самой игрой), а также передает Unix domain socket как первый аргумент командной строки. Через этот сокет происходит обмен данными между игровым сервером, и онлайном. Также, контроллер следит за стандартным выводом игрового сервера. Контроллер выделяет под игровой сервер несколько портов (сколько самой игре нужно).

6. Затем клиент "регистрируется" в комнате, предоставля свой токен доступа. Последний всегда держится в секрете, получив который, можно делать все что угодно от имени игрока. Чтобы избежать этого, токен не передается игровому серверу напрямую. В ответ на регистрацию клиент получает короткий ключ комнаты, который является разрешением к подключению к игровому серверу, а также адрес (и порты) конкретного игрового сервера.

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

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

9. Таким образом, игроку гарантируется место в комнате, а также исключается передача ключа доступа игрока по незащищенному каналу между клиентом и игровым сервером.

В целом, всю систему можно представить следующим образом:

Также, для обеспечения стабильности контроллер периодически опрашивает игровой сервер, работает ли он. Кроме того, мастер опрашивает все контроллеры. Если контроллер не отвечает – все комнаты, которые числятся за этим контроллером временно пропадают из списка. Если контроллер перегружен – запросы на создание комнаты к нему перестают приходить, и клиент получает ошибку "503 Service Unavailable".

Синхронизация.

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

Тут можно выделить следующее:

1. При подключении на сервер, сервер делает полный дамп карты со всеми блоками и игроками, сериализует их, и отправляет клиенту. Таким образом, клиент получает то, что происходило в момент подключения.

2. Дальше при создании/удалении объектов клиент получает соотв. уведомление.

3. Когда игрок стреляет, клиент производит выстрелы моментально, параллельно сообщая серверу о произведенных выстрелах. Сервер валидирует эти данные (позиция, есть у и игрока патроны), а затем запускает эти выстрелы у себя. Также, он сообщает о выстрелах всем игрокам, кроме стрелявшего. При попаданиях весь урон наносится исключительно на сервере.

Перемещение игроков стоит выделить в отдельную категорию:

1. На клиенте висит объект-наблюдатель, который держит несколько триггеров по разным критериям. Например, триггер на скорость, триггер на перемещение, триггер на поворот пушки или триггер на контакт с землей.

2. При срабатывании триггера слепок игрока (позиция, скорость, поворот) отправляется на сервер.

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

4. Тот, в свою очередь, постепенно доводит параметры игрока к требуемым (поправляет позицию, скорость и тд)

5. Как и в пункте 1, на том же объекте клиента, но на серверной стороне, висит объект наблюдатель. Но в этот раз при срабатывании триггеров, слепок отправляется всем клиентам, кроме игрока.

6. Все клиенты доводят состояния других клиентов к желаемым согласно слепкам.

P.S. Благодарим пользователей Пикабу за поддержку на Steam Greenlight. С вашей помощью мы попали в топ 20 лучших проектов! Спасибо вам!