В онлайн-играх есть проблемы, о которых не стоит беспокоиться одиночным играм или играм с локальной сетью, например, дрожание, обмен данными (RTT) или потеря пакетов.

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

Для успешного решения проблем задержки нужно учитывать приоритетность и взаимосвязь между следующими элементами:

1. Безопасность

2. Реактивность

3. Точность и последовательность

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

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

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

• Полномочия сервера: Более безопасно, менее реактивно, без проблем с синхронизацией.
• Авторизация клиента: Меньше безопасности, больше реакции, возможны проблемы синхронизации.

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

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

Если в логике клиента указано, что эти импы нельзя убить на расстоянии более 10 метров, но сообщение «kill imp» — это серверный RPC, который не проверяет расстояние на стороне сервера, то игроки могут подделать это сетевое сообщение, чтобы обойти логику на стороне клиента.

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

Серверная авторитетная игра имеет все окончательные игровые решения, выполняемые сервером.

Безопасность ✅

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

Последовательность ✅

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

Реактивность 🚫

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

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

Реактивность ✅

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

Последовательность 🚫

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

Безопасность 🚫

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

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

Хороший пример — участие пользователей. Поскольку входные данные уже принадлежат пользователям (я владею нажатой клавишей, сервер не может сказать мне «нет, вы не нажали клавишу W»), пользовательские вводные данные могут легко управляться клиентом.

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

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

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

Затем клиент может обнаружить расхождения и скорректировать свое положение в соответствии с авторитетным положением сервера.

Примечание: На данный момент этот метод не полностью поддерживается Netcode for GameObjects.

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

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

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

Перемотка сервера — это проверка безопасности функции, управляемой клиентом, чтобы мы не потеряли авторитетность сервера.

Клиент отправляет вместе с вводом сообщение серверу «Я достиг цели в момент t». Сервер при получении t+RTT/2 перемотает симуляцию в момент t-RTT, подтвердит кадр и исправит мир в самое позднее время (то есть убьет цель). Это позволяет игроку чувствовать себя однородным, сохраняя безопасность и авторитет сервера.

Примечание. Серверная перемотка состояния игры выполняется в одном кадре, и это незаметно для игроков. Это проверка на стороне сервера, которая позволяет подтвердить действия клиента.

Примечание: На данный момент этот метод не полностью поддерживается Netcode for GameObjects.

Создание Multiplayer игры — непростое, но и увлекательное дело. Независимо от того, создаете ли вы новый хит Battle Royale Smash или уютную кооперативную игру, понимание нюансов задержки и способов управления ею крайне важно.

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