Автостопом по мультиплееру. Часть 4: Авторитарность и Топологии

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

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

1. Для кого и для чего

2. Синглплеер и Мультиплеер

3. Клиент и Сервер

4. -> Авторитарность и Топологии

   1. Авторитарность

   2. Топологии

      1. Клиенты + Игровой Сервер

      2. P2P

      3. P2P: Shared Mode / Distributed Authority

      4. P2P: Клиенты + Хост

      5. Смешанная

   3. Проблемы NAT

   4. Relay-сервер

   5. Выбор топологии

   6. Рекомендации

   7. Заключение

   8. Дополнительный контент

5. ...

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

Авторитарность

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

Обычно в мультиплеере понятие авторитарности применяют:

• Для управления (Input Authority): определяет, какой из клиентов является достоверным источником ввода для конкретного игрового объекта.

• Для данных (State Authority): определяет, какой узел имеет право изменять определённые игровые данные и может быть достоверным источником этих данных.

• Для создания и удаления объектов: определяет, какой узел имеет право создавать или уничтожать те или иные сетевые объекты. Для общности, будем далее считать, что это частный случай State Authority.

Эти виды авторитарности тесно связаны друг с другом. Клиент, кому принадлежит Input Authority над своим персонажем, должен отправить команду узлу, у которого есть State Authority над данными этого персонажа, чтобы обновить его данные после ввода: изменить позицию, сделать выстрел и пр.

Клиент сам может иметь State Authority над своими данными, может иметь State Authority над данными другого клиента, может иметь State Authority над частью данных игрового мира или над всеми его данными. Клиент может иметь и Input Authority, и State Authority одновременно. Может и не иметь вообще никакого Authority.

При этом границы Authority конкретного клиента могут изменяться динамически. Например, какая-то механика (типа способности "Контроля" или обработка временного дисконнекта) может на время у клиента отбирать его Input Authority и передавать другому клиенту или игровому серверу. Аналогично со State Authority.

Как правило, все игровые клиенты большую часть времени имеют Input Authority, иначе бы игра для пользователей не имела смысла. Наличие State Authority у клиента, с одной стороны, позволяет ему быстро изменять подконтрольные данные и оперативно реагировать на эти изменения, но с другой – открывает возможность изменять их несанкционированно, не "по правилам", получая преимущество над другими игроками. Поэтому, если необходимо защитить игровой процесс от мошенничества, приходится прибегать к одному из следующих решений:

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

2. Передача State Authority доверенному узлу: клиенты сами с данными ничего не делают, а только отправляют команды выделенному доверенному неангажированному узлу (таким обычно и является игровой сервер), который по полученным командам производит корректные операции над данными, а затем отсылает клиентам обновлённые значения. Это может касаться как всех данных, так и только наиболее чувствительных.

Топологии

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

1. Клиенты с выделенным игровым сервером.

2. Клиенты без выделенного игрового сервера (P2P / Peer-to-Peer).

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

Клиенты + Игровой Сервер

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

По умолчанию клиенты имеют Input Authority, а сервер — глобальный State Authority. Для разного рода оптимизаций часть State Authority может быть передана и клиентам. Обычно это Authority над данными подконтрольного персонажа. Но Authority за спаун и деспаун объектов, как правило, принадлежит серверу.