Автостопом по мультиплееру. Часть 3: Клиент и Сервер

Это третья статья путеводителя по разработке мультиплеерных игр. В прошлой части были рассмотрены отличия синглплеерных игр от мультиплеерных и их различные классификации, среди которых был обозначен вектор дальнейшего повествования — сетевой мультиплеер. В этой части продолжится погружение в обозначенном направлении. Гостями этого выпуска будут понятия "клиент" и "сервер" — кем они друг другу приходятся и какими бывают.

Следить за выходом новых статей и другого контента можно в моём блоге на VK / Telegram / Dtf.

В сильно общем смысле:

Какие могут быть функции:
• хранение данных;
• обработка запросов;
• управление сетевыми ресурсами;
• и пр.

В зависимости от своих функций серверы могут быть разных типов:
• файловые серверы;
• веб-серверы;
• DNS-серверы;
• почтовые серверы;
• и пр.

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

"Агрегатные состояния" сервера:
• отдельный компьютер, настроенный на выполнение своих функций;
• виртуальная машина, эмулирующая отдельный компьютер;
• контейнер, выполняющий серверные функции;
• серверное приложение, запущенное на настроенном для этого компьютере.

В моей практике в геймдеве чаще всего в качестве "серверов" используют серверные приложения в виде исполняемых файлов или docker-контейнеров, в зависимости от конфигурации окружения, в котором планируется их запускать. Это, в частности, позволяет запускать такие сервера на локальном компьютере для проведения локальных тестов.

В геймдеве есть и набор наиболее часто используемых типов серверов.

Самый распространённый вид сервера. Многие игры вовсе ограничиваются только им. А какие-то и не используют совсем.

Основная функция: координация между другими серверами и сервисами с конкретными ответственностями.

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

Возможные функции мета-сервера:
• авторизация игроков;
• распределение игроков по прочим серверам и сервисам;
• взаимодействие с мастер-сервером;
• взаимодействие с профиль-сервером;
• поиск игроков для совместной игры;
• обработка игровых событий;
• валидация действий игроков;
• обработка платежей;
• и пр.

Грубо говоря, это прослойка для работы с внешней базой данных или же сама база данных. В качестве базы данных может выступать какая-нибудь СУБД, сервис хранения данных или кастомное решение, построенное хоть на беспорядочной записи всего подряд в один файл.

Функции профиль-сервера:
• безопасное хранение пользовательских и игровых данных;
• синхронизация пользовательских данных между сессиями и между различными устройствами игроков, позволяя им продолжать играть с того места, где они остановились, независимо от используемого устройства.

Варианты реализации:
• отдельный сервер или сервис, с которым общаются через мета-сервер;
• отдельный сервер или сервис, с которым общаются клиенты напрямую (если нет мета-сервера);
• ответственность мета-сервера непосредственно.

Если предыдущие типы серверов были достаточно общими и не имели прямого отношения к мультиплееру, то этот имеет отношение самое непосредственное.

Задачи игрового сервера:
• возможность нескольким игрокам одновременно участвовать в одной игровой сессии;
• обмен информацией между игроками о своих действиях и своём состоянии;
• управление состоянием игрового мира, не контролируемого игроками;
• предоставление выделенного доверенного безопасного узла, который будет поддерживать честный геймплей и обеспечивать защиту от читеров.

Функции игрового сервера:
• обработка данных, полученных от клиентов;
• передача полученных данных другим игрокам;
• обеспечение синхронизации игрового процесса;
• управление логикой игрового процесса;
• обеспечение защиты от мошенничества;
• управления правами доступа игроков;
• хранение состояния игры;
• ведение статистики;
• и пр.

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

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

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

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

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

Функции мастер-сервера:
• получение от активных игровых серверов специальных сигналов с информацией — heartbeat;
• формирование и хранение списков активных серверов по различным параметрам: режимы, карты, модификации и пр;
• мониторинг игровых серверов, отслеживание их заполненности и доступности;
• выдача списка доступных серверов по запросу клиентам или мета-серверу;
• создание и запуск новых игровых серверов.

Варианты реализации:
• отдельный сервер или сервис, с которым общаются через мета-сервер;
• отдельный сервер или сервис, с которым общаются клиенты напрямую (если нет мета-сервера);
• ответственность мета-сервера непосредственно.

Основные функции клиента (в контексте мультиплеера):
• получение ввода от пользователя;
• обработка полученных данных;
• передача данных серверу и/или другим клиентам;
• получение и обработка ответов от сервера и/или других клиентов;
• рендеринг игрового процесса на основе актуальных игровых данных.

В некотором общем смысле, если использовать термины MVP:

В синглплеерных режимах/играх вся тройка MVP находится на одном узле – на клиенте.

Почему именно модель уходит на сервер:

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

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

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

Для компенсации задержек используется масса всяких приёмов (подробнее – в следующих статьях). Из-за этого в реальности описанные выше MVP-границы разделения ответственностей часто размываются:

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

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

Если какой-то элемент игры не влияет на геймплей, то не страшно, если у каких-то игроков его состояние не синхронизируется вовремя и корректно.

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

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

Достоинства:
✅ Можно выбрать любую любимую технологию с набором любимых библиотек, не зависимо от того, в каком движке разрабатывается игра. Подойдут любые языки программирования, предоставляющие возможность писать серверные приложения: Python, Java, .NET, Node.js, PHP и др.
✅ Это легковесное решение, т.к. серверное приложение будет содержать только необходимые зависимости, заложенные разработчиком и самой технологией.
✅ Можно использовать готовый шаблон, готовый фреймворк или реализовать сервер полностью своими силами, что позволит контролировать максимум аспектов работы приложения.
✅ Есть возможность реализовать специфичные сценарии работы. Например, реализацию поддержки нескольких игровых сессий параллельно.

Недостатки:
❌ Реализация сервера потребует дополнительного времени на разработку и дальнейшую поддержку. А также дополнительной экспертизы в выбранной технологии.
❌ Может возникнуть дублирование кодовой базы, т.к. обычно в мультиплеерных играх есть слой общей логики и общих данных, которые должны быть использованы на сервере и на клиенте. Если сервер и клиент написаны с использованием разных языков и несогласующихся технологий, то может появиться потребность дублировать часть кодовой базы для клиента и сервера.
❌ От написанного сервера будет сложно отказаться, если потребуется в будущем изменить "топологию подключения" и перейти на вариант без сервера. Про то, какие варианты есть, будет написано в будущих статьях.

Проблему общих зависимостей и их дублирования в контексте Unity решают следующим образом:
• Клиентская кодовая база в Unity написана на C#.
• Для реализации сервера используют .NET Core на C#.
• Общие зависимости выделяют в отдельную сборку или отдельный C#-проект.
• Клиентский и серверный проект подключают к себе модуль с общими зависимостями или используют собранные dll с ними.

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

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

Если нужен игровой сервер для синхронной игры, то удобнее будет использовать другой способ реализации сервера.

Подобный способ реализации предоставляют практически все Netcode-библиотеки для Unity. Работая в Unity-проекте идёт работа как над клиентской логикой, так и над серверной. В зависимости от стиля работы это может быть как сгруппировано в отдельные модули внутри проекта, так и не иметь строго разделения. Тогда используют конструкции ветвления внутри логики для определения текущей стороны исполнения и запуска соответствующих сценариев работы.

Достоинства:
✅ Вместо двух-трёх проектов — один, что в каком-то смысле упрощает разработку.
✅ Проблема дублирования логики и общих зависимостей решается сама собой, т.к. всё необходимое всем сторонам исполнения уже находится в одном проекте.
✅ От сервера достаточно просто отказаться. Серверная логика уже написана на нужном языке и находится в целевом проекте – достаточно адаптировать её и включить в клиентские сценарии.

Недостатки:
❌ Сервер – полноценная игра на клиентском движке. Т.е. помимо серверного кода от CoreGame туда уйдёт, как минимум, сам движок с его зависимостями и, как максимум, вся остальная игра с MetaGame и прочим.
❌ Чтобы лишние зависимости не уходили на сервер, нужно постоянно заниматься их контролем и организовывать проект так, чтобы на этапе сборки всё лишнее имело возможность не попадать в билд.
❌ Клиент и сервер обычно имеют разные конфигурации для итоговой сборки, особенно в контексте CI/CD, поэтому нужно реализовывать и поддерживать разные сценарии сборки.
❌ Если используется готовая Netcode-библиотека, то один сервер будет обслуживать только одну игровую сессию. Чем больше параллельных сессий, тем больше серверов нужно включать.

Чем чревато утекание лишних зависимостей на сервер:

Аналогично серверные зависимости также могут "протекать" на клиент и вызывать схожие проблемы.

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

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

На этом тема серверов и клиентов не заканчивается. Это только необходимая для дальнейшего продвижения информация. В этой статье уже стало сложно поддерживать линейное повествование. Чтобы не уходить в "другие стороны", было добавлено много отсылок на будущие публикации. Для целостности буду стараться в каждой работе придерживаться одной обозначенной темы.

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

• Bare Metal vs Virtual Machines vs Containers: dev.to
• MasterServer: How it works: 333Networks
• What is a Game Server and How Does it Work: ServerMania
• Архитектура мета-сервера у Tacticool: Habr.Pixonic
• Инфраструктура серверов War Robots: Habr.Pixonic
• Fast paced шутер: технологии и подходы: Habr.Pixonic
• Вторые полгода разработки нового мобильного PvP: Habr.Pixonic

————————————————————

#client #статья #геймдев #разработка #мультиплеер #сервер #клиент #aks2dio